Проектный офис «Рексофт» внедрил в производственный процесс приёмы ситуационной инженерии методов
В 2023 году к «Рексофт» присоединились команды RNT Group (российский бизнес EPAM), Schneider Electric, Siemens, Aveva и стратегический консалтинг российского подразделения Accenture. Таким образом, бизнес значительно диверсифицировался: если раньше, в основном, это была разработка заказного ПО, то теперь в проекты добавилась новая отраслевая специфика, включающая, например, математическое моделирование, наукоемкие исследования, поставки дорогостоящего оборудования. Это потребовало ответа со стороны проектного офиса, что, в числе прочего, включало поиск нового единого и удобного механизма мониторинга и контроля, а также средства хранения и тиражирования артефактов, описаний практик и методологий управления.
Что такое ситуационная инженерия и зачем она проектному офису?
Каждая вторая статья про ситуационную инженерию начинается с рассказа про то, чем она не является. Мы тоже не будем умничать: ситуационная инженерия — это не очередная методология проектного управления, а подход к применению таких методологий. Суть подхода в том, что отдельные практики и приёмы управления адаптируются под специфику конкретных проектов перед их запуском или даже во время выполнения. Это позволяет быстрее преодолевать ограничения методологий и гибче адаптироваться под условия проектной работы, если они часто или неожиданно меняются (а у кого это не так?…). На практике это может выглядеть примерно так: вы заметили, что могли бы избежать проблем, если бы команда оценивала трудоёмкость задач точнее. Где-то в недрах интерфейсов вашей системы управления проектами вы ставите галочку напротив практики Planning Poker для этого проекта. В результате из репозитория доступных практик в устав проекта / базу знаний добавляется описание практики, в трекер задач — рабочий процесс для удалённой игры, а в систему мониторинга — метрики, отражающие то, как меняется точность, и кто из команды больше всех (и в какую сторону) повлиял на эти изменения. Внимательный читатель скажет, что добавить что-то такое к проекту можно и без всяких инженерий, и я, в общем, соглашусь, но подходы ситуационной инженерии помогут сделать это быстрее и с меньшим сопутствующим ущербом для участников проекта и его расписания. Кроме того, Planning Poker это простейший пример, он только отражает суть, в реальности всё, конечно, сложнее.
Теперь про то, причём тут проектный офис. Что такое проектный офис, все видят по-разному (определение размыто, как и многое в проектном деле). Лично я встречал трактовки от ресурсного пула проектных менеджеров до полноценных проектных организаций с собственными продажами и бухгалтерией. Поэтому договоримся что, каким бы не было наше понимание, у проектного офиса есть две важные функции.
Содействие проектной работе через поиск и оптимизацию общих для большинства проектов практик и приёмов управления. Идея в том, что проекты все в чём-то разные, но в чём-то и одинаковые, и надо этот общий знаменатель выявить, один раз качественно проработать или автоматизировать и множество раз воспроизвести. Например, это может включать в себя тиражируемые артефакты:
шаблоны проектной документации;
шаблоны проектов для трекера задач с готовыми рабочими процессами и интеграцией с BI;
готовые типовые проектные уставы;
реестры типовых проектных рисков и т.д.
Такая оптимизация поможет сократить трудозатраты (особенно, на ранних этапах проектов), снизит риски ошибок, сократит время на онбординг. Как обычно, тут главное не переборщить: слишком объёмная общая часть может не окупить затраты на собственную поддержку и создаст риск превратить поддерживаемые проекты в процессы.
Вторая важная функция — это централизованный мониторинг и контроль. Помимо сбора консолидированной отчётности они нужны для того, чтобы своевременно выявлять признаки развития кризисных ситуаций, обеспечивать необходимый запас времени для планирования и реализации компенсирующих мероприятий и в крайнем случае вовремя вводить антикризисное управление. Уже видно, что для обеих функций важно правильно выделить общую часть. Если ваш портфель проектов сильно диверсифицирован, сделать это может быть не просто. Ситуационная инженерия отвечает на этот вызов.
Что конкретно внедрялось в «Рексофт»?
Отметим, что выше мы говорили про ситуационную инженерию и проектный офис вообще, ниже речь пойдёт про конкретное внедрение. Для внедрения в «Рексофт» я выбрал реализацию, описанную стандартом OMG Essence. Во-первых, потому что сам консорциум OMG (Object Management Group) весьма авторитетен (XMI, UML, BPMN). Во-вторых, потому что это последняя на настоящий момент спецификация, в которой, к тому же, акцент сделан на разработке ПО. Кроме того, среди авторов встречается несколько фамилий, также перечисленных в предыдущий спецификации на эту тему: «Software & Systems Process Engineering Metamodel 2.0», что позволяет надеяться на то, что они учли накопленный опыт, при этом не утратив веру в идею. В сети легко можно найти множество материалов об Essence, не хочется повторяться, но без основных деталей рассказать о внедрении будет трудно. Спецификация состоит из двух основных частей: ядро и язык.
Язык Essence
Язык и графическая нотация определяют, как описываются и визуализируются объекты проектного управления: артефакты, ресурсы, роли, компетенции и т.д. Можно в едином стиле описать, например, SAFe и Waterfall. В сети есть готовые библиотеки таких описаний (например, от одного из авторов спецификации). Центральным элементом языка является альфа — нечто, что имеет ценность как результат проекта, например, удовлетворённость клиента, накопленные знания, финансовый результат и т.д. У каждой альфы свой жизненный цикл, заключающийся в последовательной смене её состояний (states). Для присвоения очередного state должен быть пройден quality gate, выраженный через чеклист. Далее описывается, что и как должно произойти для прохождения этого quality gate, например: для присвоения альфе Finance состояния Reviewed участник проектной группы, обладающий ролью Budget Owner, должен, в числе прочего, сверстать бюджет в соответствии с требованиями руководства по бюджетированию и защитить его перед владельцем роли Account Manager, для чего ему нужна компетенция «финансовая грамотность». Каждый такой объект управления может быть представлен в виде карточки (физической или виртуальной).
На рынке можно найти несколько специализированных средств (репозиториев доступных практик и методов) для создания таких карт, хранения и визуализации связей между ними (догадываюсь, что их прародителем был Rational Method Composer от IBM). Но так как у нас есть свой близкий по духу продукт (Skillflex), мы решили доработать соответствующую функциональность там.
Ядро Essence
Ядро определяет альфы, которые, по мнению авторов, так или иначе присутствуют в каждой методологии по разработке программного обеспечения. В случае внедрения в «Рексофт» важно было сохранить сложившуюся систему проектного мониторинга, поэтому сперва усилия были направлены на то, чтобы проверить, как она ляжет на стандарт. Для этого в Skillflex была добавлена (пока частичная) поддержка языка Essence и определены новые альфы, отсутствующие в стандарте.
Наши альфы
legal — юридически значимые обязательства между сторонами. Описание включает в себя процессы контрактования (шаблоны типовых документов, согласование и подписание, ответственные участники, их роли и компетенции). В части мониторинга были реализованы простейшие проверки наличия необходимых согласований и покрытия работ договорными обязательствами сторон. Требует интеграции с системой документооборота.
finance — финансирование проекта. Включает в себя процессы бюджетирования, контроль исполнения, выявление и закрытие кассовых разрывов, начисление доходов и расходов, управление кредиторской и дебиторской задолженностями. Мониторинг обеспечивает контроль финансовых метрик, бюджетный план-фактный анализ, частоту и достоверность обновления финансовых прогнозов (знаю, считать деньги в проектах сегодня моветон, но я живу в вымышленном мире, который сам придумал, где это до сих пор важно). Требует интеграции с бюджетной системой и ERP.
crew — команда участников проекта. Включает в себя формирование ресурсного плана, контроль его исполнения, процессы привлечения и освобождения участников, оценка удовлетворенности участников, мониторинг регулярности и полноты списаний трудозатрат. Функции мониторинга требуют интеграции с трекером и HRM.
delivery — исполнение обязательств по составу и срокам поставок. Включает в себя контроль ключевых вех и baselines по ним, динамики изменения прогнозов, выявление признаков развития типовых кризисных ситуаций, а также проверки своевременности, атомарности и достоверности оценок трудозатрат. Это самая важная и трудоёмкая альфа, особенно в части прогнозирования. Требует глубокой интеграции с трекером.
risks — управление проектными рисками. Включает в себя мероприятия по выявлению рисков, их количественной и качественной оценки, выбору стратегии реагирования, описанию триггеров, оценки последствий и формированию планов компенсирующих мероприятий. В части мониторинга проводится автоматизированный аудит проектных рисков по оригинальной методике, принятой в «Рексофт», а также простейшие проверки того, что реестр рисков регулярно обновляется, и для рисков в красной зоне выбрана стратегия, выполнены необходимые оценки и сформирован план реагирования. Требует интеграции с трекером или другой системой, где ведётся учёт рисков.
Таким образом, считаем, что если все работы проекта покрыты договорными обязательствами, он стабильно финансируется и планомерно выбирает бюджет, собранной команды достаточно для выполнения работ и она, в целом, довольна проектом, поставки выполняются в срок и в полном объёме, проектные риски выявлены и учтены то это хороший здоровый проект с высокими шансами на успех. При этом не обязательно все альфы должны присутствовать в каждом проекте: для внутренних проектов не будет legal, для проектов с внешним управлением может не быть delivery и так далее. И наоборот, для проектов, где есть что-то не попадающее под «общий знаменатель», могут быть доработаны и включены дополнительные альфы, отражающие эту специфику. Например, сейчас в разработке находятся support (контроль SLA), supplies (закупки лицензий и оборудования) и security.
Собираем Big Picture
Каждое возможное состояние каждой альфы соответствует одному из статусов на жизненном цикле проекта. При этом очередное состояние альфе присваивается автоматически (и только автоматически) при прохождении соответствующего quality gate (не знаю, как правильно это будет по-русски), а статус проекта — всегда вручную через осознанное управленческое решение. Статус проекта определяет набор допустимых операций или ограничений, например: нельзя списать затраты или начислить выручку на проект, который не был открыт или, наоборот, расчёт бонусов можно выполнить только для закрытого проекта, когда его финансовый результат зафиксирован и может измениться только в силу каких-то исключительных обстоятельств. Таким образом, несоответствие между статусом проекта и состоянием альфы является нарушением, требующим корректирующего действия или осознанного принятия риска.
Для каждой альфы определена проектная роль, владелец которой несёт ответственность за своевременное прохождение её quality gates. Обычно, на практике, все роли принадлежат двум участникам — проектному менеджеру или фасилитатору (как бы он не назывался) и менеджеру, ответственному за взаимоотношения с клиентом. Но, в зависимости от типа и специфики проекта граница ответственности между ними может проходить по разным альфам. При появлении не пройденной проверки в каком-то из quality gate (неважно, проекту был присвоен очередной статус, когда не всё ещё к этому готово или, наоборот, что-то было утрачено) Skillflex вышлет уведомление обладателю соответствующей проектной роли. Кроме того, (этого уже нет в стандарте, додумали сами) у каждой проверки есть несколько дополнительных атрибутов:
threshold (опционально) — пороговое значение, определяющее к каким проектам данная проверка неприменима (например, бюджет меньше X руб.).
responsible (опционально) — для возможности переопределить роль ответственного на уровне альфы.
impact — вес проверки, условная количественная оценка риска, возникающего в случае нарушения.
Таким образом, получился сквозной скоринг, абстрагированный от специфики проекта, по которому можно сортировать и фильтровать. Для удобства добавили пороговые значения для желтой и красной зоны, в которые попадали проекты, требующие наибольшего внимания и GAP анализ изменений, накопленных за временной период.
Как проходит внедрение?
В части организационных изменений всё прошло достаточно бесшовно, способствовала гибкость самой ситуационной инженерии: сложившиеся к тому моменту в «Рексофт» процессы и практики легли на новый подход как частный случай его применения. Основная сложность заключалась в технической реализации Essence внутри Skillflex. В числе прочего спецификация содержит метамодель языка, определенную в терминах MOF (Meta-Object Facility, то же средство, что применялось OMG для описания UML). Реализация модели потребовала трудоёмких изменений архитектуры Skillflex, которые во многом ещё не завершены. Тем не менее, на настоящий момент, готовы наиболее важные изменения, позволяющие последовательно, через drilldown, отобразить ключевые отчётные формы:
project / alpha
Отчёт выполнен в виде таблицы, где каждая строка — это проект, а в колонках отражены альфы, которые попадают в текущую выборку (есть хотя бы в одном проекте из тех, что попали под выбранные условия фильтрации). На пересечении — сумма весов не пройдённых проверок, также, для удобства, представлена в виде светофора. Таким образом решается вопрос выбора «общего знаменателя» для мониторинга — он меняется в зависимости от выборки рассматриваемых проектов. Дополнительно, в колонках правее, отражены обладатели ключевых проектных ролей. Чаще всего таблица сортируется по результатам скоринга. В общем, отчёт отвечает на вопрос, какие из проектов требуют внимания.
project status / alpha state
Таблица, отображающая статусы выбранного проекта (в строках), в колонках — альфы, на пересечении — соответствующие данному статусу проекта стадии альфы, также подсвеченные в соответствии с весами выявленных несоответствий. Стадии раскрываются в quality gate с результатами проверок. Отвечает на вопрос, что именно не так с конкретным проектом.
project dashboard
Плитка, где каждый виджет отражает одну из альф выбранного проекта с её стадиями, чеклистами и дополнительной аналитикой: для финансов, например, бюджетный план-фактный анализ, для деливери — гант по ключевым вехам и диаграмма MTA. Далее по кликам более глубокая проектная отчётность несвязанная с Essence или переход на исходные данные в прикладных системах. В целом, дашборд отвечает на вопрос — почему возникла та или иная проблема с проектом?
В совокупности, эти формы хорошо структурируют проектную отчётность для диверсифицированного портфеля. И, главное, если альфы и чеклисты выбраны верно, позволяют выявлять риски на ранних этапах, когда они ещё не причинили ущерба и их устранение ничего или почти ничего не стоит.
Что ещё предстоит сделать?
Следующая важная часть внедрения — централизованный репозиторий методологий проектного управления (или «методов» как указано в спецификации) и отдельных практик, их составляющих. Репозиторий будет хранить описания практик в единой графической нотации и всевозможные статичные артефакты, способствующие их применению (шаблоны документов, типовые задачи и пр.). Атрибуты справочника в систему управления проектами будут включать ссылки на доступные в репозитории практики, альфы или их группы. Добавление, например, альфы к проекту может отражаться не только на проектной отчётности и его quality gates, но и на интерактивной карте проектных практик, базе знаний и других системах, в зависимости от содержимого альфы. На настоящий момент в Skillflex эта функциональность находится на этапе реализации. В качестве временного решения сделали карту практик на базе одного из средств для создания интерактивных диаграмм с анимацией и динамической декомпозицией элементов. Получилось наглядное интерактивное справочное пособие. Все тонкости работы с практиками уместить в карточки, конечно, не удалось, поэтому почти на каждой есть ссылка на соответствующую страницу в базе знаний, но, всё равно, такая справка полезна как helicopter view, а единая нотация способствует преемственности знаний и ускорению онбординга.
Сейчас изменить состав и логику прохождения quality gate без правок кода невозможно. Через UI можно корректировать только пороговые значения метрик для некоторых проверок. Так что главное и самое интересное что предстоит сделать — это low-code редактор для реализации логики прохождения quality gate. Это потребует создания модели данных, доступной через low-code и агностичной к особенностям реализации проектных систем, с которыми интегрируется Skillflex. Например, у задач в любом трекере есть тип, статус, приоритет, ответственный, оценка и списанные трудозатраты. Поэтому, интеграционный адаптер к Jira со стороны Skillflex имеет тот же интерфейс, что и к Yandex Treaker. Остальная специфика (как правило, статусы задач и их типы) приводится к общему знаменателю через маппинг их значений, доступный через настройки. Пока подобная модель данных существует только для создания пользователями кастомных отчётов и недоступна для настроек quality gate.
Заключение
В качестве ответа на проблемы организации проектного офиса для нового, расширенного вследствие присоединения новых команд к «Рексофт», портфеля был выбран подход ситуационной инженерии, описанный стандартом OMG Essence. На настоящий момент основные базовые принципы Essence адаптированы и внедрены, применяются и признаны эффективными.
Я не утверждаю, что ситуационная инженерия и, в частности, Essence подходит абсолютно всем. Но если ваш портфель сильно диверсифицирован, а уровень рисков требует централизованного контроля то, кажется, это первое на что следует обратить внимание.
