Фреймворк OMG Essence

Эссенс придумал Ивар Якобсон, автор UML и юзкейсов. На верхнем уровне фреймворк определяет три области интересов, в которых расположены семь «альф» — абстрактных отражений разных аспектов проекта.

Области: клиентская, инженерная, менеджерская.
Альфы: стейкхолдеры и возможности; описание и воплощение системы; команда, метод работы и сами работы.

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

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

Для целей поста достаточно базового понимания: три области, семь альф, все вместе они исчерпывающе описывают состояние проекта. Чуть больше подробностей — в моем докладе 2019 года.

Факторы успеха из отчета CHAOS

До 2020 года исследовательская группа Standish Group выпускала отчеты-исследования CHAOS о проектах разработки софта. Отчет строился на основе собственных исследований: группа собирала данные с большого количества проектов в разных отраслях (я встречал цифру в 50 000 проектов), проводила интервью с проектными командами, руководителями и клиентами, и делала выводы.

Я делал посты про отчет 2018 и отчет 2020 года.

В 2020 году группа выпустила последний отчет «Beyond Infinity» и провозгласила, что эра эджайла подходит к концу и поэтому отчетов больше не будет.

Одной из основных задач группы было определение факторов, коррелирующих с успешностью проектов.
В 2018 и 2020 гг. эти факторы были примерно одинаковы:

1. Decision Latency — решения должны приниматься быстро
2. Проект должен быть небольшим
3. Спонсор проекта (это роль) должен быть опытным и грамотным
4. Проект должен управляться по аджайлу (в общем смысле)
5. Команда должна хорошо уметь и в аджайл, и в технологии — т. е. уметь всесторонне отвечать на вопрос «как сделать?»
6. Организация должна быть «эмоционально зрелой»: уметь справляться с конфликтами, неопределенностью и стрессом.

Что я хочу сделать дальше: понять, как факторы успешности ложатся на системную схему Эссенс. В каких областях находятся, к каким альфам относятся, и так далее. Я хочу научиться понимать, какие из факторов используются на отдельно взятом проекте, а какие — нет.

Decision Latency

Decision Latency — это разница во времени между моментом идентификации необходимости принять решение и моментом принятия этого решения. Главный тезис из отчета: The value of the interval is greater than the quality of the decision.

Можно разложить DL на три составляющие:

1. Идентификация необходимости принять решение. Возник риск, появилась проблема, либо необходимость в некоем действии, нужно выбрать дальнейший курс действий.
2. Анализ ситуации. Прежде чем принимать решение, мы должны обеспечить минимальный набор для него. В этот набор входит формулировка проблемы или задачи (что решаем), набор критериев для определения решения (как решаем) и набор альтернатив, из которых мы будем выбирать (что выберем в качестве решения). Для сложных решений можно еще спрогнозировать будущее в случае выбора каждой из альтернатив — на что повлияет выбор, что будет затронуто и т. п.
3. Принятие решения (такая дурацкая формулировка) — когда мы, используя результаты анализа ситуации из п.2, выбираем одну из альтернатив и выстраиваем дальнейший курс в соответствии с ним.

Cоответственно, у нас есть три метрики — Capture Latency, Analysis Latency, Decision Latency, они измеряются в днях. Все вместе тоже называется Decision Latency.

Способы повлиять на эту метрику лежат в альфе «метод», но затрагивают все остальные: необходимость принять решение может возникнуть в рамках любой из альф. Поэтому рабочей схемой кажется разработка общего подхода к принятию решений с адаптацией под конкретные ситуации. Так же будет полезно завести табличку и трекать все три стадии, чтобы понять — хорошая на проекте DL или нет. В доке https://archives.obm.ohio.gov/Files/Major_Project_Governance/Resources/Resources_and_Templates/03_Initiate/26_Tracking_Decision_Latency_Guidance.pdf есть такой перечень полей для таблички:

• An identification number
• The project phase
• A descriptive title
• The risk/issue/decision status
• Probability
• Impact
• Owner and assigned team
• Date assigned or recognized
• Next action date
• Resolution date
• And any related risks/issues/decisions

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

Про это децентрализацию много пишет Рейнертсен (мои посты про его книгу), а «решениям» как двигателю проекта посвящен фреймворк Decision Patterns Джона Фитча (два поста о нем).

Практический вывод: обеспечить низкую задержку принятия решений — задача сложная, скорее всего должна решаться на уровне методологов/PMO. Обязательно нужно поощрять инициативу сотрудников быстро решать возникающие проблемы и задачи и превращать работающие методики в общее место.

Проект должен быть небольшим

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

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

Маленькую и простую систему проще провести через приемку (v&v) после завершения разработки, чем большую. С ней связано меньше стейкхолдеров, ей нужно меньше возможностей (я про альфу) для согласия и buy-in всех интересантов.

Если пойти от обратного — может ли быть маленьким проект по разработке большой и сложной системы? Я не могу себе такого представить.

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

Грамотный и опытный спонсор проекта

Спонсор проекта — это стейкхолдер, внешняя проектная роль. Он не часть команды, он — представитель заказчика (внешнего или внутреннего). Спонсор ставит цель, формирует и поддерживает видение проекта, обеспечивает внешние ресурсы (от денег до доступа к decision making unit).

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

Практический вывод: компании, заказывающие проекты, должны вырастить несколько спонсоров — это в их интересах.

Проект должен управляться по аджайлу

Тут довольно очевидно: это альфа «метод» (way of working), у команды должны быть наработаны практики работы по аджайлу. В приоритете — альфа «система» и ее соответствие ожиданиям стейкхолдеров, именно этому должен быть подчинен весь цикл от сбора и анализа требований до релиза.

Практический вывод: если вы не строительная организация — закопайте и не разрешайте выкапывать «водопад».

Команда должна хорошо уметь в аджайл и в технологии

Ядро Essence Kernel состоит из трех типов элементов: области активности, альфы и оргспособности (capabilities). «Хорошо уметь...» — это про оргспособности.

В Essence описываются шесть типов оргспособностей:

1. Stakeholder Representation
2. Analysis
3. Development
4. Testing
5. Leadership
6. Management

Упомянутые в принципе умения касаются анализа, разработки, тестирования и управления, а альфы «Метод» и «Команда» — это скорее контекст их использования.

Практический вывод: в команду нужно брать умеющих работать по эджайлу сильных технических специалистов, ваш Кэп.

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