Ситуационная инженерия метода

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

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

Какой же должна быть такая модель?

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

В контексте практик DevOps ярким примером таких отдельных непрерывных доработок всех аспектов разом и проекта целиком является практика Postmortem — после инцидента мы адаптируем нашу систему, наши рабочие процессы, каналы коммуникации и т.д. для того, чтобы инцидент не повторялся. Другой вариант такого адаптивного строительства: постепенное построение пайплайна CI/CD — сначала мы реализуем сборку и договариваемся с разработчиками что упавший билд они чинят как можно быстрее, затем постепенно добавляем туда запуск тестов, деплой, сканирование качества кода и т.д.

Но и постмортемы и CI/CD затрагивают только небольшие вполне определенные аспекты проекта. Меня же интересует проект целиком, т.е. каким образом делать такое адаптивное развитие для всех аспектов, т.к. задача руководителя шире чем организовать постмортемы и CI/CD.

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

Что это за фреймворк? Существуют ли уже такие?

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

• Самым иллюстративным примером такого фреймворка на мой взгляд будет Zachman Framework, и хорошее и компактное его описание есть, например у Mark Richards вот в этом видео: https://youtu.be/IaQddw-uCvY
• Другой, гораздо более практичный и современный (но кажется менее понятный для людей) пример — OMG Essence.
• Неплохие, но тяжеловесные варианты — ITIL или TOGAF.
• Из вышедших совсем недавно и относящихся именно к DevOps — https://platen.dev
• Возможно и собственно фреймворки проектного управления подойдут, но глядя на например P3Express я не уверен, что могу это про него сказать — он описывает только довольно узкую часть, управления работами, но не обсуждает, например, содержание работ. У более тяжеловесных вариантов возможно все есть, но они тяжеловесные.

Все они описывают организацию сразу с нескольких разных точек зрения — например, с технической, с процессной точек зрения, с точки зрения коммуникации и контрактования с заказчиками и т.д.
(Можно вспомнить Щедровицкого с триадой “технолог-предприниматель-организатор”, но мы этого делать не будем, а вместо этого отправим читателя изучать OMG Essence).

Эти описания можно представить в виде таблицы. В каждой ее клеточке мы даем ссылку на документ в котором определяем как у нас будет в проекте устроен тот или иной аспект — процесс работы команды, компонентный состав системы, бизнес-польза от системы и того что мы ее развиваем и т.д. Нагляднее всего на мой взгляд это представлено у Zachman (см. видео Марка Ричардса выше).

Что дальше? Как это использовать?

С таким подходом, по шагам подключение к любому новому проекту будет выглядеть примерно так:

1. Выбираем фреймворк, он может быть любым — главное чтобы его содержание было понятно лично тебе как руководителю и охватывал как можно больше аспектов проекта. При этом не стесняемся адаптировать под проект или выкидывать аспекты непонятные или неприменимые — мы же рабочий инструмент собираем, а не экзамен сдаем.
2. Каждый элемент этого фреймворка — это некая задача по организации проекта. “Определить принципы разработки-тестирования-поставки”, “определить процесс работы в команде”, “нарезать бэклог для разработки”, “реализовать точку входа клиентских задач в бэклог проекта”. Это все задачи в твой список задач как организатора. В результате выполнения такой задачи вы вместе с командой договариваетесь о том или ином аспекте проекта.
3. Приоритезация этих задач делается как любая другая приоритезация задач. Самые важные делаются сразу, менее важные чуть позже, неважные — в 5 квартале. И как и для любого другого бэклога эти приоритеты будут постоянно корректироваться. Бэклог руководителя на месяц вперед делается за час-другой работы, и в результате можно достаточно спокойно одновременно и брать управление проектом и направлять его в нужном направлении.
4. По мере формирования фактической деятельности проекта бэклог управленческих задач будет расти и обрабатываться ровно таким же образом как и любой другой бэклог. По мере движения по бэклогу также одновременно будет и изменяться и дорабатываться под нужды организации фреймворк от которого мы оттолкнулись на старте.

Кто-нибудь еще применяет такой подход? Какие вы здесь видите плюсы/минусы/подводные камни?