Состояния альфы и артефакты/рабочие продукты

Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на состояние связанных с ними артефактов/рабочих продуктов. С альфами происходит мышление, с рабочими продуктами/артефактами (в том числе с документацией, но и с воплощением системы непосредственно, а также с инструментами поддержки дисциплин самых разных методов) происходит работа по изменению рабочих продуктов. Конечно, для описания (view для согласования каких-то предметов интереса, то есть набор разных моделей) состояния альфы должен быть использован какой-то метод описания/viewpoint: мета-модель предметной области проекта (не наша мета-мета-модель из руководства, она только помогает вам найти эти альфы в проекте, а метаУ-модель «из учебника предметной области» или «метаС-модель», как она понимается в ситуации конкретного проекта) и принципы создания модели, методические указания по моделированию «предмета интереса»/concern.

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

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

Документирование по сравнению с чисто устной работой «с голоса» имеет:

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

Порог сложности, когда от «разработки проговариванием» и «мышления проговариванием» надо переходить к полноценному документированию проекта и «мышлению моделированием», оказывается очень низким. Поэтому смело говорим: «не пишешь**—** не думаешь!».

Люди забывчивы и невнимательны больше, чем они осознают. А ещё у них часто ложное чувство понимания: при коллективной разработке замечание «поставь дверь вот сюда» будет понято, но вот в какую сторону будет открываться дверь — вот это не будет обсуждено, дверь мастер установит уж как ему подскажет его опыт, и это может быть весьма неожиданный опыт.

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

Вот пример описания контрольных вопросов по достижению состояния «признаны» альфы «внешние проектные роли»:

Состояние *«*Внешние проектные роли признаны»

Контрольный вопрос состояния альфы	Пример рабочих продуктов (документов) с описаниями (view), свидетельствующими ответ на контрольный вопрос	Пример метода описания (viewpoints)
Все внешние проектные роли, которые на данный момент затрагивают и/или в будущем будут затронуты разработкой и функционированием инженерной системы, определены.	«Длинный список» (long list) внешних проектных ролей.	Таблица в coda.io или Excel с ролями и описаниями этих ролей. Вариант: описания ролей даны где-то в отдельном документе, собран только список.
Есть соглашение по исполнителям внешних проектных ролей, которые будут представлены. Как минимум, должны приниматься в расчёт представители внешних проектных ролей, которые финансируют, используют, поддерживают и обслуживают систему.	Завизированный командой «короткий список» (shortlist) ролей, которые будут представлены явно какими-то исполнителями этих ролей	Отметка в «длинном списке» для ролей о представлении и ссылка на наличие соглашения (завизированный протокол, подписанное распоряжение и т.д.). Может быть в CRM-системе, таблице внешних проектных ролей в notion.so или coda.io и т.д.
Ответственности представителей проектных ролей были определены.	Запись об ответственности	Типовое содержание записи об ответственности (какие решения представитель группы исполнителей внешней проектной роли полномочен принимать, в какие сроки реагировать, обязательства по присутствию на совещаниях, согласования документов и т.д.), представлено в каком-то универсальном/табличном моделере.

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

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

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

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

Рабочие продукты, свидетельствующие состояния альф (включая подальфы) проекта, можно делать проще или сложнее: инженерный процесс может быть самым разным по сложности, но он должен быть достаточным для снижения риска утери внимания за важным в проекте, опять-таки читайте книжку «Checklist manifesto» Atul Gawande.

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