Готовность задачи к разработке

Когда нужен этот материал

Материал полезен перед передачей задачи в разработку, когда идея уже понятна, но еще не ясно, достаточно ли в ней договоренностей для спокойного старта.

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

Короткая проверка

Перед разработкой задача должна отвечать минимум на эти вопросы:

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

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

Шаблон разбора задачи

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

## Задача

Название:
Кто получает пользу:
Какой результат должен измениться:
Что не входит в первую версию:

## Основной сценарий

Стартовое условие:
Участники или системы:
Шаги:
Ожидаемый результат:

## Данные

Ключевые данные:
Источник истины:
Кто может менять данные:
Чувствительные данные и ограничения логирования:

## Ошибки и исключения

Что может пойти не так:
Как пользователь или оператор узнает о проблеме:
Что команда делает при повторном действии:
Какие риски остаются за рамками MVP:

## Критерии приемки

- При ...
- Если ...
- В логах ...
- Задача считается готовой, когда ...

## Открытые вопросы

Вопрос:
На что влияет:
Владелец:
Что делаем до ответа:

Если блоки “Данные”, “Ошибки” или “Открытые вопросы” остаются пустыми, это обычно не означает, что рисков нет. Чаще это значит, что задача пока описана только через happy path.

Как использовать после карты и сценария

Этот чеклист лучше работает не с чистого листа, а после двух коротких артефактов:

1. Рабочая карта системы дает цель, границу, участников, данные и риски.
2. Sequence-диаграмма показывает порядок взаимодействий, ветки, ожидание ответа и владельцев действий.
3. Чеклист готовности превращает это в решение: можно ли отдавать задачу в разработку, нужно ли сузить объем, провести spike, разобрать риск или декомпозировать работу.

Пример перехода:

Карта: в сценарии участвуют клиент, форма, backend, внешний сервис и оператор.
Диаграмма: при таймауте внешний сервис может ответить позже, а оператор должен видеть статус.
Готовность задачи: в объеме MVP фиксируем статус ожидания, повтор без дубля, журнал причины и критерий приемки для таймаута.

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

1. Цель и ожидаемый результат

Сначала нужно описать не экран, поле или API, а изменение, ради которого задача существует:

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

Формулировка “добавить поле” обычно слабее формулировки “дать оператору возможность увидеть причину отказа без ручного запроса к другой системе”. Вторая формулировка сразу показывает сценарий, пользователя и критерий пользы.

2. Сценарии и границы объема

Для каждого основного сценария стоит зафиксировать:

• стартовое условие;
• роли или системы, которые участвуют;
• последовательность шагов;
• ожидаемый результат;
• альтернативные ветки;
• ограничения первой версии.

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

3. Данные, владельцы и источники истины

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

Проверьте:

• какие данные нужны для сценария;
• где они создаются и обновляются;
• какая система является источником истины;
• кто может менять данные вручную;
• какие данные чувствительные и не должны попадать в логи или публичные примеры;
• что делать, если данные отсутствуют, устарели или противоречат друг другу.

Для интеграций этот блок особенно важен: без него легко перепутать проблему контракта, проблему данных и проблему бизнес-правила.

4. Ошибки, исключения и риски

Happy path редко бывает главным источником переделок. До разработки нужно хотя бы коротко пройтись по нештатным ситуациям:

• внешний сервис недоступен;
• пользователь делает повторное действие;
• статус меняется между шагами процесса;
• данные не проходят валидацию;
• операция частично выполнена;
• результат нельзя показать пользователю сразу;
• нужна ручная проверка или эскалация.

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

5. Критерии готовности

Критерии готовности должны быть проверяемыми, а не декларативными.

Слабые формулировки:

• “сделать удобно”;
• “обработать ошибки”;
• “поддержать интеграцию”;
• “добавить проверку”.

Более полезные формулировки:

• “при недоступности внешнего сервиса пользователь видит статус ожидания, а оператор видит причину в служебном журнале”;
• “повторный запрос с тем же идентификатором не создает дубль операции”;
• “в логах нет персональных данных и полных значений токенов”;
• “задача считается готовой после теста happy path, ошибки формата и таймаута”.

6. Открытые вопросы

Открытый вопрос не должен теряться внутри обсуждения. У него должны быть:

• формулировка;
• владелец;
• срок или событие, после которого нужно вернуться;
• влияние на разработку;
• решение, что делаем до ответа.

Иногда лучший результат анализа — не “все понятно”, а честный список неизвестных мест, которые больше не спрятаны в задаче.

Критерий готовности к разработке

Задачу можно считать готовой к разработке, если:

• цель и ожидаемый результат понятны;
• объем первой версии ограничен;
• основные сценарии описаны;
• данные и источники истины названы;
• нештатные ситуации хотя бы классифицированы;
• критерии приемки проверяемы;
• открытые вопросы видны и имеют владельцев;
• риски не замаскированы под “уточним по ходу”.

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