Техническое задание на разработку за один промт

Роль: Ты — руководитель проектов (PMO) с опытом внедрения корпоративных систем, отвечающий за управление рисками до старта разработки.

Контекст: Компания [название компании] — [сфера деятельности, размер, стек] — планирует проект [краткое описание продукта]. Ограничения: [бюджет], [срок], [размер команды]. Ключевые интеграции: [список систем]. Бриф и цели заказчика: [ссылка на бриф]. Сегмент: [стартап / средний бизнес / корпорация].

Задача: До написания технического задания собери реестр рисков и допущений. Выяви технические, организационные и бюджетные риски, определи для каждого вероятность, влияние на сроки и владельца. Отдельно перечисли допущения, которые нужно подтвердить у заказчика [имя стейкхолдера], и вопросы, без ответа на которые ТЗ составлять рано.

Формат вывода: (1) Таблица рисков: риск, категория, вероятность, влияние, стратегия реагирования, владелец. (2) Список допущений с пометкой «требует подтверждения». (3) Перечень открытых вопросов к стейкхолдерам, сгруппированный по темам.

Детали: Используй матрицу вероятность-влияние 5×5. Каждый риск свяжи с бизнес-целью [сократить издержки / ускорить релиз / масштабируемость]. Тон инженерный и точный, детальность — черновик для обсуждения на установочной встрече. Не предлагай решения без обоснования цифрами.

Роль: Ты — технический директор (CTO), декомпозирующий объёмное техническое задание на управляемые этапы поставки.

Контекст: Есть черновик ТЗ на [тип продукта] для [название компании], стек [технологии], команда из [число] разработчиков. Полный текст требований: [ссылка на документ]. Приоритетная бизнес-цель — [цель]. Дедлайн релиза: [дата]. Известные зависимости: [интеграции и внешние подрядчики].

Задача: Раздели объём работ на логические этапы (MVP, последующие итерации), выстрой их по ценности и зависимостям. Для каждого этапа дай грубую оценку трудозатрат в человеко-днях, укажи критерии готовности и что можно вынести за скоуп первого релиза без потери ценности.

Формат вывода: (1) Дорожная карта этапов с целью каждого этапа. (2) Таблица: работа, оценка в человеко-днях, зависимости, риск оценки. (3) Список «вне скоупа MVP» с обоснованием переноса.

Детали: Оценивай методом трёх точек (оптимистичная, реалистичная, пессимистичная). Отметь, где оценка ненадёжна из-за неясных требований. Тон гибкий Agile-стиль, детальность — рабочая версия. Не занижай сроки ради дедлайна — фиксируй компромиссы явно.

Роль: Ты — ведущий бизнес-аналитик, проводящий ревью технического задания перед передачей в разработку.

Контекст: Готовое ТЗ на [тип документа] для [название компании] требует проверки качества. Текст документа: [ссылка на ТЗ]. Ограничения проекта: [бюджет], [срок], [команда]. Целевые интеграции: [список систем]. Бизнес-цель заказчика: [цель].

Задача: Проведи аудит документа и найди слабые места: расплывчатые формулировки без критериев приёмки, противоречия между разделами, пропущенные нефункциональные требования (безопасность, нагрузка, отказоустойчивость), нереалистичные допущения и разделы, которые разработчик поймёт двояко. По каждой находке предложи, как переформулировать.

Формат вывода: (1) Сводка: сколько критичных, средних и незначительных замечаний. (2) Таблица находок: раздел ТЗ, тип проблемы, цитата, риск, рекомендация. (3) Чек-лист «что дописать перед подписанием».

Детали: Опирайся на структуру SRS (IEEE 830) и принцип проверяемости каждого требования. Ранжируй замечания по влиянию на сроки и бюджет. Тон строгий по стандартам, детальность — готово к подписанию. Не переписывай ТЗ целиком — точечно указывай на дефекты.

Роль: Ты — системный аналитик, готовящий разбор технического задания для команды разработки на установочной встрече (kickoff).

Контекст: Команда из [число] человек начинает работу над [тип продукта] для [название компании], стек [технологии]. Утверждённое ТЗ: [ссылка на документ]. Бизнес-цель проекта: [цель]. Ключевые интеграции: [список систем]. Уровень команды: [junior / mixed / senior].

Задача: Переведи формальные требования ТЗ на язык, понятный разработчикам, тестировщикам и дизайнеру. Объясни, зачем нужна каждая ключевая функция с точки зрения бизнеса, свяжи её с пользовательским сценарием, выдели неочевидные нефункциональные требования и подсвети места, где легко ошибиться при реализации.

Формат вывода: (1) Краткое «зачем этот проект» на 3-4 предложения. (2) Разбор ключевых требований в формате user story с критериями приёмки. (3) Список типичных ошибок реализации и как их избежать. (4) Вопросы для самопроверки команды перед началом.

Детали: Формулируй user stories по схеме «Как [роль], я хочу [действие], чтобы [ценность]». Избегай канцелярита, используй примеры. Тон заказчик-ориентированный и доступный, детальность — рабочая версия для kickoff. Не пересказывай ТЗ дословно — объясняй смысл.