Когда мы говорим про проект с фиксированным бюджетом, то в первую очередь в голову приходят жесткие сроки и детально согласованные требования, без которых начинать разработку нельзя. Но чаще случается, что у клиента есть определенный бюджет на разработку и совсем нет желания платить отдельно за предпроектную аналитику.
Для продажника — это клиент мечты. Наобещаем золотые горы, подпишемся под любые сроки и, наконец-то, заветные бонусы за подписанный договор.

Что происходит дальше? Если посмотреть со стороны на отношения заказчиков и аутсорсеров, то в 90% случаев они напоминают два враждующих лагеря. Одни обвиняют друг друга в вечном срыве сроков и завышении бюджетов, другие — в непрофессионализме и “саминезнаютчегохотят”.

Послушав очередные жалобы на эту тему, захотелось поделиться своим опытом заказной разработки в качестве менеджера проектов. Речь пойдет об истории 2009-2011 года. Заинтересованные в практических вопросах приглашаются в комментарии.

Нет времени объяснять, просто делай!

Большинство заказчиков не хотят тратить деньги на то, чтобы мы собирали требования, писали большие спеки, которые будут месяцами согласовываться, и только после этого оценивали бюджет на разработку.
Почему? На это просто нет времени.
Так и в нашем случае: сроки запуска проекта были согласованы внутри компании на многочисленных комитетах задолго до того, как нашли исполнителя, т.е. нас.

Пальцем в небо

Итак, что у нас есть:
— новый заказной проект,
— заказчик, с которым мы ранее не работали и он к нам не лоялен,
— представитель заказчика — директор одного из направлений в компании, хорошо разбирается в своем бизнесе, но ничего не знает про IT, слово agile никогда не слышал.
— привык мыслить и работать в классическом водопадном подходе.

По сути у нас нет ничего. Нам нужно подписать договор на какую-то определенную сумму. Не имея ничего, мы эту сумму назвать не можем.

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

После этого до момента старта проекта проходит какое-то время, например, месяца два-три. И вот команда приступает к работе над проектом, смотрит и ужасается. Просто волосы на голове встают дыбом. Кто это оценивал? (Скорее всего кто-то из них или даже все вместе).
Это ужас, что там написано: крайне оптимистичные, просто нереальные оценки.
Мы наобещали заказчику, что сделаем такой-то функционал, на деле оценили неправильно, и получилось, что мы уже съели свою маржу, еще и в минус можем уйти. Я уже не говорю про срыв сроков.

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

Короткие этапы в контракте

Итак, вернемся к нашей истории. Масштаб работ непонятен, что должно получится на выходе — тоже, срок запуска сдвинуть нельзя и есть фиксированная стоимость. Начинаем работать. Мы подписали договор, в котором зафиксировали список высокоуровневых требований и разбили их на этапы, то есть через три месяца мы делаем первый релиз, еще через месяц – второй, еще через месяц – третий и т.д. При этом общий бюджет проекта также поделен на этапы, каждый этап мы будем закрывать актом выполненных работ.

Итерация 0. Время аналитики

На этой итерации мы еще стоим в чистом поле. Закладываем не больше 2-х недель. В ситуации, когда нет времени на детальную проработку требований, нужно очень внимательно отнестись ко всей информации, полученной от клиента.
Я называю подобные интервью открытыми, когда мы приходим к нему и стараемся буквально вытягивать всю информацию. Очень важно, чтобы этим занимался действительно профессионал, который умеет стоить такие интервью и правильно задавать вопросы.

По сути, мы формируем требования заново: расписываем, приоритезируем их вместе с заказчиком. Кстати, можно почитать мою небольшую заметку по поводу декомпозиции требований и их приоритезации.

Все требования разбиваются на множество пользовательских историй (user story) – максимум 2-3 странички. На их основе мы предлагаем свое решение заказчику.
Здесь важно почувствовать разницу! Мы не спрашиваем еще раз: «А как ты хочешь, чтобы мы вот это реализовали?»
Мы сами предлагаем ему варианты, потому что это в наших интересах. Заказчик читает: «Да, мне нравится». Отлично. Согласовали.

Все это нам понадобится потом, когда заказчик вдруг что-то захочет изменить (а он обязательно захочет изменить уже сделанное), чтобы это пошло как дополнительная user story, а не как изменения за наш счет.

Постоянное изменение требований — это прекрасно

Наша работа разбита на итерации, в конце каждой из них мы демонстрируем заказчику результаты.
И тут начинается… как из рога изобилия сыпятся изменения и дополнения, которые непременно нужны. А мы радуемся и говорим ему: «Скажи нам, что ты хочешь еще?»

Казалось бы, у нас есть проект, с фиксированной стоимостью, а на демонстрациях мы опять собираем новую информацию. На первый взгляд выглядит так, будто мы сошли с ума.

Это очень важный момент.

На самом деле, изменения требований — это действительно прекрасно:
— заказчик никогда изначально не знает, что он хочет, в деталях.
— мы позволяем ему постоянно предлагать что-то новое,
— и мы это реализуем в рамках того бюджета, который мы изначально согласовали.

Главное, соблюдать правило: «Если вы что-то добавляете, то что-то удаляете».

Снижение рисков проекта

Почему же нам хорошо, когда мы собираем новые требования и действительно, меняем scope проекта? Потому, что мы даем более точные оценки по новым требованиям, ведь наши знания о проекте с течением времени разработки растут.
Если на начальном этапе мы могли основываться только на своих догадках, то в середине проекта мы можем делать новые оценки с большой точностью. Сколько займет реализовать отличия? Мы берем уже маленькие кусочки проекта, и можем оценить работы с точностью до дня.

Как оставаться в рамках бюджета

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

Каждое пожелание оцениваем, а заказчику остается планировать релизы с учетом времени и оставшейся суммы. Помните? Стоимость договора на этапы. То есть у нас был исходный бюджет проекта, например, 10 миллионов, и мы уже выработали 2 тысячи часов, которые 4 миллиона, и, например, 6 миллионов осталось. Теперь он может из очереди нереализованных требований, которую сам постоянно приоритезирует, выбрать задачи на оставшиеся 6 миллионов.

Фактически, с полностью договора по фиксированной стоимости мы переходим на T&M контракт, но с ограничением по дате и бюджету. Однако, если мы потратим на фичу не 20 часов, а 100 часов, нам никто не заплатит за это. Но мы оцениваем маленькие фичи. Мы говорим конкретно: «Я думаю, эту мы сделаем за 3 дня, эту за 5 дней, эту за 10 дней». Наши риски минимальны.

Конечно, все это огромный труд, в первую очередь, аккаунт-менеджера — человека, который выстраивает доверительные отношения с заказчиком и вовлекает его в процесс, следит за сбором информации и согласовывает пользовательские истории, в конце концов, отвечает за то, чтобы заказчик был доволен. В этом, кстати, одна из целей agile — быть на стороне заказчика.

Счастливый финал с ложкой дегтя

Что было у нас интересного? Мы действительно выпустили через три месяца первый релиз, который пошел в продакшн, которым начали пользоваться клиенты, то есть компания начала уже получать прибыль с нашего продукта. Мы уложились в бюджет и сроки.

Но при этом у заказчика в голове все равно такой прекрасный золотой ларец — идеальный большой продукт, но денег – коробочка, ограниченная в размере. И получается такой психологический момент, с которым наш заказчик, к сожалению, не смог справиться: «Я вам плачу деньги, а вы мне сделали не все».

Но тем не менее, продукт продолжил свое развитие, мы выпустили еще много релизов, и для следующих своих проектов этот заказчик выбирал только нас. А это значит, у нас все получилось!

В одном из следующих рассказов напишу про более поздние проекты 2014 года, будут интересные различия, появятся дополнительные аспекты концепции и совершенно новый подход к аутсорсингу.

Еще обещаю опубликовать пример Agile-контракта с фиксированными ценой и датой, но плавающим скоупом — из наших реальных проектов.