ТЗ действительно фиксирует вершины проектного треугольника, но эта фиксация создаёт лишь иллюзию определённости и контроля.
В моей практике был случай создания системы после неудачного внедрения SAP у одного российского ритейла. У «сапёров» ушёл год на составление ТЗ. Ещё год на настройку и программирование SAP. В итоге бизнес остался недоволен, потому что система работала медленно и частично ошибочно – «сапёры» недостаточно разобрались в бизнесе. Ещё три года ушло на дописывание, исправление и борьбу. Прочитать подробнее о ТЗ при внедрениях систем в полушуточной статье «Не купитесь на ERP!»[39]
4. ТЗ – молчаливый источник ответов
Вопросы быстрее и качественнее решаются во время живого общения. Планирования, стендапы, демо, работа в парах, вовлечение клиентов в тестирование, сбор обратной связи на ранних этапах и постоянная корректировка планов – это всё необходимо для достижения качества.
Когда написано подробное ТЗ, появляется соблазн отправлять читать ТЗ, а не отвечать на дополнительные вопросы. Тогда ТЗ заменяет здоровую коммуникацию.
Проблема в том, что ТЗ никогда не будет всеобъемлющим. Аналитик мог что-то упустить, архитектор подразумевал, но не дорисовал. Вопросы ТЗ не задашь, поэтому пойдёшь додумывать ответ сам.
5. Авторы ТЗ недоступны во время проекта
Аналитики и архитекторы обычно штучные люди в компаниях. Их делят на много параллельных проектов. Если они собрали требования, описали задачу и отдали её в работу, то, скорее всего, сразу же пошли делать другие проекты.
Если у исполнителей возникнут вопросы, то велика вероятность, что ответ придётся искать в тексте ТЗ, а не напрямую у автора.
6. Описывает только простые задачи
Иногда наиболее рискованные и неопределённые задачи нельзя изучить и описать заранее. Они больше похожи на R&D, чем на реализацию функций. Здесь прямая аналогия с клиническими исследованиями, весь процесс и результат которых невозможно описать заранее, а можно только построить гипотезы и подобрать методику.
Получается, что подробное ТЗ можно написать только для очень конкретных и относительно простых задач. Эти задачи находятся в правом секторе Cynefin framework, то есть для них известны лучшие практики или решение можно подобрать из готовых кубиков после анализа. Проблема в том, что бизнес редко ставит такие простые и конкретные задачи. Если работать над функциями, которые двигают бизнес вперёд, то это обычно верхний левый квадрат Complex, где нужно двигаться через гипотезы и эксперименты, на такие задачи ТЗ уже не напишешь.
7. Когда пора прекратить писать техническое задание?
Написание ТЗ стоит денег, которые хочется сэкономить. При этом мы балансируем между двумя крайностями:
1. Переплатить временем и деньгами за чрезмерно подробное описание задач.
2. Описать задание недостаточно подробно, что приведёт к серьёзным рискам и ошибкам.
Только эксперт сможет найти золотую середину, а таких экспертов мало. Среднестатистический IT-аналитик имеет все шансы ошибиться (раздел l, глава 5).
8. ТЗ не фиксирует «качество»
Я как разработчик и IT-архитектор прекрасно понимаю, что любую задачу, как бы подробно она ни была описана, можно сделать сотней разных способов. Одни способы будут качественными и дорогими, другие быстрыми костылями. Иными словами, при написании кода ужасного качества можно формально выполнить требования ТЗ.
Есть способы достигнуть высокого качества IT-продукта, но точно не с помощью ТЗ.
Если вы подозреваете, что ваш проект идёт как-то не так, узнайте, как заранее определить провал IT-проекта (раздел l, глава 9), сэкономите деньги и время.
9. ТЗ работает по принципу «всё или ничего»
К сожалению, нельзя согласовать ТЗ наполовину или договориться выполнить самые важные пункты из согласованных и принятых в работу. Если ТЗ подписано и выделен бюджет, то вам придётся сделать всё, что в нём написано. Его «монолитность» не поддаётся анализу Парето[40], что приведёт к неэффективной работе.
10. Невозможно доказать непротиворечивость
Если в вашем ТЗ больше сотни страниц, то в этом ТЗ будут противоречия. При этом нет никакой методики, которая бы позволила доказать непротиворечивость ТЗ. Вам могут пообещать, что проверили все тезисы и гипотезы в ТЗ, но доказать или написать тест на непротиворечивость нельзя. Фактически вы всегда подписываете ТЗ с противоречиями.
11. Невозможно доказать полноту
Как в предыдущем пункте, невозможно доказать, что в ТЗ описаны все сценарии, взаимосвязи, точки интеграции и т. п. Достигнуть 100% покрытия задач можно только за бесконечный бюджет, в других случаях ваше ТЗ не будет полным.
12. Не вдохновляет
В достижении бизнес-цели очень важна мотивация исполнителя. А можно ли мотивировать кого-то, передав ему ТЗ? Можно не пытаться вдохновить исполнителя через текст ТЗ. Ему не передать стремление достигнуть ценность для бизнеса с помощью формального текста.
Не всё так плохо
Риски, которые влекут описанные проблемы, можно снизить. Например, предусмотреть в контракте, что ТЗ можно менять, упростить процедуры пересогласования или разрешить реализовать ТЗ не в полном объёме, но подчеркнуть важность достижения бизнес-цели.
Работа над каждой проблемой так или иначе связана с выстраиванием партнёрских отношений между заказчиком и исполнителем, а это достигается постоянной совместной работой.
Глава 8. Как и какое техническое задание писать при работе по Agile
Как использовать подходящие инструменты планирования, прекратить фиксировать объём работ и строить коммуникацию вокруг бизнес-целей
Техническое задание при работе по Agile
Манифест гибкой разработки ПО[41] ставит во главу угла достижение бизнес-ценности, отбрасывая и уменьшая значимость всего, что не приближает к бизнес-ценности. В этом смысле традиционное детальное техническое задание, подписанное заказчиком и исполнителем, часто является причиной потерь (раздел l, глава 7).
ТЗ, как любой другой юридический документ, накладывает обязательства на обе стороны по формальному соблюдению ими всех пунктов документа. Это даёт побочные эффекты:
1. Заказчик, хоть и стремится к бизнес-цели, вынужден принимать результаты работ по формальному ТЗ.
2. Исполнитель, который видит, как сделать работу более оптимально, предпочтёт следовать ТЗ и провоцировать смену плана, даже если окажется, что план не эффективен (рис. 27).
Метафора для инструмента планирования
Программное обеспечение всегда абстрактно и изменчиво. Этим свойством софт отличается от производства вещей в реальном мире. Например, после постройки дома никому не придёт в голову сказать: «Теперь давайте раздвинем