Постановка задачи на разработку

Что это за процесс

Процесс описывает путь задачи от момента поступления идеи или баг-репорта до её передачи в разработку или отклонения. Он начинается со стартового события «Поступил запрос на новую функциональность / доработку» и завершается одним из финальных состояний: задача принята в бэклог со статусом «Ready for Development», отклонена из-за нецелесообразности или невозможности реализации, либо перенесена в ожидание. Ключевая цель — отфильтровать запросы и подготовить качественные требования перед началом работы команды.

Как читать эту схему

Схема построена на последовательных действиях с проверками через эксклюзивные шлюзы. Это означает, что на каждом этапе принятия решения поток идет только по одному пути. Например, после анализа требований шлюз проверяет их полноту: если данных недостаточно (ветка «нет»), процесс возвращается к уточнению требований с заказчиком. Аналогичная логика работает на этапе оценки: если оценка требует пересмотра, задача возвращается на доработку постановки. Финальный шлюз принимает решение на основе приоритета: при высоком приоритете задача уходит в разработку, а при низком или нехватке ресурсов — переносится на отложенное выполнение. Также в схеме предусмотрены аварийные сценарии, такие как отмена запроса заказчиком или выявление невозможности реализации.

Кому подойдёт

Эта схема актуальна для продуктовых команд, работающих по методологии Scrum. Она описывает взаимодействие между заказчиком (пользователем или бизнес-заказчиком), бизнес-аналитиком, Tech Lead, Product Owner и QA. Процесс подходит компаниям, где важно согласовать бизнес-ценность и технические критерии приемки (DoR) до начала написания кода.

Как адаптировать под свою компанию

• Добавьте конкретные метрики для оценки «бизнес-ценности», чтобы решение о согласовании было объективным.
• Уточните критерии «низкого приоритета» в финальном шлюзе, чтобы автоматизировать решение о переносе задачи в ожидание.
• Определите, кто именно отвечает за формирование критериев приемки (DoR): только QA или совместно с бизнес-аналитиком.
• Настройте уведомления для события «Запрос отклонен», чтобы заказчик получал обоснование в удобном формате.
• Проверьте, достаточно ли одного этапа «Уточнить требования», или нужны итерации с разными стейкхолдерами.

Типичные ошибки

Часто команды пропускают этап согласования бизнес-ценности, что приводит к разработке ненужных функций. Другая ошибка — отсутствие четких критериев приемки (DoR), из-за чего задача возвращается из разработки на доработку требований. Также распространена проблема игнорирования ветки «отложенное выполнение», когда задачи с низким приоритетом просто теряются вместо того, чтобы быть задокументированными в бэклоге.