Анатолий Левенчук - Системное мышление

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

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

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

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

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

Из V-диаграммы с подальфами хорошо видно, что потребности/требования стейкхолдеров это подальфы возможности, а не подальфы определения системы.

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

• Она будет кому-то нужна, и за неё смогут заплатить

• Её кто-то сможет сделать за разумную плату.

Это ведёт к следующим возможным подальфам возможностей:

• Потребности стейкхолдеров (нет потребностей – нет возможности сделать проект, никто не заплатит).

• Оценка выгодности (финансовые расчёты, которые зависят в том числе и от уже имеющейся загрузки ресурсов – учитывается маржинальная прибыль 200 200 https://ru.wikipedia.org/wiki/Маржинальная_прибыль ). За проект кто-то должен заплатить достаточно, чтобы он был выгоден.

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

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

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

Возможности выполнить проект – это предпринимательские возможности, они слабоформализуемы и прежде всего связаны со способностью предугадать будущее.

Альфа возможности в ходе проекта проходит следующие состояния/контрольные точки (в формулировках в том числе подчёркивается связь состояния этой альфы с состояниями других альф) 201 201 Формулировки условий прохождения контрольных точек даны по мотивам упрощённой версии стандарта Essence, представленной в карточках состояния альф фирмы Ivar Jacobson International, https://www.ivarjacobson.com/publications/tools/alpha-state-cards-pdf-version , кроме альф определения и воплощения системы. :

• Выявлена (identified): найдена идея; найден как минимум один стейкхолдер, желающий сделать инвестицию в понимание возможности; определены другие стейкхолдеры.

• Нужно решение (solution needed): выявлено инженерное и/или культурное решение; установлены потребности стейкхолдеров; определены проблемы и их причины, подтверждено, что стейкхолдерам это решение нужно; было предложено как минимум одно архитектурное решение.

• Польза установлена (value established): польза возможности была определена количественно; влияние решения на стейкхолдеров понятно; польза системы стейкхолдерами понимается; критерии успешности ясны; результаты ясны и выражены количественно.

• Жизнеспособна (viable): решение обрисовано в общих чертах; решение возможно с учётом ограничений; риски приемлемы и управляемы; решение выгодно; причины для разработки решения понимаются; ясно, что реализация возможности жизнеспособна.