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

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

Контекст: Проект — [название продукта], заказчик [название компании] из сферы [отрасль]. У меня есть расшифровки интервью со стейкхолдерами: [ссылка на транскрипт или вставленный текст]. Известные ограничения: стек [технологии], бюджет [сумма], срок [срок]. Ключевые пользователи: [роли пользователей].

Задача: Выдели из интервью явные и скрытые требования, отдели функциональные от нефункциональных, найди противоречия и пробелы, которые нужно уточнить у заказчика до старта.

Формат вывода: (1) Таблица требований — колонки «ID», «Формулировка», «Тип», «Источник (цитата)», «Приоритет MoSCoW». (2) Список из 5-8 уточняющих вопросов к заказчику. (3) Раздел «Риски и допущения».

Детали: Формулируй требования измеримо и однозначно, избегай слов «удобно» и «быстро» без метрики. Тон партнёрский, ориентирован на диалог с заказчиком без технического бэкграунда. Не выдумывай факты, которых нет в интервью — помечай пробелы как «требует уточнения».

Роль: Ты — product owner с техническим бэкграундом, готовящий Agile-спецификацию для внутренней продуктовой команды.

Контекст: Продукт — [название SaaS-продукта], новая фича — [описание фичи]. Пользовательский сценарий (JTBD): [что пользователь хочет сделать и зачем]. Технические ограничения: [стек и интеграции], метрика успеха фичи — [KPI]. Целевые роли: [роли пользователей].

Задача: Декомпозируй фичу на эпик и набор user stories, для каждой пропиши acceptance criteria по схеме Given-When-Then и оцени относительную сложность.

Формат вывода: (1) Название эпика и цель. (2) Список user stories в формате «Как [роль], я хочу [действие], чтобы [ценность]». (3) Для каждой — acceptance criteria и оценка в story points. (4) Список зависимостей между историями.

Детали: Делай истории атомарными и независимыми (INVEST). Учитывай нефункциональные требования по направлению [производительность или безопасность] и связывай их с этапом разработки. Тон разговорный, для стартап-команды. Уровень детальности — рабочая версия для команды.

Роль: Ты — technical director (CTO), который проводит экспертизу технического задания перед его передачей подрядчику-аутсорсеру на тендер.

Контекст: Документ — ТЗ на проект [название продукта], текст здесь: [ссылка на документ или вставленный текст]. Проект уровня [объём проекта], стек [технологии], интеграции [список интеграций]. Бюджет [сумма], срок [срок]. Меня беспокоит, что подрядчик может завысить оценку или сделать не то из-за размытых формулировок.

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

Формат вывода: (1) Общая оценка готовности ТЗ по шкале 1-10 с обоснованием. (2) Таблица проблем — «Раздел», «Проблема», «Почему это риск», «Как исправить». (3) Чек-лист недостающих разделов. (4) Топ-5 критичных правок перед отправкой.

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

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

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

Задача: Разбери ТЗ для команды: переведи бизнес-требования на технический язык, покажи связь фич с целями заказчика, выдели неочевидные места и подводные камни, на которые стоит обратить внимание при реализации.

Формат вывода: (1) Краткое резюме проекта в 3-4 предложениях — что и зачем строим. (2) Разбор ключевых требований блоками «что просит заказчик → что это значит в коде → на что обратить внимание». (3) Список из 5 частых заблуждений по этому ТЗ. (4) Вопросы для проверки понимания команды.

Детали: Объясняй доступно, но без потери точности, используй аналогии где уместно. Тон партнёрский и поддерживающий. Сделай акцент на [масштабируемость или удобство поддержки] и объясни, почему это важно именно для этого продукта.