Как составить техническое задание для разработчика, если вы не программист

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

На самом деле заказчику не нужно становиться разработчиком.

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

Разработчик уже переводит эти требования в техническое решение.

Хорошее ТЗ не обязано выглядеть как документ на сто страниц. Для небольшого сайта, Telegram-бота или MVP часто достаточно нескольких хорошо структурированных разделов. Главное, чтобы заказчик и исполнитель одинаково понимали объём работы.

Что такое техническое задание простыми словами

Техническое задание, или ТЗ, представляет собой описание будущего продукта и требований к нему.

Оно помогает зафиксировать:

• цель проекта;

• пользователей;

• основные сценарии;

• обязательные функции;

• ограничения;

• интеграции;

• критерии приёмки;

• сроки;

• бюджет;

• порядок передачи результата.

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

Какой результат должен получить заказчик и как проверить, что разработчик его действительно создал?

Без такого документа стороны могут понимать одну задачу по-разному.

Заказчик говорит:

Нужен личный кабинет.

Он может представлять профиль пользователя, историю заказов, платежи, уведомления и настройки.

Разработчик может понять это как одну страницу с именем и email.

Оба формально говорят об одном личном кабинете, но ожидают совершенно разный объём работы.

Что описывает заказчик, а что решает разработчик

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

Заказчику не нужно писать:

Использовать Next.js, PostgreSQL, Redis и микросервисную архитектуру.

Гораздо полезнее написать:

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

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

Шаг 1. Опишите проблему и цель проекта

Не начинайте ТЗ со списка страниц и кнопок.

Сначала объясните, зачем вообще нужен продукт.

Слабое описание:

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

Более полезное описание:

Сейчас клиенты записываются через сообщения в Telegram. Менеджер вручную проверяет свободное время и подтверждает каждую запись. Нужен сервис, через который клиент сможет самостоятельно выбрать услугу, свободное время и получить подтверждение.

Во втором варианте разработчик понимает:

• существующую проблему;

• текущий процесс;

• ожидаемое улучшение;

• основной пользовательский сценарий.

Хорошая формулировка цели отвечает на три вопроса:

1. Что происходит сейчас?

2. Что работает плохо или занимает слишком много времени?

3. Что должно измениться после запуска продукта?

Пример:

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

Шаг 2. Определите пользователей и роли

Одним продуктом часто пользуются разные люди.

Например, в сервисе онлайн-записи могут быть:

• посетитель;

• зарегистрированный клиент;

• сотрудник;

• менеджер;

• администратор.

Для каждой роли нужно кратко описать доступные действия.

Посетитель

• просматривает услуги;

• видит цены;

• выбирает специалиста;

• начинает оформление записи.

Клиент

• входит в личный кабинет;

• создаёт запись;

• переносит или отменяет её;

• видит историю;

• получает уведомления.

Менеджер

• видит все записи;

• меняет статусы;

• связывается с клиентом;

• назначает сотрудника.

Администратор

• управляет пользователями;

• добавляет услуги;

• изменяет цены;

• настраивает расписание;

• просматривает аналитику.

Такое описание помогает заранее обнаружить вопросы о правах доступа.

Например, может ли обычный менеджер менять цены? Должен ли сотрудник видеть данные всех клиентов? Может ли клиент отменить запись за пять минут до начала?

Шаг 3. Описывайте функции через пользовательские сценарии

Список функций сам по себе часто остаётся слишком абстрактным.

Например:

• регистрация;

• личный кабинет;

• оплата;

• уведомления.

Разработчик видит названия модулей, но не понимает их точное поведение.

Полезнее описывать сценарии.

Регистрация

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

Оформление заказа

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

Восстановление доступа

Пользователь указывает email, получает ссылку для восстановления и задаёт новый пароль. Старая ссылка перестаёт работать после использования или истечения срока.

Формула хорошего сценария:

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

Шаг 4. Разделите функции по приоритету

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

Полезно разделить требования на три группы.

Обязательно для первой версии

Без этих функций продукт не решает основную задачу.

Например:

• регистрация;

• каталог услуг;

• создание записи;

• административная панель;

• уведомление менеджера.

Желательно

Эти функции полезны, но запуск возможен и без них.

Например:

• избранное;

• промокоды;

• расширенная аналитика;

• несколько цветовых тем;

• автоматические рекомендации.

Следующий этап

Идеи, которые стоит обсуждать после проверки первой версии.

Например:

• мобильное приложение;

• бонусная программа;

• интеграция с несколькими CRM;

• сложная система ролей;

• отдельный кабинет партнёра.

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

Шаг 5. Перечислите страницы и разделы

После описания цели и сценариев можно составить примерную структуру интерфейса.

Например:

• главная страница;

• каталог услуг;

• страница услуги;

• оформление записи;

• вход и регистрация;

• личный кабинет;

• история записей;

• административная панель;

• настройки;

• политика конфиденциальности.

Не нужно самостоятельно проектировать каждую кнопку. Достаточно указать назначение разделов и данные, которые пользователь должен там видеть.

Например:

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

Шаг 6. Укажите все интеграции

Интеграция представляет собой подключение внешнего сервиса.

Она может существенно повлиять на стоимость, срок и сложность проекта.

Укажите заранее, если продукт должен работать с:

• платёжной системой;

• Telegram;

• CRM;

• email-сервисом;

• телефонией;

• картами;

• аналитикой;

• складской системой;

• онлайн-кассой;

• внешним API;

• импортом из таблиц;

• экспортом документов.

Для каждой интеграции полезно уточнить:

• какой сервис используется;

• существует ли уже аккаунт;

• есть ли документация;

• кто предоставляет доступ;

• какие данные передаются;

• что должно произойти при ошибке.

Пример:

После новой заявки система отправляет сообщение в Telegram-группу менеджеров. Сообщение содержит имя клиента, телефон, выбранную услугу и ссылку на заявку в административной панели.

Шаг 7. Опишите требования к дизайну

Фраза «нужен современный и красивый дизайн» почти ничего не говорит исполнителю.

У разных людей разные представления о современном интерфейсе.

Полезнее приложить:

• логотип;

• фирменные цвета;

• брендбук;

• готовые макеты;

• ссылки на понравившиеся сайты;

• примеры отдельных блоков;

• список нежелательных решений.

Можно написать:

Нравится простая структура и крупная типографика сайта A. У сайта B подходит оформление карточек. Не подходят яркие градиенты, сложная анимация и перегруженные экраны.

Важно уточнить, кто создаёт дизайн:

• заказчик передаёт готовый макет;

• разработчик проектирует интерфейс самостоятельно;

• привлекается отдельный дизайнер;

• используется готовый шаблон.

Шаг 8. Зафиксируйте исходные материалы

Разработка часто останавливается не из-за кода, а из-за отсутствующих текстов, изображений и доступов.

Заранее укажите, кто предоставляет:

• тексты;

• фотографии;

• изображения товаров;

• логотип;

• цены;

• список услуг;

• юридические документы;

• переводы;

• доступ к домену;

• доступ к серверу;

• ключи внешних сервисов.

Пример:

Это позволяет понять, какие этапы зависят от действий заказчика.

Шаг 9. Добавьте измеримые ограничения

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

Например:

• сайт должен корректно работать на телефонах;

• интерфейс должен поддерживать русский и английский языки;

• административная панель доступна только авторизованным сотрудникам;

• формы должны быть защищены от массового спама;

• пользователь не должен видеть данные других клиентов;

• продукт должен работать в актуальных версиях основных браузеров;

• перед публикацией должна проходить production-сборка;

• ошибки должны записываться в журнал;

• база данных должна резервироваться.

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

Шаг 10. Сформулируйте критерии приёмки

Критерий приёмки объясняет, как проверить готовность функции.

Слабая формулировка:

Уведомления должны работать корректно.

Проверяемая формулировка:

После создания записи клиент получает email с датой, временем и названием услуги. Менеджер получает сообщение в Telegram не позднее чем через одну минуту.

Ещё один пример:

Администратор может создать услугу, указать название, описание, цену и изображение. После сохранения услуга появляется в каталоге и доступна для записи.

Для каждой важной функции желательно ответить:

• какое действие выполняет пользователь;

• какой результат появляется;

• где он отображается;

• кто получает уведомление;

• какие данные сохраняются;

• что происходит при ошибке.

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

Шаг 11. Укажите бюджет

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

Но отсутствие бюджета приводит к несопоставимым предложениям.

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

Полезнее указать диапазон:

На первую версию предусмотрено от 150 000 до 250 000 рублей. Если весь объём не помещается в бюджет, нужно предложить сокращённый MVP.

Диапазон помогает разработчику подобрать реалистичный подход.

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

Шаг 12. Объясните желаемый срок

Напишите не только дату, но и причину.

Например:

Рабочая версия нужна до 1 октября, потому что 10 октября начинается рекламная кампания.

Или:

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

Разработчик сможет предложить этапы:

1. Аналитика.

2. Прототип.

3. Основная разработка.

4. Тестирование.

5. Публикация.

Если дата слишком жёсткая, часть функций можно перенести на следующий этап.

Шаг 13. Определите порядок приёмки

До начала работы нужно согласовать:

• кто принимает результат;

• где проходит проверка;

• сколько дней даётся на обратную связь;

• какие ошибки считаются критическими;

• сколько раундов исправлений входит в стоимость;

• когда этап считается принятым;

• когда производится оплата;

• что относится к новой функции, а не к исправлению.

Пример:

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

Шаг 14. Зафиксируйте передачу проекта

В ТЗ или договорённостях нужно указать, что получит заказчик после завершения.

Обычно это:

• исходный код;

• доступ к репозиторию;

• доступ к серверу;

• доступ к базе данных;

• домен;

• список переменных окружения;

• инструкции запуска;

• список подключённых сервисов;

• документация;

• резервная копия;

• права на созданные материалы.

Лучше, когда основные аккаунты изначально принадлежат заказчику, а исполнитель получает отдельный ограниченный доступ.

Шаг 15. Опишите порядок изменений

После начала разработки почти всегда появляются новые идеи.

Например, заказчик решает добавить:

• ещё одну роль;

• новый способ оплаты;

• дополнительный язык;

• интеграцию с CRM;

• импорт старых данных.

Это нормально, но новое требование может изменить архитектуру, срок и стоимость.

Поэтому полезно заранее согласовать правило:

Новые функции и изменения согласованного поведения фиксируются отдельно. Исполнитель оценивает их влияние на стоимость и срок до начала реализации.

Так стороны отличают исправление ошибки от расширения проекта.

Готовый шаблон ТЗ для разработчика

Ниже находится заготовка, которую можно скопировать и заполнить.

1. Название проекта

Короткое рабочее название.

2. Описание текущей ситуации

Как задача решается сейчас? Какие проблемы возникают?

3. Цель проекта

Что должно измениться после запуска?

4. Целевая аудитория

Кто будет пользоваться продуктом?

5. Роли пользователей

Какие типы пользователей существуют и чем отличаются их права?

6. Основные пользовательские сценарии

Что должен уметь делать каждый пользователь?

7. Обязательные функции первой версии

Без каких возможностей продукт не решает основную задачу?

8. Дополнительные функции

Какие возможности полезны, но могут быть перенесены?

9. Не входит в первую версию

Что специально исключается из текущего объёма?

10. Страницы и разделы

Какие основные экраны нужны?

11. Интеграции

Какие внешние сервисы необходимо подключить?

12. Дизайн

Есть ли логотип, фирменный стиль, макет или примеры?

13. Исходные материалы

Кто предоставляет тексты, изображения, данные и доступы?

14. Общие требования

Мобильная версия, языки, безопасность, браузеры и другие ограничения.

15. Критерии приёмки

Как проверить каждую обязательную функцию?

16. Желаемый срок

Когда нужен прототип, первая версия и публичный запуск?

17. Бюджет

Какой диапазон предусмотрен?

18. Порядок исправлений

Как собираются замечания и сколько раундов входит в стоимость?

19. Передача проекта

Какие исходники, доступы и инструкции получает заказчик?

20. Поддержка после запуска

Нужна ли гарантийная поддержка, исправление ошибок или дальнейшее развитие?

Пример плохого ТЗ

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

Проблемы такого описания:

• неизвестно, кто пользуется личным кабинетом;

• не описан процесс записи;

• непонятно, как работает расписание;

• не указан способ оплаты;

• не определены возможности администратора;

• нет критериев готовности;

• неизвестно, кто предоставляет контент;

• невозможно объективно оценить срок и стоимость.

Пример улучшенного ТЗ

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

Нужен адаптивный веб-сервис, в котором клиент выбирает услугу, специалиста, свободную дату и время. После подтверждения запись сохраняется в системе. Клиент получает email, а менеджер получает сообщение в Telegram.

В первой версии клиент не регистрируется. Он указывает имя, телефон и email. Администратор добавляет услуги, сотрудников, рабочие часы и недоступные даты. Менеджер видит список записей и может менять их статус.

Онлайн-оплата, бонусная программа и мобильное приложение не входят в первую версию.

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

Бюджет первой версии составляет от 180 000 до 250 000 рублей. Тестовая версия нужна через шесть недель.

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

Частые ошибки при составлении ТЗ

Описание экранов без цели

Список страниц не объясняет, какую проблему решает продукт.

Попытка самостоятельно выбрать все технологии

Заказчик может случайно ограничить разработчика неподходящим решением.

Отсутствие приоритетов

Все идеи объявляются обязательными, поэтому первая версия становится слишком большой.

Расплывчатые требования

Фразы «удобно», «быстро» и «красиво» нельзя объективно проверить без дополнительных критериев.

Скрытые интеграции

Неожиданное подключение платежей или CRM может значительно изменить оценку.

Неограниченные правки

Исполнитель не понимает, когда работа считается завершённой.

Отсутствие ответственного лица

Несколько сотрудников заказчика дают противоречивую обратную связь.

Отсутствие требований к передаче

После запуска выясняется, что репозиторий, сервер или ключевые аккаунты принадлежат исполнителю.

Насколько подробным должно быть ТЗ

Объём документа зависит от сложности продукта.

Небольшой лендинг

Может быть достаточно:

• цели;

• структуры блоков;

• материалов;

• примеров дизайна;

• требований к формам;

• мобильной версии;

• аналитики;

• срока.

Telegram-бот или небольшой сервис

Потребуются:

• роли;

• сценарии;

• состояния;

• интеграции;

• административные функции;

• обработка ошибок;

• критерии приёмки.

Сложная система

Понадобится отдельный этап аналитики:

• интервью;

• карта процессов;

• прототипы;

• модель данных;

• спецификация ролей;

• требования к нагрузке;

• безопасность;

• план интеграций;

• этапы запуска.

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

Как должен реагировать хороший разработчик

Профессиональный исполнитель не просто читает ТЗ и сразу называет цену.

Он:

• задаёт уточняющие вопросы;

• находит противоречия;

• уточняет роли и сценарии;

• предупреждает о рисках;

• предлагает упростить первую версию;

• фиксирует допущения;

• объясняет влияние интеграций;

• превращает пожелания в критерии приёмки;

• делит проект на этапы.

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

Чек-лист перед отправкой ТЗ

Перед публикацией задания проверьте:

1. Понятно ли, какую проблему решает продукт?

2. Указаны ли пользователи и роли?

3. Описаны ли основные сценарии?

4. Выделены ли обязательные функции?

5. Отделены ли будущие идеи?

6. Перечислены ли интеграции?

7. Понятно ли, кто предоставляет материалы?

8. Есть ли проверяемые критерии приёмки?

9. Указан ли диапазон бюджета?

10. Объяснён ли желаемый срок?

11. Определён ли порядок правок?

12. Зафиксирована ли передача исходников и доступов?

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

Как использовать ТЗ на VibeMarket

Подготовленное техническое задание можно использовать как основу для размещения проекта на VibeMarket.

В описании задачи укажите:

• цель;

• основные функции;

• бюджет;

• срок;

• обязательные интеграции;

• критерии готовности;

• материалы, которые уже подготовлены.

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

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

Разместить задачу на VibeMarket

Итог

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

Заказчику достаточно хорошо описать:

• проблему;

• цель;

• пользователей;

• сценарии;

• обязательные функции;

• интеграции;

• ограничения;

• критерии приёмки;

• бюджет;

• срок;

• порядок передачи результата.

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

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