Зачем нужно техническое задание и что в нём должно быть
Техническое задание часто воспринимают как документ, который нужен разработчикам «для галочки».
На практике хорошее ТЗ решает гораздо более важную задачу: до начала разработки зафиксировать, что именно компания собирается получить, как система должна работать и по каким признакам будет понятно, что работа выполнена.
Без этого разработчик и заказчик могут одинаково понимать слова «автоматизировать процесс», «интегрировать с 1С» или «сделать личный кабинет» — и при этом представлять совершенно разные системы.
Отсюда появляются знакомые ситуации:
«Мы думали, это тоже входит в проект».
«Why это не предусмотрено?»
«А разве система не должна была делать это автоматически?»
«Мы хотели другой сценарий».
«Почему изменение оказалось отдельной работой?»
Проблема в таких случаях часто возникает не на этапе программирования.
Она возникает раньше — когда ожидаемый результат не был достаточно точно определён.
ТЗ — это граница между идеей и конкретной системой
На старте проекта обычно есть бизнес-задача:
Но разработать систему по одной этой фразе невозможно.
Техническое задание переводит задачу из общего описания в систему конкретных требований.
Чем сложнее система, тем важнее этот переход.
Почему нельзя описать систему только списком функций
Предположим, в ТЗ написано:
Нужно определить:
Поэтому хорошее ТЗ описывает не только что система делает, но и при каких условиях, с какими данными и каким должен быть результат.
Что должно быть в техническом задании
Универсального шаблона ТЗ для любой системы не существует.
Для простой автоматизации один документ может занимать несколько страниц.
Для корпоративной системы с десятками интеграций ТЗ может стать большим комплектом документации с отдельными спецификациями.
Но основные блоки обычно можно представить так:
Не каждый проект требует одинаковой глубины по каждому пункту.
Но чем больше цена ошибки, количество систем и пользователей, тем подробнее должны быть зафиксированы критичные части.
1. Цель и границы проекта
Сначала необходимо определить, зачем система создаётся и что именно входит в проект.
Например:
Система должна автоматически принимать заявки с сайта, проверять обязательные данные, создавать обращение в CRM и уведомлять ответственного сотрудника.
Но важно зафиксировать и обратную сторону:
Система не отвечает за обработку заявки менеджером после её создания в CRM.
Это уже граница ответственности.
Она кажется очевидной до начала проекта.
После запуска именно такие вещи часто становятся причиной разногласий.
Поэтому полезно фиксировать:
Граница проекта защищает обе стороны.
2. Пользователи и роли
Одна и та же система может выглядеть совершенно по-разному для разных пользователей.
Например:
│
├── пользователи
├── настройки
└── журнал операций
│
├── заявки
├── карточка клиента
└── статусы
│
├── отчёты
└── показатели
Важно определить не только список ролей, но и их права.
Менеджер может изменить статус.
Руководитель может видеть все заявки.
Администратор может менять настройки.
Если это не определить заранее, система может получить либо слишком широкие права, либо ограничения, которые мешают работе.
3. Бизнес-процесс
Функции сами по себе не объясняют, как система должна вести себя во времени.
Например:
Такую последовательность гораздо легче обсуждать, чем длинное текстовое описание.
Особенно если в процессе есть исключения:
Именно здесь ТЗ превращает абстрактную задачу в управляемую логику.
4. Функциональные требования
Здесь описывается, что система должна уметь.
Например:
[fn]создавать заявку;
[fn]изменять статус;
[fn]искать клиента;
[fn]прикреплять документы;
[fn]отправлять уведомления;
[fn]формировать отчёт;
[fn]передавать данные в ERP.
Но хорошее требование должно быть проверяемым.
Система должна быстро создавать заявку.
После отправки формы заявка должна быть создана в системе не позднее установленного времени при доступности всех необходимых сервисов.
5. Данные
Очень большое количество проблем в корпоративных системах начинается не с интерфейса, а с данных.
В ТЗ нужно определить:
Например:
├── ID
├── Название
├── ИНН
├── Телефон
Чем точнее определены данные, тем меньше двусмысленности появляется при интеграции.
6. Интерфейс
Техническое задание не обязательно должно содержать готовый дизайн всех экранов.
Но должно быть понятно, какие действия пользователь выполняет и какой результат получает.
Например:
│
├── поиск
├── фильтр
├── сортировка
└── открыть заявку
↓
КАРТОЧКА
├── данные
├── история
├── документы
└── действия
Для сложных систем могут дополнительно использоваться прототипы интерфейсов.
Главное — не рисовать интерфейс ради рисунка.
Нужно определить поведение системы:
7. Интеграции
Если система взаимодействует с другими системами, интеграции нужно описывать отдельно.
Например:
Для каждой интеграции желательно определить:
Фраза «интеграция с 1С» сама по себе почти ничего не говорит разработчику.
Нужно понимать что именно происходит между системами.
8. Ошибки и нестандартные сценарии
Хорошее ТЗ описывает не только идеальный путь.
Потому что именно идеальный путь обычно работает первым.
Проблемы начинаются здесь:
Для каждого критичного сценария желательно понимать:
9. Нефункциональные требования
Это требования, которые не описывают отдельную кнопку или функцию, но определяют качество системы.
Например:
[q]производительность;
[q]доступность;
[q]безопасность;
[q]резервное копирование;
[q]журналирование;
[q]масштабирование;
[q]ограничения по нагрузке;
[q]время обработки операций;
[q]требования к инфраструктуре.
Система может выполнять все заявленные функции и всё равно оказаться непригодной.
Например, отчёт формируется корректно, но занимает 40 минут.
Поэтому в серьёзных проектах важно фиксировать не только что система делает, но и в каких условиях она должна это делать.
10. Критерии приёмки
Один из самых важных разделов ТЗ.
Именно здесь появляется ответ на вопрос:
Как понять, что система действительно готова?
Вместо:
Лучше:
При получении заявки со всеми обязательными полями система создаёт запись в CRM, присваивает ей установленный статус и сохраняет идентификатор созданной записи.
Теперь это можно проверить.
И если проверка пройдена — требование выполнено.
ТЗ не должно пытаться предсказать абсолютно всё
Есть и обратная крайность.
Иногда техническое задание превращают в документ на сотни страниц, где пытаются заранее описать каждую пиктограмму, каждый возможный клик и каждую строчку будущего кода.
Это тоже не всегда правильно.
ТЗ должно фиксировать существенные требования и ожидаемый результат, а не лишать команду разработки возможности принимать инженерные решения.
Например, заказчику может быть важно:
Система должна обрабатывать до 1 000 операций в час.
Но необязательно заранее определять:
Для этого использовать именно конкретную библиотеку X версии Y.
Граница между ними должна быть осознанной.
Хорошее ТЗ отвечает на пять главных вопросов
Если отбросить всю документацию, остаётся простая проверка:
Если на эти вопросы невозможно ответить по документации, проект всё ещё содержит существенную неопределённость.
Что меняется после появления ТЗ
До фиксации требований разговор часто выглядит так:
После проработки:
После этого можно гораздо точнее оценить архитектуру, сроки и состав работ.
И здесь появляется ещё один важный эффект: изменения становятся видимыми.
Если после утверждения ТЗ появляется новая функция, можно понять, является ли она частью первоначального объёма или новым требованием.
ТЗ — не гарантия идеального проекта
Даже очень подробный документ не спасёт проект, если сама задача неправильно поставлена.
Поэтому до составления ТЗ необходимо понять бизнес-процесс, ограничения существующей инфраструктуры и реальную проблему, которую должна решить автоматизация.
Техническое задание фиксирует согласованное решение.
Когда ТЗ особенно важно
Чем сложнее проект, тем выше цена недоговорённости.
Особенно важно подробно фиксировать требования, когда есть:
В простом внутреннем инструменте часть требований может быть зафиксирована компактно.
В корпоративной системе ТЗ становится одним из основных элементов управления проектом.
Хорошее ТЗ должно помогать не только начать разработку, но и закончить её
Это, пожалуй, главный критерий.
Документ полезен не тогда, когда он выглядит объёмным.
Он полезен, если по нему можно пройти весь путь:
На каждом этапе должно быть понятно, что именно проверяется и откуда это требование появилось.
Тогда ТЗ становится не формальностью перед стартом разработки, а общей точкой отсчёта для бизнеса, архитекторов, разработчиков и тех, кто будет принимать результат.
Именно поэтому хороший документ отвечает не на вопрос «что мы хотим примерно сделать?», а на гораздо более практичный:
«Как мы поймём, что система сделана именно так, как было согласовано?»
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870