Структура и принципы построения технического задания

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

Принципы построения:

1) Не смейте создавать формальное ТЗ лишь для скорейшего подписания договора и старта работ.

2) Отводите на разработку ТЗ не менее 30% времени и бюджета от всех затрат на разработку.

3) Пишите кратко, только информацию, которая необходима и достаточна для реализации проекта.

4) Оставайтесь в зоне своей компетенции.

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

Ответьте на вопросы — что нужно сделать и зачем, как делать — не ваша забота.

5) Не играйте в разработчика.

В 99% проектов нет смысла тратить весь день на обсуждение формы и цвета кнопки на странице контактов или всем офисом обсуждать картинку на главную страницу.

Запустите проект, добейтесь от него желаемых результатов.

Единственным лицом принимающим решение о том, как должен выглядеть ваш IT-проект является его пользователь.

6) Предусмотрите достаточную гибкость в постановке задач.

В техническом задании должны быть предусмотрены механизмы его корректировки (добавление или исключение этапов из проекта) и оговорена система увеличения или уменьшения вознаграждения консультанта для каждого случая.

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

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


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

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

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

Как найти product owner’a в стартап?

Очень странный вопрос.

Продакт оунер – это человек, который управляет созданием продукта и отвечает за то, что получится в результате.

Продакт — обязан иметь видения продукта, уметь корректно расставлять приоритеты потребностей продукта, обладать знаниями и навыками по работе с разработчиками.
Найти продакта «с улицы» — редкая удача, обычно они сами вырастают из project manager’a.

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

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

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