За чем следить в проекте ​

Основное использование альф (примерные отношения которых показаны в системной схеме проекта или даже предприятия) --- в качестве чеклиста (checklist, список контрольных вопросов), заставляющего подумать о том, о чём можно забыть подумать.

Когда самолёты стали слишком большими для управления одним человеком, они часто взрывались на взлёте из-за банальных ошибок: то с ручного тормоза не снимут, то забудут проверить работу всех многочисленных двигателей перед взлётом. Помогло введение чеклиста: чеклист заставлял подумать и проверить то, что в спокойной обстановке все знают, что нужно делать, но в суматохе взлёта иногда забывают действительно сделать, и это ведёт к фатальным неприятностям^[1].

Системная схема проекта представляет собой ровно такой чеклист: на верхнем уровне это альфы, которые необходимо удерживать во внимании всё время проекта. Если члены команды не задумывались о состоянии какой-то из альф, то возникают большие риски, что там что-то может пойти не так --- просто потому, что не хватило внимания. Проект создания системы обычно не менее сложен и хлопотен, чем взлёт самолёта, поэтому можно ожидать отсутствия самых понятных и простых работ --- например, можно в суете проекта забыть наладить коммуникацию с исполнителями внешних проектных ролей и просто фантазировать вместо выяснения ситуации по поводу потребностей и надсистемы, или забыть провести испытания в рамках инженерных обоснований, или забыть учесть какие-то архитектурные решения. Коллективная собранность в проекте должна быть как-то организована:

• Важные объекты внимания, которые меняются в ходе проекта --- это альфы. Понимаем, какими рабочими продуктами реализуются альфы и не забываем их отслеживать.
• «Не забываем» реализуем через использование компьютерной памяти, а также привычку регулярно просматривать содержимое этой памяти.
• Ключевым является даже не само состояние альфы --- а подумали или не подумали о её состоянии (ибо если подумали, то шанс что-то исправить есть, а если не подумали --- «всё, что может пойти не так, обязательно пойдёт не так»).

Контрольные точки/milestones достижения состояний каждой альфы в графе изменения её состояний формулируются как вопросы чеклиста, положительный ответ на которые означает достижение этой контрольной точки. Скажем, в альфе «работа» области интересов организации проекта состояние «инициирована» имеет первым же подпунктом «требуемый результат работ ясен». Вы можете считать контрольной точкой достижение состояния «инициирована» к какой-то дате и все подпункты там просто контрольными вопросами достижения этого состояния, а можете эти критерии тоже считать контрольными точками, достижение которых возможно в разные моменты времени для каждого. Это ваш выбор, какой дробности моделирование вы делаете. Моделирование альф и их состояний, контрольных точек по достижению этих состояний гибкое, оно не жёстко предопределено.

При этом результат работ сам себя не прояснит: для прохождения контрольных точек надо задействовать какую-то практику (или довольно много практик, выполняемых самыми разными ролями), чтобы достичь определяемого ей состояния --- к назначенной дате, раньше её или позже. Взгляд на контрольные точки неминуемо порождает обсуждение методов достижения состояний альф, а затем обсуждение ресурсов для ведения этих работ по всплывшим в обсуждении практикам. Мысль должна бежать так (приведём простой пример, но это общее рассуждение, при этом все соседние рассуждения по похожим последовательностям откидываем для простоты):

• Тишина в комнате совещаний::альфа
• Внешний шум отсечён::состояние альфы «тишина в комнате совещаний»
• Внешний шум отсечён к началу совещания (ожидается в 16 часов)::контрольная точка (сделана из состояния альфы и ожидаемого времени достижения)
• Дверь закрыта:: контрольный вопрос к состоянию альфы шум убран.
• Окна закрыты:: контрольный вопрос к состоянию альфы шум убран
• Дверь закрыта к началу совещания (ожидается в 16 часов)::контрольная точка/milestone (делается из контрольного вопроса для проверки состояния двери и указания ожидаемого времени достижения)
• Окна закрыты к началу совещания (ожидается в 16 часов)::контрольная точка/milestone (делается из контрольного вопроса по проверке состояния окон и указания ожидаемого времени достижения)
• Мобильники участников переведены в режим «без звука»::вопрос к состоянию альфы
• «Закрытие двери»::работа проводится «секретарём совещания»::оргзвено (варианты: «ближайшим к двери участником совещания»::оргзвено, установка автодоводчика на дверь и далее «автоматическое закрытие двери» проводится автодоводчиком::оборудование, но требует дополнительной работы по установке автодоводчика)
• Закрытие двери заносится в issue tracker и назначается на секретаря совещания (и дальше выполнение этой работы проверяется «как обычно» --- эта работа не потеряется, она тоже оказывается записанной).

Беда в том, что вот этих многочисленных действий/работ для достижения нужных состояний, непрерывно сползающих к предыдущим состояниям «неготовности» (жизнь меняется, и нужно всё время развивать систему), накапливается много. Это одна из причин, почему прикладные инженеры не любят такой issue tracker как Trello, а также не любят всякие «канбан-доски на стикерах». «Менеджеры», наоборот, их обожают: «всё наглядно», каждая работа выглядит как «карточка работы», и продвижение проекта хорошо показывается как «продвижение карточек». Но менеджер считает, что 200-300 работ на контроле --- это очень много, а в даже небольшой командной разработке за несколько месяцев легко набегает 2-3 тысячи issues, которые нужно отслеживать. Программисты и инженеры с этим справляются, а вот менеджеры теряются. Как решить эту проблему? Нужно понимать, кто такие «менеджеры» по их ролям и зачем им нужно знать все работы. Обычно современные issue trackers позволяют делать иерархию issues, а операционным менеджерам показывать только верхнеуровневые кейсы, их не так много, и большинство issue trackers позволяют их красиво изобразить карточками на экране. Это, конечно, похоже на первые автомобили --- их делали в форме кареты, и даже называли «самобеглые повозки».

В нашем примере нужно ещё заметить, что альфы --- это предметы кейсов. Нарезка на кейсы и подкейсы тут существенно зависит от того, как вы думаете о мире. Скажем, «тихая комната» против «тишины в комнате», состояние «внутренние и внешние шумы отсутствуют», альтернативные решения по тишине путём изменения постановки задачи (перенос совещания из физической комнаты в онлайн, далее мьют всех микрофонов, кроме микрофона докладчика, или даже чат вместо проведения совещания --- и тогда проблемы с тишиной не возникает, и т.д.). Мир можно делить на части очень разными способами, а ещё с этими частями работать потом очень разными способами, и некоторые из этих способов работы подразумевают другой мир, который мы тоже как-то можем получить --- тоже работами по каким-то практикам, но это будут другие работы по другим практикам. То, что вы работаете с альфами и кейсами и думаете о них одинаково, никак не закрывает огромной сложности и многообразия мира. Думать можно одинаково о самых разных вещах, это немного экономит время. Но творчество никуда не девается!

Все эти даты в контрольных точках --- это только ожидания, но очень полезно оценивать время достижения этих состояний, а если время трудно оценивается --- бить дальше систему на такие версии или инкременты, или выделять такие фичи, чтобы время прохождения контрольных точек можно было оценить. Понятно, что прохождение состояний вышестоящих альф плохо прогнозируется во времени, а вот с подальфами это проще. Поэтому дробим альфы на подальфы.

Граф прохождения состояний альф --- это совсем необязательно линейная последовательность этих состояний. В приведённых в предыдущих разделах примерах даны простейшие случаи как именно последовательности состояний, но в общем случае там граф состояний с циклами и ветвлениями. К тому же сама альфа или подальфа (подальфа тоже альфа!) может относиться только к одной версии или инкременту системы, к одной фиче, но могут быть и альфы, которые меняют своё состояние постепенно по мере выпуска самых разных версий системы (скажем, достижение какой-то желаемой архитектурной характеристики может достигаться в ходе выпуска пяти версий системы --- и состояние альфы архитектуры должно отслеживаться сквозным образом для разных версий системы, а вот состояние альфы какой-то фичи --- как при однократном прохождении V-диаграммы, разве что не «водопадно», но только для этой небольшой фичи, ибо для большой фичи тоже может потребоваться много попыток реализации).

Ещё часты случаи, когда одна альфа будет подальфой нескольких других альф, сами альфы представляют собой не дерево, а граф. Да и отношение там, помним, не «часть-целое», а «подальфа --- это что-то, что при продвижении по своим состояниям как-то двигает свою вышестоящую альфу».

Вот ещё пример: контрольная точка для альфы организации/команды/коллектива/предприятия --- «сотрудничает» формулируется как пункт чеклиста, который читается тоже как чеклист: «команда работает как одно сплочённое оргзвено; общение в команде открытое и честное; команда сфокусирована на достижение миссии/задания команды; члены команды знают друг друга и сотрудничают.». Это чеклист в чеклисте, и их легко набирается четыре уровня:

1. Область интересов системы создателя целевой (а есть ещё в графе создания и создатели других систем, например, клиентуры),

1.1. Альфа команда (ещё есть альфы описания команды, работы команды, могут быть и другие)

1.1.3. Состояние альфы «Сотрудничает» (это третье состояние в ряду «намечена, сформирована, сотрудничает, производит, распущена», поэтому 1.1.3),

1.1.3.2. Контрольный вопрос про «общение в команде открытое и честное» (он второй в списке).

Достижение этой контрольной точки 1.1.3 требует практики лидерства. Достижение этого состояния из контрольного вопроса 1.1.3.2. требует подумать о способах получить честное и открытое общение --- и это приводит к мысли о какой-то подпрактике лидерства, надо будет выбрать конкретный вариант достижения этого состояния через какие-то работы по какой-то практике (желательно из учебника, а не сочинённой самостоятельно). Думать нужно так: «дисциплину из какого учебника лидерства будем применять для достижения этой контрольной точки»? «Инструменты какого поставщика будем применять для поддержки лидерства?», ибо в 21 веке ведь даже лидерство поддерживается инструментально!

Затем нужно будет провести работы (понять, кто и когда будет проводить эти работы по выбранной практике лидерства --- запланировать работы, а потом выделить время и другие ресурсы, и провести эти работы --- выполнение работ) для выбранной практики лидерства. И так с каждой контрольной точкой, по каждому вопросу чеклиста.

Конечно, этих вопросов оказывается множество! Следуем следующим правилам:

• Помним, что так и должно быть. Человеческая деятельность сложна. Просто нужно думать о каждом деле по отдельности, а не обо всём сразу. Обо всём сразу невозможно. Но вопросов и впрямь много, даже в маленьких проектах.
• Записываем, особенно самое главное (принцип чеклиста: не пишем всех мелочей и нюансов из того, что известно из учебников, но пишем самое главное, что неплохо бы проверить --- ибо без этого проект провалится). И не забываем проверять записанное, возвращаться к нему снова и снова. Мозгу не верим (хотя спецы могут хорошо помнить все эти нюансы из учебников разных практик, их необязательно писать --- но вот что требует хоть какого-то коллективного действия или существенно может повлиять на успех, то непременно пишем. Помним книжку «Манифест чеклиста» от Atul Gawande).
• В команде довольно много людей, все они имеют свои версии чеклистов --- совсем необязательно одному человеку и разрабатывать эти чеклисты, и работать с ними. Нет, огромное количество этих вопросов делится по людям. Другое дело, что записанные (чаще всего в issue trackers или даже в универсальных моделерах, которые потом связываются с issue trackers для управления получившимися работами) чеклисты довольно легко потом обсуждать при делёжке работ проекта между его исполнителями. Поэтому не забываем писать и практики, и роли, и исполнителей этих ролей.

Если команда не обсуждает достижение всех этих контрольных точек и не выполняет работы по их достижению, то у проекта могут быть большие (в том числе фатальные для проекта) неприятности от непродуманности, «просто забыли подумать, и поэтому забыли сделать».

Формулировки контрольных точек и в самом стандарте OMG Essence (и, соответственно, в нашем курсе) намеренно «мутные», неопределённые и расплывчатые. Авторы стандарта говорят, что эта «мутность» поощряет команду провести обсуждение этих контрольных точек, чтобы адаптировать формулировки к индивидуальным особенностям проекта, и получить явное соглашение команды о том, что все члены команды одинаково понимают эти контрольные точки.

Для учёта обстоятельств проекта необходимаадаптация/изменение всех приведённых в нашем курсе примеров:областей интереса, числа и имён альф, числа и имён состояний, формулировок контрольных вопросов по достижению отдельных состояний. Адаптация проводится так, чтобы учесть мета-модели предметных областей проекта («как в учебнике» и «как на предприятии»), ненужно использовать прямые формулировки из нашего курса! Без адаптации к конкретным предметным областям проекта и уровню опыта конкретной команды чеклисты альф «прямо из курса методологии» и тем более «прямо из стандарта OMG Essence» использовать нельзя!

Тексты из курса тут дают только типы мета-мета-модели, они нужны как средства наведения внимания команды на объекты в их предметной области! Команда должна договориться, за чем следить в проекте, кто в проекте берёт на себя ответственность за продвижение состояний какой альфы --- и иметь для этого понятные ей формулировки. Эти альфы (и их подальфы) становятся затем предметами кейсов, и в курсе системного менеджмента рассказывается, как на их основании строить различные модели оргзвеньев (рабочей группы проекта или предприятия) в универсальных моделерах типа coda.io или notion.so.

Основных альф в цепочках создания как объектов внимания в проекте не будет хватать, слишком маленькое разрешение, нужно видеть в проекте больше деталей. Поэтому увеличиваем разрешающую способность нашего внимания: уделяем внимание не только альфам, но и подальфам. Команда берёт эти подальфы из дисциплин/теорий/принципов принятых ей практик, и опять-таки делает из них предметы кейсов::работ: если есть объект внимания, имеющий какие-то состояния, то должны быть практики/методы, которые двигают этот объект внимания от состояния к состоянию, а чтобы это всё и впрямь случилось, надо выполнить по этим практикам какие-то работы.

Например, в практике управления проектами методом критической цепи вводят альфу «буфер проекта» (project buffer) и отслеживают затем её состояние --- сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Альфа «буфер проекта» может быть подальфой «работы организации проекта». Ответ на вопрос «в каком состоянии работы проекта?» может включать в себя отдельный рассказ про состояние «буфера проекта». Вот именно поэтому подальфа определяется не через отношение часть-целое, онтологически «буфер проекта» уж точно не часть «работы» (онтологически буфер проекта --- это описание работы, хотя можно трактовать и так, что это «потенциальная работа». В любом случае, трудно представить «буфер» истинной частью «работ». А вот как подальфа --- да, это удобно).

В разговоре про альфы необязательно каждый раз произносить слово«альфа». Как не говорят «система самолёт», «система чайник»(но добавляют слово «система», когда хотят подчеркнуть рассмотрение как системы), так в проекте не говорят «альфа работа»и «альфа команда», но говорят «работа» и«команда» (а слово «альфа» добавляют, только когда хотят подчеркнуть именно работу с альфой как типом, ролевым объектом).Но машинка типов у вас всё время должна в мозгу работать: вы должны отслеживать упоминание альф и подальф!

Мы предлагаем использовать практику адаптации системной схемы проекта: считать, что всё это проекты по изменению мира (инженерные), думать о всех этих проектах по-инженерному (те же типы мета-мета-модели, что и в нашем курсе для области интересов инженерии), но использовать приемлемую для целевых предметных областей терминологию в именовании многочисленных подальф (типы мета-модели). Общий рецепт: думайте одинаково (отмечайте типы мета-мета-модели задействованных в самых разных проектах объектов, находите объекты пропущенных в мышлении и действии типов объектов --- но только «в голове», не произносите терминов мета-мета-модели), но в общении с сотрудниками не говорите и не пишите типов мета-мета-модели, заменяйте их типами мета-модели. Если у вас в голове «целевая система» как альфа, которую вы отслеживаете, в речи не говорите ни слова «альфа», ни слова «целевая система», а говорите тип системы, взятый в предметной области: самолёт, мастерство, игровой сеанс. Но вы обязаны делать это осознанно: если произнесли «самолёт», то должны понимать, что это целевая система, имеется ввиду воплощение системы, оно проходит самые разные состояния по ходу проекта, но главное из них --- это во время использования, то есть когда самолёт летит. Сотрудникам необязательно знать, как вы думаете, но им обязательно надо знать результаты вашего мышления. Вот эти результаты и говорите на языке мета-модели, не произносите слов мета-мета-модели. Конечно, если сотрудники прошли наши курсы, разговор с ними пойдёт много быстрее и легче (мышление в терминах мета-мета-модели универсальней и компактней), но если они не прошли наши курсы, разговор с задействованием терминов мета-мета-модели пойдёт в разы медленней, вас будут не понимать и считать странным. Умным, а не странным, вас будут считать за высказывание результатов мышления на языке мета-модели, то есть принятом в предметных областях вашего проекта языке (метаУ-модель) или даже принятом на вашем предприятии языке (метаС-модель). А типизацию этой модели типами из курсов моделирования и собранности, системного мышления, методологии, системной инженерии и менеджмента оставьте при себе.

Заметим, что для инженерии есть множество предметных областей, и язык разговора о каждой из них будет разным. Прикладные инженеры целевой системы будут абсолютно разными, например, в биоинженерии может не оказаться «разработчика» и «архитектора».

Менеджмент более-менее одинаков, с точностью до разницы терминологии той или иной школы менеджмента. Хотя многим сотрудникам будут знакомы типы объектов из нашего курса менеджмента, будьте внимательны: они могут эти типы определять совсем не так, как определяете их вы на основе материалов наших курсов. «Операционный менеджмент» примерно один и тот же в инженерии, медицине, торговле, образовании. Но ваши сотрудники могут даже не знать, что они занимаются управлением кейсами, хотя полдня будут проводить с issue tracker. Поэтому каждый раз уточняйте язык, на котором идёт разговор с сотрудниками: правильно будет говорить на языке метаС-модели, а если вы хотите поменять эту модель --- обсуждайте это на языке метаУ-модели, мета-мета-модель из курсов интеллект-стека держите у себя в голове и говорите на этом «птичьем языке» только с сотрудниками, которые этот язык мета-мета-модели уже хорошо понимают. Помним о метанойе: то, что для вас кажется естественным, вы когда выучили и у вас даже когда-то были трудности в обучении. У других людей так же.