Техническое задание для вайбкодера помогает заранее договориться, какой результат вы хотите получить и как будете его проверять. Для этого не обязательно разбираться в программировании. Достаточно описать задачу, действия пользователей, нужные данные и условия готовности.
Даже если исполнитель пишет код с помощью нейросетей, ему нужны конкретные требования. Формулировку «сделайте удобного бота» каждый понимает по-своему. Формулировку «после отправки заявки администратор получает услугу, желаемое время и контакт клиента» уже можно проверить. С таким описанием проще обсуждать задачу со специалистами в каталоге разработки под ключ.
Начните с одной основной задачи: что должно стать проще после запуска программы? Например, собирать заявки на запись и передавать их администратору без ручного копирования переписки.
Затем перечислите пользователей и их действия. Клиент отправляет заявку, администратор рассматривает её, клиент получает ответ. Если в первой версии запись подтверждает человек, это нужно прямо указать. Иначе можно ожидать автоматическое бронирование свободного времени, хотя исполнитель сделает только форму обращения.
Приложите примеры экранов, сообщения или таблицу с нужными полями. У каждого примера поясните, что именно вам подходит: расположение кнопок, порядок вопросов или состав данных. Перед включением материалов уберите из них пароли, токены и лишние персональные сведения.
Скопируйте шаблон и замените текст в квадратных скобках. Если ответ пока неизвестен, так и напишите: «нужно согласовать». Это лучше, чем оставлять важную часть на усмотрение исполнителя.
1. Цель и результат
[Какую задачу решаем? Что пользователь сможет сделать после запуска?]2. Пользователи и роли
[Кто пользуется программой? Какие действия доступны каждой роли?]3. Основной сценарий
[Опишите действия от первого экрана до получения результата по шагам.]4. Функции первой версии
[Перечислите обязательные функции. У каждой укажите ожидаемое поведение.]5. Границы первой версии
[Какие возможности оставляем на потом? Что программа пока не делает?]6. Данные и их хранение
[Какие поля собираем, какие обязательны, где сохраняем, кто видит данные?]7. Внешние системы
[С какими сервисами связываем программу? Какие аккаунты уже есть? Секреты сюда не вставлять.]8. Интерфейс и сообщения
[Какие экраны, кнопки и тексты нужны? Приложите примеры.]9. Ошибки и ограничения
[Что происходит при неправильных данных, отмене, повторной отправке или сбое?]10. Передача и публикация
[Какие файлы, исходники и инструкции получаем? Где запускаем? Кто публикует?]11. Проверки приёмки
[Какие действия выполняем и какой результат ожидаем в каждом случае?]12. Сроки, бюджет и поддержка
[Когда нужен результат? Какой бюджет рассматриваем? Какие расходы оплачиваются отдельно? Кто отвечает после запуска и как согласуем изменения?]
Ниже — учебный пример для небольшой студии. Бот собирает пожелания клиента, а окончательное время согласует администратор. Платёжных интеграций в этом задании нет.
Оценивайте наблюдаемое поведение. Для каждой проверки заранее запишите исходные данные и ожидаемый результат. Используйте тестовые контакты, которые контролируете сами.
| Действие | Ожидаемый результат |
|---|---|
| Нажать /start | Появляются две кнопки главного меню с согласованными названиями. |
| Заполнить и отправить заявку | Клиент получает её номер; администратор получает все согласованные поля; статус — «Новая». |
| Оставить имя пустым или указать прошедшую дату | Бот просит исправить соответствующее поле; заявка ещё не отправлена. |
| Нажать /cancel во время заполнения | Заполнение прекращается; новая заявка не создаётся. |
| Дважды быстро нажать «Отправить» | В базе появляется одна заявка, администратор получает одно уведомление. |
| Подтвердить заявку, затем проверить её состояние | Статус становится «Подтверждена»; клиент получает уведомление. |
| Отклонить другую заявку | Её статус становится «Отклонена»; уведомление получает создавший её клиент. |
| Попытаться открыть административные действия с другого аккаунта | Просмотр чужих заявок и изменение их статусов недоступны. |
Если проверка не проходит, зафиксируйте шаги, фактический результат и ожидаемое поведение. Например: «После двойного нажатия создались заявки №15 и №16; ожидалась одна». Скриншот помогает показать проблему, но не заменяет описание действий.
Лендинг. «В форме заявки нужны имя, контакт и выбранная услуга. После отправки данные приходят администратору по согласованному каналу, а посетитель видит подтверждение. Пустой контакт не принимается». Проверка: отправить тестовую заявку, сверить три поля у администратора, повторить отправку без контакта.
Обработка таблицы. «Скрипт читает CSV с колонками “Артикул” и “Цена”, оставляет одну строку на артикул и сохраняет результат в новый файл. При повторе артикула берём первую строку. Исходный файл не меняем». Проверка: подготовить пять строк с одним повтором; в результате должны остаться четыре, а значения — совпасть с ожидаемыми.
Спросите, что именно передадут: весь исходный код, файлы настройки без секретов, сведения о зависимостях и команды запуска. Проверьте, можно ли по инструкции запустить программу в согласованной среде. Ссылка на работающего бота сама по себе не отвечает на эти вопросы.
Отдельно определите, чьи аккаунты используются для бота и сервера, кто оплачивает размещение, кто публикует обновления и кто может перезапустить программу. Не включайте пароли и токены в ТЗ. Способ предоставления необходимых доступов согласуйте отдельно; объём доступа должен соответствовать задаче.
Согласуйте желаемую дату результата и доступный бюджет до начала работы. Уточните отдельно плату за сервер, сервисы и дальнейшее сопровождение.
Уточните, сохраняются ли заявки после перезапуска и кто отвечает за резервные копии, если они нужны. Для поддержки запишите, какие обращения входят в согласованный объём, через какой канал их отправлять и как обсуждать новые функции. Эти условия помогают понимать обязанности после передачи программы.
Нужно ли знать программирование, чтобы написать ТЗ?
Нет. Опишите действия людей, данные и ожидаемый результат. Выбор языка и технических решений можно обсудить с исполнителем. Если сложно собрать требования, можно начать с консультации по задаче.
Насколько подробным должно быть задание?
Настолько, чтобы обязательные функции можно было однозначно проверить. Для небольшой программы достаточно заполненного шаблона, примеров сообщений и списка проверок. Важнее конкретность, чем количество страниц.
Что делать, если требования изменились?
Запишите изменение отдельным пунктом, укажите затронутые сценарии и обновите проверки приёмки. Согласуйте новую версию ТЗ с исполнителем до реализации изменения, чтобы оба работали по одному описанию.
Когда шаблон заполнен, а открытые вопросы перечислены, опубликуйте задание в разделе «Заказы». Укажите цель, функции первой версии и ожидаемый результат: так исполнителю будет проще задать предметные вопросы и оценить работу.
