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

Время прочтения: 3 мин
Сложность: норм Просмотров:
Денис Сапожников 01.10.2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Рано или поздно исчезнут простые работяги, их профессии падут под гнетом автоматизации и нейронных сетей. Следом падут и рядовые разработчики, их заменят SAAS-сервисы. Проект-менеджеры наконец-то окажутся никому ненужными. Останется лишь чернь, бездумно потребляющая контент и безумные изобретатели‑первопроходцы, меняющие мир.

А пока этого не произошло, я буду писать этот блог и стараться давать Вам самую суть разработки, продвижения и управления в IT‑проектах.


P.s. нравится проект?
Ну так помоги развить его - репосты, донат и интересная работа приветствуются

Рекомендую посмотреть

Случайный вопрос

Подрядчик сорвал сроки разработки. Что делать, как найти нового?

Для начала стоит определить истинную причину срыва сроков проекта, самые популярные — некорректная оценка объема работ, отсутствие у текущего подрядчика необходимых знаний и ресурсов для реализации проекта, ошибки проект-менеджеров с обеих сторон. По возможности — простимулировать доработку текущей проектной командой.

Если смена подрядчика неизбежна, общая схема выглядит так:
1)  Уведомить текущего подрядчика о прекращении сотрудничества и необходимости подготовки проектной документации
2) Произвести независимую оценку текущего положения — что уже сделано, что осталось сделать. Для этого потребуется привлечение стороннего специалиста.
3) Решить юридические и финансовый вопрос с текущим подрядчиком
4) Сформировать техническое задание на доработку проекта и разработать методику миграции проекта от одного разработчика к другому
5) Начать поиски нового подрядчика (hh, тендер, биржи фриланса — в зависимости от размера проекта)

Показать больше ответов

Привет, дружок‑пирожок