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

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

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

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

Одна из сложностей для нетехнического заказчика — непонятно, с чего вообще начинать. С экранов? С перечня функций? С интеграций? С фразы «нам нужен личный кабинет»? Лучше начать раньше — с самой бизнес-задачи.

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

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

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

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

Необязательно сразу описывать каждый экран и каждую кнопку. Важнее понять:

При формировании бизнес-требований аналитики вместе с командой уточняют роли пользователей, действия, данные, уровни доступа и основные сценарии. На этой основе бизнес-задача переводится в функциональные требования к информационной системе, а затем дополняется нефункциональными и техническими требованиями. Результатом такой проработки может стать техническое или частное техническое задание (ТЗ/ЧТЗ), по которому работает команда разработки.

Функции отвечают на вопрос «что должна делать система». Но этого недостаточно. Допустим, личный кабинет открывается, данные сохраняются, заявки создаются. А что произойдёт, если одновременно в системе будут работать сотни пользователей? Как быстро должны загружаться страницы? Какие требования есть к безопасности и доступности?

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

Отдельно фиксируются технические требования к информационной системе. В зависимости от проекта это могут быть CMS или платформа, инфраструктура, поддерживаемые браузеры и устройства, технологический стек и другие ограничения.

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

Часть решений определяется уже во время проектирования. При этом важно не потерять причины, по которым команда выбрала конкретный вариант. Мы отдельно разбирали, как ADR помогает сохранять логику архитектурных решений.

У корпоративной веб-системы почти всегда есть окружение. Она может получать данные из CRM или 1С, передавать информацию в платёжный сервис, обращаться к корпоративному хранилищу или взаимодействовать с другими внутренними системами. Поэтому недостаточно написать: «Нужна интеграция с CRM».

Важно понять, что именно должно происходить:

Например, если сведения о клиентах уже ведутся в CRM, стоит определить, должна ли новая система только получать их или также изменять и передавать обратно.

Такие вопросы помогают заранее увидеть связи между будущей системой и уже существующей ИТ-инфраструктурой компании.

Ещё один источник разного понимания между бизнесом и разработкой — границы проекта.

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

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

Если часть функций планируется на следующие этапы, используется готовое внешнее решение или задача вообще не относится к текущей разработке, это лучше зафиксировать заранее.

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

Фраза «система должна быть удобной» звучит понятно, пока не наступает момент приёмки. Как проверить удобство? Кто решает, что результат уже соответствует требованию? Поэтому для значимых функций нужны проверяемые условия.

Например:

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

Для сложных систем также фиксируют порядок испытаний: какие сценарии проверяются, какие данные используются, кто участвует в проверке и как оформляется результат.

Если проект требует формализованной процедуры, может готовиться программа и методика испытаний информационной системы. В ней подробно описываются состав проверок, условия их проведения и ожидаемые результаты.

Готовое ТЗ может появиться на разных этапах проекта, поэтому единственной схемы здесь нет.

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

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

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

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

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

Когда требования уже позволяют понять объём будущего проекта, возникает следующий вопрос — кто будет его реализовывать. Мы отдельно собрали, что проверить при выборе подрядчика на разработку ПО до старта работ.

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

Обычно в ТЗ для разработчика фиксируют:

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

Но есть более важный критерий, чем количество разделов: связанные требования должны действительно быть связаны.

Если пользователь выполняет определённый сценарий, для него должны быть предусмотрены нужные функции. Функциям нужны данные и права доступа. Интеграции должны быть привязаны к конкретным процессам. А для результата должны быть понятны критерии проверки.

Иначе можно получить формально подробный документ, из которого всё равно сложно понять, как будет работать будущая система.

Когда документ собран, полезно посмотреть на него не как на ТЗ, а как на описание ещё не существующей системы.

Чтобы понять, как проверить техническое задание, попробуйте ответить на пять вопросов:

Если на каком-то этапе ответить сложно, скорее всего, в описании ещё остаётся пробел.

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

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

Есть простой способ проверить документ даже человеку без технического бэкграунда. Попробуйте мысленно пройти один из основных сценариев будущей системы. Что делает пользователь? Что происходит после его действия? Откуда система получает данные? Что видит следующий участник процесса? Чем сценарий заканчивается?

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

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

Поэтому нетехническому заказчику не нужно пытаться написать документ на языке разработчика. Гораздо важнее другое: понять, можно ли по этому документу представить будущую работу системы и увидеть, как она решит исходную бизнес-задачу.

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