ТЗ на разработку сайта или приложения: как составить заказчику

ТЗ на разработку сайта или приложения чаще всего пишут в последний момент, когда подрядчик уже спросил: «А что именно делаем?» Тогда в документ попадает список пожеланий, а через два месяца стороны спорят, что было обещано.

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

Зачем заказчику ТЗ на разработку сайта или приложения?

Что такое техническое задание в общем виде, разобрано в словаре ClaudeLab. Здесь речь о другом: что с этим документом делает заказчик, который сам не программирует, но платит за результат.

У заказчика в разработке три риска:

1. Получить не то. Подрядчик собрал «удобный личный кабинет», как он его понимает. Вы представляли другой.
2. Заплатить дважды. Всё, что не записано, в смету не попало. Дописывать это потом приходится за отдельные деньги.
3. Не суметь принять работу. Нет списка проверок - нет и точки, где можно сказать «готово» или «не готово».

ТЗ закрывает все три риска, если в нём записаны проверяемые вещи. Длинный текст про миссию компании и «современный дизайн» не закрывает ни один.

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

Чем ТЗ отличается от брифа и от прототипа?

Бриф отвечает на вопрос «что вы хотите». ТЗ отвечает на вопрос «что именно будет сделано и как мы это проверим». Если в вашем «ТЗ» нет ни одного критерия приёмки, у вас на руках бриф, даже если в нём тридцать страниц.

Нужен ли ГОСТ для ТЗ на сайт?

Стандарт ГОСТ 34.602-2020 заменил ГОСТ 34.602-89 и введён в действие приказом Росстандарта от 19 ноября 2021 года. Он задаёт полный состав ТЗ на автоматизированную систему: назначение, требования к системе и её частям, к видам обеспечения, порядок контроля и приёмки, требования к документации.

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

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

Что должно быть в ТЗ на сайт или приложение: структура документа

Раздел 3 важнее остальных. Сценарии связывают всё: из них выводятся экраны, роли, данные и проверки. Когда сценариев нет, ТЗ превращается в перечень страниц. Страницы есть, а как по ним пройти клиенту от интереса до заявки, никто не описал.

Раздел 9 чаще всего пропускают. Список «что не входит» кажется лишним, пока подрядчик не скажет, что интеграция с 1С «подразумевалась в следующем этапе». Запишите явно: «в этап не входят: оплата онлайн, английская версия, мобильное приложение».

В разделе 7 для сайтов, которые собирают заявки или регистрируют пользователей, отдельной строкой пишут требования к персональным данным: согласие на обработку, политика конфиденциальности, где хранятся данные. Эти требования задаёт закон 152-ФЗ «О персональных данных», и подрядчик должен понимать их до сборки формы, а не после.

Как составить ТЗ на разработку за семь шагов

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

1. Запишите цель одним предложением с результатом

   Плохая цель: «сделать современный сайт». Хорошая: «получать заявки на ремонт кухонь из поиска и рекламы и передавать их менеджеру в CRM в течение минуты». В хорошей цели есть действие пользователя, результат для бизнеса и место, где этот результат виден. Если цель не помещается в одно предложение, у вас, скорее всего, два проекта.

2. Перечислите пользователей и их права

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

3. Опишите три-пять главных сценариев

   Сценарий - это путь от события до результата. «Клиент нашёл услугу в поиске, открыл страницу, выбрал дату, оставил телефон, получил подтверждение в мессенджере». Для каждого сценария запишите, чем он заканчивается и что происходит при ошибке: неверный телефон, занятое время, недоступная оплата. Если процесс внутри компании не записан, начните с описания бизнес-процессов: таблица «как есть» почти готовая основа для этого шага.

4. Составьте перечень страниц или экранов

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

5. Запишите данные и системы, с которыми нужна связь

   Откуда берутся товары, цены, расписание, остатки. Куда уходят заявки, заказы, оплаты. С какими системами нужен обмен: CRM, 1С, платёжный сервис, почта, мессенджер. По каждой связи задайте вопрос: что должно произойти, если система на той стороне не ответила. Ответ на этот вопрос чаще всего и отличает рабочий проект от витрины.

6. Сформулируйте критерии приёмки по каждому сценарию

   Для каждого сценария напишите одну-три проверки, которые вы сами сможете выполнить руками: «оставить заявку с телефона, увидеть её в CRM с источником и временем», «попытаться записаться на занятое время и получить отказ с предложением другого». По этим строкам вы будете принимать работу, поэтому пишите их так, чтобы результат был «да» или «нет».

7. Вынесите открытые вопросы в отдельный список

   Всё, что вы пока не знаете, не прячьте в формулировки вида «по согласованию». Запишите отдельным списком: «откуда брать остатки - уточнить у бухгалтера», «нужна ли оплата онлайн в первом этапе - решить после прототипа». Открытый вопрос, записанный честно, дешевле уверенной строки, которую потом переделывают.

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

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

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

Проверьте свой документ простым приёмом: найдите в нём все прилагательные. Около каждого спросите себя, каким действием вы его проверите. Если ответа нет, строку нужно переписать.

Критерии скорости и нагрузки лучше обсуждать с подрядчиком. Вы описываете ситуацию («в сезон заявок в десять раз больше, чем обычно»), а он переводит её в технические требования и объясняет, что за ними стоит.

Чем ТЗ на приложение отличается от ТЗ на сайт?

Структура та же, но в приложении появляются вопросы, которых у сайта нет:

• Платформы. Нужны iOS, Android или обе, и на каких версиях систем приложение должно работать.
• Работа без сети. Что пользователь видит в метро: сохранённые данные, сообщение об ошибке или пустой экран. Какие действия ставятся в очередь до появления связи.
• Уведомления. Какие события их вызывают, как часто, может ли пользователь их отключить.
• Права доступа. Камера, геолокация, контакты, файлы: для чего каждое и что будет, если пользователь откажет.
• Публикация. Кто владеет аккаунтами разработчика в App Store и Google Play, кто готовит описание, скриншоты и политику конфиденциальности для магазина.
• Обновления. Как пользователи получат исправления и что делать со старыми версиями приложения.

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

Как пишется ТЗ, когда есть прототип до договора?

Классический порядок такой: сначала ТЗ, потом оценка, потом договор, потом разработка. Слабое место этого порядка - вы подписываете договор, не видя результата. Всё, что вы представили по тексту документа, может оказаться совсем не тем, что представил подрядчик.

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

Как это выглядит по шагам:

1. Бриф и сценарий. Вы рассказываете задачу, вместе выбираем один главный сценарий: например, запись клиента или обработку заявки.
2. Прототип. Подрядчик собирает этот сценарий в рабочем виде: вход, основное действие пользователя, результат.
3. Проверка руками. Вы проходите сценарий как клиент и как сотрудник. Записываете, что совпало, что нет и чего не хватило.
4. ТЗ по итогам. В документ идут три списка: что согласовано по прототипу, что нужно изменить, что добавить в этап. Критерии приёмки пишутся по сценариям, которые вы уже видели.
5. Договор. Подписывается под документ, который описывает проверенное решение.

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

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

Можно ли составить ТЗ с помощью нейросети?

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

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

Правила:
- ничего не додумывай; если данных нет, пиши «не указано»;
- каждый сценарий описывай от события до результата и добавь, что
  происходит при ошибке;
- к каждому сценарию предложи 1-3 проверки, результат которых - да или нет;
- в конце дай список вопросов, которые нужно задать заказчику.

Описание: [вставьте расшифровку]

Полученный черновик читайте с карандашом. Нейросеть склонна дописывать «стандартные» функции, которые вам не нужны, - их вычёркивайте в границы этапа. Персональные данные клиентов, пароли и коммерческую тайну в запрос не вставляйте.

Какие ошибки делают заказчики в ТЗ на разработку?

1. Описали внешний вид вместо поведения. Пять страниц про цвета и шрифты, ни одной строки о том, что происходит после нажатия кнопки «Записаться».
2. Оставили оценочные слова. «Удобно», «быстро», «современно» - то, что нельзя проверить, нельзя и принять.
3. Описали только удачный путь. Что делает сайт, если оплата не прошла, время занято, а CRM не ответила, никто не записал.
4. Не назвали границы. Всё, что не записано как «не входит», будет спором о том, «подразумевалось» ли это.
5. Забыли про контент. Сайт готов, а текстов, фото и каталога нет. Запуск откладывается, хотя разработка закончена. Если сайт уже запущен и заявок нет, проверку формы и пути заявки разбирает статья нет заявок с сайта.
6. Писали в одиночку и отдали как готовое. ТЗ без вопросов подрядчика почти всегда содержит пробелы, которые видит только тот, кто будет собирать.
7. Не меняли документ по ходу. Требования изменились устно, ТЗ осталось прежним. Приёмка идёт по старому тексту, и обе стороны недовольны.

Где вы сейчас

• Есть только идея и понимание, зачем она бизнесу: начните с шагов 1 и 3 - цель одним предложением и три главных сценария. Этого хватит для разговора с подрядчиком и первого прототипа.
• Процессы в компании нигде не записаны: сначала снимите процесс «как есть» по описанию бизнес-процессов, потом переходите к сценариям.
• Подрядчик прислал своё ТЗ на согласование: проверьте его по таблице девяти разделов и найдите оценочные слова. Отдельно проверьте раздел «что не входит».
• Есть прототип или макет: пишите ТЗ по нему - три списка «согласовано, изменить, добавить» и критерии приёмки по пройденным сценариям.

Чек-лист: ТЗ готово к передаче подрядчику

• Цель записана одним предложением и содержит результат, который можно увидеть.
• Перечислены все роли пользователей, у каждой указаны права и запреты.
• Описаны три-пять главных сценариев от события до результата, включая ошибки.
• Каждый экран в перечне связан хотя бы с одним сценарием.
• Для каждой интеграции записано, что происходит, если внешняя система не ответила.
• По каждому сценарию есть проверки с ответом «да» или «нет».
• Есть список «в этап не входит» и отдельный список открытых вопросов.