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

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

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

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

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

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

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

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

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

Эта статья входит в цикл статей о техническом задании:

1. Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
2. 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
3. 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
4. Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
5. Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
6. Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.