Техническое задание — это документ, в котором фиксируются требования к проекту.
В чём основное отличие проектной и продуктовой разработки? Проектная разработка имеет начало и конец, когда продуктовая разработка — это непрерывный цикл развития продукта, где требования часто меняются.
Чтобы разработать техническое задание, нужно провести исследование с потенциальными пользователями проекта или продукта. Разбираться в базовых паттернах пользовательского опыта. Человек, который разрабатывает ТЗ, должен провести огромную аналитическую работу и фактически спроектировать будущий продукт, здесь нет права на ошибку.
Но кто не ошибается? Я не знаю таких людей.
Тем не менее, у нас есть 44-ФЗ
Бюджетные организации нанимают исполнителей через тендеры и они обязаны составлять технические задания к программным продуктам. Если это форма на сайте, заказчик должен описать всё в мельчайших подробностях, какие поля, какие кнопки. А исполнитель должен всё в точности повторить.
Если исполнитель используя свою экспертизу сделает что-то иначе, это могут увидеть проверяющие органы, тогда ответственность понесёт сотрудник, который принимал проект, а исполнитель не увидит денег на своём счёте, пока не исправит всё в соответствии с ТЗ.
ТЗ в коммерческих организациях
Если с бюджетными организациями всё понятно, закон регламентирует их взаимодействие с исполнителями, то использование ТЗ в коммерческих организациях в продуктовой разработке, скорее всего, сигнализирует о сломанных процессах.
Когда я слышу ТЗ, сразу представляю, что в компании процесс разработки построен по методологии Waterfall (Водопад).
Waterfall
Это методология каскадной разработки проекта, которая тоже не даёт права на ошибку. Это последовательная работа без возможности вернуться на предыдущий шаг:
- Аналитики собирают требования к проекту, готовят подробное техническое задание и план графика работ;
- Дизайнеры проектируют интерфейс, готовят дизайн-макеты;
- Разработчики пишут код на основе технического задания и дизайн-макетов. Чаще всего, это приводит к написанию монолитной архитектуры приложения, что потом сложно поддерживать и модернизировать;
- Тестировщики проверяют приложение на наличие ошибок и соответствие техническому заданию;
- Проект передают заказчику.
Организационная структура строится по отделам с четкой иерархией, где команды аналитиков, дизайнеров, разработчиков и тестровщиков не пересекаются в работе.
Чем плоха Waterfall модель разработки? Нельзя разбить всю работу на части и поставлять функции маленькими партиями. Дизайнеры требуют полную документацию, разработчики полностью готовый дизайн, а тестировщики готовое приложение. Если на каком-то этапе решили внести исправление в ТЗ, это вызывает боль и хаос в работе всех команд по цепочке ниже. А главное — это длинный цикл разработки, когда от начала и до конца может пройти несколько лет.
Agile
Процесс продуктовой разработки строится по гибкой методологии Agile, в которой нет технического задания. User Stories заменяют техническое задание. А организационная структура формируется по продуктам из кросс-функциональных команд с плоской иерархией. Кросс-функциональная команда — это группа людей с различным функциональным опытом, работающих над достижением общей цели.
Как, примерно, выглядит процесс продуктовой разработки:
- Есть бэклог гипотез, который формируется из обратной связи от пользователей, из функций конкурентов и артефактов исследований;
- По каждой гипотезе команда проводит исследование, результатом которого являются User Stories;
- Команда берет в работу User Story и придумывает решение;
- Команда изготавливает прототип и тестирует его на пользователях;
- После успешных тестов разрабатывается решение и тестируется на предмет ошибок;
- Изменения выливаются в продукт и маркетинг проводит свои активности, чтобы рассказать целевой аудитории и пользователям о новой функции.
Таким образом, команда может постепенно поставлять новые функции пользователям, быстро получать обратную связь от пользователей и вносить исправления. Планирование работы в гибкой методологии более предсказуемо, а качество выше.
