Что ТЗ даёт разработчику?

Плох тот разработчик, что не способен сформировать адекватное техническое задание.

Хотя большинство талантливых отечественных программистов, к сожалению, не обладают необходимыми для этого навыками.

Так исторически сложилось, но оформлять проектную документацию, документировать и комментировать код у нас не принято.

А если где и принято, то делают это крайне не охотно и «‎из под палки»‎.

Экскурс в историю ТЗ

Предполагаю, что виной нелюбви отечественных разработчиков к написанию проектной документации и ТЗ, в частности, является — развал СССР.

В чем связь спросишь ты? Все просто.

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

ВУЗы учат по государственным программам.

Главный государственный стандарт о техническом задании в программных продукта — Единая система программной документации (ЕСПД), а если еще точнее, то «ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению»‎

Основным разработчиком этого ГОСТа являлся Институт Стандартизации и Сертификации в городе Минске, Белоруссия.

Так вот, написан ГОСТ был в 1978 году. Для большего понимания ситуации, первый айфон появился спустя 29 лет, в 2007 году.

После распада Союза, этот ГОСТ не обновлялся. Сперва некому было его обновить, а ныне отсутствие обновления, видимо, выгодно сильным мира сего.

Стоит ли говорить о том, что его содержание практически не применимо в современных IT-проектах?

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

А раз стандарта нет, то и единого оформления нет — вот разработчики массово и боятся оформлять документацию. Не умеют и не знают где научиться.

Что-то я разговорился, наболело… вернемся к «нашим баранам».

Что ТЗ даёт разработчику?

Несмотря на все сказанное выше, любой разработчик любит работать с качественным ТЗ.

И этому есть ряд причин:

1. Четкая структура постановленной задачи
А значит, снижение рисков. Резкое увеличение вероятности сдачи проекта в срок. К тому же, меньше приходится «додумывать» за заказчика, вмешиваться в поле его деятельности.

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

3. Возможность управления проектом
Проект-менеджер со стороны разработчика может управлять лишь 4 параметрами:
1) Сроки разработки
2) Технологии разработки
3) Кадры
4) Финансы

Играя с этими параметрами достигается удовлетворение желания заказчика и внутренних интересов компании-разработчика.
Находясь в ситуации низкого качества постановки задачи, возможность успешного управления проектом — очень сильно снижается.

4. Рычаг давления на заказчика

Нет ничего удивительного, что желания заказчика трансформируются с течением времени.
Однако, новые «хотелки заказчика» — частая причина конфликтов между заказчиками и разработчиками.
Грамотное ТЗ позволяет заранее урегулировать большинство потенциальных конфликтов.

Оглавление рубрики

1. Что такое техническое задание?
2. Когда необходимо составлять ТЗ?
3. Что ТЗ даёт заказчику?
4. Что ТЗ даёт разработчику?
5. Кто должен заниматься разработкой технического задания - разработчик или заказчик?
6. Как заказчику подготовиться к составлению ТЗ
7. Готовые шаблонны и брифы для создания технического задания
8. Структура и принципы построения технического задания
9. Степень детализации технического задания
10. Этапы построения технического задания
11. Проблемы при работе по техническому заданию
12. Контрольные вопросы при утверждении технического задания
13. Пример и особенности ТЗ для разработки сайта
14. Пример и особенности ТЗ для разработки мобильного приложения
15. Пример и особенности ТЗ для разработки программного обеспечения