Техническое задание (ТЗ): писать или не писать? — часть 2

В прошлой статье мы разбирали «за» и «против» технического задания. Если вкратце, мы считаем, что ТЗ нужно практически всегда — вопрос только в сроках и стадии проекта. Тема этой части — что будет, если ТЗ нет.

Спойлер: его отсутствие влечет ворох проблем. Какие риски? Разберем ниже.

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

Если ТЗ нет — образуется серая зона. Клиент представляет себе, как выглядит функционал. Он не обрисовывает его детально, поэтому исполнитель работает, исходя из предыдущего опыта, понимания того, как должно быть, и обрывочных знаний о задаче клиенте.

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

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

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

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

В разработке ТЗ обязательно учитываются границы проекта: что входит в реализуемый функционал. Если границ нет, клиент всегда может просить о доработках. Это откладывает сдачу проекта, он затягивается. Для команды разработки это демотивация. Задержки не принесут больше денег. Из-за них команда просто бесконечно занимается проектом и никак не может его сдать. Понятно, что при таком подходе эффективность снижается.

Когда нет ТЗ, усложняется тестирование. Нет четких требований и критериев успешности и приемки. Получается, что разработчик тестирует сервис, который как-то работает. Ключевое слово — «как-то». Необычное поведение системы может быть по-разному интерпретировано: это баг или фича? Что негативно влияет на взаимоотношения между клиентом и командой разработки.

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