Мы используем файлы cookie. Чтобы улучшить работу сайта и предоставить вам больше возможностей. Продолжая использовать сайт, высоглашаетесь с условиями использования cookie.

Как правильно составить задание на разработку и каким оно должно быть

AGIMA10 июля 2019Татьяна Болдырева·Руководитель проектов

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

Коротко

Нужно зафиксироватьГлавный вопрос
Бизнес-цельЧто должно измениться после запуска
ПользователиКто и в какой ситуации решает задачу
СценарииКакие действия должен выполнить пользователь
ОграниченияЧто нельзя изменить по сроку, бюджету или технологии
ПриёмкаКак проверить готовность результата

Чем задание отличается от технического задания

Первичный бриф объясняет проблему и границы проекта. Техническое задание появляется после исследования и проектирования: оно описывает согласованное решение достаточно подробно для реализации и приёмки.

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

Структура задания

  1. Опишите компанию, продукт и причину запуска проекта.
  2. Назовите аудиторию и ключевые пользовательские сценарии.
  3. Перечислите текущие проблемы и подтверждающие факты.
  4. Зафиксируйте обязательные интеграции и ограничения.
  5. Разделите требования на обязательные и желательные.
  6. Определите критерии приёмки и владельцев решений.

Как проверить качество задания

ПроверкаХороший признак
ЦельСформулирован измеримый результат, а не название функции
СценарийПонятны пользователь, контекст и ожидаемое действие
ПриоритетКоманда знает, что можно исключить из первой версии
ОграничениеУказаны срок, бюджет, право и технические зависимости
ПриёмкаРезультат можно проверить наблюдаемым способом

Частые ошибки

  • перечислять экраны без описания пользовательской задачи;
  • копировать требования конкурента без проверки;
  • смешивать обязательный объём и идеи на будущее;
  • использовать слова «удобный» и «современный» без критериев;
  • скрывать ограничения, чтобы получить более низкую оценку.

Вывод

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

Пример связи цели, задач и функций системы
Менеджмент
Загружаем чат

Напишите в поддержку

Опишите проблему — команда разберётся.