Как написать ТЗ на разработку IT-продукта. Что должно быть в ТЗ для разработчика

Техническое задание (ТЗ) — обязательная составляющая процесса разработки. О том как правильно написать грамотное ТЗ для разработчика, которое действительно поможет команде разработки создать ваш IT-продукт, а не будет бесполезным томом на 540 страниц — читайте в нашем материале.

Эта статья будет полезна вам, если:

1. Вы хотите отдать проект в разработку, при этом не важно инхаус или внешней команде;
2. У вас в команде нет бизнес-аналитика или тимлида, который уже имеет опыт формирования ТЗ на разработку IT-проекта;
3. Вы хотите убедиться, что техническое задание полное, команда сможет по нему точно оценить проект и реализовать его в срок.

Техническое задание: что важно знать

Техническое задание (ТЗ) — документ, который содержит цели, задачи, характеристики, функциональные и технические требования к разрабатываемому IT-продукту. Это полный, детализированный список, который помогает разработчикам понять какой именно продукт они создают и каким функционалом этот продукт должен на выходе обладать, какие задачи решать.

Что предшествует составлению ТЗ на разработку

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

На этом остановимся подробнее:

Бизнес-требования — это задачи, которые должен решать IT-продукт, с какой целью этот продукт создается и как он поможет в достижении бизнес-показателей. Этот документ должен быть понятен человеку без технических навыков.

Например, бизнес-требованием можно назвать:

• Настроить фильтрацию каталога по ключевым словам: бренд, цвет, вид товара, производитель, страна производителя

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

Например, к функциональным требованиям можно отнести:

• Организовать сортировку результатов поиска по релевантности. Первыми должны идти те товары, у которых все слова поискового запроса находятся в одной строке. Далее идут товары у которых все слова встречаются в разных свойствах (при этом учитывается «вес свойства» см. ниже). Далее идут товары у которых встречается меньшее количество слов из поискового запроса
• Сделать возможность поиска по свойствам: бренд, суббренд, вид товара, название производителя, страна производитель
• Организовать сортировку результатов поиска в соответствии с «весом» свойства (название, бренд, суббренд, вид товара, состав, название производителя, страна производитель)

Обязательные составляющие тех. задания на разработку

Итак, вы собрали бизнес и функциональные требования, определили кто будет формировать техническое задание. Теперь важно определить блоки, которые должны быть в ТЗ. Сразу отметим, что техническое задание может содержать неограниченное количество блоков, в этом материале мы расскажем о наборе требований к ТЗ на разработку, без которых любое ТЗ не будет полным и емким. Также важно отметить, что существует несколько регламентов, в том числе и ГОСТ, которые описывают составляющие технического задания на разработку IT-проекта.

Например:

• ГОСТ 34
• IEEE 29148-2011 — стандарт разработки сложных систем
• Rational Unified Process — спецификация для разработки требований к IT-продуктам

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

Что должно быть в ТЗ для разработки IT-продукта

Информация о разрабатываемом IT-продукте

1. Назначение и цели создания
2. Структура IT-продукта
   • из чего состоит продукт
   • как он взаимодействует с системой в целом

Глоссарий

• Он же справочник. Как правило, бизнес пользуется специфической терминологией, которая понятна заказчику или представителю сферы. Команда разработки же может не всегда верно истолковать эту терминологию, поэтому важно сверить «понятийные аппараты» и говорить на одном языке
• Также и со стороны разработчиков необходимо описывать технические термины, чтобы сотрудник Заказчика, согласовывающий ТЗ (при этом чаще всего не технический специалист) понимал, о чем идет речь

Требования к IT-продукту

1. Бизнес-требования
2. Функциональные требования
3. Технические требования:
   • характеристики (нагрузка, которую должен выдержать сервис, производительность и т.д.)
   • требования к технологиям
   • требования к серверам
   • требования к скорости работы сервиса
   • обязательная интеграция со сторонними сервисами
   • требования к безопасности
   • и прочее. Таких требований может быть очень много, все зависит от того, какой продукт вы разрабатываете

Спецификация на интерфейс

Этот пункт присутствует в ТЗ на разработку IT-продукта при реализации по прототипам или макетам.

• Спецификация — это документ, который описывает функциональное назначение и тип каждого элемента управления/блока, техническую составляющую интерфейса. Как правило, спецификация составляется по типу: Элемент-Изображение-Описание.

Пользовательские сценарии (use case)

• Use case — это ответ системы на действия пользователя. Соответственно, чем больше пользовательских сценариев и реакций системы будет описано в ТЗ, тем лучше.

Пользовательские сценарии помогают всем участникам системы, в том числе тимлиду:

• Определить появление возможных проблем во время разработки
• Четко определить и предсказать поведение системы
• Упрощает приемку задачи, дает совпасть ожиданию и реальности
• Дает однозначность: упрощает жизнь для разработчика, тестировщика, постановщика

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

Однако, каждый сценарий должен обязательно содержать 3 блока:

• Предусловие — что привело к старту сценария
• Постусловие — что должно произойти по окончании выполнения сценария
• Основной поток событий — основной алгоритм действий
• Необязательно, но зачастую присутствует альтернативный поток событий — альтернативный алгоритм действий

Пользовательская и техническая документация

Набор документации, которая будет передана по итогу работ:

• Пользовательская документация — это документ для пользователя (не технического специалиста), который описывает, как работать с системой
• Тех. документация — это представление различных сервисов/разделов, хранящих техническую информацию о работе с системой
• Эти документы предназначены для технических специалистов

Неважно, внешняя или внутренняя у вас команда разработки – любая команда должна вести документацию по вашему проекту и передать ее вам по итогу. В каком виде передается документация:

• Техническое задание — мы используем Confluence, Notion
• Спецификация на интерфейс — Confluence, Notion
• Конструкторскую документацию — Confluence, Notion
• Описание API — мы используем openAPI (swagger), postman
• Документация кода (оно же комментирование кода) мы используем PHPDoc, JsDoc

Порядок контроля и приемки

• Этот пункт описывает сроки и порядок сдачи разработанного web-сервиса. И значительно упрощает жизнь как команде разработке, так и Заказчику, так как регламентирует порядок приемки разработки. Не бывает так, что Заказчик отдал ТЗ и забыл о разработке продукта, вспомнив только на финальном этапе. Обычно весь процесс поделен на этапы и у каждого этапа есть контрольные точки. Чтобы у обеих сторон было понимание о ходе разработки — эти контрольные точки фиксируются и закрепляются.
• Также в этом пункте описывается, с помощью каких инструментов будет тестироваться работоспособность системы. Как правило, грамотное ТЗ содержит набор этих основных требований, но, как и говорили выше, может дополняться в зависимости от исходных данных. Следите, чтобы в вашем техническом задании были все эти пункты. Если же в команде нет экспертизы, которая может описать технические требования — передавайте эту функцию потенциальной команде разработки.

Согласование ТЗ

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

Вместо заключения

Разработкой технического задания обычно занимаются аналитики, но довольно часто его функции на себя берет тимлид. Техническое задание можно также приложить к пользовательской инструкции, это поможет в будущем разработчику быстрее вникнуть в задачу по доработке. Так же нужно понимать, что нет необходимости писать ТЗ на каждый чих, это имеет смысл делать на разработку отдельного IT-продукта или переработку разделов/модулей/блоков. Сначала может показаться, что это бюрократическая мера, но когда крупных задач будет больше двух, а вопросы по функционалу будут расти с геометрической прогрессией — без ТЗ не обойтись. Кроме того, без технического задания сложно бюджетировать проект, нет проверки на «ожидание/реальность» к разработанному продукту, нет четко описанных критериев продукта. Составляйте грамотное техзадание и не жалейте на этот этап своих ресурсов!