Бриф, функциональное и техническое задание на разработку интернет-магазина: зачем составлять и как это правильно делать

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

1. Бриф, функциональное и техническое задание для интернет-магазина — в чем разница?
2. Как составить бриф на интернет-магазин
3. Как составить функциональное задание
4. Как составляется техническое задание для интернет-магазина
5. Выводы

Разработка интернет-магазина должна начинаться с последовательности шагов:

Бриф и ФЗ — это документы бизнеса, их готовит команда клиента. А ТЗ на основании брифа и функционального задания создают разработчики. Клиент просто не способен написать техзадание для интернет-магазина по стандартам разработки — из-за некомпетентности он упустит важные моменты.

Составление этих документов — не пустая трата времени. Только так можно получить адекватную смету, которая не увеличится в 2-3 раза в итоге написания ТЗ на разработку. Ответственный подход к составлению брифа и ФЗ застрахует вас от сюрпризов не только в плане стоимости, но и в плане сроков. Вы сэкономите время и деньги впоследствии, сразу получив нужный результат.

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

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

• Главная страница — опишите роль страницы, какой информационный контент и товарные блоки на ней будут. Например: меню, баннер с акциями, группы товаров.
  

• Поиск — опишите требования к поиску, где он будет расположен, он будет реализован штатными средствами CMS или необходимо подключить Sphinx.
  
• Каталог товаров или лендинги с товарными подборками — укажите, что планируете реализовать.
  
• Карточка товара — опишите, какая информация может в ней содержаться, укажите основные требования к карточке. Ранее подробно рассказывали про заполнение карточек товара для интернет-магазина.
  
• Корзина — укажите, будет ли реализована корзина, и какие специфические требования к ней предъявляются.
  
• Чекаут — опишите количество способов оплаты, доставки и географию доставки. Отразите специфику оформления заказа, если она есть.
  
• Типовые внутренние страницы — опишите, какие сервисные страницы планируете использовать, и какая информация на них будет.
  
• Вишлист «Избранное» — укажите, какие требования предъявляете к нему, если он будет реализован.
  
• Специфичные страницы — опишите, какие нестандартные страницы необходимы исходя из специфики бизнеса.
  
• Личный кабинет на сайте — если вы ориентированы на b2b-клиентов, перечислите функционал, который будет важен для вашей ЦА (выгрузка документов, быстрый заказ через, баланс контрагента, отчёты и так далее).
  

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

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

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

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

Два подхода к составлению функционального задания:

Функциональная роль — это то, что может делать пользователь на сайте. Главный пользователь в интернет-магазине, конечно, покупатель. Но можно прописать и другие функциональные роли (администратор, b2b-клиент и прочие), в зависимости от специфики бизнеса.

Чтобы учесть особенности каждой функциональной роли, используют метод пользовательских историй (user story) — тезисы, которые описывают функциональность от лица пользователя.

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

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

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

Пользователь может:

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

К сожалению, многим клиентам кажется, что они готовят полноценное техническое задание на разработку интернет-магазина. И когда у клиента во время знакомства со сметой возникает вопрос: «У нас же есть ТЗ, почему в смете вы закладываете на него время?», нам приходится объяснять разницу между функциональным и техническим заданиями.

Конечно, если техническое задание на разработку интернет-магазина в редакции заказчика достаточно детализированное, мы учитываем это и уменьшаем трудозатраты на написание ТЗ разработчиками, но такая детализация и соответствие общепринятым стандартам — большая редкость. Например, в ТЗ на создание интернет-магазина, составленных клиентами, точно не встретишь описания интеграций с 1С.

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

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

Стоимость создания интернет-магазина по брифу составляла 1 800 000 рублей, а после создания ФЗ увеличилась практически в 1,5 раза — до 3 000 000 рублей.

Сравнение предложений от подрядчиков только на основании брифа — классическая ошибка многих клиентов при организации тендера. Когда подрядчик выбран и техзадание на разработку уже написано, руководителю проекта на стороне клиента приходится краснеть и оправдываться, отвечая на вопрос руководства: «Почему бюджет на разработку сайта вырос в 2 раза от первоначально озвученной цены?».

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

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

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

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

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

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

В разделе перечисляем типы данных, используемых на сайте, а также сущности 1С-Битрикс и их значения, в которых хранятся данные сайта.

Здесь мы описываем функциональные элементы с использованием скриншотов из прототипа, логику работы и требования к реализации того или иного функционала.

Очевидно, что клиент не может составить качественное ТЗ на разработку интернет-магазина сам. Также очевидно, что подрядчикам для составления техзадания на разработку интернет-магазина нужны подробные ответы на вопросы о бизнесе, описанные в брифе, и функциональные требования к сайту, описанные в ФЗ. Понимание нюансов подготовки этих документов и готовность клиента вместе работать над проектом — залог того, что интернет-магазин будет удобным для пользователей и прибыльным для собственников. А чтобы убедиться в этом на 100%, проведите оценку юзабилити сайта.