Что ТЗ даёт разработчику?
Плох тот разработчик, что не способен сформировать адекватное техническое задание.
Хотя большинство талантливых отечественных программистов, к сожалению, не обладают необходимыми для этого навыками.
Так исторически сложилось, но оформлять проектную документацию, документировать и комментировать код у нас не принято.
А если где и принято, то делают это крайне не охотно и «из под палки».
Экскурс в историю ТЗ
Предполагаю, что виной нелюбви отечественных разработчиков к написанию проектной документации и ТЗ, в частности, является — развал СССР.
В чем связь спросишь ты? Все просто.
Базовые знания и методы, хотим мы того или нет, большинство разработчиков получают в ВУЗах.
ВУЗы учат по государственным программам.
Главный государственный стандарт о техническом задании в программных продукта — Единая система программной документации (ЕСПД), а если еще точнее, то «ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению»
Основным разработчиком этого ГОСТа являлся Институт Стандартизации и Сертификации в городе Минске, Белоруссия.
Так вот, написан ГОСТ был в 1978 году. Для большего понимания ситуации, первый айфон появился спустя 29 лет, в 2007 году.
После распада Союза, этот ГОСТ не обновлялся. Сперва некому было его обновить, а ныне отсутствие обновления, видимо, выгодно сильным мира сего.
Стоит ли говорить о том, что его содержание практически не применимо в современных IT-проектах?
Так и получилось, что хорошего современного стандарта оформления проектной документации — на данный момент не существует.
А раз стандарта нет, то и единого оформления нет — вот разработчики массово и боятся оформлять документацию. Не умеют и не знают где научиться.
Что-то я разговорился, наболело… вернемся к «нашим баранам».
Что ТЗ даёт разработчику?
Несмотря на все сказанное выше, любой разработчик любит работать с качественным ТЗ.
И этому есть ряд причин:
1. Четкая структура постановленной задачи
А значит, снижение рисков. Резкое увеличение вероятности сдачи проекта в срок. К тому же, меньше приходится «додумывать» за заказчика, вмешиваться в поле его деятельности.
2. Возможность оценить сроки и стоимость реализации проекта
Здравомыслящий разработчик никогда не оценит стоимость реализации проекта в конкретную сумму.
Это всегда будет диапазон чисел. Причем разброс между минимальной и максимальной ценой может отличаться в десятки раз, а иногда и сотни.
Детальное ТЗ позволяет сделать оценку более корректно и по срокам и по цене.
3. Возможность управления проектом
Проект-менеджер со стороны разработчика может управлять лишь 4 параметрами:
1) Сроки разработки
2) Технологии разработки
3) Кадры
4) Финансы
Играя с этими параметрами достигается удовлетворение желания заказчика и внутренних интересов компании-разработчика.
Находясь в ситуации низкого качества постановки задачи, возможность успешного управления проектом — очень сильно снижается.
4. Рычаг давления на заказчика
Нет ничего удивительного, что желания заказчика трансформируются с течением времени.
Однако, новые «хотелки заказчика» — частая причина конфликтов между заказчиками и разработчиками.
Грамотное ТЗ позволяет заранее урегулировать большинство потенциальных конфликтов.

Оглавление рубрики
- Что такое техническое задание?
- Когда необходимо составлять ТЗ?
- Что ТЗ даёт заказчику?
- Что ТЗ даёт разработчику?
- Кто должен заниматься разработкой технического задания - разработчик или заказчик?
- Как заказчику подготовиться к составлению ТЗ
- Готовые шаблонны и брифы для создания технического задания
- Структура и принципы построения технического задания
- Степень детализации технического задания
- Этапы построения технического задания
- Проблемы при работе по техническому заданию
- Контрольные вопросы при утверждении технического задания
- Пример и особенности ТЗ для разработки сайта
- Пример и особенности ТЗ для разработки мобильного приложения
- Пример и особенности ТЗ для разработки программного обеспечения