Консалтинговые ИТ-проекты в стиле Agile?06.06.2016 17:03

Наверное, рассказывать о том, что такое 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» возможны. Мы даже их делаем. Будем рады услышать вопросы и комментарии по данной теме, в том числе с учётом специфики отечественных компаний и организаций.