Что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта

В предыдущем посте я написал о том, что делать, если Заказчик приходит с просьбой сделать часть работ бесплатно. В этом посте хотелось бы поговорить, как сделать так, чтобы либо подобные вопросы в проекте вообще не возникали, либо чтобы процесс был управляемым.

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

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

1. Закладывайте на подобные работы 3-5% от стоимости контракта сразу на этапе продажи. И в следующий раз, когда Заказчик придёт с просьбой бесплатных работ, оцените сколько вы потратите, запишите в общий бэклог таких хотелок и следите за тем, чтобы не превышать этот лимит. Правда тут есть тонкая грань, как сделать так, чтобы в определенный момент, когда этот буфер в 3-5% у вас закончится, не словить непонимание у Заказчика «как так, вы всегда принимали наши мелкие хотелки, а теперь вдруг упёрлись».

2. Основная проблема в дополнительных работах не в том, чтобы обосновать Заказчику, что это не входит в скоуп, а в том, что у Заказчика на это уже нет денег, так как бюджет на проект выделен и больше денег не дадут. Поэтому на этапе продажи договаривайтесь на выделение определенного риск-буффера у Заказчика, который он будет использовать по своему усмотрению. В идеале, это должно быть не менее 10% от стоимости проекта. Захотели доп.хотелку, которой нет в скоупе – залезли в выделенный риск-буффер и потратили, сколько надо. У нас такой опыт был, так что проверено – работает очень классно.

3. Чтобы снизить вероятность возникновения дополнительных хотелок по ходу проекта, необходимо перед стартом основного проекта сделать аудит или небольшой пилотный проект. Для Заказчика плюс в том, что он будет знать реальное состояние дел, сколько денег потребуется для реализации проекта, увидит, что из себя представляет продукт (если речь про небольшой пилот) и сможет гораздо лучше и осознаннее сформулировать к нему требования. Для вас плюсы все те же самые, и в дополнении вы оцените Заказчика - насколько сложно с ним будет работать в реальном проекте, попробуете оцените будет ли он генерировать бесконечные требования, насколько сложно у них происходят согласования и предоставление запрашиваемой информации. Ну и как следствие – вы сможете дать более точную оценку. Если вы думаете, что Заказчики не идут на пилотные проекты и проекты по аудиту, потому что по результатам не получат то, ради чего будет открываться проект, то смею вас разубедить – для нас это распространенная практика, таких проектов много.

4. Если пилота или аудита не было, то на старте проекта (а лучше, конечно, еще на этапе формирования ТЗ) необходимо продемонстрировать Заказчику пример готовой работы. То есть показать то, что получится на выходе из проекта. Таким образом Заказчик сформирует правильные ожидания, сможет лучше описать свои требования, а вы обозначите рамки готового продукта.

5. Если пример готовой работы продемонстрировать не получается, то, чтобы сформировать правильные ожидания, на старте проекта можно описать User Story и Use Case. Первые сосредоточены на том, что пользователь хочет, а вторые - это детальное описание сценариев использования системы, то есть то, что должно произойти в системе, когда пользователь выполняет определенное действие. Use Case описывают действия пользователей, систему и результаты. Честно признаюсь, мы в своей практике используем User Story и Use Case либо при подготовке ПМИ, либо на этапе обсуждения уже каких-то конкретных требований. Но очевидно, что формирование подобных сценариев и кейсов на старте проекта более эффективно, чем в середине или ближе к концу проекта.

6. Если пилота или аудита не было, а показать пример готовой работы не получилось, то одна из главных задач для вас в проекте - сделать MVP как можно быстрее. Не будем вдаваться в теорию проектного управления и обсуждать водопадную модель и agile-подход. Тут нас в первую очередь интересует вероятность получения новых требований от Заказчика по ходу проекта и способы уменьшения этой вероятности. Поэтому, чем быстрее вы дадите Заказчику результат, который можно пощупать и сформировать правильные ожидания и требования, тем лучше будет для проекта.

7. Независимо от того, получилось ли у вас пройти по пунктам 3-6, команда (и в первую очередь менеджер проекта) должны уметь управлять ожиданиями Заказчика. Необходимо делать так, чтобы образ результата в голове у Заказчика совпадал с образом результата в голове у команды Исполнителя. И это делается не только на старте проекта, это постоянная и регулярная работа. Любое обсуждение каких-то задач и проблем в проекте, должно сопровождаться работой с ожиданиями Заказчика. То есть он должен в деталях понимать, к чему приведет любое решение на проекте, и как будет работать тот или иной функционал.

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

9. Независимо от того, договорились ли вы с Заказчиком по пункту 8, у вас в любом случае должен существовать процесс управления этими требованиями. Необходимо обязательно учитывать информацию о том, какие требования уже уточнили, какие выполнили, какие новые требования поступили. Вы можете вести этот документ только у себя, а в следующий раз, когда Заказчик скажет «да что вам стоит там немного поправить», вы ему показываете фактуру, в которой таких «да что вам стоит» уже два десятка набралось.

10. Сложнореализуемый пункт, к которому мы сами ещё не пришли, но уже очень активно «смотрим в его сторону». Использование Fix price flexible scope модели, которая совмещает в себе фиксированный скоуп проекта и эджайл подход. В ней мы берем лучшее от обеих моделей. Смысл в том, что мы фиксируем бюджет, за который проект не выйдет, как в fixed price, но при этом позволяем клиенту менять scope в лучших традициях T&M и эджайла. Главное, что нужно сделать для FPFS модели - определить, какой scope нельзя выкинуть ни под каким соусом. С этим обычно проблем нет, Заказчики даже на старте проекта знают, что вот эти 4 фичи из 10 нужны кровь из носа, а остальные можно пустить под нож (flexible scope). Сначала делаем наши 4 фичи и ставим им приоритет highest. На протяжении всего проекта они висят в топе бэклога. С заказчиком четко проговариваем, что они идут в работу первыми. Хотим добавить новые фичи? Не проблема - добро пожаловать в бэклог. Но сначала мы сделаем наивысший приоритет, а потом все остальное.

11. Не соглашаться на всё подряд. Даже если выглядит, что сделать это дешево и быстро, а вы больше времени потратите на то, чтобы доказывать Заказчику, что это за доп.бюджет. Вроде бы очевидно, зачем брать лишние работы, да ещё и бесплатно? Однако, в огромных проектах, которые идут годами, в моменте об этом можешь не задумываться. А если вы не ведёте список того, на что соглашаетесь, то вам вдобавок ещё и трудно будет оценить, сколько вы такого уже реализовали. В итоге Заказчик привыкает, что вы подписываетесь на всё подряд, а вы потратите дополнительные трудозатраты и усложните систему, из-за чего впоследствии может возникнуть больше проблем (попробуйте через год доказать Заказчику, что бага, исправление которой критично для проекта, вылезла из-за работ, которые вообще в проект не входили).

12. Если вы всё-таки соглашаетесь на какие-то работы, которые в скоуп не входили, обязательно нужно зафиксировать это письмом. И обязательно ответным письмом Заказчик должен это согласовать. Люди увольняются, нюансы за давностью событий забываются, и вспомнить потом, почему вы это сделали, кто вас просил и на каких условиях вы это согласовали, без такой фактуры будет очень проблематично. Доказано горьким опытом.

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