Авторы: Алексей Янчук, Константин Кондратюк
Представим, что к вам приходит проект-спонсор, выкладывает перед вами бриф проекта и спрашивает: когда можете сделать, и если нужны деньги - только скажите, деньги не будут проблемой. Почти что мечта, только с чего начать обсуждение будущего проекта:
Кто будет писать спецификации? или
Что на самом деле и к какому сроку хочет увидеть спонсор? или
Какую максимальную цену готов заплатить спонсор за проект?
По правде говоря, все элементы проекта взаимосвязаны. По большому счету, нет особой разницы, с чего начинать обсуждение. Спецификация трансформируется в оценку разработчика, оценка пересчитывается в бюджет. Как правило, первоначально рассчитанный бюджет слишком большой, поэтому идем назад: пересматриваем оценки, меняем спецификации. Поменяли -- прослезились: продукт-то получается вообще никакой. Возвращаемся в начало, и по новой... После нескольких итераций в итоге получаем спецификацию, оценку и бюджет, с которой все согласны.
Минус номер один -- игра в такой пинг-понг занимает много времени. Можно ли, если не избежать, то хотя бы сократить временные затраты? Чтобы не получилось, что обсуждали дольше, чем делали.
Нет ничего невозможного, хотя "договаривание" заинтересованных сторон это скорее игра, нежели точная наука. Здесь надо полагаться на чутье и умение делать оценки на начальных стадиях проекта. Если стоит цель сэкономить время, стоит рассматривать факторы в порядке их влияния на проект. Например, если бюджеты на разработку и эксплуатацию фиксированы, то планировать проект надо от них. Не имеет смысла тратить силы на написание спецификации, которую заведомо невозможно реализовать. Если стоит цель тянуть время в силу разных причин, то стоит рассматривать факторы в порядке обратном их влияния.
Минус номер два в пинг-понге "спецификация-оценка-бюджет-и-назад" в том, что он часто "садит на коня" спонсора или заинтересованные стороны. Поскольку оценки крайне редко пересматриваются в сторону уменьшения, а вносить изменения и дополнения в проект вроде как никто не запрещает, то проект из маленького простого на пару человеко-дней может вырости в большого монстра на пару человеко-лет. Заказчика, которому это надо оплачивать, такой поворот событий вряд ли может устроить. Его претензии вполне можно понять: ведь еще недавно говорили, что проект простой и маленький, надо вот только детали проработать. А после проработки деталей получилось, что проект огромный, сложный и неподъемный.
Такая ситуация случается всякий раз, когда разработчиков просят выдавать оценку по требованиям, сформулированным на скорую руку. Такая оценка будет всегда заниженной, подчеркиваем - всегда, потому что разработчики в лучшем случае забыли или не учли половину задач. А напомнить им об этом может только более-менее полная спецификация вместе с качественно проведенным планированием.
В нашем опыте следующий подход почти всегда дает результат и бережет нервы:
Заказчик формулирует идею в любой ему понятной форме;
Обсуждается идея на уровне принципиальной возможности или невозможности, и на какой квартал ее можно запланировать;
Заказчик прорабатывает требования и уточняет детали. Происходит обсуждение новых деталей, чтобы понять, не стала ли задача гораздо больше;
Бизнес-аналитик пишет спецификацию. Задача спецификации - проработать вопросы как бизнеса, так и разработчиков о том, как целевое решение должно себя вести в различных ситуациях, ответить на возникающие вопросы;
Заказчик подписывает спецификацию;
И только после этого разработчиком официально объявляются: ресурсы, дата старта, дата начала фазы тестирования, дата запуска в эксплуатацию.
Будет ли заказчик ждать до самого конца, чтобы услышать дату (бюджет и т.д.) -- ну когда же его решение будет готово? Естественно, нет. С изрядной долей вероятности будет очень настойчив, чтобы разработчики чем скорей "разродились" ей. Что делать тут разработчику?
Все зависит от того, какие отношения сложились между заказчиком и исполнителем. Наш опыт показывает, что более-менее адекватную оценку можно дать, когда в спецификации полностью проработаны все ключевые вопросы, а это как привило значит, что спецификация закончена на 80%. Давая оценку раньше, вы всегда рискуете либо выдать слишком завышенную, либо, что более вероятно, слишком заниженную. Мы сами стараемся избегать называть любые даты или цифры раньше, чем спецификация готова на эти 80% -- даже когда работаем с теми заказчиками, с которыми сотрудничаем годами.
Остался один вопрос: что делать бизнесу в случае, если в конечном итоге разработчики не могут сделать проект в желаемых рамках, будь то календарь, бюджет или функциональность? Эти и другие вопросы будут рассмотрены на тренинге "Управление ИТ-проектами" в Минске 19-20 мая 2012 г., который проводится командой iTrainings.ru в партнерстве с компанией Itransition. Скачать программу и зарегистрироваться на тренинг вы можете здесь.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.