Наверное, рассказывать о том, что такое Agile, уже никому не нужно. И особенно про Agile в проектах, где есть постановка задачи и разработка софта. Про это всё хорошо рассказано много раз. Другое дело – когда это консалтинговые проекты, где речь, как нас всех учили, идёт о «процессах, людях, технологиях». В таких проектах мы не просто ставим задачу разработчикам, а они выдают правильный и быстрый результат. Мы ещё и проводим организационные изменения, проектируем процессы, много работаем с людьми, передаём им знания.
Консультанты Hewlett Packard Enterprise выполняют подобные проекты в области управления ИТ: ITSM, управление проектами и портфелями, мониторинг на любом уровне и т.д.
В последние пару лет во всём мире мы сталкиваемся с тем, что заказчики всё чаще просят или активно настаивают на применении подхода Agile к реализации подобных проектов. Уже и в России появились такие прецеденты.
Понятное дело, что за многие годы подход к реализации консалтинговых проектов в области управления ИТ был отработан в HPE на «пять с плюсом». Тысячи реализованных проектов по всему миру, огромное количество выученных уроков и строгая методология, которая говорит, как правильно. И это всё, разумеется, в формате waterfall. То есть «Пуск проекта», «Проектирование», «Создание», «Развёртывание и опытная эксплуатация». «Пришёл, увидел, победил».
Зачем
Здесь всё просто – заказчику нужен результат как можно быстрее. Посудите сами. Возьмём почти любую российскую компанию среднего или крупного масштаба:
1. Планирование бюджета начинается где-нибудь в августе:
- формируем инициативы,
- они оцениваются и «просеиваются» через сито экономической эффективности,
- превращаются в проекты,
- потом кто-нибудь пишет к ним детальные требования,
- и появляется соответствующая строчка в ИТ-бюджете.
2. В начале года берём бюджет и играем тендер – процедура занятная и мало где быстрая.
3. В марте, если повезёт, начинаем работы.
4. Результаты надо так или иначе выдать в конце года, ведь у всех KPI (как на стороне заказчика, так и на стороне подрядчика).
Итого: жизненный цикл проекта от инициативы до результатов проекта – порядка одного года-полутора лет. Это очень долго.
Что не так
Причин у такой ситуации несколько, но как минимум:
- Бюджетные и тендерные процедуры «победить» (сократить их сроки) тяжело. После 4-6 месяцев от появления инициативы до итогов тендера требования заказчика могут поменяться, пусть и в рамках той же темы. Нужен инструмент для гибкой переприоритизации задач.
- В рамках проекта работать по waterfall заказчик, конечно, тоже привык. И это написано во всех его внутренних регламентах, стандартах по управлению проектами и т. д. Но ждать результатов 6, 9 или 12 месяцев – очень скучно. Опять же, за это время уже в ходе реализации проекта многое может поменяться. Да если и не поменялось, результат хочется получать по частям и сразу же использовать его в работе.
Что делать
Заказчик должен понять, что выделять деньги под решение конкретных задач – прошлый век. Постановка задач, как мы уже выяснили, успевает часто меняться в ходе реализации этих задач. Поэтому деньги нужно выделять на развитие какого-то магистрального направления (в случае консалтинговых проектов, которые делает наша компания – на ITSM, управление портфелями и проектами, на мониторинг инфраструктуры или услуг и т.д.), задавая определённый вектор развития, но не конкретные требования и результаты. Безусловно, это потребует изменения способа , перестройки внутренних процедур, но без этого – никуда.
Кроме того, нужно обеспечить гладкое прохождение организационных изменений, изменений в способах работы людей. Во многих организациях мы сталкиваемся с тем, что люди привыкли к быстрым и многочисленным изменениям – обычно это результат «ручного управления» на том или ином уровне в организации. Нужно использовать лучшие практики управления организационными изменениями – MoC, Management of (Organizational) Changes – в том числе, чтобы показать людям, что эти изменения не носят хаотический характер, а обеспечивают тот самый вектор развития, который был задан ранее.
Наконец, если мы говорим именно о консалтинговых проектах, то мы в HPE используем так называемую «модель бутерброда» (sandwich model):
- В начале проекта формируется исходный backlog задач, которые нужно реализовать. Можно считать это «микропроектированием», похожим на то, как мы проектируем процессы и функциональные требования к системе в рамках подхода waterfall.
- Данный backlog приоритизируется, как велит нам, например, ScrumXP. Далее работаем в режиме Agile, требования могут корректироваться и меняться. Разумеется, необходима жесткая дисциплина, наличие соответствующих ролей (product owner, scrum master и т.д.). Параллельно с разработкой кода пишем необходимые документы, готовим организационные изменения (кстати, в рамках DevOps есть мантра «everything is code», которая очень хорошо трансформирует сознание процессных консультантов).
- От понятия проекта мы всё равно не избавимся, когда работаем в связке «заказчик-подрядчик». А проект по определению – это ограниченная во времени деятельность. Поэтому Agile-историю в какой-то момент нужно подытожить, и сдать заказчику результат проекта (возможно, снабдив его необходимой дополнительной бюрократией). Кстати, это совсем не значит, что работа завершена – заказчик, привыкнув к тому, что в рамках середины «бутерброда» (п. 2) он регулярно получает новые релизы и новую ценность, с большей охотой и заранее будет готов позаботиться о продолжении работ и о выделении новых средств.
Как можно видеть, мы обворачиваем Agile с двух сторон waterfall-ом, что позволяет, с одной стороны, делать релизы и выдавать ценность заказчику чаще, с другой стороны, за счёт начала и окончания проекта, близкого к подходу waterfall, внешне проект выглядит как нечто, что имеет начало и конец. Это необходимо, в т. ч., потому что заказчики очень часто хотят реализовывать даже Agile-проекты по схеме fixed price, а не по схеме time & material.
Данная тема нам кажется весьма перспективной, и уже сейчас идут достаточно много проектов в таком формате. Например, есть крупный проект в компании, работающей по всему миру, где между релизами product owner собирает до 200 ключевых пользователей системы со всего мира, им демонстрируются результаты работы, а с них собирается обратная связь и при их помощи добавляются новые пункты в backlog. Это лишь небольшой штрих, показывающий возможный масштаб таких проектов, ведь традиционно Agile хорошо живёт в небольших командах. Впрочем, когда мы говорим об уровне предприятия, на помощь приходит SAFe, о котором мы уже рассказывали.
Подводя итог, хочется сказать следующее: консалтинговые проекты в формате Agile или «почти Agile» возможны. Мы даже их делаем. Будем рады услышать вопросы и комментарии по данной теме, в том числе с учётом специфики отечественных компаний и организаций.
Автор: Hewlett Packard Enterprise
