Путеводитель по бюджетированию проектов: Waterfall или Agile?

Сколько стоит построить самолет? Мы легко можем подсчитать это, ведь типовой самолет – это «коробочное решение». А сколько стоит построить новый тип самолета с двигателем на новых физических принципах, из неизведанных материалов, который при этом выполняет несвойственные самолетам функции – скажем, бурение нефтяных скважин? Хм… Примерно так выглядит бюджетирование проекта по разработке нового программного продукта.

В постоянно меняющейся высокотехнологичной среде оценить бюджет проекта очень не просто. Но ведь есть набор моделей CMMI и каскадная модель разработки (Waterfall), которые позволяют точно рассчитать бюджет? Да, только если команда выполнила уже сотню проектов подобного типа и может ручаться за отсутствие рисков. Конечно, хороший план поможет увидеть, как сильно мы отклоняемся от желаемого пути, но вряд ли ответит на важный вопрос – почему? В реальной жизни каскадная модель вовсе не гарантирует предсказуемости, не говоря уж о динамичной методологии Agile.

Глядя на «водопад»

Многие думают, что каскадная модель подразумевает фиксированный бюджет. Очевидно, они путают модель разработки продукта и сам продукт, который, в свою очередь, должен иметь предопределенную/ожидаемую стоимость, качество и время выхода на рынок. Во многих случаях это можно фиксировать.

В целом, консервативные подходы к разработке ПО, такие как Waterfall, в сочетании со сложными процессами типа CMMI, IEC 62304 или DO-178B помогают быстрее достичь конечной точки проекта: часто – с предопределенным качеством, иногда – в установленные сроки и очень редко – в рамках фиксированного бюджета. Это происходит даже в том случае, если проект типичен.

Для проектов модели Waterfall типовое распределение усилий следующее:

• проработка и уточнение требований – 10%
• дизайн – 10%
• собственно разработка – 40% (сюда же входят unit-тесты)
• тестирование – 40%
  • собственно тестирование (системное, нагрузочное и т.п.)
  • валидация (проверка соответствия продукта требованиям заказчика)
  • верификация (проверка правильности и качества разработки продукта)
  • приемочное тестирование

Важно понимать, что верификация и валидация – достаточно сложные процессы, которые зачастую существенно (до 2-х и более раз!) меняют стоимость проектов в ряде областей. Кроме того, проект может включать разворачивание в боевую систему, интеграцию с существующими системами, поддержку – и все это поверх исходного бюджета.

Приступая к разработке инновационного решения, мы вынуждены предусмотреть:

• процедуру управления изменениями, которая, как правило, увеличивает бюджет (хотя, если бюджет фиксирован, финансовые директора ни за что не согласятся его увеличить);
• и процедуру управления рисками (включая риск изменения требований), которая четко указывает на увеличение бюджета проекта в 2-4 раза.

Провайдер услуг встает перед нелегким выбором:

• добавить к оценке бюджета мультипликатор Х с высокой вероятностью потерять проект (вряд ли клиент сочтет повышение обоснованным)
• или понадеяться на низкие риски и выполнить оговоренный объем работ в установленный срок и в рамках бюджета – правда, выставляя себя «недостаточно гибким» партнером

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

Переоценивая Agile

Кое-что нужно прояснить сразу – не стремитесь к Agile только потому, что это модно! Сперва присмотритесь к своему проекту: будет ли «гибкая» модель работать на вас или лишь вытянет ваши деньги? Помните, что методология Agile полезна и эффективна в двух случаях:

• Проект предполагает исследование и разработку (R&D), т. е. инновационную деятельность, предпринимаемую компанией для разработки совершенно нового, технологически продвинутого продукта. Здесь трудно предсказать результаты: никто не гарантирует, что проект будет следовать заранее установленному плану, а результат оправдает начальные ожидания. Следовательно, мы должны учесть множество рисков (включая изменение требований), которые, в свою очередь, повлияют на бюджет.
• Проект предполагает разработку ПО для быстро меняющейся (например, мобильной) отрасли в очень короткие сроки (всего за пару месяцев). Технологии развиваются ежедневно, и мы не знаем, куда повернет рынок завтра. Требования могут устареть очень быстро. У нас есть общий план проекта на месяц вперед, но мы не можем зафиксировать объем работ – в изменчивой среде мы должны быть гибкими, а гибкость всегда стоит дороже.

Простая, но часто пренебрегаемая многими истина заключается в том, что Agile-проектам крайне необходима вовлеченность заказчика. Именно заказчик должен помочь команде разработчиков пройти ключевые этапы проекта. Очень важно, чтобы в «гибком» проекте был сотрудник на стороне клиента, готовый работать с инженерами 24/7. В вашей компании есть такой человек? Тогда вы и правда можете задуматься об Agile!

Методология Agile имеет несомненные преимущества: она обеспечивает гибкость, регулярную обратную связь и быструю реакцию на неожиданные движения рынка. Однако она не позволяет фиксировать бюджет проекта, а значит, требует участия мудрых и опытных проектных менеджеров со стороны провайдера.

Какую опцию выбрать?

Часто бывает сложно заранее оценить, сколько денег и времени требуется инвестировать в проект разработки ПО. Во многих случаях можно говорить лишь о векторе направления движения – так называемой «дорожной карте» разработки. Она обозначает основные этапы проекта, но в то же время оставляет пространство для изменений и экспериментов.

Разрабатывая «дорожную карту» вместе с клиентом, мы определяем необходимый набор параметров и функций будущего решения. Этот шаг очень важен, ведь мы работаем над коммерческими продуктами, и наше ПО должно соответствовать ожиданиям конечных пользователей. Это не зависит от того, используем мы Agile или другие подходы.

В проектах с неопределенным уровнем риска мы обычно договариваемся об MVP («минимально жизнеспособный продукт») с мультипликатором 2 или более. Если в проекте будет мало рисков, мы сделаем больше за те же деньги. Если риски будут высоки, заказчик все же получит продукт, обладающий минимальными, но достаточными функциями.

Для высокостандартизированных отраслей, таких как медицина и авионика, где наряду с базовыми (надежность, безопасность, соответствие стандартам и пр.) имеются дополнительные требования заказчика, мы предлагаем «смешанный» подход к бюджетированию и итеративную модель разработки, подразумевающую регулярные релизы и возможность корректировки требований на любом этапе проекта.

В итоге, какой бы подход вы ни выбрали, мудрое и дальновидное управление будет залогом успеха вашего проекта. Каждый проект уникален, и мы в Ауриге обеспечиваем индивидуальный подход к каждому клиенту: помогаем предусмотреть и снизить риски, избежать ошибок при планировании и бюджетировании проектов. Какие риски и что за ошибки, спросите вы? Об этом я расскажу в своих следующих статьях. Оставайтесь на связи!

— Вячеслав Ванюлин, Генеральный директор ООО «Аурига»

Источник.