22 мая 2017 г.

Откровенное общение с заказчиком

Полгода назад мы были на грани расставания с одним заказчиков. Управление проектом скатывалось на микроменеджмент и взаимные упрёки. Диалоги типа такого стали нормой:

  • Заказчик: Это баг и вы не должны были его допускать, исправляйте бесплатно.
  • Мы: Это не баг, такое поведение не обговаривалось.
  • Заказчик: Это было очевидно, поэтому обговаривать не надо. Вы должны были предусмотреть...
  • <Заказчик задумал писать более подробные ТЗ и жёстче контролировать время на потраченные задачи>

Такое общение убивало мотивацию команды. Если коммуникация на проекте скатывается до этого уровня, то я понимаю, что мы ошиблись в заказчике, а он ошибся в нас. Мы не смогли перейти в квадрат С по матрице Доверие-Прозрачность.

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

Расходиться с заказчиком не хотелось, но и продолжать проект с таким настроем не получалось. Мы настроились на отказ от проекта, но перед тем, как разойтись, я решил открыть все карты и рассказать заказчику как я вижу процесс разработки, почему его подход стратегически неверен и как можно всё исправить:

  1. Мы никогда не сделаем всё идеально с первого раза и даже после первой заливки и показа конечным пользователям.
  2. Вы никогда не опишите на столько исчерпывающее ТЗ, что по нему будет однозначно понятно что, где, когда и как нужно сделать. Более развернуто в статье Техническое задание как база знаний о проекте
  3. Вы можете бесконечно копаться в мелочах, находить проблемы и утверждать, что мы не правы.
  4. Мы можем бесконечно копаться в ТЗ и доказывать, что "в ТЗ этого не было" (этим мы ни за что не будем заниматься, т.к. ценим своё время).
  5. Мы начинаем работу с долей неопределенности, которую соглашаемся вместе уменьшать за счет постоянного общения, стендапов и демо.
  6. Нет успешных проектов, где все находятся в обороне и ждут друг от друга укора.
  7. Есть успешные проекты, где обе стороны хотят помогать друг другу.
  8. Мы открываем весь наш процесс, не закрываемся проджект-менеджерами, вы видите каждый коммит и получаете результат сразу, когда он готов.
  9. Мы правда хотим сделать так, чтобы вы получили ПО, которое принесет бизнес-ценность.
  10. Важно поддерживать друг друга.

Этот список, отправленный в чат заказчику и команде, изменил всё. На следующий день и команда и заказчик начали работать по-новому. Обе стороны начали работать с новой энергией и уже через несколько месяцев выпустили первый релиз. Видимо есть что-то магическое в этих строках! Отдаю их в публичный доступ, вдруг вам тоже поможет.


Добавлю к своей коллекции IT-манифестов.

Комментариев нет:

Отправить комментарий