Стратегия внедрения Agile в госсекторе и крупном бизнесе
Почему Agile, созданный для гибкости, с таким трудом приживается там, где он, казалось бы, нужнее всего – в госсекторе и крупных корпорациях? Рассказываем, в чем причина, и как работать с негибкими структурами.
Системный тупик
Представим типичную картину: госкомпания публикует ТЗ на разработку какой-либо системы. Поставщики предлагают цену за фиксированный объем работ. Контракт обязывает выполнить именно его. Изменить что-либо позже крайне сложно, даже если заказчик поймет, что часть функционала не нужна, а чего-то не хватает.
Подвох кроется в системе закупок: ее неповоротливость напрямую противоречит духу Agile. Вместо адаптивности здесь жесткое ТЗ и фиксированный объем, загоняющие в рамки «водопада». Но ТЗ априори не может учесть все – заказчики редко до конца понимают потребности на старте (для этого и создан Agile!). В госзакупках эта неопределенность становится тупиком. Добавьте обязательные ГОСТы, строгую последовательность выполнения работ и объем документации – и для гибкости просто не остается места.
Результат: потрачено
Итог предсказуем: формально работа ведется, контракт выполняется, но результат часто не соответствует реальным потребностям. Деньги и время уходят на ненужные функции, а критически важные возможности остаются за бортом или реализуются с запозданием и скрипом. Все участники процесса остаются, мягко говоря, недовольны.
Решение: «Водопад» с обратной связью
С госкомпаниями правила игры диктует система: работать придется строго по контракту, выполнять ТЗ до запятой и соблюдать все ГОСТы. Это данность. Но это не значит, что нужно поднять руки и плыть по течению. Работать можно и в русле старой доброй стратегии «водопад», которую обычно придерживаются госструктуры и при которой каждый следующий этап должен быть обязательно завершен перед переходом к следующему. Стратегия выживания и повышения качества результата в данном случае – это частое и регулярное вовлечение заказчика.
Внедрите практику демонстрации промежуточных результатов каждые 2 недели, даже если это прямо не прописано в контракте. Технически это несложно, но будет крайне полезно:
- Во-первых, это позволяет выявить несоответствия ожиданиям заказчика еще на ранних стадиях, до финальной сдачи проекта.
- Во-вторых, помогает прояснить все серые зоны и неоднозначности ТЗ, а, выявив их, найти разумные компромиссы.
- В-третьих, это хороший инструмент управления ожиданиями: вы можете мягко, но наглядно показать, что выходит за рамки текущего контракта.
- Наконец, эта тактика просто работает на формирование доверия.
Открытость, готовность к диалогу и использование экспертизы заказчика в процессе – залог более успешного результата. Да, если в процессе реализации системы выяснится, что часть требований ТЗ на самом деле не нужны, их все равно придется сделать. Но понимание этого заранее позволит минимизировать затраты на их реализацию, т.е. к их выполнению можно подойти более «формально». А простые дополнительные пожелания заказчика (если они не нарушают контракт) – это повод укрепить деловые отношения.
В итоге формально мы получаем все тот же «водопад», но с постоянной адаптацией и выравниванием курса в пределах возможного. Это не чистый Agile, но это значительно лучше строгого следования плану без обратной связи до самого конца.
Решение для крупного бизнеса: модули
С крупным бизнесом ситуация тоже сложная, но чуть более оптимистичная. Проблемы фиксированных ТЗ и бюрократии никуда не делись, однако в этом сегменте уже значительно больше компаний, признающих ценность гибких подходов. И здесь у вас появляется пространство для маневра.
Ваша эффективная стратегия – модульность и этапность. Вместо одного большого проекта с гигантским ТЗ предложите заказчику разбить систему на логические, относительно независимые модули и заключайте последовательные контракты. К примеру:
- сначала на разработку и внедрение Модуля 1 (по более четкому ТЗ с ограниченным функционалом).
- Затем, на основе результатов первого этапа и опыта работы с первым модулем, – контракт на Модуль 2 и на доработки Модуля 1.
- Далее – контракт на расширенное сопровождение системы, в рамках которого можно вносить доработки и улучшения, основанные на реальном использовании. И так далее.
Суть в том, что каждый модуль – это маленький «водопадный» проект. Но последовательность этих модулей и контрактов на их развитие создает цикличность, очень похожую на Agile. Требования к следующим шагам уточняются на основе реального опыта, и у вас есть возможность вносить изменения в уже работающие части системы.
Безусловно при таком подходе несколько увеличивается количество документации — для многих корпораций нет разницы в процедуре сдачи-приемки результатов работ по одному модулю и по всей системе в целом, но затраты на такие дополнительные (и, честно говоря, особо не приносящие реальной пользы) работы точно будут оправданы: заказчик получит именно то, что ему надо.
Гибкость – это прагматизм
Стоит признать — чистый Agile по учебнику в условиях госзакупок или консервативных корпоративных структур невозможен. Во всяком случае, на сегодняшний день. Но это не повод отказываться от его главных преимуществ – адаптивности и фокуса на ценности для заказчика. Успех кроется в прагматизме и гибридных подходах. Лучше с ходу признать неизбежные ограничения (особенно в госсекторе) и внедрять то, что дает максимальный эффект при минимальном конфликте с системой – а именно, регулярные демонстрации и обратную связь.
Объясняйте заказчику преимущества заключения контрактов на разработку небольших частей системы (модулей, сервисов и т.п.). И главное – постоянно управляйте ожиданиями заказчика. Да, гибридные модели могут означать чуть больше отчетности. Но игра стоит свеч.