Task Pack: что это и как собрать постановку задачи для разработки

Task Pack полезен перед стартом разработки, миграцией API, интеграцией с внешним провайдером, передачей legacy-проекта новой команде или подготовкой крупного эпика в Jira. Типовой сигнал: аналитик уже разобрал источники, нашел противоречия, но еще рано писать финальное ТЗ.

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

Минимальный Task Pack обычно состоит из восьми блоков.

1. Scope. Что входит в задачу и что явно остается вне рамки.
2. Functional requirements. Требования с цитатами на источники: S01 §3.1, email от 12.03.2026, фрагмент POC.
3. Non-functional requirements. Security, performance, availability, compliance, audit trail, rate limits.
4. Open questions. Вопросы к PM, заказчику, провайдеру, архитектору или security.
5. Risks. Находки из Review Findings, отсортированные по severity.
6. Assumptions. Что команда временно принимает без подтверждения и что случится, если допущение неверно.
7. Acceptance criteria. Как команда поймет, что решение готово.
8. Estimation. Предварительная оценка с явной оговоркой, какие ответы могут ее изменить.

Ключевое свойство Task Pack — трассируемость. Требование «передавать customer_id в каждом recurring-платеже» должно вести к конкретному источнику: разделу PDF, письму support, API spec или найденной Review Finding.

ТЗ и SDD обычно описывают согласованное решение. Task Pack описывает рабочее состояние понимания перед решением или на раннем этапе решения.

Финальное ТЗ стремится быть чистым: без лишних сомнений, без спорных мест, без внутренних следов анализа. Но до появления договоренности команде нужен другой артефакт, где видны источники, открытые вопросы, риски и допущения.

Task Pack — четвертый артефакт в workflow.

source map -> System Context Pack -> Review Findings -> Task Pack

В учебном кейсе Acme Pay команда мигрирует платежную интеграцию с API v1 на v2.1. После source map и SCP аналитик видит, что POC использует /v1/, не передает Idempotency-Key, не валидирует webhook signature и не отправляет обязательный customer_id. Review Findings фиксируют это как набор рисков и вопросов. Task Pack собирает из них черновик постановки.

## FR-03 — Передача customer_id

Требование:
Backend должен передавать customer_id при создании recurring-платежа
в Acme Pay v2.1.

Evidence:
- S01 §3.1: customer_id required for recurring charges.
- RF-03: POC не передает customer_id.

Acceptance criteria:
- recurring charge request содержит customer_id;
- при отсутствии customer_id запрос не отправляется в Acme;
- ошибка мапится в понятный business error.

Open question:
Кто является источником customer_id в текущей архитектуре:
CRM, billing profile или user service?

Это еще не финальный SDD. Но это уже не заметка «надо разобраться с customer_id». Команда видит требование, evidence, риск из Review Findings и вопрос, который блокирует точную реализацию.

Хороший functional requirement должен быть коротким, проверяемым и связанным с evidence. Достаточно структуры: ID требования, формулировка, evidence, notes и acceptance criteria.

Плохой вариант: «Система должна корректно работать с платежами». Рабочий вариант: «Backend должен передавать Idempotency-Key во все create payment requests к Acme Pay v2.1. Evidence: S01 §4.3, RF-06. Acceptance criteria: повторный запрос с тем же ключом не создает второй платеж».

Open questions показывают, где задача еще не готова к финальному commitment. Вопросы лучше группировать по адресату: PM, заказчик, провайдер, архитектор, security.

Assumptions нужны рядом, но это другой тип записи. Вопрос означает «нам нужен ответ». Допущение означает «мы временно считаем так, пока нет ответа». У хорошего assumption есть последствие: что сломается или изменится, если оно окажется неверным.

Task Pack можно вести вручную в Markdown, Confluence, Notion, Google Docs или Jira epic. Метод не привязан к инструменту. Важнее, чтобы сохранялись ID требований, ссылки на источники, Review Findings, открытые вопросы и решения.

«Подмастерье аналитика» ускоряет первый черновик Task Pack: если уже готовы source map, System Context Pack и Review Findings, черновик можно собрать за 5-10 минут, разложить требования, подтянуть evidence, сгруппировать вопросы и предложить acceptance criteria.