Технологии
ТЗ для разработчиков: как описать будущую систему до начала разработки
Заказчику новой веб-системы не обязательно быть техническим специалистом, но именно ему нужно объяснить разработчикам, какой результат нужен бизнесу. Поэтому вопрос, как писать ТЗ для разработчиков, — не только про структуру документа. Хорошее техническое задание ещё до начала разработки должно давать первую рабочую модель будущей системы, которую можно проверить и согласовать.
На практике команда разработки обычно не ждёт от заказчика полностью проработанного технического задания. На старте важнее сформулировать бизнес-требования: какую задачу должна решить система, какие процессы изменить и какие цели должен закрывать разрабатываемый функционал.
Начинаем с задачи, которую система должна решать для бизнеса
Если готового технического задания ещё нет, заказчику не нужно сразу переводить задачу на технический язык. Работу стоит начинать с бизнес-требований: описать, что происходит сейчас, что требуется изменить и какой результат нужен компании.
Например, если компания планирует автоматизировать согласование заявок, сначала важно зафиксировать текущую схему работы: кто создаёт заявку, кто её согласует, где возникают задержки и что должно измениться после внедрения системы.
Дальше эту бизнес-задачу прорабатывают вместе с командой: через интервью и брифование уточняют процессы, ограничения и ожидаемый результат, а затем переводят их в требования, по которым уже можно проектировать и разрабатывать систему.
Описываем, кто и как будет работать в системе
Следующий шаг — обозначить основные группы пользователей будущей системы и задачи, которые они будут в ней решать. Например, менеджеры создают заявки, руководители согласуют их, бухгалтерия получает данные для расчётов.
При формировании бизнес-требований аналитики вместе с командой уточняют роли пользователей, действия, данные, уровни доступа и основные сценарии. На этой основе бизнес-задача переводится в функциональные требования к информационной системе, а затем дополняется нефункциональными и техническими требованиями. Результатом такой проработки может стать техническое или частное техническое задание (ТЗ/ЧТЗ), по которому работает команда разработки.
Дополняем функции нефункциональными требованиями к информационной системе
Техническое задание описывает функции системы и условия её работы. Нефункциональные требования к информационной системе могут задавать производительность, допустимую нагрузку, уровень доступности, требования к безопасности и другие характеристики, которые влияют на работу решения.
Отдельно фиксируются технические требования к информационной системе. В зависимости от проекта это могут быть CMS или платформа, требования к инфраструктуре, поддерживаемым браузерам и устройствам, технологическому стеку и другим ограничениям. Если часть решений определяется уже в ходе проектирования, в итоговую версию документа вносятся согласованные параметры.
Как не потерять логику архитектурных решений
Разбираем, зачем фиксировать ключевые технические решения в ADR и как это помогает сохранять контекст проекта.
Читать →
Связываем систему с данными и внешними сервисами
Будущая система редко работает изолированно. Она может получать данные из CRM или 1С, обращаться к платёжному сервису, корпоративному хранилищу или другим внутренним и внешним решениям.
В техническом задании важно зафиксировать, с какими системами нужен обмен и какие данные должны передаваться в каждом направлении. Например, откуда поступают сведения о клиентах, где хранятся документы, куда передаются результаты расчётов и какая система остаётся источником исходных данных.
При проработке интеграций уточняют способы обмена, состав и формат данных, периодичность синхронизации и поведение системы при ошибках или недоступности внешнего сервиса.
Фиксируем границы разработки и состав будущей системы
Когда основные требования собраны, важно определить состав будущей системы. В документе фиксируется, какие части должны войти в проект: например, личный кабинет, административная панель, отдельные модули, интерфейсы для разных групп пользователей.
Здесь же обозначаются границы разработки. Если часть функций планируется на следующие этапы, используется готовое внешнее решение или вообще не входит в текущий проект, это лучше отделить от того, что должно быть реализовано в первой версии.
Так техническое задание задаёт понятный объём работ и одновременно показывает, из каких частей будет состоять будущая система.
Закладываем критерии проверки и приёмки результата
Техническое задание задаёт состав функций и понятные условия, по которым потом можно проверить готовую систему. Для значимых требований заранее определяют, какой результат будет считаться выполненным корректно.
Критерий приёмки описывает проверяемый результат. Например, заявка после согласования должна перейти в заданный статус, пользователь с определённой ролью — видеть только доступные ему данные, а обмен с внешней системой — передавать предусмотренный набор полей. Это даёт понятную основу для приёмки.
Для сложных систем также фиксируют порядок испытаний: какие сценарии проверяются, какие данные используются, кто участвует в проверке и как оформляется результат. Если проект требует формализованной процедуры, может готовиться программа и методика испытаний информационной системы. В ней подробно описываются состав проверок, условия проведения и ожидаемые результаты.
Разбираемся, кто составляет ТЗ: заказчик или исполнитель
Готовое техническое задание может появиться на разных этапах проекта, поэтому единой схемы здесь нет.
Если компания выходит на тендер уже с ТЗ, обычно возможны два сценария. В первом бизнес-задачу заранее проработала внутренняя команда заказчика и сама перевела её в технический документ. Во втором ТЗ было подготовлено с привлечением внешней команды — например, текущего подрядчика, отдельного исполнителя на этапе предпроектной проработки или в рамках предыдущего этапа закупки.
Если готового ТЗ на старте нет, заказчик приходит с бизнес-задачей, исходными требованиями и ограничениями. Дальше через брифование и проработку требований команда переводит эту задачу в функциональные, нефункциональные и технические требования и формирует документ, по которому можно начинать разработку.
К началу разработки документ должен быть согласован и утверждён в порядке, предусмотренном конкретным проектом или закупочной процедурой. Он фиксирует объём работ, требования к системе и критерии приёмки и может оформляться приложением к договору.
Поэтому вопрос, кто должен составлять техническое задание, решается с учётом модели проекта. Заказчик отвечает прежде всего за бизнес-контекст, цели и ожидаемый результат, а степень его участия в подготовке самого технического документа зависит от того, есть ли у компании собственная компетенция и на каком этапе подключается команда разработки.
Как выбрать подрядчика на разработку
Разбираем, что проверить у команды до старта проекта, чтобы оценить опыт, подход к работе и будущий процесс разработки
Читать →
Собираем требования в единое ТЗ для разработчика
Когда требования проработаны, их нужно собрать в документ с понятной структурой. По нему должна быть видна общая логика проекта: зачем создаётся система, кто будет с ней работать, что входит в объём разработки и по каким условиям будет приниматься результат.
Состав разделов зависит от масштаба и типа проекта, но обычно в техническом задании фиксируют:
- Цели и назначение системы;
- пользователей и основные сценарии;
- функциональные, нефункциональные и технические требования;
- интеграции и требования к данным;
- состав системы и границы проекта;
- критерии приёмки и порядок проверки результата.
Структура может быть другой, если этого требует проект, договор или закупочная документация. Важно, чтобы связанные требования не были разбросаны по разным документам без понятных отсылок и чтобы их можно было однозначно сопоставить с объёмом разработки и приёмкой.
Проверяем техническое задание перед передачей в разработку
Когда документ собран, его стоит перечитать целиком и проверить, складывается ли из отдельных требований единая картина будущей системы. Понятно ли, какие задачи она решает, кто будет с ней работать, какие функции входят в проект, с какими системами нужен обмен и какие технические условия необходимо учитывать.
Чтобы понять, как проверить техническое задание, полезно смотреть не только на наличие обязательных разделов, но и на связи между ними. Пользовательский сценарий должен опираться на предусмотренные функции, функция — учитывать нужные данные и права доступа, а интеграция — быть связана с конкретным процессом.
Отдельно стоит проверить формулировки, которые допускают разное толкование: «быстро», «удобно», «при необходимости», «автоматически». В техническом задании такие требования лучше переводить в конкретные условия, которые одинаково понимают все участники проекта.
ТЗ — первая рабочая модель будущей системы
Перед согласованием технического задания полезно мысленно пройти основной сценарий: что делает пользователь, как система реагирует на его действия, откуда получает необходимые данные и к какому результату приводит каждый шаг. Если на каком-то этапе возникает вопрос «а что происходит дальше?», значит, в описании ещё остаётся пробел.
Так техническое задание работает как модель будущей системы: помогает увидеть противоречия и недостающие детали ещё до того, как требования превратятся в интерфейсы, программный код и интеграции.
Для заказчика здесь есть простой ориентир: перед утверждением документа стоит посмотреть на него не как на набор технических требований, а как на описание будущей работы. Понятно ли по нему, как будет решаться исходная бизнес-задача и какой результат в итоге предстоит принять? Если эта логика прослеживается от начала до конца, техническое задание выполняет свою основную функцию.
Если по техническому заданию уже можно представить будущую систему без догадок, следующий шаг — превратить эту модель в работающий продукт. DIGITAL SECTOR разрабатывает сложные веб-системы и подключается к проектам от проектирования до запуска и дальнейшего развития.
Согласен