Степень детализации технического задания

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

ТЗ — никогда не будет полным. Любое ТЗ можно детализировать бесконечно долго. Далеко не каждый аспект стоит детализировать в ТЗ.

Опытный проект менеджер знает, когда начинается излишняя детализация.

Простой вопрос, ответ на который позволит Вам понять, нужно углубляться дальше в детали или нет:

Стоимость исправления ошибки в описываемом аспекте ТЗ превышает стоимость затрат на детализацию этого аспекта?

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

Примеры:

1) Анимация кнопки при наведении на нее курсором — стоимость исправления копеечная, письменное описание займет больше времени.

Решение:
Не нужно детализировать

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

Решение:

Необходимо детализировать

3) Выбор cms/framework/ЯП для создания проекта — в случае некорректного выбора миграция готового проекта может в разы превышать стоимость всей разработки.

Решение:

Необходимо не только детализировать, но и обоснованность выбор конкретного технического решения.

4) Описание расположения элементов

Решение:

Не нужно детализировать, если к ТЗ приложены макеты.

5) Контрольные устройства для проверки корректности вёрстки проекта.

Решение:

Если проект с малым бюджетом и количество пользователей мало, можно не вводить контрольные устройства.

Если верстка имеет коючевое значение в проекте, например разрабатывается ПО для терминалов с определенным специфичным разрешением экранов самообслуживания в сети ресторанов — требуется указать.

6) Требования к тестированию проекта перед демонстрацией заказчику.

Решение:
Если у заказчика масса свободного времени, можно не указывать.

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

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

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


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

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

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

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

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

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

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

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

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

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