Антихрупкость в IT - Александр Васильевич Бындю

ТЗ действительно фиксирует вершины проектного треугольника, но эта фиксация создаёт лишь иллюзию определённости и контроля.

В моей практике был случай создания системы после неудачного внедрения 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).

Метафора для инструмента планирования

Программное обеспечение всегда абстрактно и изменчиво. Этим свойством софт отличается от производства вещей в реальном мире. Например, после постройки дома никому не придёт в голову сказать: «Теперь давайте раздвинем