Применение Agile в рамках договора с фиксированными фазами

Вы руководитель нового проекта заказной разработки. Вам принесли договор, неизвестно кем и как заключенный, дали контакты заказчика и дальше вы предоставлены сами себе. Изучив функциональный объем проекта, вы понимаете, что в данном случае было бы правильно применить Agile. Но в договоре уже прописаны четкие фазы в соответствии с каскадной моделью разработки (waterfall) со сроками, результатами и фиксированной ценой по каждому этапу. Что делать в этой ситуации?

1. Подготовка проекта

Убедитесь, что именно для вашего проекта методология Agile и высокая итеративность циклов разработки дают существенные преимущества. Если, например, вы строите гидроэлектростанцию, то начать с небольшого гребного колеса и постепенно его наворачивать, будет не самой лучшей идеей. То же самое касается масштабного внедрения ERP системы, когда над каждым модулем работает отдельная проектная команда, все они должны быть интегрированы и заработать одновременно – тут без качественной проработки блюпринта и единого поэтапного плана не обойтись. Но если ваша задача достаточно локальна, у вас компактная проектная команда, тесное взаимодействие с заказчиком, то есть все предпосылки чтобы использовать Agile.

2. Этап концептуального проектирования

Итак, в соответствии с методологией Agile вы определили минимальную функциональность, которая имеет для заказчика наибольшее значение и в кратчайшие сроки запустили ее в продуктивную эксплуатацию. Далее начинаете раз в две недели выкладывать обновления, добавлять функции и исправлять замечания. Первая засада поджидает вас, когда подойдет срок сдачи этапа проектирования по договору (рис 3).

Рис. 3 Закрытие этапа Проектирования

По договору к этому моменту вы должны сдать ТЗ на весь функционал, а вы толком его и не обследовали, потому что были заняты запуском первого релиза. Что делать? На самом деле ничего страшного в этом нет, вы просто сдаете ТЗ в котором весь функционал описан очень высокоуровнево (можно прямо скопировать формулировки из договора), а по функциям которые вы уже обследовали или даже уже внедрили даете детальную спецификацию. Практически всегда заказчик отнесется к этому лояльно. Он получил наиболее важный для него функционал очень быстро, замечания исправляются оперативно, у него нет причин не доверять вам, ему не терпится двигаться дальше, и он легко подпишет какое-то формальное ТЗ.

Кстати, это очень хороший момент, чтобы пересмотреть функциональный объем проекта. У заказчика уже могут появиться пожелания по уже внедренному функционалу. И у вас есть отличный шанс обменять эти небольшие, понятные и нужные заказчику допфункции на мутные и опасные куски требований из договора. Просто договоритесь о такой замене с заказчиком и зафиксируйте ее в ТЗ без изменения стоимости договора и подписания допсоглашений.

3. Этап реализации

Настоящая засада ждет вас дальше, когда подойдет срок сдачи этапа реализации.

Рис.4 Закрытие этапа Реализации

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

• Надо заранее объяснять заказчику, почему вы придерживаетесь методологии Agile. Рассказывать про бесперебойную поставку ценного ПО, снижение рисков и все такое прочее.
• Можно нарисовать схему, похожую на рис. 4 и наглядно показать, что половина работ выполнена, поэтому вы хотите получить половину денег.
• Очень хорошо, если у вас будут критичные дефекты по функционалу находящемуся в продуктивной эксплуатации. Вы говорите: «Как же так, вы хотите, чтобы мы вам устраняли дефекты, то есть выполняли работы по этапу 4, а вы нам еще за этап 2 не заплатили?». Если внедряемая система действительно полезна заказчику – это хороший рычаг воздействия.
• Чтобы заказчику было психологически проще подписать вам акт, можно попробовать для оставшегося функционала реализовать в системе заглушки: неработающие пункты меню, интерфейсы без реализации и т.п. При этом объяснять, что все это будет реализовано на этапе внедрения, по уже привычной ему итеративной схеме.
• Можно заявить, что заказчик сам виноват в сложившейся ситуации, потому что не мог сразу сформулировать все требования. А вы пошли ему на встречу и позволили формулировать требования постепенно на протяжении всего проекта.
• Постоянно напоминайте, что это только вторая фаза и до конца проекта еще далеко.
• Ну и применяйте все остальные стандартные средства из арсенала проджект-менеджера: просьбы, манипуляции, изматывание, угрозы, шантаж. На этом этапе все средства хороши.

4. Этап внедрения

После подписания акта по этапу реализации дальше можно расслабиться. Больше никаких подводных камней из-за несоответствия вашей методологии и договора не предвидится. Просто посмотрите, какие отчетные материалы вы должны сдать по этапу внедрения. Обычно там какие-нибудь протоколы миграции данных, протоколы обучения пользователей, инструкции и т.п. Если до этого вы все делали правильно, то у вас эти документы уже подписаны в части внедренной функциональности. И самое главное, их подписание у вас поставлено на поток. Заказчик, рутинно подписывая очередной протокол обучения, даже не заменит, что это был последний протокол необходимый для закрытия этапа внедрения.

Рис.5 Закрытие этапа внедрения

5. начальное сопровождение промышленной эксплуатации

То же самое с этапом начальной поддержки промышленной эксплуатации. Вы с первого месяца работы над проектом приучили заказчика, что он по любому поводу выставляет дефекты в системе багтрекинга, а вы их оперативно отрабатываете. Заказчик уже понимает, чем баг отличается от нового требования, как приоритезируются дефекты и почему нельзя всем дефектам ставить критичный приоритет. Когда подойдет срок закрытия этапа начальной поддержки, вы просто выгружаете все дефекты заведенные заказчиком на протяжении проекта, оформляете в красивый отчет со всякой статистикой и графиками, и вместе с актом направляете заказчику. Желательно, чтобы на этом этапе критичных дефектов у вас не осталось. Единственное, что остается, объяснить заказчику, что ваш проект подошел к концу, а чтобы дальше исправлять дефекты надо заключить отдельный договор на сопровождение системы.

Если вы следовали этим рекомендациям, то вы реализовали все преимущества методологии Agile, то есть получили полезный продукт максимально соответствующий потребностям заказчика. При этом уложились в сроки и бюджет, первоначально заданные в договоре.