В этой части нашего цикла статей про создание IT-концепции рассказываем про стандарты и шаблоны для ТЗ на разработку программного обеспечения.
Сейчас мы находимся на этапе, когда определены скоуп работ и приоритетность задач проекта. Следующий шаг — определить функциональные и нефункциональные требования:
Функциональные требования: функции продукта — что могут делать пользователи, процесс взаимодействия, интеграция с другими сервисами.
Нефункциональные требования: ограничения и свойства продукта, производительность и безопасность.
Техническое задание или ТЗ — документ, в котором описываются требования к проекту. Основное назначение ТЗ — синхронизировать ожидания заказчика и понимание задачи командой разработки, чтобы по результатам реализации проекта получить требуемый результат. Разработка ТЗ позволяет детально погрузиться в требования и технические аспекты разработки.
Классическая картинка, которая четко описывает отсутствие ТЗ:
ТЗ конкретизирует пожелания каждой из сторон. Чем качественнее оно составлено, тем больше шансов создать крутой продукт. Рассмотрим, что ТЗ дает заказчику и команде разработки.
Заказчик:
Команда разработки:
Это зависит от конкретного проекта и договоренностей сторон.
Вариант 1. ТЗ разрабатывает Заказчик.
Если на стороне заказчика есть специалисты, которые хорошо понимают предметную область, цели и задачи проекта, а также имеют технический бэкграунд, то данный вариант позволит сократить время на разработку ТЗ. Исполнитель будет глубоко понимать требования к продукту, что упростит коммуникацию с командой разработки, так как взаимодействие будет происходить на одном языке.
Вариант 2. ТЗ разрабатывает команда разработки.
Если на стороне заказчика в формировании требований участвуют только эксперты со стороны бизнеса, то лучше отдать этот блок на сторону команды разработки, которая может задать нужные вопросы, предложить решения, зафиксировать требования в необходимом формате. Это позволит повысить качество ТЗ, проработать технические вопросы на старте работ, сократить время на передачу информации от заказчика к разработке. Команда разработки проведет необходимые встречи, соберет и проанализирует требования, изучит и согласует итоговый вариант ТЗ с заказчиком.
Существуют ГОСТы и рекомендации, по которым следует описывать ТЗ. Данные правила подразумевают использование готовых шаблонов, что помогает не тратить время на структурирование. При этом нужно помнить, что это гибкий инструмент, который может включать в себя все, что необходимо для достижения результата.
Основные стандарты:
Мы в своей работе используем те, которые в первую очередь требует заказчик. Если такого требования нет, выбираем свой формат, который мы отработали в ходе реализации многочисленных проектов. Для того, чтобы разработчик создал именно тот продукт, который заказчик хотел получить, формат не так важен. Содержание является ключевым моментом при составлении ТЗ.
Структура ТЗ включает следующие смысловые блоки:
Двигайтесь от общего к частному, погружайтесь от верхней функциональной архитектуры к нижним уровням детализации.
Описывайте функции подробно. Описание должно быть достаточным, чтобы после реализации можно было оценить степень выполнения функции. Излишние подробности приведут к увеличению сроков разработки ТЗ. Недостаточные подробности — к расхождению. Если функция критична с точки зрения достижения бизнес-ценности, то следует описать ее в деталях.
Пишите однозначно и четко. Используйте понятные формулировки, которые не подразумевают двойных трактовок. Избегайте прилагательных с неясным смыслом: удобный, современный, быстрый.
Помогите разобраться в терминах. Вы наверняка будете использовать специфические термины, которые не всегда понятны для заказчика. Создайте раздел с кратким словарем проекта, где будут представлены все необходимые определения. Это значительно облегчит коммуникацию.
Используйте модели, диаграммы, картинки. Это позволит посмотреть на требования с разных ракурсов и сделает ТЗ более читаемым. Обязательно описывайте все модели и рисунки текстом, чтобы не упустить детали, которые сложно отразить в схеме.
Не снижайте приоритетность нефункциональных требований. В ходе их проработки могут быть приняты решения по изменению функциональных требований, сроков и стоимости работ, состава команд, применяемых технологий.
Учитывайте концепцию развития системы и скоуп работ, чтобы при проектировании отразить масштабируемость и возможность развития системы.
Наша опытная команда готова прийти к вам на помощь и взять функцию написания технического задания на себя. Мы всегда стараемся максимально учитывать интересы заказчика и работать в тесном взаимодействии со всеми заинтересованными сторонами.
