Альфа метода/способа/культуры работы

По большому счёту, содержание следующего после руководства по методологии руководства по системной инженерии — это весьма обобщённое/абстрактное изложение методов создания и развития (инженерных процессов, процессов разработки) самых разных систем и указание типовых ролей для этих методов. Руководство по системному менеджменту — это тоже довольно абстрактное изложение метода создания и развития организационных систем. Руководство по инженерии личности — это описание метода инженерии личности в целом и отдельного мастерства, то есть описание «инженерного процесса» для учебных проектов. Наставления всех этих руководств инженерной серии, по большому счёту, должны лечь в основу чеклиста для альфы метода/способа/культуры работы. Эту альфу можно назвать и альфой инженерного процесса, и альфой метода разработки — помним, что это всё общее название для общего метода, которым идёт создание и развитие целевой системы.

Руководство по методологии посвящено в том числе и методам описания методов. Так что моделирование метода работы путём определения альф, их состояний, контрольных вопросов, которые удостоверяют достижение состояний как прохождение контрольных событий/вех/milestones — это и есть один из методов описания метода. Конечно, это самый простой способ моделирования такого сложного объекта, как «метод» — и помним про то, что регламент/инструкция/«корпоративный стандарт» тоже может считаться моделью, а в первом разделе нашего руководства мы говорили о том, что простейшие пошаговые «процедуры», «стеки» и прочие простейшие модели в сложных случаях неприменимы, но таки лучше, чем вообще отсутствие явных описаний.

Так что дадим пример состояний альфы «метод создания и развития системы»/«метод разработки»/«инженерный процесс» и контрольных вопросов для этих состояний. Прототипом для этого набора состояний возьмём альфу way of working из примера основных альф OMG Essence. Итак, альфа инженерного процесса могла бы иметь следующие состояния (акцент тут делается не просто на постановку метода, но на реализацию оргвозможности — чеклист проверит, что в конечном итоге люди действительно задействуют метод, а не работают «уж как получается»):

• Правила установлены (principlesestablished*)**😗 команда активно поддерживает дисциплину/теорию/правила/принципы инженерного процесса; внешние проектные роли согласны с принципами; потребные для их поддержки инструменты/оборудование согласованы; рекомендации по выбранному варианту инженерного процесса доступны; рабочий контекст понимается; ограничения методов и выбранных для их выполнения инструментов известны.
• Основа**положена (foundationestablished*)😗 ключевые методы работы инженерного процесса и их инструменты выбраны; методы, необходимые для того, чтобы начать работу, согласованы; методы, по которым не будет обсуждений и их инструментарий выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; инженерный процесс, в котором все его методы удобно использовать, определён.
• Используется (inuse*)😗 методы работы и их инструментарий используются; использование методов работы регулярно проверяется; методы адаптированы к обстоятельствам проекта; методы поддерживаются командой; механизмы получения откликов/feedback на методы работы работают; методы работы поддерживаются общением команды, команда сотрудничает в выполнении практик.
• Наличествует (inplace*)**😗 инженерный процесс используется всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.
• Работает хорошо (workingwell*):*альфы проекта предсказуемо продвигаются по состояниям; методы применяются естественным образом без дополнительного обучения; инструменты естественным образом без дополнительной настройки поддерживают инженерный процесс работы; идёт постоянное совершенствование.
• Вышел из употребления (retired): инженерный процесс и его методы работы больше не используются; уроки использования практик метода опубликованы для использования в будущих проектах.

Руководство по методологии как раз разъясняет, как работать с описаниями методов и инженерным процессом в целом, а руководства инженерной серии дают развёрнутые описания вариантов методов для разных систем и указывают литературу, где можно найти ещё больше вариантов. Поэтому мы намеренно не будем тут подробно рассказывать про альфу инженерного процесса или даже её подальфу для какого-то прикладного метода. Сами попробуйте адаптировать чеклист альфы к своему проекту — выберите синонимы для метода и составляющих его методов, подберите подальфы. И помним: минимальный комплект действий по постановке метода (для оргвозможности надо ещё, чтобы метод можно было задействовать при работе) — это описание-регламент, шаблон чеклиста (примеры альф и их состояний как раз удобны для этого), чеклист для отметок при каждом прохождении метода в операционном софте, первый проход по методу с работником «за ручку» (обучение и заодно отладка возможных ошибок), установка надзора за выполнением метода и заполнением чеклиста.

Мы не приводим тут вариантов альфы функции системы как метода работы «не очень живой» системы, ибо в каждой предметной области приняты очень разные способы моделирования функциональности системы, подробней мы это обсуждали в первом разделе. Если вы считаете полезным, то вы можете попробовать сделать такой чеклист самостоятельно — но предупреждаем, что это может оказаться более трудным, чем вы это себе представляете. У вас должна быть как минимум квалификация методолога для той прикладной предметной области, к которой относится система, методы/функции работы которой вы будете описывать.