Авторы: Алексей Янчук, Константин Кондратюк

Представим, что к вам приходит проект-спонсор, выкладывает перед вами бриф проекта и спрашивает: когда можете сделать, и если нужны деньги — только скажите; деньги не будут проблемой. Почти что мечта; только с чего начать обсуждение будущего проекта:

• Кто будет писать спецификацию, или
• Что на самом деле и к какому сроу хочет увидеть спонсор, или
• Какую максимальную цену готов заплатить спонсор за проект?

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

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

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

Нет ничего невозможного; хотя «договаривание» заинтересованных сторон — это скорее игра, нежели точная наука; здесь надо полагаться на чутье и умение делать оценки на начальных стадиях проекта. Если стоит цель сэкономить время, стоит рассматривать факторы в порядке их влияния на проект. Например, если бюджеты на разработку и эксплуатацию фиксированы — то планировать проект надо от них. Не имеет смысла тратить силы на написание спецификации, которую заведомо невозможно реализовать. Если стоит цель тянуть время — в силу разных причин, — стоит рассматривать факторы в порядке, обратном их влияния.

Минус номер два в пинг-понге спецификация-оценка-бюджет-и назад в том, что он часто «садит на коня» спонсора или заинтересованные стороны. Поскольку оценки крайне редко пересматриваются в сторону уменьшения, а вносить изменения и дополнения в проект вроде как никто не запрещает, то проект из маленького простого на пару человеко-дней может вырости в большого монстра на пару человеко-лет. Заказчика, которому это надо оплачивать, такой поворот событий вряд ли может устроить. Его претензии вполне можно понять: ведь еще недавно говорили, что проект простой и маленький — надо вот только детали проработать. А после проработки деталей получилось, что проект — огромный, сложный и неподъемный.

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

В нашем опыте следующий подход почти всегда дает результат и бережет нервы:

1. Заказчик формулирует идею в любой ему понятной форме;
2. Обсуждается идея на уровне принципиальной возможности или невозможности, и на какой квартал ее можно запланировать;
3. Заказчик прорабатывает требования и уточняет детали. Происходит обсуждение новых деталей, чтобы понять, не стала ли задача гораздо больше;
4. Бизнес-аналитик пишет спецификацию. Задача спецификации — проработать вопросы как бизнеса, так и разработчиков о том, как целевое решение должно себя вести в различных ситуациях, ответить на возникающие вопросы;
5. Заказчик подписывает спецификацию;
6. И только после этого разработчиком официально объявляются: ресурсы, дата старта, дата начала фазы тестирования, дата запуска в эксплуатацию.

Будет ли заказчик ждать до самого конца, чтобы услышать дату (бюджет и т.д.) — ну когда же его решение будет готово? Естественно нет. С изрядной долей вероятности будет очень настойчив, чтобы разработчики чем скорей разродились ей. Что делать тут разработчику?

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

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