5 причин написать ТЗ

Перед Заказчиком стоит почти неподъёмная задача — поместить в голову Исполнителя свою идею и замотивировать его на достижение бизнес-результата.

Почему из всех вариантов решения этой задачи часто выбирают написание подробного плана действий в форме технического задания? Не обязательно перед начало работ иметь 100% контроль над проектом от текущего момента и на два года вперед. Более того, бывает вредно и дорого делать Big Upfront Design. Гонщик Mario Andretti говорил об этом так: «Если вы контроллируете всё, значит едите недостаточно быстро».

Тем не менее, существует ряд объективных причин, которые подталкивают подробно описывать весь план работ до начала проекта.

1. Снизить риски, уменьшить неопределенность

Перед началом проекта и Заказчик, и Исполнитель будут рады узнать список задач, бюджет и дату релиза. Когда все три составляющие известны и неизменны, тогда проще планировать работу.

Если не зафиксировать хотя бы одну из вершин проектного треугольника, это рождает неопределенность. Люди не любят жить в неопределенности. Мы избегаем неопределённости всеми силами, потому что она поглощает энергию и создает стресс.

Чтобы уменьшить неопределенность, надо предсказать будущее, построить план и двигаться согласно плану. Как сказал Джокер в драматической сцене в больнице, люди охотно соглашаются двигаться согласно плану, каким бы он ни был, важен сам факт наличия плана.

С этой точки зрения, идеальный уменьшитель неопределенности — техническое задание, фиксирующее все вершины треугольника.

2. Задача «бездумному» исполнителю

Если вы взяли проект на субподряд или отдадите его на субподряд, то всем проще работать со списком задач, который передается по цепочке. Чем подробней формализовано задание, тем проще отчитаться о выполнении. Чем подробнее описаны требования, тем меньше возникнет вопросов у всех участников «бездумной» цепочки.

3. ТЗ требуется согласно регламентам

В крупных компаниях и гос. структурах часто есть регламент, по которому наличие ТЗ является обязательным пунктом при согласовании бюджета на проект. Не зависимо от того, оправдано написание ТЗ для конкретного проекта или нет, придется его написать, согласовать и подписать.

4. Нет доверия с одной из сторон

Если Заказчик не доверяет Исполнителю или Исполнитель не доверяет Заказчику, то у них возникает естественное желание защититься друг от друга через подробное описание задачи.

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

5. Прокси-менеджер

Прокси-менеджер создает преграды в коммуникации. Это такой человек, который пересылает письма от Заказчика к Исполнителю и обратно, не дает общаться напрямую, мотивируя свою ценность занятостью людей за его плечами. Он паразит в цепочке коммуникации, передаст информации с дефектом искажения.

Если в ваших коммуникациях есть прокси-менеджеры, то для всех проще написать подробное ТЗ и реализовать задачи без лишних контактов друг с другом.

Что если в вашем случе ни одна причина не подошла

Надо ли вам вкладывать деньги и время в создание подробного ТЗ — вопрос непростой. Приведу пример того, как мы делаем выбор. В нашей компании ТЗ создаются только, если у заказчика есть корпоративное правильно, которое запрещает начинать проект без формального ТЗ. Мы делаем эти ТЗ в рамках аналитика IT-продукта. Итоговый документ состоит из Impact Mapping, Customer Journey, User Story Mapping и схем с архитектурой.

Если до начала проекта ТЗ можно не писать, то формальный документ не создается, а все активности по аналитике IT-продукта входят в процесс создания IT-продукта.

Мы не работаем на субподряде и всегда внедряемся в бизнес заказчика, чтобы строить коммуникацию как можно ближе.

Проблема с доверием между нами и Заказчиком решается как описано в статье Customer satisfaction для программистов: Доверие и прозрачность.

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

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