Обязательно ли готовить ТЗ до обращения к разработчику?

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

Что обязательно должно быть в техническом задании?

Цель, пользователи и роли, сценарии, данные, интеграции, ограничения, критерии приёмки и список того, что не входит в текущую версию.

Как проверить качество требования?

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

Как составить ТЗ на разработку ПО

Короткий ответОпишите не техническое решение, а задачу, пользователей и результат, который можно проверить.

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

Структура технического задания

1. Проблема и цель. Что происходит сейчас, почему это мешает и какой показатель должен измениться.

2. Пользователи и роли. Кто работает с продуктом, что видит и какие действия может выполнять.

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

4. Данные. Какие сущности хранятся, откуда появляются, кто их меняет и как долго они нужны.

5. Интеграции. CRM, 1С, платежи, Telegram, почта и другие API; кто выдаёт доступы.

6. Нефункциональные требования. Устройства, браузеры, нагрузка, безопасность, скорость и резервное копирование.

7. Ограничения. Сроки, обязательные технологии, законодательство, существующий код и инфраструктура.

8. Критерии приёмки. Наблюдаемые условия, по которым функция считается выполненной.

9. Не входит в версию. Явный список отложенных функций защищает проект от разночтений.

Плохое и хорошее требование

Неоднозначно	Проверяемо
«Сайт должен быстро загружаться»	«Ключевые страницы должны проходить согласованный порог Core Web Vitals на мобильных устройствах»
«Менеджеру нужен удобный кабинет»	«Менеджер видит новые заявки, меняет статус и оставляет внутренний комментарий»
«Интегрировать с CRM»	«После отправки формы создать сделку в выбранной воронке и сохранить источник, телефон и услугу»
«Бот должен принимать оплату»	«Пользователь выбирает тариф, оплачивает через согласованного провайдера и получает подтверждение; статус заказа обновляется»

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

Чек-лист перед отправкой разработчику

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

Если ТЗ ещё нет

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

Не скрывайте неопределённость. Если неизвестно, как работает API или какие данные хранятся в старой системе, это лучше оформить как вопрос для технического исследования, а не как обещание.

Разберём задачу вместе

Пришлите описание процесса своими словами. Мы уточним сценарии, отделим первую версию и поможем превратить идею в требования для оценки.

Отправить описание задачи ↗