Состояния альфы и артефакты/рабочие продукты
Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на состояние связанных с ними артефактов/рабочих продуктов. С альфами происходит мышление, с рабочими продуктами/артефактами (в том числе с документацией, но и с воплощением системы непосредственно, а также с технологиями поддержки дисциплин самых разных практик) происходит работа по изменению рабочих продуктов. Конечно, для описания (view для согласования каких-то предметов интереса, то есть набор разных моделей) состояния альфы должен быть использован какой-то метод описания/viewpoint: мета-модель предметной области проекта (не наша мета-мета-модель из курса, она только помогает вам найти эти альфы в проекте, а метаУ-модель «из учебника предметной области» или «метаС-модель» как она понимается в ситуации конкретного проекта) и принципы создания модели, методические указания по моделированию предмета интереса/concern. Помним, что предмет интереса отражается его методом описания, а само описание документируется, чтобы внимание коллектива на нём стабильно удерживалось независимо от уровня отвлечений людей в этом коллективе --- это и есть коллективная собранность. Поэтому в реальной обстановке обсуждение ведётся не только альф, но и свидетельствующих об их состояниях рабочих продуктов/артефактов (и в том числе документов). Чтобы обсуждать состояние «забивала» надо обсуждать и состояние и играющих его роль предметов --- молотка, микроскопа, камня.
Документирование (прежде всего компьютерное, в форме каких-то баз данных, в том числе с использованием разных моделеров) моделей/описаний по сравнению с чисто устной работой «с голоса» имеет
- достоинства: возможность коллективной и независимой проверки моделей, возможность помнить о деталях через долгое время после обсуждений, моделирование только важного и т.п.
- недостатки: лишняя работа, требующая времени --- в простых случаях и при малом числе участников проекта иногда ведь хватает и устных обсуждений с неформальными заметками, особенно если речь идёт не о крупных вопросах (как для чеклистов), а о различных мелких нюансах, которые тут же учитываются --- и о них можно забыть.
Конечно, «легковесные методологии» предпочтительны, но легковесная/lightweight методология в части документирования разработки не должна свестись к отсутствию документирования, «разработке проговариванием».
Каждая команда выбирает свой уровень документирования происходящего в проекте, это тоже вопрос договорённостей в команде. Вот пример описания критериев достижения состояния «признаны» альфы «внешние проектные роли» (их же можно назвать «подсостояния»). Указание методов описаний для рабочих продуктов позволяет перейти от чисто «устной» работы к документированию (на бумаге или в компьютере --- это всё равно), то есть «определены», «есть соглашение» оказываются документированными, состояние альфы свидетельствуется в документе, а документирование ведётся в подходящих моделерах (вы должны уметь использовать для этого разные моделеры, понимать принципы моделирования, а не привыкнуть к одному моделеру конкретного вендора софта. Софт тут как ручка писателя: некоторые пишут лучше, некоторые хуже, но будет ли написанное претендовать на Нобелевскую премию по литературе, зависит не от ручки. С моделированием альф то же самое: от моделера качество моделирования зависит меньше всего):
«Внешние проектные роли признаны»
Критерии достижения состояния (подсостояния) Пример рабочих продуктов (документирование views) Пример практик/методов описания (viewpoints) Все внешние проектные роли, которые на данный момент, или в будущем будут затронуты разработкой и функционированием инженерной системы, определены. «Длинный список» (long list) внешних проектных ролей Таблица в coda.io (хуже: Excel/Word) с ролями и описаниями ролей (или описания ролей даны где-то в отдельном документе, и собран только список). Есть соглашение по исполнителям внешних проектных ролей, которые будут представлены. Как минимум, должны приниматься в расчёт представители внешних проектных ролей, которые финансируют, используют, поддерживают и обслуживают систему. Завизированный командой «короткий список» (shortlist) ролей, которые будут представлены явно какими-то исполнителями этих ролей Отметка в «длинном списке» для ролей о представлении и ссылка на наличие соглашения (завизированный протокол, подписанное распоряжение и т.д.). Может быть в CRM-системе, таблице внешних проектных ролей в notion.so или coda.io и т.д. Ответственности представителей проектных ролей были определены. Запись об ответственности Типовое содержание записи об ответственности (какие решения представитель группы исполнителей внешней проектной роли полномочен принимать, в какие сроки реагировать, обязательства по присутствию на совещаниях, согласования документов и т.д.), представлено в каком-то универсальном моделере
Конечно, для каждого проекта командой адаптируются как сами критерии достижения состояния, так и формы документирования их прохождения. Используемые в проекте методы создания и развития системы часто сами оговаривают методы описания важных объектов (практики определяют альфы, за которыми нужно следить в ходе выполнения работ по практике, и рассказывают, каким методом эти альфы лучше описывать).
В обсуждениях состояния проекта участвуют главным образом альфы, функциональные объекты, мышление идёт с ними. Но работаем в проектах с конструктивными объектами, отражающими/свидетельствующими/evidence состояния альф, т.е. с документами и другими артефактами/рабочими продуктами. Легко обсуждать готовность документа: красоту шрифта, число страниц или экранов, была ли литературная редакция, или нет. Обсуждение альфы требует вчитаться в документ --- и готовым или нет будет сам документ, это неважно, обсуждается то, что в документе описано: альфа.
Уровень бюрократии (типовых решений, выполняемых с использованием стандартизованного набора рабочих продуктов) можно и нужно выбирать в зависимости от профиля рисков проекта. Рабочие продукты, свидетельствующие состояния альф (включая подальфы) проекта, можно делать проще или сложнее: методология должна быть легковесной, но она должна быть достаточной для снижения риска утери внимания за важным в проекте, опять-таки читайте книжку «Checklist manifesto» Atul Gawande.
Фундаментальные дисциплины, в том числе методология и использование системного подхода подразумевают письменную работу, мышление невсё в биологических головах, оно протягивается «из головы» во внешний мир (extended cognition, active/embodiedinference)! Кроме того, в проектах важно мышление организации/команды/коллектива/предприятия, оно требует организации коллективной памяти, что делается сегодня компьютернымимоделерами, и всё больше универсальными табличными моделерами!