Советы по change requests Представьте, ваш проект распланиро | Менеджер от боженьки
Советы по change requests
Представьте, ваш проект распланирован на следующие 5 месяцев. Все требования, дизайны, отпуски утверждены, ничего не предвещает беды. И тут заказчику приходит в голову революционная идея, которая уничтожит всех конкурентов! Надо всего лишь добавить оплату криптой и прикрутить рекомендательную систему для покупок.
Что ж, придется изучать блокчейн и МЛ . А если у вас fix price контракт, то эти две фичи для проекта - change request (CR).
Вот несколько хороших практик по работе с такими изменениями:
Закладывайте время на оценку в стоимость CR. За обсуждение новых фич заказчик вряд ли заплатит, потому что это как бы пресейл, он обычно бесплатный. Но ведь нам нужно превратить хотелки в требования, погрумить их с командой, дать оценку. На все это тоже нужно время. Можно добавить потраченные часы к будущему контракту. Т.е. насчитали 100 часов на новую фичу, 4 потратили на оценку, выставляем клиенту 104 часа.
Если же изменение большое, как в примере выше, то его проводят как фазу discovery, уже платно.
Закладывайте старые косяки по бюджету в новые CR. Классика. Если часть проекта на старте недооценили и он ушел в минус, то совсем не стыдно часть недостачи заложить в новую оценку, чтобы улучшить баланс. Это вообще не грех, я узнавал.
Помимо оценки в деньгах, не забывайте про оценку сроков. Самое важное тут - проверить, как новый скоуп влияет на дату основной поставки. Обычно он как раз влияет, т.к. поменять просят что-то близкое по функционалу. Будьте внимательны здесь.
Если CR становится слишком много, предложите клиенту перейти на Time and Material - контракт, с оплатой за потраченные по факту часы. Тогда не нужно будет бегать за каждой оценкой и подписывать документы на любое изменение. Для обеих сторон это вин.
Ваша компания работает за прибыль, поэтому, чем больше будет нового скоупа, тем больше денег вы заработаете. С другой стороны, у вас нет обязательства делать каждый CR, особенно если работать с этим клиентом - боль. В любой момент можно сослаться на недоступность команды, заказчики хорошо принимают этот аргумент.
Соглашаясь на CR, не забудьте проверить доступность команды у ресурсного и забронировать ее на новый срок. Ваших инженеров могли уже забукать на другой проект после окончания вашего.
Когда заказчик даст аппрув на новую фичу, положите ваши договоренности на бумагу. Для каждого CR надо подписать два документа: scope of work, с описанием фичи и delivery acceptance, в котором заказчик эту фичу принимает. Если отношения с клиентом хорошие, то начинать работу можно и без подписанного договора, но иметь его все равно нужно.
Эти советы настоены на горьком опыте многих ПМов. Не повторяйте их ошибок
