Промпт-рецепт: составление технического задания для разработчика или фрилансера

Задача: что решает этот промпт

Вы знаете, что хотите сделать — Telegram-бот, лендинг, мобильное приложение, API-интеграция. Но объяснить это разработчику так, чтобы на выходе получилось именно то, что вы представляли — отдельное искусство.

Этот промпт решает классическую проблему: заказчик хочет одно, разработчик делает другое, потому что техническое задание было написано «на коленке» или вообще в мессенджере.

В 2026 году подход Spec-Driven Development (разработка от спецификации) стал стандартом в командах, работающих с AI-агентами: сначала подробная спека, потом код. Чем точнее написано ТЗ, тем меньше итераций, правок и недопониманий. Тот же принцип работает при найме фрилансеров.

Для кого

Как работает процесс

graph TD
    A[Ваша идея в словах] --> B[Промпт → Claude]
    B --> C{Уточняющие вопросы}
    C -->|Отвечаете| D[Claude генерирует ТЗ]
    D --> E[Раздел: цель и контекст]
    D --> F[Раздел: функциональные требования]
    D --> G[Раздел: стек и ограничения]
    D --> H[Раздел: критерии приёмки]
    E --> I[Готовое ТЗ]
    F --> I
    G --> I
    H --> I
    I --> J[Разработчик / фрилансер / AI-агент]

Промпт

Ты — опытный технический менеджер с 10+ годами опыта в постановке задач для разработчиков. 
Твоя задача — помочь мне написать детальное техническое задание (ТЗ) для разработчика или 
фрилансера.

=== МОЯ ИДЕЯ ===
[ОПИШИ ЗДЕСЬ, ЧТО ХОЧЕШЬ СДЕЛАТЬ — 2-5 предложений]

=== КОНТЕКСТ ===
- Тип проекта: [сайт / бот / мобильное приложение / API / другое]
- Для кого: [целевая аудитория, кто будет пользоваться]
- Бюджет (опционально): [укажи диапазон или "не определён"]
- Сроки: [желаемые сроки или "гибкие"]
- Предпочтения по стеку: [если есть: Python, React, Telegram Bot API и т.д.]

=== ЗАДАНИЕ ===
На основе этой информации:
1. Сначала задай мне 3-5 уточняющих вопроса, ответы на которые критически важны для ТЗ.
2. После того как я отвечу на вопросы, составь ТЗ в следующей структуре:

# Техническое задание: [название проекта]

## 1. Цель и контекст
- Зачем создаётся продукт
- Кто им будет пользоваться
- Какую проблему решает

## 2. Функциональные требования
(пронумерованный список с приоритетами: Обязательно / Желательно / Опционально)

## 3. Нефункциональные требования
- Производительность, безопасность, масштабируемость
- Доступность (мобильная версия, браузеры)
- Языки интерфейса

## 4. Технический стек (рекомендации)
- Предложи подходящий стек с кратким обоснованием

## 5. Интеграции и зависимости
- Сторонние сервисы, API, базы данных

## 6. Что НЕ входит в scope
(явно перечисли, что не нужно делать, чтобы избежать scope creep)

## 7. Критерии приёмки
(чёткие, проверяемые условия — как понять, что задача выполнена)

## 8. Вопросы и риски
- Потенциальные сложности, которые стоит обсудить заранее

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

Пример результата

Исходный запрос:

Хочу Telegram-бота для приёма заказов. У меня небольшая кофейня, 3 точки в Москве.

Claude сначала задаёт вопросы:

1. Нужна ли онлайн-оплата через бота, или только приём заказа с оплатой на месте?
2. Должны ли разные точки получать уведомления раздельно, или всё в один чат?
3. Нужна ли история заказов и статистика для вас как владельца?
4. Используете ли вы сейчас какую-либо систему учёта (IIKO, 1С)?
5. Ожидаемое количество заказов в день: до 50, до 200, больше?

После ответов — фрагмент готового ТЗ:

## 2. Функциональные требования

### Обязательно
1. Бот отображает меню с категориями (напитки, еда, комбо) и ценами
2. Пользователь выбирает точку из 3 доступных
3. Пользователь формирует заказ: добавляет позиции, указывает количество
4. При подтверждении заказа — уведомление в отдельный чат каждой точки
5. Уведомление содержит: состав заказа, имя клиента, username, время

### Желательно
6. Возможность оставить комментарий к заказу
7. Кнопка "повторить прошлый заказ"

### Опционально (в следующей версии)
8. Онлайн-оплата через Telegram Stars или ЮКаssa
9. Личный кабинет владельца со статистикой

## 7. Критерии приёмки
- Заказ проходит полный цикл от /start до уведомления менеджеру за ≤ 30 секунд
- Бот корректно работает при одновременных заказах с разных точек
- При недоступности бота сообщение об ошибке появляется в течение 5 секунд

Хорошее ТЗ — это не документ ради документа. Это контракт между вашими ожиданиями и реальностью, которую создаст разработчик.

Вариации и настройки

Советы по улучшению

1. Итеративный подход. Не пытайтесь заполнить промпт идеально с первого раза. Напишите черновик, получите вопросы от Claude, ответьте — и только тогда ТЗ получится точным.

2. Фиксируйте «не входит в scope». Раздел «Что НЕ входит» — один из самых важных. Опытные PM-ы говорят: 80% конфликтов с разработчиками возникают не из-за того, что написано в ТЗ, а из-за того, что туда не попало.

3. Измеримые критерии приёмки. «Сайт должен быстро загружаться» — плохо. «Страница загружается за ≤ 2 секунды на мобильном 4G» — хорошо. Просите Claude заменять все субъективные оценки на конкретные числа.

4. Передайте ТЗ разработчику и попросите оценку. Хорошее ТЗ позволяет получить точную оценку с первого раза. Если разработчик задаёт много вопросов — значит, ТЗ нужно доработать.

5. Используйте ТЗ как промпт для AI-агента. В 2026 году AI-агенты (Claude Code, GitHub Copilot Workspace, Cursor) умеют генерировать рабочий код из детальной спецификации. Чем точнее ТЗ — тем меньше правок в коде.