Техническое задание на разработку программного обеспечения: структура, пример и чек-лист

«Сделать удобную программу для заявок и связать её с 1С». Ровно одна строка. С неё начиналось техническое задание на разработку программного обеспечения в сервисной компании, которая чинит кондиционеры. Компания вымышленная, а история — типичная до мелочей.

Через шесть недель программист показал результат. Заявки заводились, список открывался, в 1С что-то уходило. Руководитель сервиса посмотрел пять минут и сказал: «Это не то». Мастера не видели адресов на телефоне. Счета в 1С появлялись без договора. Диспетчер не мог найти повторную заявку того же клиента. Программист честно ответил: «В задании этого не было». И был прав.

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

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

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

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

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

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

ТЗ, спецификация, постановка задачи — в чём разница

В разговоре эти слова смешивают, и это нормально. Для порядка:

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

Какие ГОСТы есть для ТЗ и нужны ли они малому бизнесу?

Когда ищут «ГОСТ 34 техническое задание», обычно имеют в виду ГОСТ 34.602. Действующая редакция — ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Он введён в действие с 1 января 2022 года приказом Росстандарта от 19 ноября 2021 года № 1522-ст и заменил ГОСТ 34.602-89, на который до сих пор ссылаются многие шаблоны в интернете.

По пункту 4.1 этого стандарта ТЗ на автоматизированную систему содержит десять разделов:

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

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

Для остальных документов на автоматизированную систему — пояснительной записки, руководств, программы испытаний — в 2021 году утвердили ГОСТ Р 59795-2021 «Требования к содержанию документов» (приказ Росстандарта от 25 октября 2021 года № 1297-ст). Он пригодится, если вместе с ТЗ заказчик требует полный комплект документации.

Теперь главное. Национальные стандарты в России по общему правилу применяются добровольно — так сказано в части 1 статьи 26 закона о стандартизации. Частная компания может написать ТЗ в любой форме. Если же в договоре стоит «ТЗ по ГОСТ 34.602-2020», стандарт становится частью договорённости, и спорить об оформлении придётся уже по нему.

Практичный путь для небольшого проекта: взять из ГОСТ 34.602-2020 логику разделов, а не объём. Раздел о приёмке и раздел о документировании пропускать нельзя ни в каком формате.

Госзаказчики и крупные компании обычно требуют формат по ГОСТу целиком. Для системы учёта заявок на 15 человек сорок страниц по всем десяти разделам — перебор: их никто не прочитает. А значит, и не проверит.

Структура технического задания: восемь разделов, которые работают

Ниже — структура технического задания, которая подходит для большинства заказных программ малого и среднего бизнеса. Справа — с каким разделом ГОСТ 34.602-2020 она примерно совпадает, если позже понадобится оформить документ по стандарту.

Дальше — что писать в каждом разделе и где обычно ошибаются.

1. Цель и границы

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

Сразу под целью — границы. Что программа не делает в первой версии. Звучит странно, но этот абзац экономит больше денег, чем любой другой. «Склад запчастей не ведём, он остаётся в 1С». «Оплату картой на сайте не принимаем». Пока это не записано, заказчик с исполнителем по-разному представляют себе объём.

2. Пользователи и роли

Список людей, которые будут работать в системе, и что каждому разрешено. Роль — это набор прав, а не должность. Один человек может совмещать две роли; одна роль может быть у десятка человек.

Удобно писать таблицей: роль, сколько человек, с какого устройства работает, что может видеть, что может менять. Здесь же решают неприятные вопросы. Видит ли мастер суммы? Может ли диспетчер удалить заявку или только отменить? Кто вообще может что-то удалять?

3. Сценарии

Сценарий — история работы с системой глазами одного пользователя: с чего начинается, какие шаги, чем заканчивается. «Клиент звонит, диспетчер находит его по номеру, видит прошлые заявки, создаёт новую, назначает мастера на завтра с 10 до 12, мастер получает уведомление».

Сценарии полезны тем, что их понимают все. Руководитель, который не прочтёт двадцать пунктов функциональных требований, прочтёт пять историй и скажет: «А где возврат на гарантийный ремонт?» Именно такие пропуски и нужно ловить до разработки.

Для каждого сценария стоит описать хотя бы одно отклонение. Клиент отменил заявку. Мастер не приехал. Связь пропала на объекте. Именно на отклонениях программы ломаются чаще всего, а в задании о них обычно ни слова.

4. Функциональные требования

Нумерованный список: что система делает. Каждое требование — отдельная строка с номером, чтобы на него можно было сослаться в переписке, в смете и в протоколе приёмки. «ФТ-07 не работает» — понятно всем. «Там что-то с поиском» — нет.

У требований бывает приоритет. Самый простой вариант — три уровня: «обязательно в первой версии», «желательно», «потом». Без приоритета всё становится обязательным, а срок — нереальным.

5. Нефункциональные требования

Всё, что касается качества работы системы целиком, а не одной функции:

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

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

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

Для каждой внешней системы — отдельный подраздел. Что передаём, в какую сторону, когда (сразу, раз в час, по кнопке), что считается главным источником, что происходит при ошибке обмена. Если интеграция с 1С, обязательно указать конфигурацию и её версию, а также доработана ли она: обмен с типовой и с переписанной конфигурацией — две разные задачи по трудоёмкости.

7. Данные

Какие сущности живут в системе: клиент, объект, заявка, работа, счёт. Откуда они берутся и кто их владелец. Какие старые данные переносим — и в каком виде они сейчас: таблица Excel на 4 000 строк с дублями отличается от аккуратного справочника. Перенос данных регулярно съедает больше времени, чем ожидают обе стороны, поэтому его лучше вынести отдельной строкой в смете.

8. Приёмка и документация

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

Пример: техническое задание на разработку программы учёта заявок с обменом с 1С

Возьмём вымышленную компанию «Климат-Юг» из Краснодара: установка и ремонт кондиционеров, 2 диспетчера, 9 мастеров, руководитель сервиса и бухгалтер. Заявки сейчас записывают в общую таблицу и в мессенджер, счета бухгалтер набирает в 1С вручную. Компания и люди придуманы, цифры тоже.

Ниже — фрагмент ТЗ. Это образец того, как выглядит каждый раздел в рабочем виде, а не полный документ. Техническое задание на разработку программы, пример которого вы видите, на практике занимает 12–18 страниц вместе с таблицами.

1. Цель. Перевести учёт заявок из таблицы и мессенджера в одну систему. Диспетчер создаёт заявку не дольше чем за 2 минуты. Мастер видит свои выезды на телефоне. Руководитель утром получает сводку за прошедший день. Счёт по выполненной заявке появляется в 1С без ручного ввода.

Границы первой версии. Склад запчастей, зарплата мастеров, онлайн-оплата, личный кабинет клиента — в первую версию не входят. Склад и бухгалтерия остаются в 1С.

2. Роли.

3. Сценарий С-02 «Повторное обращение». Клиент звонит, диспетчер вводит номер телефона. Система показывает карточку клиента, адреса его объектов и последние 5 заявок. Если с момента последней выполненной заявки прошло меньше 30 дней, карточка помечается «Возможен гарантийный случай». Диспетчер создаёт заявку, выбирает объект и тип работ, назначает мастера на свободное окно. Мастеру приходит уведомление.

Отклонение: номер не найден. Диспетчер создаёт нового клиента в той же форме, без перехода на другой экран.

4. Функциональные требования (выдержка).

• ФТ-03. Поиск клиента по последним 4 цифрам номера телефона или по части адреса; результат — не более чем через 2 секунды при базе до 20 000 клиентов. Приоритет: обязательно.
• ФТ-08. Мастер может перевести заявку в статус «Выполнена», только если указал хотя бы одну выполненную работу из справочника и приложил хотя бы одно фото. Приоритет: обязательно.
• ФТ-11. Отменить заявку может диспетчер или руководитель; причина отмены выбирается из справочника, поле «Комментарий» обязательно при причине «Другое». Удалить заявку не может никто. Приоритет: обязательно.
• ФТ-17. В 8:00 руководитель получает сводку за прошедший день: число новых, выполненных, отменённых заявок, сумма выполненных работ, заявки без мастера. Приоритет: желательно.

5. Нефункциональные требования (выдержка).

• НФ-01. Интерфейс мастера работает на телефонах с экраном от 5,5 дюйма в двух последних версиях мобильных браузеров.
• НФ-04. Все изменения заявки пишутся в журнал: кто, когда, какое поле; значение до и после. Журнал не редактируется.
• НФ-06. Резервная копия базы — ежедневно, хранится 30 дней. Восстановление проверяется до сдачи.

6. Интеграция с 1С (выдержка).

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

7. Данные. Переносится таблица заявок за последние 12 месяцев, около 4 300 строк. Дубли клиентов по номеру телефона объединяются по правилу: остаётся запись с самой поздней датой заявки. Персональные данные клиентов хранятся на серверах в России.

8. Приёмка (выдержка). Приёмка проводится по 12 сценариям на тестовом адресе с тестовыми данными. Каждый сценарий считается пройденным, если фактический результат совпал с ожидаемым. Работа принимается, когда пройдены все сценарии с приоритетом «обязательно»; замечания по «желательным» вносятся в план следующей версии.

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

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

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

Хорошее требование отвечает на четыре вопроса. Кто делает действие. Что происходит в системе. При каком условии. С каким измеримым результатом — время, число, статус.

Ещё несколько правил, которые экономят переписку:

• Одно требование — одно действие. «Диспетчер создаёт заявку, назначает мастера и отправляет клиенту СМС» — это три требования. Если не работает СМС, остальное принимать или нет?
• «Должна» и «желательно» не смешиваются. «Система должна, по возможности, показывать…» — непонятно, обязательно это или нет. Пишите приоритет отдельно.
• Без «и т. д.» и «и прочее». Список статусов — полный. Если завтра появится новый статус, это изменение ТЗ.
• Числа с единицами. Не «быстро», а «2 секунды». Не «много заявок», а «до 500 в день».
• Термины в одном значении. Если «объект» — это адрес, где стоит кондиционер, то не называйте так же сам кондиционер. Глоссарий в начале документа на полстраницы решает эту проблему.

Заметили? Во втором варианте у программиста не осталось места для догадок. И у руководителя — для «я имел в виду другое».

Критерии приёмки: как понять, что программа сделана

Раздел о приёмке — главная страховка обеих сторон. Без него у исполнителя нет точки, где работа закончена, а у заказчика нет способа сказать «не принято» с аргументами.

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

Что ещё стоит прописать в разделе о приёмке:

• Где проверяем. На тестовом адресе с тестовыми данными, а не на рабочей базе с живыми клиентами.
• Кто проверяет. Конкретные люди со стороны заказчика: например, один диспетчер, один мастер, бухгалтер. Не «отдел».
• Сколько времени на проверку. Например, 5 рабочих дней после передачи версии. Молчание дольше — тоже ответ, и договор должен говорить какой.
• Что считается замечанием, а что новым требованием. Не работает описанное в ТЗ — замечание, исправление входит в цену. Хочется иначе, чем описано, — изменение, оценивается отдельно.
• Что передаётся при сдаче. Исходный код, инструкция по установке и выкладке, руководство пользователя для каждой роли, описание обмена с 1С, доступы.

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

Сколько стоит неясное требование: расчёт на примере

Посчитаем, во что обходится пропуск в ТЗ. Допущения наши, для арифметики, не рыночный ориентир: час работы разработчика — 2 000 ₽, проект «Климат-Юг» по исходной оценке — 240 часов, то есть 480 000 ₽.

Возьмём три пропуска из истории в начале статьи:

Плюс 29% к бюджету. И это не самое дорогое. Пока программа не запущена, диспетчеры продолжают вести таблицу, бухгалтер набирает счета руками, а руководитель не видит заявок без мастера. Если бухгалтер тратит на ручной ввод счетов 2 часа в день, за 3,5 недели набегает около 35 часов её работы.

Сколько стоит написать хорошее ТЗ? На проект такого размера обычно уходит 2–4 встречи с людьми, которые будут работать в системе, и несколько дней на текст. Даже если считать по той же ставке, это заметно меньше 140 000 ₽ переделок. Но главное даже не деньги — а то, что спор о приёмке не начинается.

Кто пишет ТЗ: заказчик, исполнитель или вместе?

Короткий ответ — вместе, но отвечают за разное.

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

Исполнитель знает, как это сделать и что из сказанного будет стоить дорого. Хороший исполнитель задаёт неудобные вопросы: «А если мастер закрыл заявку без интернета?», «А кто правит цену, если в 1С она другая?». Плохой — молча кивает и начинает писать код.

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

Если подрядчик предлагает обойтись без ТЗ

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

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

Как выбрать подход к разработке ИИ-решений и какие вопросы задать исполнителю до договора, разобрано в статье про разработку ИИ-агента. Здесь — только про ТЗ.

Где ТЗ не поможет: честные ограничения

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

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

ТЗ устаревает. Через три месяца работы процесс в компании может измениться. Это нормально. Ненормально — делать вид, что документ всё ещё точен. Изменения записывают и согласуют, предварительно оценив.

ТЗ не обещает результат в бизнесе. Документ описывает, что программа делает. Станут ли заявки обрабатываться быстрее, зависит от того, как люди будут ею пользоваться. Это решает руководитель, а не исполнитель.

Нейросеть не напишет ТЗ за вас. Она соберёт аккуратный шаблон с правильными заголовками. Но она не знает, что у ваших мастеров старые телефоны, а у трети клиентов нет договоров. Шаблон без этих деталей — та самая строка «сделать удобную программу», только на двенадцати страницах.

О том, как разработку ведёт IT-специалист в аренду и где проходит граница его работы, — в статье «ИИ-программист: что он делает и где нужен человек». Если коротко про КАРАДЕСК: это не полная замена программиста — цель и приёмка остаются за клиентом, архитектуру утверждает инженер.

Ответы на частые возражения

«Мы маленькие, нам не нужно ТЗ». Объём зависит от задачи, а не от размера компании. Для доработки на три дня хватит полстраницы: цель, что меняется, как проверить. Для новой программы с обменом с 1С нужен полноценный документ, даже если в компании 12 человек.

«Пусть исполнитель сам напишет». Пусть пишет — но по вашему рассказу и с вашей проверкой. Документ, который вы подписали, не читая, защищает того, кто его писал.

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

«ГОСТ слишком сложный». Не используйте его целиком, если договор этого не требует. Возьмите логику разделов и обязательно — порядок приёмки.

Как составить техническое задание по шагам

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

Типичные ошибки в ТЗ

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

Чек-лист: техническое задание на разработку программного обеспечения перед отправкой

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

Кому отдать разработку, когда ТЗ готово

Готовое ТЗ можно отдать штатному программисту, студии или фрилансеру. Можно и IT-специалисту в аренду — разработку и сопровождение программ в КАРАДЕСК ведёт IT-специалист в ежемесячной аренде, это дешевле штатного программиста; проект оцениваем до старта.

Задачи ему ставят как сотруднику — голосовым сообщением или текстом в рабочем чате; он уточнит непонятное, назовёт срок и покажет результат. С 1С работает: обмен с сайтом и CRM, обработки, выгрузки и отчёты. Требования уточняем вместе с заказчиком: разбираем сценарии и роли, фиксируем, что войдёт в версию. Для разработки берут тестовые данные, а не базу клиентов, выкладка — только после одобрения клиента. Код, документация и история изменений остаются у компании.

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