Как написать ТЗ на разработку сайта или приложения

Как написать ТЗ на разработку сайта или приложения

За два десятилетия работы в области IT-разработки мы убедились, что каждый воспринимает понятие технического задания по-своему:

• это может быть простой звонок программисту с просьбой «добавить новый раздел на сайт»,

• анкета, отправленная подрядчиком клиенту для заполнения,

• нарисованный на бумаге эскиз интерфейса сайта,

• документ с описанием пользовательских сценариев и их выполнением на сайте,

• обширная документация с техническими деталями работы программного продукта в соответствии со стандартами.

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

Эта область является основным направлением деятельности компании PROFI SOFT. За последние пять лет в нашем инструменте управления задачами было выполнено более 15 000 заданий общей продолжительностью почти 90 000 часов.

Мы разработали шаблон, который упрощает работу с требованиями к разработке, особенно если вы являетесь менеджером проекта или заказчиком. Этот шаблон можно применять независимо от используемой методологии, но с различным подходом, поэтому давайте рассмотрим различные методы разработки. Затем мы опишем роли и обязанности участников процесса, представим примеры и предоставим инструменты, которые помогут вам при создании технического задания.

Как написать техническое задание на разработку (план)

Почему важно правильно составить ТЗ

Правильное составление технического задания имеет важное значение по нескольким причинам. Ошибки, допущенные на этапе сбора требований, составляют от 40 до 50% всех дефектов, что может привести к необходимости переделки уже выполненной работы. Это в свою очередь может замедлить процесс разработки, а также привести к излишним расходам. По оценкам, от 30 до 50% общего бюджета разработки тратится на исправление ошибок и переделку в результате проблем с требованиями. Более того, ошибки в требованиях могут обойтись от 70 до 85% стоимости процесса переделки.

Исправление ошибок, обнаруженных уже после передачи продукта пользователю, обходится еще дороже. По мнению авторов книги «Разработка требований к программному обеспечению», это может обойтись в 21 раз дороже, чем исправление ошибок, выявленных на этапе проектирования.

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

Подходы к разработке
Waterfall (водопад)

Методика получила название «водопадный подход» благодаря тому, что на диаграмме Ганта шаги выполнения проекта располагаются один за другим сверху вниз, как последовательные стадии каскада. Waterfall считается «классическим» методом из-за того, что требования, определяющие ход работы на протяжении всего проекта, формулируются в самом начале и не изменяются в процессе.

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

При подаче заявки на грант также применяется метод водопада. Это позволяет грантодателю ясно представить, через какие этапы будет проходить проект.
Подходит: для небольших проектов, крупных тендеров, грантов.

Agile — гибкие методологии разработки

В данном контексте понятие объединяет различные подходы к разработке, где отсутствует четкое представление о конечном результате. Например, это может быть ситуация, когда создается продукт, спрос на который еще не исследован.

Работа в таких методологиях осуществляется через короткие спринты, основная цель которых - проверить гипотезы о продукте. Гибкий подход не требует подробного технического задания (ТЗ). Небольшие кросс-функциональные группы берут на себя ответственность за принятие решений, необходимых для достижения поставленной цели. Грубо говоря, программист сам выбирает способ реализации той или иной функциональности, чтобы достичь нужного бизнес-результата.
Подходит: для стартапов, проверки гипотезы на спрос.

Смешанный подход

Сочетает первые два подхода.

Задача разбивается на последовательные этапы, каждый из которых включает в себя полный цикл: проектирование, разработка, запуск и сбор обратной связи. Эти этапы имеют более продолжительную длительность по сравнению с методологиями Agile, и могут занимать несколько недель или даже месяцев.

Подходит: для крупных проектов, в которых нет формальных ограничений по использованию водопада.

Функции и роли в процессе создания ТЗ

В рамках проектирования и подготовки технического задания определение функций и ролей может быть примерно следующим:

Определение цели и достижение бизнес-результата от разработки - здесь включены собственник проекта, заинтересованные стороны (стейкхолдеры) и владелец продукта.

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

Проработка UX/UI дизайна - эта задача ложится на арт-директора и дизайн-команду.

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

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

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

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

Компоненты ТЗ

Для создания продуктов для клиентов мы применяем методологии водопадного или смешанного типа. Мы подробно собираем требования, описываем пользовательские сценарии, разрабатываем дизайн, создаем описание функционала проекта и подготавливаем техническую спецификацию. В итоге мы получаем набор материалов, необходимых для передачи проекта на стадию разработки программистам.

Весь процесс создания продукта можно разделить на два этапа:

Проектирование и дизайн.

Разработка и запуск.

В данной статье мы будем считать ТЗ набором материалов, необходимых для передачи проекта на программирование frontend- и backend-разработчикам, то есть для перехода от первого этапа ко второму. Эти материалы, по сути, являются «артефактами», полученными в результате работы на первом этапе – проектировании и дизайне. Они необходимы для начала программирования и последующего запуска продукта.

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

· Первые 4 компонента — это бриф: общая информация, которая необходима для любого подхода к разработке.

· 5 и 6 компоненты необходимы, чтобы приступить к дизайну и написанию спецификации, после 6 шага можно сделать оценку трудозатрат по ним.

· После подготовки дизайна (7 шаг) и спецификации (8-10 шаг) можно сказать, что ТЗ готово для постановки задачи разработчикам.

Ниже мы расскажем подробнее о каждом компоненте, а также дадим готовые шаблоны в Notion с чеклистами для использования на практике.

В данной статье мы определим ТЗ как набор материалов, необходимых для передачи проекта разработчикам frontend и backend, что позволит перейти с проектирования и дизайна (этап 1) к разработке и запуску (этап 2). Эти материалы, так называемые "артефакты", являются результатом первого этапа работ и суть того, что требуется для начала программирования и запуска продукта. Оценить стоимость программирования продукта с высокой степенью точности можно лишь на основе данного набора материалов, хотя стоит помнить, что любая оценка в области разработки несет риск неполноты реализации в реальной практике.

Как пользоваться шаблоном

Шаблон Notion с компонентами ТЗ на сайт или приложение

При начале работы над новым проектом, скопируйте шаблон с таблицей и заполните карточки компонентов ТЗ поочередно. В данном шаблоне присутствуют три основных поля и описание. Поле "Тег" служит для информации, а поле "Статус" для отслеживания прогресса выполнения задач. Начинайте работу над карточкой, устанавливая статус "в процессе", завершая — "готово", а после согласования со стейкхолдером — "согласовано".

Внутри каждой карточки содержится список пунктов и вопросов. Ответы на которые следует записывать в этой же карточке под соответствующими пунктами. В случае большого объема материалов, например, при проведении детального конкурентного анализа в карточке 2, создайте дополнительную страницу для удобства.

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

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

1. Цель и видение проекта

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

O (Objective) — Цель,

KR (Key Results) — Ключевые Результаты.

Сначала формулируется цель, а затем она декомпозируется на ключевые результаты.

Для проекта запуска новой версии интернет-магазина можно определить следующие цели и результаты:

Цель: поднять уровень онлайн-продаж

KR 1: Провести редизайн интернет-магазина.

KR 2: Достичь 10 000 продаж в месяц через полгода.

KR 3: Увеличить долю рынка с 2% до 5% за год.

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

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

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

2. Бизнес-контекст

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

Общие вопросы бизнеса включают в себя следующие аспекты:

Информация о компании и проекте

Анализ конкурентов и сопоставимых продуктов

Стратегия привлечения пользователей (каналы продвижения)

Здесь также можно зафиксировать предпочтения относительно структуры и функциональности продукта на высоком уровне — это необходимо для определения затрат времени и усилий на различные этапы работ после получения задания.

3. Требования к дизайну

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

4. Технические требования

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

После того как разработчики получают ответы на эти вопросы, им становится понятно, с какими технологиями им предстоит работать на этапе разработки.

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

В заказной разработке этап подготовки брифа проходит до заключения договора на этапе предпродажной подготовки. Затем производится оценка затрат и сроков на разработку, дизайн и спецификацию.

5. Пользовательские сценарии и бизнес-процессы

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

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

Дополнительными источниками информации для этого этапа могут служить обратная связь от клиентов (отзывы, интервью, customer development) и аналитические данные (логи, аналитика, продуктовые метрики).

Jobs-to-be-done

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

Customer Journey Map

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

1. Идентифицируйте ключевые этапы клиентского взаимодействия.

2. Для каждого этапа укажите моменты контакта с брендом и продуктом.

3. Опишите конкретные действия, которые выполняют клиенты на каждой точке контакта, а также их мысли и чувства: что они слышат, видят, ощущают.

Иногда нет необходимости проводить подробное исследование и описание всех маршрутов. Часто достаточно простого описания основных сценариев пользовательского взаимодействия. Например, для сайта клиники: "при посещении в качестве нового пациента я хочу записаться на прием через онлайн-сервис". Для визуализации многоэтапных пользовательских сценариев часто используют UML-диаграммы.

Из этих сценариев будут выведены функциональные требования и структура страниц или разделов проекта. Более глубокое изучение бизнес-процессов может потребоваться при разработке нетипичного продукта, например, системы автоматизации производства, которая включает несколько уровней взаимодействия: пользовательский интерфейс, интеграцию с внешними системами, физический уровень. Для таких случаев рекомендуется использовать инструмент визуализации схемы бизнес-процессов по методологии BPMN.

6. Функциональные требования

Если продукт имеет нетипичный пользовательский опыт, не имеет аналогов, или требования к интерфейсам сложны для формулирования словами, приемлемо на этом этапе разработать быстрые прототипы и варфреймы. В других случаях, по моему опыту, схематические прототипы интерфейса могли ввести заказчика в заблуждение — окончательное впечатление все равно формируется на основе дизайн-макетов. Это было актуально в то время, когда не было современных инструментов, например, Figma, для быстрой отрисовки дизайна.

Также, варфрейм может быть полезен, если необходимо предварительно протестировать пользовательское взаимодействие с интерфейсом (в таком случае лучше сделать его кликабельным): дать задачу и изучить, как ее решают на прототипе.

По итогам этого блока можно определить итерации разработки, зафиксировать трудозатраты на дизайн и написание технической спецификации.
В смешанном подходе к разработке беклог можно разделить на спринты и подробно описать только первые 2-3 спринта, чтобы начать работу

7. Интерфейс

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

После утверждения стиля, дизайнер приступает к отрисовке остальных экранов во всех необходимых разрешениях. Также готовятся 3D-рендеры и визуализации анимаций элементов интерфейса. Важным результатом этого этапа является создание UI-кита, в котором отображены все состояния всех функциональных элементов.

С учетом того, что в 2022 году 50% интернет-трафика приходится на мобильные устройства, и 30% американцев используют их исключительно для онлайн-шопинга, рекомендуется применять подход mobile first при проектировании веб-сайтов.

8. Функциональное описание

Этот компонент готовится после или вместе отрисовкой макетов дизайна интерфейса. Готовить описание могут бизнес-аналитик, менеджер и дизайнер.

В существующий таблицу бэклога, разделенную на разделы, вносятся скриншоты элементов интерфейса с подробным описанием их функционала:

• указывается назначение ссылок,

• описывается взаимодействие с кнопками и другими активными элементами,

• раскрывается источник данных в областях контента,

• определяются функции экрана в зависимости от уровня доступа.

В результате составляется детальное описание функциональности, которое поясняет, как будет взаимодействовать продукт через интерфейс. Эта информация помогает разработчикам понять, какие задачи необходимо выполнить, тестировщикам понять, что нужно протестировать, а заказчику представить, что он получит в результате. Это описание становится спецификацией для frontend-разработчика. Кроме того, помимо письменного описания требований к функциональности, рекомендуется создавать скринкасты — видеозаписи экрана с подробными пояснениями.

9. Техническая спецификация

Детально описывается архитектура как бэкенда, так и фронтенда, составляется техническая документация, описываются методы API, и определяется структура базы данных. В случае использования архитектуры Single Page Application, необходимо дополнить бэклог ссылками на методы API, которые используются на конкретной странице, а также учесть другие технические детали.

Здесь же описывается архитектура DevOps (если применимо) и процесс релиза продукта на продакшн.

10. План тестирования и приёмки

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

Для передачи проекта на тестирование требуется создать план тестирования. Исходя из предварительно подготовленных компонентов на предыдущих этапах, опытный тестировщик сможет разработать план, так как на каждом этапе уже имеются полные ответы на вопросы "что", "как" и "когда" будет тестироваться.

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

Тестировщику следует подготовить тестовые площадки с данными, наиболее приближенными к реальным, чтобы обеспечить максимально точное тестирование. Также в этом этапе описывается план приемки работ.

Выводы: как поставить задачу программистам

Недостаточная проработка требований может привести к серьезным рискам и потерям в процессе разработки.

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

Если у вас нет формальных требований к использованию каскадной модели разработки, целесообразно не разрабатывать обширное техническое задание на все этапы сразу, а сосредотачиваться на разработке ТЗ по коротким этапам и запускать процесс более часто.

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

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

PROFI SOFT