Как подготовить ТЗ на разработку ПО: что написать исполнителю

Хорошее ТЗ на разработку отвечает на четыре вопроса: какую проблему решаем, кто будет пользоваться продуктом, что он должен делать в главном сценарии и по каким признакам работу примут. Для старта достаточно короткого брифа на одну-две страницы своими словами, а подробное техническое задание удобнее собирать вместе с исполнителем после разбора задачи. Если ТЗ нет совсем, это не препятствие: опишите, что мешает сейчас и какой результат нужен.

Что такое техническое задание и зачем оно заказчику

Техническое задание (ТЗ) — это документ, в котором записано, что нужно построить, для кого и как понять, что работа сделана. Его часто считают формальностью для исполнителя, но на деле ТЗ в первую очередь защищает заказчика: оно фиксирует ожидания до начала работ, а не после того, как деньги и время уже потрачены.

Без договорённостей на бумаге каждая сторона держит в голове свою картину продукта. Заказчик представляет приложение с личным кабинетом и оплатой, исполнитель — простую форму с выгрузкой в таблицу. Расхождение обнаруживается на сдаче, когда исправлять дороже всего. Даже короткое описание задачи снимает большую часть таких сюрпризов.

При этом ТЗ не обязано быть толстым. Его задача — не описать каждую кнопку, а договориться о главном: цели, пользователях, сценариях, ограничениях и критериях приёмки. Остальное уточняется по ходу работы, если продукт собирается частями.

Бриф и полное ТЗ: в чём разница

Слова «бриф» и «техническое задание» часто путают. Это два разных документа для разных этапов, и заказчику обычно нужен только первый.

Практический вывод простой: заказчику не нужно садиться за техническое задание в одиночку и разбираться в архитектуре. Достаточно хорошего брифа, а подробности удобнее прорабатывать с командой, которая будет строить продукт.

Что делать, если ТЗ нет

Отсутствие технического задания — нормальная ситуация, особенно для первого проекта. Готовое ТЗ не обязательно: задачу можно описать своими словами. Начните с трёх вещей:

• Что мешает сегодня. Где теряются деньги и время, какую работу сотрудники делают руками, на что жалуются клиенты.
• Какой результат нужен. Что изменится, когда продукт заработает: заявки приходят сами, отчёт собирается без человека, клиент оплачивает в два касания.
• Кто будет пользоваться. Клиенты, сотрудники, партнёры, администратор — и с каких устройств.

Этого достаточно, чтобы начать разговор. Например, у JEEKSSHIRE 24 задачу можно описать в форме заявки на странице разработки: что сейчас мешает и какой результат нужен. Дальше на разборе задачи вместе формулируем, что строить, и раскладываем работу на части. Иногда на этом шаге выясняется, что нужен бот, а не приложение, — и это лучше узнать до начала работ.

Из каких разделов состоит ТЗ: чек-лист

Если вы хотите подготовить документ заранее, используйте таблицу как чек-лист. Не обязательно заполнять все строки: пустой раздел честнее, чем выдуманные требования.

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

Как составить ТЗ: пошагово

Если вы пишете документ сами, двигайтесь от задачи к деталям, а не наоборот:

1. Сформулируйте проблему в одном-двух предложениях без технических слов.
2. Опишите, как выглядит успех: что измеримо изменится после запуска.
3. Перечислите пользователей и что каждый из них делает в продукте.
4. Распишите главный сценарий по шагам, как рассказ: «клиент открывает, выбирает, оплачивает, получает».
5. Разделите функции на обязательные для первой версии и те, что можно добавить потом.
6. Перечислите системы, с которыми нужно связаться, и данные, которые через них идут.
7. Назовите ограничения: желаемый срок, ориентир по бюджету, требования к хранению данных.
8. Запишите критерии приёмки — проверяемые утверждения, а не «удобно» и «красиво».
9. Отдайте бриф исполнителю и задайте вопросы: что непонятно, что лишнее, что можно сделать проще.

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

ТЗ на разработку приложения, бота и ИИ-агента: что добавить

Общий каркас одинаков, но у разных типов продуктов есть свои вопросы, которые стоит закрыть заранее.

Мобильное или настольное приложение

Укажите платформы (iOS, Android, macOS, Windows, веб), нужна ли публикация в магазинах приложений, работа без интернета, оповещения, автообновление. Для настольных приложений — нужны ли установщик и работа с файлами на компьютере.

Telegram-бот или мини-приложение

Опишите сценарий диалога: какие кнопки видит пользователь, что происходит после каждого нажатия, кто получает уведомления. Отдельно — нужна ли оплата, рассылки, админка и связь с CRM или таблицами. Подробнее о сценариях — в разборе Telegram-бот для бизнеса.

ИИ-агент

Главное в ТЗ на ИИ-агента — данные и границы. Перечислите источники (документы, переписка, база знаний), задачи, которые агент выполняет, и действия, которые ему запрещены. Приложите реальные примеры вопросов и правильных ответов: на них проверяют качество первой версии. Как такие проекты устроены, разобрано в материале ИИ-агент для бизнеса.

Типичные ошибки в техническом задании

Большинство проблем с ТЗ повторяется от проекта к проекту:

• Решение вместо задачи. «Нужно приложение» вместо «клиенты не могут быстро оставить заявку». Описание проблемы оставляет место для более простого решения.
• Всё сразу. В первую версию попадают все идеи, и запуск отодвигается. Лучше выделить главный сценарий и выпустить его раньше.
• Размытые критерии. «Удобный интерфейс» и «быстрая работа» нельзя проверить. Пишите, что именно должно происходить.
• Забытые роли. Описан путь клиента, но не указано, кто и как управляет продуктом изнутри.
• Молчание об интеграциях. Связь с CRM, складом или оплатой выясняется в середине работы и меняет объём.
• Требования к безопасности в конце. Права доступа и хранение данных проще заложить сразу, чем добавлять перед сдачей.
• Нет условия о передаче. Не записано, что заказчик получает исходный код, права на него и описание продукта.
• Копия чужого ТЗ. Шаблон из интернета описывает чужой бизнес и создаёт ложное ощущение полноты.

Как ТЗ связано со сроками, MVP и приёмкой

От качества брифа напрямую зависит, насколько точной будет оценка. Пока задача не разобрана, срок можно назвать только ориентиром: по опыту JEEKSSHIRE 24 Telegram-бот или небольшая автоматизация занимают обычно от одной до нескольких недель, первая версия ИИ-агента — несколько недель, отдельное приложение — от нескольких месяцев. Подробнее о том, из чего складывается срок, — в разборе сколько длится разработка приложения.

Если идей много, а уверенности мало, ТЗ стоит писать не на весь продукт, а на первую версию с главным сценарием. Как выделить такую версию, разобрано в материале MVP: с чего начать.

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

Как мы работаем с задачей в JEEKSSHIRE 24

Мы начинаем с задачи, а не с технологии. Порядок такой:

1. Разбор задачи: смотрим, что мешает бизнесу сегодня, где теряются деньги и время и какой результат считается успехом.
2. Решение и оценка: предлагаем самое простое решение, которое даёт нужный результат, и раскладываем его на части, которые можно показать и проверить по отдельности.
3. Сборка по частям: вы видите работающие куски по ходу дела и можете менять приоритеты между частями.
4. Проверка и релиз: сборка, линт и тесты проходят до выкатки.
5. Наблюдение и развитие: оповещения о сбоях и резервные копии.

Поэтому от заказчика не требуется идеальный документ. Вместе с продуктом передаём исходный код, права на него и описание того, как продукт устроен и как его выпускать; условия фиксируются договором до начала работ. Чтобы обсудить вашу задачу, загляните на страницу разработки ПО или сразу опишите её в форме заявки.

User stories и критерии приёмки: как описать функции

Функции удобно описывать не списком экранов, а пользовательскими историями (user stories). Каждая история отвечает на три вопроса: кто действует, что он хочет сделать и зачем. Шаблон простой: «Как <роль>, я хочу <действие>, чтобы <польза>». Например: «Как менеджер, я хочу видеть новые заявки в одном списке, чтобы не искать их в почте».

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

• Дано: клиент заполнил форму заявки.
• Когда: он нажимает «Отправить».
• Тогда: заявка появляется в списке менеджера, а клиент видит, что произойдёт дальше.

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

Границы проекта и порядок изменений

Раздел «вне рамок» так же важен, как список функций. В нём прямо перечисляют, чего в этой версии не будет: например, мобильного приложения, если сначала запускается веб, или интеграции со складом, если она нужна позже. Это снимает споры на приёмке и не даёт объёму расти незаметно.

Изменения по ходу работы нормальны, особенно когда продукт собирается частями. Важно, чтобы у них был порядок:

1. Изменение записывают: что меняется и зачем.
2. Исполнитель оценивает, как оно влияет на срок и на уже сделанные части.
3. Стороны договариваются, что изменение заменяет или откладывает.
4. Только после этого его берут в работу, а ТЗ обновляют.

Особенно строго границы держат в первой версии продукта. Если вы запускаете разработку MVP, список «вне рамок» помогает выпустить главный сценарий раньше, а остальное отложить на следующие релизы.