Comments 11
Скажите, а бывали ли в Вашей практике случаи, когда клиент дополняет проект фичей, но урезать проект не может (не хочет и всячески противится). Как Вы справлялись с таким ?
Отвечу за автора: прошу за дополнительную фичу дополнительных денег.
Я может быть неправильно выразился, извините, попробую исправиться.
В ТЗ есть фраза которая неявно трактуется (ничего не поделаешь, ТЗ подписано). Фича оценивается в X человеко-часов, но представитель со стороны клиента описывая функциональность детализирует ее так, что формально она подходит под описание в ТЗ, но оценивается в 3*X человеко-часов. На уверения и доказательства что это не то что написано в ТЗ не реагирует и отказывается урезать другие части проекта (даже те, что особо не влияют работу продукта — рюшечки). Грозиться отменить приемку проекта, если это не будет реализовано и подать в суд за срыв сроков.
Вот о какой ситуации я говорил.
В ТЗ есть фраза которая неявно трактуется (ничего не поделаешь, ТЗ подписано). Фича оценивается в X человеко-часов, но представитель со стороны клиента описывая функциональность детализирует ее так, что формально она подходит под описание в ТЗ, но оценивается в 3*X человеко-часов. На уверения и доказательства что это не то что написано в ТЗ не реагирует и отказывается урезать другие части проекта (даже те, что особо не влияют работу продукта — рюшечки). Грозиться отменить приемку проекта, если это не будет реализовано и подать в суд за срыв сроков.
Вот о какой ситуации я говорил.
Окей, допустим переговоры провалились.
Сроки можно за скобками оставить — нагнал на фичу втрое больше людей и успел (если есть ресурсы).
Если вычитание из ожидаемой прибыли проекта 2*Х (для простоты — прибыль в часах) дает положительное число — сжимаем зубы и делаем.
Если отрицательное, допустим оно равно M, то смотрим:
1) Если М больше, чем уже потрачено человеко-часов на проект — закрываем проект.
2) Если М меньше — делаем проект и молимся*, чтобы второй такой фразы не было.
* на самом деле не молимся, а внимательно читаем ТЗ и анализируем риски.
Сроки можно за скобками оставить — нагнал на фичу втрое больше людей и успел (если есть ресурсы).
Если вычитание из ожидаемой прибыли проекта 2*Х (для простоты — прибыль в часах) дает положительное число — сжимаем зубы и делаем.
Если отрицательное, допустим оно равно M, то смотрим:
1) Если М больше, чем уже потрачено человеко-часов на проект — закрываем проект.
2) Если М меньше — делаем проект и молимся*, чтобы второй такой фразы не было.
* на самом деле не молимся, а внимательно читаем ТЗ и анализируем риски.
UFO just landed and posted this here
Эти 3X больше вашего риск буфера на фазе проекта? Вы работаете с подрядчиком или только внутренними ресурсами?
На лицо явно ошибка человека, разработавшего ТЗ. Почему в процессе работы над fixed-price проектом происходит детализация? Либо люди, которые оценивали работу в X ч-часов не удосужились детализировать требования.
Что делать:
— обсудить с командой, чтобы у всех было видение ситуации,
— обсудить с клиентом вместе с людьми, которые писали ТЗ. Понять, кто же все-таки неправ (вендор или клиент)
— если вендор неправ (обычно так и бывает :)) попробовать закончить проект в сроки и за тот же бюджет. Да, поговорить с руководством, взять дополнительных разработчиков, пожертвовать собственным бонусом. Если это невозможно, объяснить все это клиенту. Да, он может обращаться в суд, но тогда, скорей всего он вообще не увидит проекта, либо получит низкокачественный продукт. По идее такие вещи должен уже решать не конкретный ПМ, а sales или аккаунт-менеджер. Может быть они в баню сходят с клиентом :) Если клиент мелкий и ненужный — то можно и забить на него.
И еще — в договоре fixed-price всегда нужно прописывать штрафные санкции за срыв сроков, но всегда прописывать максимальную сумму штрафа. Например, 1% от суммы за день просрочки, но не более 10%… Тогда деньги (за минусом макс 10%) будут получены.
Что делать:
— обсудить с командой, чтобы у всех было видение ситуации,
— обсудить с клиентом вместе с людьми, которые писали ТЗ. Понять, кто же все-таки неправ (вендор или клиент)
— если вендор неправ (обычно так и бывает :)) попробовать закончить проект в сроки и за тот же бюджет. Да, поговорить с руководством, взять дополнительных разработчиков, пожертвовать собственным бонусом. Если это невозможно, объяснить все это клиенту. Да, он может обращаться в суд, но тогда, скорей всего он вообще не увидит проекта, либо получит низкокачественный продукт. По идее такие вещи должен уже решать не конкретный ПМ, а sales или аккаунт-менеджер. Может быть они в баню сходят с клиентом :) Если клиент мелкий и ненужный — то можно и забить на него.
И еще — в договоре fixed-price всегда нужно прописывать штрафные санкции за срыв сроков, но всегда прописывать максимальную сумму штрафа. Например, 1% от суммы за день просрочки, но не более 10%… Тогда деньги (за минусом макс 10%) будут получены.
Всегда сложно быть в такой ситуации. Я думаю, направления дествий такие:
Если есть желание, можем более конкретную ситуацию разобрать в далее комментах или в личных сообщениях
- Попытаться разубедить клиента. Безусловно, если это подходящее решение
- Анализ заложенных заранее рисков и применение их на данную фитчу
- Поиск компромисса с клиетом. Это как раз «Процесс пересмотра скоупа проекта в условиях изменения функциональности без изменения бюджета» — из статьи
Если есть желание, можем более конкретную ситуацию разобрать в далее комментах или в личных сообщениях
Это хороший вариант, о котором никогда не надо забывать. И хорошо, когда клиент приучен к такому. Я имею, в виду, что если ему говорят, что работа не планировалась и он знает, что нужно доплатить.
Но глобально мы говорим о том уровне сервиса, когда все ожидания клиента оправдываются и за счет этого улучшается его фидбэк по проекту. Но в то же время он знает, что это произошло не просто так и с такими недопониманиями при взаимодействии нужно бороться.
Но глобально мы говорим о том уровне сервиса, когда все ожидания клиента оправдываются и за счет этого улучшается его фидбэк по проекту. Но в то же время он знает, что это произошло не просто так и с такими недопониманиями при взаимодействии нужно бороться.
Sign up to leave a comment.
Решаем стандартные для PMов проблемы на проектах. Часть 1