Заказчик выдает неадекватные требования — что делать руководителю проекта

«Я люблю клубнику. Но если я собираюсь ловить рыбу и стану кормить ее клубникой, то не поймаю ни одной рыбешки».

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

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

Кто виноват, и как избежать таких ситуаций?

Посмотрим, что на эту тему нам говорит теория управления проектами. 

По определению из классического подхода к управлению проектами, Руководитель проекта — лицо, назначенное возглавить команду и отвечающее за достижение целей и результатов проекта. Заказчик, по определению, — лицо или группа лиц, которые будут пользоваться результатами проекта. Важно не путать роль Заказчика в методологии управления проектами и роль Заказчика в юридическом контексте договорных отношений. Например, в строительном проекте роль Заказчика принадлежит тем, кто в будущем будет эксплуатировать построенное здание. А в проекте внедрения ИТ-системы Заказчиками являются будущие пользователи этой системы или их представители. У Заказчика в проекте есть ответственность — в начале проекта он должен утвердить будущие результаты проекта, а по окончании проекта принять полученные результаты.

Как в классическом, так и в адаптивном подходе к управлению проектами одним из первых шагов руководителя проекта является сбор требований. Требования при этом может выдавать дает не только Заказчик, а более широкий круг лиц, именуемый стейкхолдеры (заинтересованные стороны). По определению, стейкхолдеры — лица или организации, которые могут позитивно или негативно повлиять на исполнение или завершение проекта. Пример стейкхолдера — государственные надзорные органы в строительных проектах. Они не будут пользоваться результатами проекта, но их требования являются определяющими. 

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

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

Вернусь к вопросу, вынесенному в заголовок. Так что же делать, если Заказчик и прочие стейкхолдеры выдают некорректные на ваш взгляд требования и требуют в рамках проекта создавать результат, который в дальнейшем не принесет никому никакой пользы? Исходя из лучших международных практик управления проектами и логики здравого смысла возникает три варианта действий.

1. Переубедить стейкхолдеров

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

2. Делать то, что вам говорят

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

Конечно, при этом сценарии у Вас есть риск по окончании проекта услышать фразу: «Так вы же специалист, почему вы нам сразу не сказали, что требования некорректны?». Причем услышать вы ее можете даже в случае, если многократно предлагали требования поменять. Для того минимизировать подобный риск (именно минимизировать, потому что полностью исключить его невозможно), в подобных ситуациях крайне рекомендую «оставлять следы», то есть формально фиксировать Ваши предложения, хотя бы в формате письма по электронной почте. 

3. Уйти из проекта

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

Вот такая проза жизни.

Отдельно остановлюсь на вариантах «плохой практики» действий в рассматриваемой ситуации. Практика плохая, но, к сожалению, встречается достаточно часто — когда руководитель проекта занимает одну из двух приведенных ниже позиций:

1. Заказчик дал некорректные требования, поэтому я делаю так, как я считаю правильным, а не так, как требует заказчик.
2. Сижу в роли «обиженного», работаю спустя рукава и делаю халтуру, потому что мои идеи и предложения здесь не ценят.

Такие варианты действий лучшими международными практиками управления проектами не предусматриваются.