Task Pack: как прийти к PM не с пустыми руками

• Scope — что в проекте и что явно не в проекте.
• Functional requirements — каждое требование с цитатой на источник: S01 §X.Y, email от DD.MM или файл в Git.
• Non-functional requirements — безопасность, performance, availability, compliance.
• Open questions — явный список к PM, заказчику и провайдеру.
• Risks — находки из Review Findings, отсортированные по severity.
• Assumptions — что принимаем без подтверждения и что случится, если предположение неверно.
• Acceptance criteria — как команда определит, что решение готово.
• Estimation — preliminary, требует уточнения после ответов на open questions.

ТЗ и SDD — финальные документы, описывающие решение. Task Pack — рабочий артефакт аналитика, который явно фиксирует непонимание. Через месяц на code review, когда разработчик спросит «а где сказано, что customer_id обязателен?», аналитик открывает Task Pack §2.5, находит цитату на PDF §3.1 и за 15 секунд отправляет ссылку.

Task Pack живёт дольше, чем ТЗ, и обновляется по мере роста понимания. Это не попытка заранее написать идеальный документ, а способ держать вместе требования, вопросы, риски и evidence.

Task Pack — четвёртый и последний артефакт в workflow: Source map → System Context Pack → Review Findings → Task Pack. Первые три собирают понимание проекта, Task Pack превращает это в артефакт, с которым команда разработки работает.

Task Pack можно вести вручную в Markdown, Confluence или Jira epic — методология не привязана к инструменту. AI-напарник аналитика, Подмастерье в alpha, собирает первичный черновик Task Pack за 5–10 минут при готовых SCP и Review Findings.

Мастер проверяет цитаты, редактирует scope и добавляет бизнес-контекст. Решение всё равно остаётся за аналитиком и командой.

• Полный worked example на кейсе Acme Pay v2.1 — в pillar-статье про source map.
• POC-репозиторий на GitHub — InnokentyB/acme_poc.
• Готовый шаблон Task Pack планируется как lead magnet в августе 2026.