Привет!
Не раз сталкивался с мнением, что менеджеру проекта необязательно разбираться в бизнесе заказчика, для которого он и его команда разрабатывают продукт или услугу. Дескать, есть спецификация – её и держись. Я с таким подходом совершенно не согласен, т.к. понимание бизнес целей заказчика позволяет руководителю проекта предлагать заказчику решения, которые ему самому могут и не прейти в голову. А помощь заказчику на этапе принятия решений о требованиях к будущему продукту или услуге является одним из признаков хорошего менеджмента, на мой взгляд.
Уже больше года я руковожу рядом проектов в рамках одной программы, реализуемой для крупной российской компании, услугами которой пользуется, наверное, пятая часть населения страны. Один из проектов в рамках этой программы – разработка web-сайта для миллионной аудитории клиентов данной компании. Бизнес заказчиков этого сайта несколько: отдел маркетинга, отдел продаж, отдел работы с партнёрами компании и верхушка в лице нескольких заинтересованных лиц. И у всех этих заказчиков свои бизнес цели и, соответственно, свои требования к сайту и его функционалу. На выявление и документацию только бизнес требований всех заинтересованных сторон ушло два месяца очень и очень плотной работы – постоянные встречи, опросы, интервью, формулировка всего услышанного на бумаге и согласование. Я, как менеджер этого проекта, старался присутствовать на всех подобных встречах. Когда, наконец, все требования бизнеса были документированы и согласованы начался этап сбора функциональных и нефункциональных требований, но это отдельная история.
По плану, первую версию сайта мы должны были запустить в промышленную эксплуатацию 29 октября. Из-за серьёзных задержек в поставках оборудования со стороны наших заказчиков случился риск, который присутствовал в плане управления рисками проекта, и я оповестил руководство компании и заказчиков о том, что дата выпуска сайта сдвигается на определённое количество дней в связи с задержками. Заказчики восприняли такую задержку нормально, т.к. проблема возникла на их стороне.
Через пару дней представитель отдела работы с партнёрами компании нашего заказчика звонит и говорит, что 1 ноября сайт должен работать кровь из носу и (внимание!!!) содержать новую функциональность, которая критична для партнёров. И сделать это нужно именно к 1 ноября, т.к. уже заключены ряд договоров с партнёрами компании. И в этих договорах прописаны пункты, согласно которым компания заказчика должна 1 ноября предоставить определённые сервисы клиентам партнёров посредством web-сайта, иначе – штрафы. С таким подходом (сначала заключаем договоры с указанием сроков, потом ставим в известность исполнителей), я думаю, встречались многие.
Что тут началось… Спонсор проекта со стороны заказчика звонит моему руководству и говорит, что 1 числа сайт должен работать и точка! Моё начальство звонит мне, предлагает взять в команду ещё людей, порвать тельняшки, ни шагу назад, за нами Москва и т.д. и за оставшийся месяц реализовать новую функциональность, провести полный цикл тестирования и установить сайт на пока отсутствующее железо =) Одним словом, запахло управленческим беспределом.
На предложение добавить людей в команду разработки сайта я сразу сказал “НЕТ!”. Согласно правилу Брукса, уже подтверждённому и моим опытом тоже, инъекция “неподготовленных” людей в проект разработки программного обеспечения, находящийся в завершающей фазе, лишь усугубляет ситуацию со временем окончания проекта. Это факт! Предложение “порвать тельняшки” в данном случае меня тоже не вдохновило, т.к. тельняшки рвать имеет смысл тогда, когда и менеджер и команда на 100% уверены в том, что после трёх недель работы по 14 часов в сутки они наверняка успеют и сделают то, что удовлетворит и их (команду разработки) и заказчика. Иначе, если три недели пота и крови заканчиваются разочарованием заказчика из-за нереализованных требований и неудовлетворённостью команды, общий моральных дух команды резко падает, желания работать и мотивация снижается ниже плинтуса. Хороший PM, на мой взгляд, никогда не должен допускать такой ситуации, т.к. люди в конечном итоге всегда важнее любых сроков.
Я сел и стал думать, что можно сделать, имея жёсткие временные ограничения, новые требования к функционалу и свободные ресурсы, не занятые на разработке сайта, но и не имеющие представления о проекте. В итоге, двигаясь в своих размышлениях снизу вверх, я дошёл до того, с чего, по-хорошему, нужно было начинать с самого начала. С бизнес требований данного конкретного заказчика. И подумав о бизнес целях, ещё раз их проанализировав, я понял, что отделу работы с партнёрами нужен на самом деле не сам сайт целиком, со всем его наполнением и возможностями, а только небольшая часть функционала, покрывающая потребности данного бизнес заказчика. Я прикинул, что если собрать, как пишет ДеМарко, “команду тигров” (команда из двух-трёх человек, способных “порвать” всё что угодно – реализовать любое сложное техническое решение в кратчайшие сроки =), то вполне можно реализовать до нужного срока отдельный сайт с ограниченным функционалом, который полностью покроет требования заказчика. Таким образом, минимизируются риски срывов сроков разработки, риски связанные с дальнейшими возможными проблемами с поставкой оборудования (т.к. этот небольшой сайт можно будет развернуть на существующем железе) и с переутомлением команды, занимающейся разработкой основного сайта. Красота =)
Сделав предварительную оценку трудозатрат и сроков, я позвонил заказчику и рассказал ему своё предложение. Заказчик был в восторге от такого решения, т.к. его полностью устраивало такое решение с учётом того, что на уровне БД и сервисов этот отдельный сайт будет совместим с основным и в будущем нам будет легко мигрировать все данные и функционал.
В итоге, за неделю мы совместно с заказчиком провели детальную аналитику, написали и согласовали функциональную спецификацию, распланировали дальнейшие работы и приступили к разработке. Все счастливы и довольны =)
Лишь понимание того, для чего именно в конечном итоге нужен web-сайт отдельно взятому бизнес заказчику, позволило мне принять оптимальное, на мой взгляд, решение.
