Тренинг "Управление ИТ-проектами" пройдёт 19-20 мая 2012 в г. Минске

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

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

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

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

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

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

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

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

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

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

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

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

Эти и другие вопросы будут рассмотрены на тренинге "Управление ИТ-проектами" в Минске 19-20 мая 2012 г., который проводится командой iTrainings.ru в партнерстве с компанией Itransition.

Тренер: Константин Кондратюк

Аудитория

Курс предназначен для менеджеров среднего звена, руководителей проектов и специалистов.

Требуемые знания и профессиональный опыт

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

Программа тренинга (2 дня, 16 часов)