Здесь мы рассматриваем случай когда проект работает по схеме “Оплата по Оценке”, а не Time And material. Т.е. когда разработчики на основании ТОЧНОГО задания дают оценку затрат и оплата производится на основании этой оценки, а не фактических затрат (это как раз Time & material). (Научится самостоятельно писать техническое задание можно на нашем курсе создания ТЗ).
Обработка допа
Итак, у клиента появился доп, который не фигурировал в ТЗ. Как его следует обработать менеджеру проекта?
- Определить нужен ли доп в целом. Очень много допов от клиента вообще никак не вяжутся с общей канвой проекта. Как это ни парадоксально, но именно клиент является главной угрозой для проекта, а именно стремление впихнуть в проект все и сразу!
Если вы поняли, что доп является крайне сомнительным, то дайте клиенту честное открытое мнение с обоснованием. Решение в итоге все равно принимать клиенту, но вы должны проявить упорство, если уверены, что это плохой для проекта доп. В крайних случаях подключите и других людей (руководство, лояльных представителей клиента, внешнего авторитета и т.д.). - Зафиксируйте, что это доп. Вы должны добиться с клиентом однозначного понимания, что это доп, а не часть текущего технического задания. Если этого не сделать, то в будущем клиент может повернуть это в свою сторону и вам придется принять это как часть ТЗ.
- Дайте клиенту понять, что доп увеличивает сроки и бюджет. Очень важно, чтобы клиент не представлял проект как резиновую перчатку, которую можно раздувать до бесконечности. Если появляется доп – вы оцениваете его и даете клиенту ясно понять что сроки увеличиваются на N дней. На все уговоры сделать быстрее – категоричный отказ. По статистике очень мало проектов делаются быстрее срока. И тому ряд причин – нет данных, заболел разработчик, новые требования, неверное понимание бизнес-логики, ошибки и т.д.
- Учитывайте хвост допа. Что это? Например, вы внедряете в интернет-магазин новую CRM. Это может потребовать много неявных доработок, которые вы не учитываете. И тут вы попадаете в капкан. Вы реализовываете, что было по допу, а клиент начинает накручивать функционал, который подразумевается и “без этого мы никак не сможем работать”. Получается конфликт интересов. Ваша главная задача – распознать все хвосты допа и вовремя их озвучить и оценить.
- Очень осторожно берите мелкие допы в рамках ТЗ. Иногда хочется сделать приятно клиенту, и реализовать что-то по мелочи в рамках текущего ТЗ. Здесь есть 3 момента
- Клиент может понять это как “можно и дальше понемногу пропихивать допы”.
- Могут появиться хвосты этого допа, и клиент уже будет не просить, а требовать исправлять допы.
- Вы увеличиваете не только время разработки, но и время отладки, тестирования и интеграции. т.е. учитывайте полный цикл внедрения новой незначительной возможности.
- Допы и пожелания клиента очень нужны проекту. Без них он не будет развиваться. Вы должны показать клиенту свою готовность реализовать все необходимые и полезные допы. Но при этом вы должны организовать процесс обработки этих допов, а также дать понимание клиенту по этому процессу. Чем яснее будут правила для клиента в плане допов, тем меньше будет трений и недопонимания по их внедрению.
И еще, очень важно чтобы допы согласовались с общей концепцией проекта. Если этого не будет – то в итоге получится несбалансированный проект под фантомного пользователя. А концепция в свою очередь должна четко определять целевую аудиторию проекта.