Когда необходимо составлять техническое задание?

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

Одни «эксперты» утверждают, что техническое задание — пережиток прошлого и все IT-проекты стоит создавать исключительно при помощи гибких подходов к управлению проектами без разработки полноценного технического задания (Agile/Scrum, etc).

Другие «эксперты» из числа гос.сектора требуют обязательного оформления документации по абсолютно неработоспособному устаревшему 19 ГОСТу (1978г), ну или 34 ГОСТу.

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

Так, что же делать нам, простым смертным?

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

Признаки:

1) Значимая для заказчика стоимость проекта.
Значимая — не обязательно высокая, тут цифры у каждого свои, кому то 10 000 рублей критичны, кому-то и 2-3 млрд нет.

2) Новая команда разработчиков.
Нет опыта работы с конкретным разработчиком? Тогда не нужно рассчитывать на то, что он поймет Вас с полуслова.

3) Отсутствие опыта в разработке IT-проектов у Заказчика.
Никогда не создавали проекты в IT-секторе — не нужно пытаться сделать все без ТЗ — не удастся.

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

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

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


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

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

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

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

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

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

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

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