Как написать ТЗ на разработку IT-продукта. Что должно быть в ТЗ для разработчика
Техническое задание (ТЗ) — обязательная составляющая процесса разработки. О том как правильно написать грамотное ТЗ для разработчика, которое действительно поможет команде разработки создать ваш IT-продукт, а не будет бесполезным томом на 540 страниц — читайте в нашем материале.
Эта статья будет полезна вам, если:
- Вы хотите отдать проект в разработку, при этом не важно инхаус или внешней команде;
- У вас в команде нет бизнес-аналитика или тимлида, который уже имеет опыт формирования ТЗ на разработку IT-проекта;
- Вы хотите убедиться, что техническое задание полное, команда сможет по нему точно оценить проект и реализовать его в срок.
Техническое задание: что важно знать
Техническое задание (ТЗ) — документ, который содержит цели, задачи, характеристики, функциональные и технические требования к разрабатываемому IT-продукту. Это полный, детализированный список, который помогает разработчикам понять какой именно продукт они создают и каким функционалом этот продукт должен на выходе обладать, какие задачи решать.
Что предшествует составлению ТЗ на разработку
Как правило до написания технического задания формируют бизнес и функциональные требования, они и станут основой ТЗ программного продукта.
На этом остановимся подробнее:
Бизнес-требования — это задачи, которые должен решать IT-продукт, с какой целью этот продукт создается и как он поможет в достижении бизнес-показателей. Этот документ должен быть понятен человеку без технических навыков.
Например, бизнес-требованием можно назвать:
- Настроить фильтрацию каталога по ключевым словам: бренд, цвет, вид товара, производитель, страна производителя
Функциональные требования (ФТ) — это набор требований, которые должны быть реализованы, иными словами функционал, которым должна обладать система, без подробного описания. Именно набор ФТ и станет в последующем основой технического задания.
Например, к функциональным требованиям можно отнести:
- Организовать сортировку результатов поиска по релевантности. Первыми должны идти те товары, у которых все слова поискового запроса находятся в одной строке. Далее идут товары у которых все слова встречаются в разных свойствах (при этом учитывается «вес свойства» см. ниже). Далее идут товары у которых встречается меньшее количество слов из поискового запроса
- Сделать возможность поиска по свойствам: бренд, суббренд, вид товара, название производителя, страна производитель
- Организовать сортировку результатов поиска в соответствии с «весом» свойства (название, бренд, суббренд, вид товара, состав, название производителя, страна производитель)
Обязательные составляющие тех. задания на разработку
Итак, вы собрали бизнес и функциональные требования, определили кто будет формировать техническое задание. Теперь важно определить блоки, которые должны быть в ТЗ. Сразу отметим, что техническое задание может содержать неограниченное количество блоков, в этом материале мы расскажем о наборе требований к ТЗ на разработку, без которых любое ТЗ не будет полным и емким. Также важно отметить, что существует несколько регламентов, в том числе и ГОСТ, которые описывают составляющие технического задания на разработку IT-проекта.
Например:
- ГОСТ 34
- IEEE 29148-2011 — стандарт разработки сложных систем
- Rational Unified Process — спецификация для разработки требований к IT-продуктам
В этом материале мы будем говорить о техническом задании без привязки к конкретному регламенту, но которое точно поможет вашей команде разработки оценить проект, спрогнозировать ресурсы, а в дальнейшем декомпозировать задачи и в итоге сдать проект в нужном виде. В то же время, если со стороны клиента техническое задание регламентировано внутренним распорядком (у нас были и такие клиенты, чаще всего это государственные органы), то и тут не будет никаких накладок, т.к. техническое задание может быть дополнено на этапе согласования проекта.
Обязательные составляющие эффективного процесса разработки читайте в гайде: «Разработка IT-продукта».Что должно быть в ТЗ для разработки IT-продукта
Информация о разрабатываемом IT-продукте
- Назначение и цели создания
- Структура IT-продукта
- из чего состоит продукт
- как он взаимодействует с системой в целом
Глоссарий
- Он же справочник. Как правило, бизнес пользуется специфической терминологией, которая понятна заказчику или представителю сферы. Команда разработки же может не всегда верно истолковать эту терминологию, поэтому важно сверить «понятийные аппараты» и говорить на одном языке
- Также и со стороны разработчиков необходимо описывать технические термины, чтобы сотрудник Заказчика, согласовывающий ТЗ (при этом чаще всего не технический специалист) понимал, о чем идет речь
Требования к IT-продукту
- Бизнес-требования
- Функциональные требования
- Технические требования:
- характеристики (нагрузка, которую должен выдержать сервис, производительность и т.д.)
- требования к технологиям
- требования к серверам
- требования к скорости работы сервиса
- обязательная интеграция со сторонними сервисами
- требования к безопасности
- и прочее. Таких требований может быть очень много, все зависит от того, какой продукт вы разрабатываете
Спецификация на интерфейс
Этот пункт присутствует в ТЗ на разработку IT-продукта при реализации по прототипам или макетам.
- Спецификация — это документ, который описывает функциональное назначение и тип каждого элемента управления/блока, техническую составляющую интерфейса. Как правило, спецификация составляется по типу: Элемент-Изображение-Описание.
Пользовательские сценарии (use case)
- Use case — это ответ системы на действия пользователя. Соответственно, чем больше пользовательских сценариев и реакций системы будет описано в ТЗ, тем лучше.
Пользовательские сценарии помогают всем участникам системы, в том числе тимлиду:
- Определить появление возможных проблем во время разработки
- Четко определить и предсказать поведение системы
- Упрощает приемку задачи, дает совпасть ожиданию и реальности
- Дает однозначность: упрощает жизнь для разработчика, тестировщика, постановщика
Не существует на текущий день согласованной методологии описания пользовательских сценариев, их можно описывать в табличном или текстовом виде. Тут выбор за вами, главное, чтобы сценарии были понятны.
Однако, каждый сценарий должен обязательно содержать 3 блока:
- Предусловие — что привело к старту сценария
- Постусловие — что должно произойти по окончании выполнения сценария
- Основной поток событий — основной алгоритм действий
- Необязательно, но зачастую присутствует альтернативный поток событий — альтернативный алгоритм действий
Пользовательская и техническая документация
Набор документации, которая будет передана по итогу работ:
- Пользовательская документация — это документ для пользователя (не технического специалиста), который описывает, как работать с системой
- Тех. документация — это представление различных сервисов/разделов, хранящих техническую информацию о работе с системой
- Эти документы предназначены для технических специалистов
Неважно, внешняя или внутренняя у вас команда разработки – любая команда должна вести документацию по вашему проекту и передать ее вам по итогу. В каком виде передается документация:
- Техническое задание — мы используем Confluence, Notion
- Спецификация на интерфейс — Confluence, Notion
- Конструкторскую документацию — Confluence, Notion
- Описание API — мы используем openAPI (swagger), postman
- Документация кода (оно же комментирование кода) мы используем PHPDoc, JsDoc
Порядок контроля и приемки
- Этот пункт описывает сроки и порядок сдачи разработанного web-сервиса. И значительно упрощает жизнь как команде разработке, так и Заказчику, так как регламентирует порядок приемки разработки. Не бывает так, что Заказчик отдал ТЗ и забыл о разработке продукта, вспомнив только на финальном этапе. Обычно весь процесс поделен на этапы и у каждого этапа есть контрольные точки. Чтобы у обеих сторон было понимание о ходе разработки — эти контрольные точки фиксируются и закрепляются.
- Также в этом пункте описывается, с помощью каких инструментов будет тестироваться работоспособность системы. Как правило, грамотное ТЗ содержит набор этих основных требований, но, как и говорили выше, может дополняться в зависимости от исходных данных. Следите, чтобы в вашем техническом задании были все эти пункты. Если же в команде нет экспертизы, которая может описать технические требования — передавайте эту функцию потенциальной команде разработки.
Согласование ТЗ
После того, как техническое задание составлено — необходимо его согласовать со всеми участниками. Важным нюансом здесь будет согласование ТЗ со всеми отделами, которые будут использовать IT-продукт. Как правило на первом этапе создания IT-продукта всегда есть правки от разных отделов, т.к. составить техническое задание, которое сразу же будет отвечать всем требованиям маркетинга, контент-менеджера, коммерческого директора и так далее практически нереально. После внесения всех правок — готовое техническое задание утверждается и становится основой для приемки продукта бизнесом.
Вместо заключения
Разработкой технического задания обычно занимаются аналитики, но довольно часто его функции на себя берет тимлид. Техническое задание можно также приложить к пользовательской инструкции, это поможет в будущем разработчику быстрее вникнуть в задачу по доработке. Так же нужно понимать, что нет необходимости писать ТЗ на каждый чих, это имеет смысл делать на разработку отдельного IT-продукта или переработку разделов/модулей/блоков. Сначала может показаться, что это бюрократическая мера, но когда крупных задач будет больше двух, а вопросы по функционалу будут расти с геометрической прогрессией — без ТЗ не обойтись. Кроме того, без технического задания сложно бюджетировать проект, нет проверки на «ожидание/реальность» к разработанному продукту, нет четко описанных критериев продукта. Составляйте грамотное техзадание и не жалейте на этот этап своих ресурсов!
Скачать полный гайд: «Разработка IT-продукта с привлечением внешней команды».