Как написать ТЗ на разработку сайта или приложения
За 20 лет в IT-разработке я убедился, что все по-разному понимают, что такое ТЗ:
- телефонный звонок программисту с просьбой «запилить новый раздел на сайте»,
- анкета, которую подрядчик отправил клиенту, и клиент её заполнил,
- нарисованный на бумаге скетч интерфейса сайта,
- док-файл со списком пользовательских сценариев, которые должны выполняться на сайте,
- большая стопка бумаги со всеми техническими нюансами работы программного продукта по ГОСТу.
Всё это — лишь разные способы описать то, что нужно сделать. Иными словами, ТЗ — это требования к разработке программного продукта: сайта, приложения, информационной системы.
Это как раз то, чем мы занимаемся в компании panfilov.digital. За последние 5 лет в нашем таск-трекере выполнено больше 20.000 задач общей продолжительностью почти 100.000 часов.
Мы составили шаблон, который упрощает работу с требованиями к разработке, если вы менеджер проекта или заказчик. Его можно использовать вне зависимости от методологии, но по-разному, поэтому вначале расскажу о подходах к разработке. Затем опишу роли и функции участников процесса, поделюсь примерами и дам инструменты, которые помогут при составлении ТЗ.
Получить консультацию по управлению разработкой цифровых продуктов — consulting@panfilov.group.
Заказать разработку — panfilov.digital.
Почему важно правильно составить ТЗ
На ошибки, внесенные на этапе сбора требований, приходится от 40 до 50% всех дефектов. Следствие проблем с требованиями — переделка того, что, как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки.
Ещё дороже обходится исправление ошибки, обнаруженной пользователем. Как утверждают авторы книги «Разработка требований к программному обеспечению» (ISBN 978-5-9909805-3-2) — это в 21 раз дороже, чем исправление ошибки, обнаруженной на этапе проектирования.
Напротив, чёткое понимание требований к продукту дает уверенность, что команда работает над теми проблемами, над которыми нужно, и создаёт лучшее их решение.
Подходы к разработке
Подход называется так, потому что на календарном плане (диаграмме Ганта) этапы работ идут сверху вниз, друг за другом и похожи на водопад. Waterfall считается «классическим» подходом, поскольку требования, по которым идёт работа на протяжении всего проекта, готовятся в самом начале и остаются неизменными.
Главный признак проекта, к которому применим водопадный подход — это проект с чётко обозначенным и заранее известным объёмом работ. Например, небольшая задача: собрать лендинг из нескольких экранов или разработать корпоративный сайт с понятной структурой. Или наоборот — крупный проект с жёсткими нормативами, от которых нельзя отступить: разработать ПО для контроля за безопасностью трубопровода в нефтяной компании. Здесь важно, чтобы работа шла точно по плану и было меньше рисков. Этот же случай относится к государственным и другим крупным тендерам.
При подаче заявки на грант тоже используют waterfall. Так грантодатель лучше видит, через какие этапы пройдет проект.
Подходит: для небольших проектов, крупных тендеров, грантов.
Agile — гибкие методологии разработки
Под этим термином здесь я объединяю все подходы к разработке, когда нет чёткого понимания, что именно должно получиться в результате. Например, когда вы разрабатываете продукт, на который ещё не проверен спрос.
Работа ведётся короткими спринтами, главным результатом которых является проверка продуктовых гипотез.
В подходе с гибкими методологиями не предполагается подготовка большого ТЗ. Небольшие кросс-функциональные команды несут ответственность за принятие решений на своём участке для достижения поставленной цели: грубо говоря, программист сам вправе решать, как запилить ту или иную функцию, чтобы получить необходимый бизнес-результат.
Подходит: для стартапов, проверки гипотезы на спрос.
Процесс работы разбивается на этапы, в рамках каждого проделывается полный цикл: проектирование — разработка — запуск — сбор обратной связи. Этапы более длинные, чем в agile, это может быть несколько недель или даже месяцев.
Подходит: для крупных проектов, в которых нет формальных ограничений по использованию водопада.
Читайте подробнее о бизнес-процессе управления разработкой.
Функции и роли в процессе создания ТЗ
В контексте проектирования и подготовки ТЗ можно приблизительно расписать функции и роли так:
- Установка цели и получение бизнес-результата от разработки — собственник / стейкхолдер / продукт оунер.
- Сбор требований, исследования и подготовка функциональной документации — бизнес-аналитик, менеджер проекта, исследователь.
- Проработка ux / ui — арт-директор, дизайн-команда.
- Выбор и описание технической архитектуры — техлид / техническая команда.
- Координация и управление проектом — если работа с подрядчиком, то менеджер должен быть и со стороны подрядчика (ведёт проект и организует работу команды исполнителей), и со стороны клиента (координирует процессы и получение необходимой информации на стороне заказчика); если команда inhouse — менеджер объединяет функции координации и управления проектом.
- Проработка плана тестирования — QA-лид.
В зависимости от проекта также может потребоваться участие маркетологов, UX-редакторов, копирайтеров для написания текстов. В данном контексте мы не будем рассматривать их работу.
Если вы предприниматель и решили поставить ТЗ на разработку, вам нужно определиться, будете ли вы брать на себя роль бизнес-аналитика или менеджера, арт-директора или технического тимлида, — а какие из задач проектирования делегируете.
Компоненты ТЗ
В разработке продуктов для наших клиентов мы используем водопадный или смешанный подход. Собираем детальные требования, описываем пользовательские сценарии, рисуем дизайн, готовим описание функций проекта и делаем техническую спецификацию. В результате получаем набор материалов, которые необходимы, чтобы передать проект в разработку программистам.
Весь процесс создания продукта разделён на два этапа:
В этой статье я буду понимать под ТЗ набор материалов, которые необходимы, чтобы передать проект на программирование frontend- и backend-разработчикам — то есть перейти от этапа 1 к этапу 2.
По сути, это все «артефакты», которые являются итогом первого этапа работ, — проектирования и дизайна. Это то, что необходимо, чтобы приступить к программированию и в результате запустить продукт.
Только по набору таких материалов можно сделать оценку программирования продукта, максимально приближённую к действительности (держим в уме, что любая оценка в разработке — имеет очень большой риск не быть реализованной в реальности).
- Первые 4 компонента — это бриф: общая информация, которая необходима для любого подхода к разработке.
- 5 и 6 компоненты необходимы, чтобы приступить к дизайну и написанию спецификации, после 6 шага можно сделать оценку трудозатрат по ним.
- После подготовки дизайна (7 шаг) и спецификации (8-10 шаг) можно сказать, что ТЗ готово для постановки задачи разработчикам.
Ниже я расскажу подробнее о каждом компоненте, а также дам готовые шаблоны в Notion с чеклистами для использования на практике.
Как пользоваться шаблоном
Когда начинаете новый проект, скопируйте шаблон с таблицей и последовательно заполняйте карточки компонентов ТЗ.
В шаблоне три поля и описание. «Тег» установлен для информации, «статус» — для отслеживания прогресса выполнения. В начале работы над карточкой меняйте статус на «в процессе»; заканчиваете — «готово»; когда содержание согласовано стейкхолдером — «согласовано».
Внутри карточек — перечень пунктов и вопросов. Ответы записывайте в этой же карточке под пунктами. Если материалов много, например объёмный конкурентный анализ в карточке 2, создавайте подстраницу.
Необязательно пользоваться всем, что написано в карточках — каждый проект уникален и не все инструменты актуальны для любого проекта.
И наоборот — для некоторых проектов указанной информации будет недостаточно: дополняйте и изменяйте состав материалов в зависимости от задачи.
В карточке 6 есть таблица с беклогом, её можно вынести вовне ТЗ, поскольку она будет использоваться дальше в ежедневной работе над проектом. В карточке 8 — ссылка на эту же таблицу с беклогом.
1. Цель и видение проекта
Цель реализации является объединяющим компонентом для всех участников проекта. Если чётко определена бизнес-цель, то лучше принимаются локальные решения, оптимальным образом находятся пути реализации.
Например, в стратегическом планировании распространена методология OKR:
Сначала формулируете цель, а потом раскладываете её на составные результаты.
Например, можно сформулировать такие цели и результаты для проекта запуска новой версии интернет-магазина:
Если у проекта несколько стейкхолдеров, зафиксируйте ожидания каждого.
В идеальном мире, если вы предприниматель или руководитель (бизнес-заказчик), то на этом этапе ваше участие в подготовке ТЗ заканчивается. Высший пилотаж делегирования — управление по бизнес-целям и показателям. Понятно, что в реальности такого не бывает: чаще всего заказчику также захочется взять на себя часть ролей дизайнера, бизнес-аналитика, а иногда и технического специалиста.
В зависимости от компетенций клиента, процессов в его компании и в команде подрядчиков, это может привести к разным результатам, но здесь я не буду на этом останавливаться, а расскажу об остальных компонентах ТЗ.
2. Бизнес-контекст
После определения общих целей необходимо погрузить исполнителей ТЗ в бизнес-контекст. Этого можно не делать, если вы точно знаете, что исполнителю нужно просто реализовать какую-то фичу. Если задача более обширная, то знакомство с бизнес-контекстом позволит исполнителям в процессе работы правильно расставить приоритеты и предлагать оптимальные решения.
Общие вопросы о бизнесе состоят из следующих блоков:
- Информация о компании и проекте
- Анализ конкурентов и аналогичных продуктов
- Стратегия привлечения пользователей (каналы продвижения)
Здесь же могут быть зафиксированы пожелания по верхнеуровневой структуре разделов и функций продукта — это необходимо, чтобы оценить трудозатраты по блокам работ, следующих после брифа.
3. Требования к дизайну
В данном случае под дизайном я подразумеваю то, как будет выглядеть интерфейс продукта. Чтобы дизайнерам лучше понимать, в какой стилистике работать и какие есть требования по визуальной реализации, заполняют бриф на дизайн.
Бриф состоит из подборки референсов, анализа конкурентов, а также ограничений по корпоративной стилистике, если они есть. В карточку прикрепляются файлы или ссылки с брендбуком, исходники логотипов в векторе и другие артефакты при необходимости.
4. Технические требования
В этом блоке фиксируется всё, что касается технологий и интеграций. Определяется технологический стек (языки, платформа и движок), требования к фронтенду (параметры вёрстки, совместимость с устройствами и браузерами), даются ссылки на документацию внешних систем, которые планируется подключить, определяется серверная архитектура.
После получения ответов на эти вопросы разработчикам становится понятно, с чем придётся работать с технологической точки зрения.
На этом этапе заканчивается этап брифа. Это четыре карточки, которые остаются неизменными на всех спринтах. Далее карточки могут изменяться по итерациям.
В заказной разработке этап брифа проводится до момента заключения договора на этапе предпродажной подготовки. После этого делается оценка стоимости и сроков на проектирование, дизайн и спецификацию.
5. Пользовательские сценарии и бизнес-процессы
На этом этапе фокус смещается в сторону пользователей. Для чего они будут использовать продукт? Какую ценность они от него получат? Как использование продукта встроено в общий контекст взаимодействия с бизнесом?
Для ответов на эти вопросы можно использовать несколько фреймворков и инструментов. Не все их обязательно применять на каждом проекте — зависит от сложности бизнес-процессов и необходимости погружать в них разработчиков.
Источниками информации для данного шага может также быть обратная связь от клиентов (отзывы, интервью, customer development) и статистика (логи, аналитика, продуктовые метрики).
Если продукт создаётся на стадии проработки идеи и требуется сформулировать потребности потенциальных пользователей, подойдёт фреймворк JTBD.
Подход помогает на высоком уровне абстракции сформулировать, к какому эмоциональному состоянию должен прийти пользователь продукта. Эта формулировка поможет направить команду на достижение цели, приблизит к пониманию, зачем вообще ведётся разработка.
CJM полезен, чтобы увидеть макро-контекст использования продукта в общих сценариях взаимодействия клиента с компанией.
- Определите макро-этапы клиентского взаимодействия.
- В рамках каждого этапа зафиксируйте точки касания с брендом и продуктом.
- Опишите реальные действия, которые осуществляют клиенты, проходя по точкам контакта, а также их мысли и ощущения: что они слышат, видят, чувствуют.
Подробное исследование и описание маршрутов нужно не всегда. Часто достаточно простого описания базовых пользовательских сценариев. Например для сайта клиники: «когда я как новый пациент хочу попасть на приём, я ожидаю возможность записаться онлайн».
Для визуализации многошаговых пользовательских сценариев можно использовать UML-диаграммы.
Из списка таких сценариев далее сформируется функциональные требования и структура страниц или разделов проекта.
Более детальная проработка бизнес-процессов может потребоваться, если разрабатывается нетиповой продукт. Например система автоматизации производства, которая затрагивает несколько уровней взаимодействия: интерфейс пользователя, интеграцию с внешними системами, физический уровень.
Для таких случаев подойдёт инструмент визуализации схемы бизнес-процессов по методологии BPMN.
6. Функциональные требования
После того, как определены бизнес-процессы и пользовательские сценарии, наступает время зафиксировать функции продукта, которые должны воплотить их в жизнь.
Функциональные требования — это описание того, какие функции, разделы, страницы должны быть у продукта.
Если есть панель администрирования, то здесь описываются её функции. Функции могут отличаться в зависимости от ролей пользователя и прав доступа, поэтому здесь также фиксируется перечень ролей.
Информационная архитектура — структура информационных сущностей, используемых на проекте. Например, для каталога товаров в интернет-магазине: какие параметры есть у каждого товара, как они отличаются в зависимости от категории, как товары связаны друг с другом и с категориями товаров.
Для гибкого управления разработкой рекомендую сгруппировать функциональные требования по разделам или страницам продукта в виде беклога на канбан-доске.
В каждой карточке беклога описываются функции, пользовательские сценарии и структура блоков данного экрана или страницы. После проработки интерфейса (7 шаг) эти же карточки дополняются описанием функциональности со скриншотами дизайна.
Если продукт нестандартный по UX, не имеет аналогов или требования к интерфейсам сложно формулируется в словах, уместно на этом же этапе создавать быстрые прототипы и варфреймы. В остальных случаях на моей практике схематичные прототипы интерфейса только вводили заказчика в заблуждение — итоговое впечатление всё равно создаётся на основе макетов дизайна. Это было уместно, когда не было современных инструментов для быстрой отрисовки дизайна типа Figma.
Варфрейм также может быть полезен, когда нужно до разработки протестировать пользовательское взаимодействие с интерфейсом (тогда лучше сделать его кликабельным): дать задачу и посмотреть, как её будут решать на прототипе.
По итогам этого блока можно определить итерации разработки, зафиксировать трудозатраты на дизайн и написание технической спецификации.
В смешанном подходе к разработке беклог можно разделить на спринты и подробно описать только первые 2-3 спринта, чтобы начать работу.
7. Интерфейс
По материалам, подготовленным к этому шагу, дизайнер может взять в работу задачу по отрисовке интерфейсов.
Для многостраничных сайтов и приложений обычно отрисовывается одна страница или несколько экранов, чтобы определиться со стилистикой. Возможна отрисовка нескольких вариантов дизайна в разных стилях, чтобы можно было выбрать.
После утверждения стиля отрисовываются остальные экраны во всех требуемых разрешениях. Готовятся 3D-рендеры и визуализация анимаций элементов интерфейса.
Результатом также должен быть UI-кит с отображением всех состояний всех функциональных элементов.
📱 В 2022 году 50% всего интернет-трафика приходится на мобильные телефоны, а 30% американцев используют для онлайн-шоппинга только их — поэтому при проектировании сайтов рекомендую использовать подход mobile first.
8. Функциональное описание
Этот компонент готовится после или вместе отрисовкой макетов дизайна интерфейса. Готовить описание могут бизнес-аналитик, менеджер и дизайнер.
В уже созданной таблице беклога, разбитой на разделы, добавляются скриншоты элементов интерфейса. Они сопровождаются описанием того, как эти элементы должны работать:
- куда должны вести ссылки,
- что будет происходить при взаимодействии с кнопками и другими активными элементами,
- откуда в областях с контентом появятся данные,
- какие функции на экране доступны с какими правами доступа.
В итоге получается функциональное описание, которое объясняет, как будет работать продукт с точки зрения интерфейса. Это даёт разработчикам понимание, что нужно делать, тестировщику — что нужно тестировать, а заказчику — что он получит в итоге.
Это описание становится спецификацией для frontend-разработчика.
В дополнение к текстовому описанию требований о функциональности я рекомендую записывать скринкасты — записи экрана с пояснениями.
9. Техническая спецификация
Описывается вся программная архитектура бэкенда и фронтенда, пишется техническая документация и методы API, фиксируется структура БД.
Если используется архитектура Single Page Application, то беклог нужно обогатить ссылками на методы API, которые используются в конкретной странице, и другими техническими нюансами.
Здесь же описывается архитектура DevOps (если применимо) и процесс релиза продукта на продакшн.
10. План тестирования и приёмки
Для приёмки работы программистов перед релизом требуется функциональное тестирование. Даже если программисты применяют test-driven подход к разработке (когда вначале пишут автотесты на продукт, а затем его программируют), всё равно нужно ручное тестирование функциональности.
Для передачи проекта на тестирование нужен план тестирования. На основе уже подготовленных компонентов из предыдущих шагов хороший тестировщик сможет составить план, поскольку все готовые материалы к текущему шагу полноценно отвечают на вопросы что, как и когда будет тестироваться.
Важно указать требования по устройствам, разрешениям и браузерам, на которых нужно проводить тестирование.
Эту карточку можно подготовить, если тестировать будут люди, не принимавшие участия в разработке.
Тестировщику необходимо подготовить площадки для тестирования, желательно с данными, максимально приближенными к реальности.
Здесь же описывается план приёмки работ.
Выводы: как поставить задачу программистам
- Неправильная проработка требований влечёт за собой большие риски и потери при разработке.
- Не для всех подходов к разработке необходимо писать большое подробное ТЗ: если в приоритете скорость запуска и непонятна итоговая функциональность продукта, используйте гибкий подход.
- Если вы не ограничены формальными требованиями по использованию водопадного подхода к разработке, то лучше не готовить большое ТЗ на все работы, а прорабатывать ТЗ на короткие этапы и запускаться чаще.
- Если вы заказчик, вы не пройдете все 10 шагов самостоятельно так, чтобы на выходе получился хороший продукт. Желательно оставаться в рамках своей роли, если есть такая возможность.
- Точная оценка разработки всё равно невозможна, но составление ТЗ приблизит понимание трудозатрат на программирование.
Подписаться на телеграм → @panfilovonline
Заказать разработку → panfilov.digital
Получить консультацию по управлению и запуску digital-проектов → consulting@panfilov.group