Альфы – общий объект отслеживания команды

 

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

 

 

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

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

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

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

 

Альфа возможности

 

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

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

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

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

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

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

• Оценка выгодности (финансовые расчёты, которые зависят в том числе и от уже имеющейся загрузки ресурсов – учитывается маржинальная прибыль[200]). За проект кто-то должен заплатить достаточно, чтобы он был выгоден.

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

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

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

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

Альфа возможности в ходе проекта проходит следующие состояния/контрольные точки (в формулировках в том числе подчёркивается связь состояния этой альфы с состояниями других альф)[201]:

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

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

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

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

• Реализована (addressed): возможность реализована; решение достойно воплощения; стейкхолдеры удовлетворены;

• Извлекается выгода (benefit accrued): решение приносит выгоду; возврат на инвестиции приемлем.

 

Альфа стейкхолдеров

 

В системной схеме проекта альфа стейкхолдеров по факту относится к внешним стейкхолдерам, чья целевая система – использующая. Команда (внутренние стейкхолдеры) представлена отдельной альфой[202]. Стейкхолдеры дают возможности выполнения проекта, успешность целевой системы определяется стейкхолдерами, так как успешная/successful система – это та, в которой учтены стейкхолдерские интересы, точнее, оценки интересов (интересы это интересующие стейкхолдеров темы, а оценки интересов это как раз максимизация или минимизация каких-то подразумеваемых этими интересами характеристик системы и/или какого-то проекта по ходу жизненного цикла системы).

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

Хорошей практикой является сразу разделение альфы «стейкхолдеры» на отдельные подальфы «стейкхолдер» и раздельный учёт состояния этих подальф.

Вот состояния/контрольные точки для стейкхолдеров:

• Признаны (recognized): группы стейкхолдеров выявлены; ключевые группы стейкхолдеров представлены; ответственности представителей стейкхолдеров определены.

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

• Вовлечены (involved):  представители помогают команде; реагирование представителей на запросы своевременно и они предлагают решения; изменения сообщаются вовремя.

• В согласии (in agreement): минимальные ожидания согласованы; представители стейкхолдеров довольны своим вовлечением; вклад стейкхолдеров приносит пользу; вклад команды приносит пользу; приоритеты ясны и перспективы команды и стейкхолдеров сбалансированы.

• Удовлетворены для разворачивания (satisfied for deployment): имеется отклик/feedback стейкхолдеров; система готова для разворачивания.

• Удовлетворены в использовании (satisfied in use): отклик/feedback по использованию системы доступен; система отвечает ожиданиям.

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

 

Альфа определения системы

 

Определение системы наряду с воплощением системы относится к инженерной области интересов. Как самостоятельная альфа определение системы осмыслена только в самых общих разговорах по проекту, для более осмысленной работы нужно сразу разбивать его на подальфы. Трудность и в том, что для разных типов систем подальфы определения системы называются по-разному. Например, что для информационных и «железных» системы «требования», для предприятия может называться «стратегией», а для спортивного события «правилами».

В оригинальном OMG Essence в числе основных альф нет определения системы, но зато есть альфа «требования». Доработанный для системной инженерии вариант включает в себя все подальфы определения системы – и требования, и архитектуру, и неархитектурную часть проекта/design (рабочку).

Состояния альфы определения системы тут даётся очень обобщённое для «железной системы», рекомендуется для разных систем адаптировать эти состояния:

• Замыслено (concieved): стейкхолдеры согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний со стейкхолдерами согласован; механизмы управления конфигурацией описаний согласованы.

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

• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления определены и описаны; возникающие при изготовлении системы проблемы приводят к доработке и актуализации определения системы.

• Используется для проверки и приёмки воплощения (in use for V&V):  есть все описания, нужные для проверки и приёмки; проверки, критерии их успешности и способ проведения определены; стейкхолдеры согласны с объёмом проверок.

• Используется для эксплуатации (in use for operations): определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); определение системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.

• Используется для вывода из эксплуатации (in use for retirement):  используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

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

 

Альфа воплощения системы

 

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

• В виде сырья (as a raw material):  материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей.

• В виде частей (as a parts):  части воплощения системы созданы и/или закуплены и проверены; график интеграции (сборки, монтажа, строительства) из частей согласован; возможны работы по интеграции (сборке, монтажу, строительству).

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

• Готово (ready): функциональность протестирована; уровни дефектов для стейкхолдеров приемлемы; установочная и другая пользовательская документация доступна; представители стейкхолдеров удовлетворены системой; состав передаваемой системы известен; представители стейкхолдеров готовы эксплуатировать систему; эксплуатационная поддержка наличествует.

• Эксплуатируется (operational): доступна стейкхолдерам для эксплуатации в рабочем окружении; есть как минимум один пример работающей системы; поддерживается на согласованном уровне сервиса.

• Выведено из эксплуатации (retired):  Воплощение системы было заменено или прекращено в использовании; система больше не поддерживается; нет «официальных» стейкхолдеров, которые до сих пор используют систему; доработки/доделки системы больше не будут производиться; все материальные компоненты системы либо повторно используются, либо надлежащим образом уничтожены.

 

Альфа работы

 

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

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

• Подготовлена (prepared):  обязательства приняты; цена и потребные усилия оценены; доступность ресурсов понимается; правила и процедуры контроля ясны; критерии приёмки определены и согласованы; работы разбиты на части в достаточной для начала работ мере; задачи (tasks) определены, приоритеты для них расставляются; наличествует правдоподобный план; финансирование работ наличествует; как минимум, один человек из команды готов начать работу; моменты интеграции результатов работы определены.

• Начата (started):  работа по разработке начата; прогресс работы отслеживается; работа разбита на единицы действий с ясными определениями того, что нужно сделать; члены команды принимают и выполняют задания.

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

• Закончена (concluded):  остались только административные задачи; результат работ был достигнут; стейкхолдеры приняли результирующую систему.

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

 

Альфа команды

 

Альфа команда представляет собой тех сотрудников, которые охотно и качественно выполняют роли внутренних стейкхолдеров. Ведущие дисциплины тут – управление персоналом (human resources management), управление талантами (talent management, занимающиеся обеспечением организации сотрудниками-актёрами и их подготовкой к выполнению внутренних стейкхолдерских ролей в командах проектов, а также практика лидерства (leadership), занимающаяся обеспечением сотрудничества в команде, т.е. качественного отыгрывания стейкхолдерских ролей и продуктивного взаимодействия с другими членами команды.

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

• Намечена (seeded):  миссия команды определена; ограничения известны и явны; механизмы роста команды наличествуют; состав команды определён; обязанности команды обрисованы в общих чертах; уровень принятых командой обязательств ясен; требуемые компетенции определены; размер команды определён; правила надзора за деятельностью определены; вид/форма лидерства выбрана.

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

• Сотрудничает (collaborating): команда работает как одно сплочённое подразделение; общение в команде открытое и честное; команда сфокусирована на достижение миссии команды; члены команды знают друг друга.

• Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа впустую (waste) и причины для работы впустую постоянно устраняются.

• Распущена (adjourned): обязанности были выполнены; члены команды доступны для участия в других командах; миссия завершена.

 

Альфа технологии

 

В оригинальном стандарте речь идёт об альфе way of working (способ проведения работ), и авторы стандарта не случайно ушли от того, чтобы назвать альфу «практики». В практиках дисциплина грузится в головы исполнителей работ, её нужно искать в компетенциях команды, в человеческом капитале. И сама практика называется по имени своей дисциплины – и нужно постоянно про это помнить. Ещё есть большой соблазн различать начальное состояние «практики где-то там» (то, что обычно делают люди) и конечное состояние «доступной для использования в работах практики тут у нас». Для этого случая есть термин оргвозможности (capability, поставленная практика – то есть имеющиеся в команде обученные дисциплине люди и развёрнутые инструменты, на которых эти люди умеют работать).

Поэтому мы приняли решение для way of working говорить о том, что осталось от практики и разворачивается на самом предприятии – о технологии, но рекомендуем при этом не забывать о практике в целом, и это отражено в формулировках состояний альфы/контрольных точек. Конечно, говорить сразу о всех практиках и всех их технологиях не получится – поэтому лучше всего будет отслеживать в проекте связанные с технологиями подальфы отдельных практик/способов работы/технологий, а то и дробить их дальше на подальфы инструментов и отдельных рабочих продуктов.

Вот состояния/контрольные точки основной альфы «технологии»:

• Дисциплина установлена (principles established):  команда активно поддерживает дисциплину/теорию/принципы; стейкхолдеры согласны с принципами; потребные для их поддержки инструменты согласованы; рекомендации по выбранному подходу доступны; рабочий контекст понимается; ограничения практики и выбранных в её составе инструментов известны.

• Основа положена (foundation established):  ключевые практики и их инструменты выбраны; практики, необходимые для того, чтобы начать работу, согласованы; практики, по которым не будет обсуждений и их инструменты выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; способ работы, в котором все практики удобно использовать, определён.

• Используется (in use):  практики и их инструменты используются; использование практик и их инструментов регулярно проверяется; практики и их инструменты адаптированы к контексту; практики и их инструменты поддерживаются командой; механизмы получения откликов/feedback на практики и их инструменты работают; практики и их инструменты поддерживают общение команды и сотрудничество.

• Наличествует (in place):  практики и их инструменты используются всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well):  делается предсказуемый прогресс; практики применяются естественным образом; инструменты естественным образом поддерживают принятую дисциплину работы; идёт постоянное совершенствование/подстройки.

• Вышла из употребления (retired):  больше не используется; уроки использования практики опубликованы для использования в будущем.

 

За чем следить в проекте

 

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

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

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

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

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

Всего семи объектов внимания в проекте не будет хватать – тем более в больших проектах. Поэтому команде необходимо уделять внимание не только альфам, но и подальфам, на что мы обратили внимание, когда описывали основные альфы.

Но часто команда будет брать эти подальфы из дисциплин/теорий/принципов принятых ими практик. Например, в практике управления проектами методом критической цепи вводят альфу «буфер проекта» (project buffer) и отслеживают затем её состояние – сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Essence предлагает, чтобы все эти подальфы обязательно были подальфами либо основных альф, либо друг друга (подальфы представляют собой направленный граф, в том числе подальфа может быть подальфой сразу нескольких основных альф или других подальф). Так, альфа «буфер проекта» может быть подальфой «работы». И ответ на вопрос «в каком состоянии работы проекта?» может включать в себя отдельный рассказ про состояние «буфера проекта».

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