ТЗ на разработку. Как его написать, если вы не айтишник?

Что такое техническое задание (ТЗ) и причем тут зеленый забор

ТЗ – это важный документ, который описывает жизненный цикл создания продукта. Он содержит требования, в соответствии с которыми осуществляется создание и разработка продукта. Основа ТЗ – бизнес-требования.

ТЗ есть не только в ИТ. Например, «Хочу зеленый забор» – тоже является техническим заданием, но далеко не полным. Из него непонятно, есть ли уже готовый забор, который нужно покрасить. Если да – то где находится этот забор, красить с одной или двух сторон, какой именно оттенок зеленого использовать.Если забора нет, то это усложняет задачу. Возникает вопрос, где забор поставить, из чего его сделать, какой высоты.

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

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

Что такое бизнес-требования

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

Бизнес-требования, например, могут звучать так:

Сокращение ручного труда персонала ресторана при обработке данных; Автоматизация формирования отчета по поступившим заказам в форматы *.xlsx, *.pdf на основе собранных данных; автоматизация отправки отчета по поступившим заказам на e-mail менеджера.

Что должно быть в ТЗ

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

Например:

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

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

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

Примерная структура ТЗ

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

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

Как написать ТЗ для MVP

MVP – это минимально жизнеспособный продукт. То есть продукт, который содержит минимальный набор функций, но является уже ценным для пользователя.

Techopedia описывает три ключевых особенности MVP:

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

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

Что может быть такими критериями успешности продукта?

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

Например, если продукт автоматизирует какой-либо процесс, то критериями могут быть:

• доля обрабатываемых через продукт документов (например, 70% от всех документов, участвующих в процессе).
• сокращение общей длительности процесса обработки документов (например, до автоматизации 2 дня, после – 30 минут).

Чек-лист. Как составить ТЗ для MVP:

1. Сформулировать бизнес-требования к проекту. Описать максимально подробно, какие задачи бизнеса будет решать проект.
2. Описать пользовательские сценарии – то, как с проектом будет взаимодействовать пользователь.
3. Подробно изложить видение по структуре проекта. Описание разделов лучше составлять развернуто: не просто «раздел о нас», а структура страницы, контент, нужна ли форма обратной связи, какие поля должны в ней быть.
4. Собрать референсы – примеры похожих продуктов, которые нравятся, и примеры продуктов, которые категорически не нравятся.
5. Зафиксировать используемые в проекте технологии. С этим помогут технические специалисты.
6. Собрать все данные в один документ, структурировать информацию.
7. Отформатировать текст, чтобы его было удобно читать и редактировать (например, использовать буллеты вместо сплошного текста, проставлять внутренние ссылки).

Фото на обложке: pixabay.com