Техническое задание на IT-проект — документ, который описывает, что должна делать будущая система, при каких ограничениях она работает и по каким признакам работу примут. Хорошее ТЗ пишут не как список пожеланий, а как набор проверяемых требований: по нему разные подрядчики оценивают один и тот же объём, а приёмка идёт по заранее согласованным критериям.
Коротко
Техническое задание — основной документ проекта, который связывает задачу бизнеса с требованиями к системе и с правилами приёмки. Его путают с соседними документами, хотя пишут их разные люди и в разные моменты.
| Документ | Кто обычно пишет | Что внутри | Когда нужен |
|---|---|---|---|
| Бриф | Заказчик | Задача в бизнес-словах: что мешает работать, чего хотим добиться, бюджетная рамка | В самом начале, до разговора с подрядчиками |
| Техническое задание | Аналитик вместе с заказчиком | Цели, границы, процессы, функциональные и нефункциональные требования, интеграции, критерии приёмки | Перед оценкой стоимости и подписанием договора |
| Спецификация требований к ПО (SRS) | Аналитик со стороны исполнителя | Подробные требования к продукту: сценарии, состояния экранов, обработка ошибок, правила расчётов | Внутри разработки, детализирует техническое задание |
| Спецификация работ (SOW) | Менеджер проекта и юрист | Состав работ, этапы, результаты каждого этапа, ответственность и порядок оплаты | Как приложение к договору |
Названия этих документов в разных компаниях отличаются, поэтому в договоре пишут перечень разделов и то, что считается согласованной версией. Общая рамка описана в стандарте ISO/IEC/IEEE 29148:2018: он задаёт процессы работы с требованиями и признаки, по которым требование считается пригодным.
Набор разделов почти не зависит от того, что разрабатывается — CRM, портал или мобильное приложение: меняется наполнение, а не структура. Таблица ниже — рабочее оглавление документа.
| Раздел | Что писать | Пример |
|---|---|---|
| Цель проекта | Какую задачу бизнеса решает система и по чему будет видно, что она решена | Сократить сборку месячного отчёта: сейчас данные сводят вручную из трёх систем |
| Границы | Что входит в проект и что не входит — второе важнее первого | Склад и закупки входят, расчёт заработной платы остаётся в бухгалтерской программе |
| Текущие процессы | Как работа устроена сейчас: кто что делает, откуда берутся данные, где ручной ввод | Схема приёма заказа от обращения до отгрузки со всеми участниками |
| Роли и права | Кто пользуется системой и что доступно каждой роли | Кладовщик видит остатки, но не видит себестоимость и закупочные цены |
| Функциональные требования | Что система делает, по одному проверяемому требованию на пункт | Система назначает ответственного за заявку по правилу распределения и уведомляет его |
| Нефункциональные требования | Нагрузка, скорость, доступность, безопасность, языки интерфейса, устройства | Одновременно работают до 50 пользователей, интерфейс на русском и узбекском |
| Интеграции | С чем обменивается данными, в какую сторону, как часто и кто источник истины | Остатки приходят из учётной системы раз в час, источник истины по ним — склад |
| Данные и их размещение | Что храним, сколько, где физически лежит база и копии | Персональные данные клиентов: состав, срок хранения, площадка размещения |
| Миграция данных | Что переносим из старых систем, в каком виде и на какую дату | Справочники и остатки на дату запуска, история заказов за два предыдущих года |
| Критерии приёмки | Какие проверки подтверждают, что работа выполнена | Двадцать заказов проходят путь от заявки до отгрузки без ручных правок в базе |
| Что остаётся у заказчика | Исходный код, документация, доступы, права на результат | Код в репозитории компании, инструкции для пользователей, доступы к серверам |
Раздел о текущих процессах удобнее рисовать схемой, а не описывать текстом: схема в общепринятой нотации, например BPMN 2.0 консорциума OMG, читается и руководителем, и разработчиком. Размещение данных тоже стоит зафиксировать заранее: обязательное хранение внутри Узбекистана распространяется на биометрические и генетические данные и данные абонентов связи — это статья 27-1 закона о персональных данных, остальные данные можно хранить за рубежом при соблюдении условий той же статьи.
Требование пригодно, если его нельзя понять двояко и можно проверить. Стандарт ISO/IEC/IEEE 29148 называет среди признаков хорошего требования необходимость, однозначность, единичность, выполнимость и проверяемость — то есть одно требование описывает одну вещь и для него понятен способ проверки.
| Плохо | Почему не работает | Хорошо |
|---|---|---|
| Удобный интерфейс | Нельзя проверить и нельзя оценить в часах | Оформление заказа занимает не более четырёх экранов и не требует переключения между окнами |
| Система должна быть быстрой | Нет ни числа, ни условий, при которых его измеряют | Список из 10 000 заказов открывается за 2 секунды при 50 одновременно работающих пользователях |
| Интеграция с учётной системой | Не сказано, что передаётся, в какую сторону и как часто | Остатки по складам передаются из учётной системы раз в час; при ошибке обмена ответственный получает уведомление |
| Отчёты по продажам | Неизвестно, какие именно и кому они нужны | Отчёт «выручка по менеджерам за период» с фильтром по каналу и выгрузкой в таблицу |
| Система должна поддерживать рост | Нет границы, до которой рост считается предусмотренным | Система рассчитана на 200 пользователей и утроение числа заказов без смены архитектуры |
Каждое требование нумеруют: по номерам потом ссылаются в оценке, в плане работ и в акте приёмки. Требование, которое содержит слова «и», «или», «при необходимости», обычно распадается на два или три — их лучше разделить сразу.
Критерий приёмки — описание проверки, результат которой не зависит от настроения сторон. Без него спор о готовности проекта решается убеждением, а не документом.
Пример Формулировка «нам нужна CRM» не годится ни для оценки, ни для приёмки. Рабочий вариант выглядит так: «Все заявки из Telegram, с сайта и по телефону попадают в одну систему с указанием источника; руководитель видит воронку за любой день; в приёмке проверяем 20 заявок из всех трёх каналов».
Ошибки повторяются от проекта к проекту, и почти все они появляются из-за того, что документ писали, не разобравшись в работе компании.
Вариантов три, и у каждого своя цена и свой риск. Выбор зависит от того, есть ли внутри человек, который умеет описывать требования, и какова цена ошибки.
Важно Syntra Systems — разработчик, поэтому свой интерес мы называем сразу. В задании мы отдельно помечаем то, что закрывается настройкой уже купленных систем и изменением правил, без разработки, а документ отдаём в редактируемом виде — с ним можно идти к любому подрядчику.
Подготовка начинается не с документа, а с разбора работы компании: иначе требования описывают не процесс, а представление о нём.
Сколько времени занимает подготовка, зависит от числа процессов, систем и участников, поэтому объём оценивают после обследования. Разбор инфраструктуры — отдельная работа, она описана в статье об аудите IT-инфраструктуры и в статье о том, как устроен IT-консалтинг.
Перед тем как рассылать документ на оценку, пройдите по списку. Каждый невыполненный пункт — это будущее дополнительное соглашение.
Проверьте, что все подрядчики получили одну и ту же версию документа. Иначе предложения окажутся несопоставимыми, а выбор сведётся к сравнению сумм, за которыми стоит разный объём работ.
Подробное ТЗ хорошо работает там, где область понятна и стабильна: учёт, документооборот, интеграции, перенос существующего процесса в систему. Хуже — в продуктах, где ценность проверяют на пользователях.
Гибкие подходы прямо исходят из того, что требования будут меняться: принципы Agile предлагают приветствовать изменение требований даже на поздних этапах и считать работающий продукт главным мерилом продвижения. Отсюда и другой инструментарий — список задач (бэклог), пользовательские истории, приёмка по спринтам.
На практике подходы совмещают. Рамочное задание фиксирует цели, границы, нефункциональные требования, интеграции и правила приёмки — то, что меняется редко. Детализация функций живёт в бэклоге, а изменения объёма проходят согласованный порядок: оценка, решение заказчика, правка плана.
Отдельной услуги «разработка технического задания» с ценой у нас на сайте нет: обследование и задание — первый этап разработки, и объём считают после того, как определены рамки. На проектах ERP этап описан прямо в составе работ: описываем процессы, документооборот и точки принятия решений, проектируем модель данных, готовим задание и согласуем этапы — цены на странице ERP-систем.
Сравнение предложений подрядчиков мы своей услугой не называем: в нём мы сторона заинтересованная. Для этой задачи есть отдельный инструмент — каталог исполнителей, о котором мы рассказывали в статье о том, как появился IT Caravan.
Мы начинаем с обследования и заканчиваем документом, по которому можно оценивать и принимать: цели, границы, процессы, требования с номерами, интеграции, критерии приёмки и план этапов. Задание остаётся у заказчика в редактируемом виде вместе со схемами.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Для небольшой доработки — да, достаточно описания задачи и критерия готовности. Для проекта, который стоит заметных денег, без задания не получится ни сравнить предложения подрядчиков, ни закрыть работу: приёмка упрётся в разное понимание того, что именно заказывали.
Нормы не существует: объём определяется числом процессов, ролей и интеграций. Признак плохого документа не размер, а разделы, которые никто не будет проверять при приёмке. Если требование нельзя проверить, оно не добавляет ценности независимо от того, сколько страниц занимает.
Это вопрос договора. Условие о передаче прав на результат, об исходном коде, документации и доступах записывают до начала работ и указывают, в какой момент они переходят заказчику. Если этого нет в договоре, спор придётся решать по общим правилам, а не по вашим ожиданиям.
Нужна его рамочная часть: цели, границы проекта, требования к скорости, нагрузке и безопасности, интеграции и правила приёмки — это меняется редко. Список функций ведут отдельно и уточняют по ходу, а каждое изменение объёма проходит один порядок: оценка, решение заказчика, правка плана.
Заказчик — отдельно или как первый этап разработки. У нас обследование и задание идут первым этапом проекта, объём считаем после того, как определены рамки, а документ отдаём в редактируемом виде: с ним можно идти к любому подрядчику.
Возьмите любое требование и спросите, как вы проверите его выполнение и кто это сделает. Если ответ есть у каждого пункта, а в документе описаны границы проекта и порядок приёмки, задание рабочее. Если ответов нет, спор при сдаче проекта предопределён.
