ТЗ на разработку программы: как описать систему, чтобы её сделали как нужно

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

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

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

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

Вопрос	ТЗ на сайт	ТЗ на программу или систему
Главный объект описания	Страницы и блоки	Данные, статусы, правила, роли
Кто пользуется	Посетители, один редактор	Несколько ролей с разными правами
Что сложнее всего описать	Дизайн и контент	Исключения: что делать, если данные неполные или сценарий пошёл не так
Связи с другими системами	Форма уходит в почту или CRM	Обмен в обе стороны с 1С, телефонией, оплатой, сайтом
Как принимают	По страницам и сценариям посетителя	По сценариям каждой роли и контрольным данным

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

ГОСТ 34.602-2020, ГОСТ 19.201-78 или своё ТЗ

ГОСТ для ТЗ нужен, когда его требует заказчик или договор, чаще всего в государственных и крупных проектах. Для системы малого бизнеса обычно хватает бизнес-ТЗ, но полезно знать, что в стандартах, и брать оттуда структуру и правила.

ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» действует в России с 1 января 2022 года вместо ГОСТ 34.602-89. Он описывает систему целиком: не только программу, но и людей, процессы и подготовку к запуску. Пункт 4.1 называет обязательные разделы:

1. общие сведения;
2. цели и назначение создания автоматизированной системы;
3. характеристика объектов автоматизации;
4. требования к автоматизированной системе;
5. состав и содержание работ по созданию автоматизированной системы;
6. порядок разработки автоматизированной системы;
7. порядок контроля и приёмки автоматизированной системы;
8. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
9. требования к документированию;
10. источники разработки.

Если требований по разделу нет, раздел оставляют и пишут, что требований нет. Изменения оформляют дополнением к ТЗ.

ГОСТ 19.201-78 из Единой системы программной документации описывает ТЗ на отдельную программу. Его разделы: введение, основания для разработки, назначение разработки, требования к программе или программному изделию, требования к программной документации, технико-экономические показатели, стадии и этапы разработки, порядок контроля и приёмки. Можно добавить приложения.

Вариант	Что описывает	Когда подходит
ГОСТ 34.602-2020	Систему вместе с процессами, людьми и подготовкой к запуску	Госзаказ, крупные компании, требование договора
ГОСТ 19.201-78	Отдельную программу	Когда заказчик просит оформить по ЕСПД
Бизнес-ТЗ	Роли, данные, статусы, сценарии, экраны, интеграции, приёмку	CRM, кабинет, внутренняя система для малого и среднего бизнеса

Из ГОСТ 34.602-2020 стоит взять одно правило в любое ТЗ. Пункт 3.4 перечисляет характеристики хорошего требования: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность.

Как описать систему: восемь слоёв

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

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

Слои 1–4 по сути описание процесса. Если процесс ещё не описан, начните с него: как описать бизнес-процесс перед автоматизацией.

Как писать требования: размыто и проверяемо

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

Размыто	Проверяемо
Система должна быть удобной	Менеджер создаёт заявку из звонка не больше чем за 5 полей, телефон проверяется на формат
Руководитель видит всю статистику	Отчёт по менеджерам за период: число заявок, переходы по статусам, сумма закрытых сделок, выгрузка в Excel
Интеграция с 1С	При переводе заказа в статус «Оплачен» в 1С создаётся счёт с номером заказа, ошибка обмена видна в журнале и приходит ответственному
Система работает быстро	Список заявок до 10 000 записей открывается не дольше 2 секунд при 20 одновременных пользователях
Данные защищены	Вход по логину и паролю, менеджер видит только своих клиентов, все изменения карточки пишутся в журнал

Отдельно пропишите требования, которые не видны на экране:

• Персональные данные. Если разработчик или подрядчик получает доступ к данным клиентов, часть 3 статьи 6 закона 152-ФЗ требует поручения на обработку: перечень данных, действия с ними, цели, конфиденциальность и меры защиты.
• Права на код. По статье 1296 ГК РФ исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не говорит иное. Запишите в ТЗ, что передаётся: исходный код, доступ к репозиторию, инструкция по развёртыванию.
• Резервные копии и журнал. Как часто копия, где хранится, сколько времени на восстановление, что пишется в журнал действий.
• Где работает система. Свой сервер или облако, браузеры, телефоны, нужна ли работа без интернета.

Примеры ТЗ: CRM, кабинет клиента, внутренняя система

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

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

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

Цели в ТЗ: переведите пользу в цифры

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

Готовые цифры перенесите в ТЗ: «система снимает ручной перенос заявок, ожидаемая экономия N часов в месяц, проверяем через три месяца после запуска по отчёту». Если через три месяца цифр нет, это повод разобраться, пользуются ли системой на самом деле.

Кто пишет ТЗ и как оно меняется по ходу работ

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

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

ТЗ и гибкая разработка не противоречат друг другу. Частый вариант: подробное ТЗ на первую версию, а дальнейшие улучшения идут списком задач с короткими описаниями и критериями приёмки. Любое изменение уже подписанного ТЗ записывайте дополнением с влиянием на сроки и бюджет, так же поступает и ГОСТ 34.602-2020.

Как принимать систему по ТЗ

Систему принимают на контрольных примерах: заранее подготовленных данных, для которых известен правильный результат. Их собирают вместе с ТЗ, а не в последнюю неделю. Если результат известен только «на глаз», спор при приёмке неизбежен.

Что проверяем	Контрольный пример	Ожидаемый результат
Сценарий роли	Менеджер получает заявку с сайта и доводит её до оплаты	Заявка прошла все статусы, у каждого перехода есть автор и время
Исключение	Клиент отказался после расчёта	Без причины отказа статус не меняется, причина видна в отчёте
Права	Менеджер пытается открыть клиента коллеги по прямой ссылке	Доступ закрыт, попытка записана в журнал
Расчёт или отчёт	Десять заказов, посчитанных вручную в таблице	Суммы в системе совпадают до рубля
Интеграция	Заказ с ошибкой в реквизитах уходит в 1С	Обмен не теряет заказ, ошибка видна ответственному

Удобно принимать в два шага. Сначала на тестовой копии с контрольными примерами. Потом неделю-две на реальной работе одного отдела, пока прежний способ ещё доступен. Только после этого переводить всех.

Что приложить к ТЗ

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

• Примеры текущих документов. Таблицы, бланки, счета, выгрузки, по которым сейчас работают сотрудники. Персональные данные в них заменяют на вымышленные.
• Схема статусов. Одна картинка вместо страницы текста.
• Таблица прав. Строки это роли, столбцы это действия.
• Прототип ключевых экранов. Достаточно набросков: список, карточка, форма.
• Словарь терминов. Что у вас называется «заявкой», «заказом» и «сделкой». В разных компаниях это разные вещи.

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

• Описаны экраны, а не процесс. Есть макеты, но непонятно, что делать с заявкой, если клиент передумал.
• Нет исключений. Описан только идеальный путь. На деле больше всего времени уходит на возвраты, отказы и неполные данные.
• Все хотят всё. В первую версию попадают пожелания всех отделов. Срок растёт, а запускать нечего.
• Нет контрольных данных. Принимать нечем: нет примеров заявок и заказов, на которых проверяют расчёты и отчёты.
• Права «потом». Роли добавляют в конце, и приходится переделывать половину экранов.
• Нет цели в цифрах. Через полгода невозможно сказать, окупилась ли система.

Проверьте ТЗ перед подписанием

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

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