С чего начать и что учесть
Техническое задание на разработку интернет-магазина
Сибирикс

Техническое задание на разработку интернет-магазина

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

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

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

Что делать? Начинать с начала

Перспектива искать нестыковки в многостраничном документе не радует. Там более это не должно быть проблемой заказчика. Рекомендую начинать не с технического задания, а с предварительной аналитики. Проанализировать целевых пользователей и их пути по сайту, нарисовать диаграммы бизнес-процессов и спроектировать структуру сайта (для этого удобно использовать mindmap). Для ключевых страниц — разработать интерактивные прототипы. Чтобы можно было прокликать весь путь пользователя от входа на сайт до покупки и сразу увидеть, если какой-то шаг пропущен или что-то неудобно.

Второй момент — не стоит сразу писать техническое задание на все-все-все функции, которые вам хочется видеть на сайте. Лучше разбить проект на два контура. Сначала, MVP (или даже MLP — minimum lovable product): интернет-магазин с базовыми возможностями, с которыми можно запускаться. После — развитие проекта: все фишки и необязательные функции.

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

Все готово? Пишем ТЗ

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

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

Кстати, очевидные вроде бы вещи, которые не описаны в ТЗ, никому, кроме вас, не очевидны. И, скорее всего, в итоговый проект не попадут. И это не только в web-разработке.
Анна
Аккаунт-директор
В далеком 2014 году мы строили себе офис. Прихожу я на стройку, и вижу, что сантехники сверлят отверстиЕ (ОДНО) под трубы с водой. Начинаю выяснять — почему так. Говорят: «Только под холодную сказали делать». Звоню застройщику — уточнить, когда же под горячую будут сверлить. Выясняю, что по проекту горячая вода в здании не предусмотрена. В смысле совсем. Все коммуникации в договоре (считай, в ТЗ) значились одной строкой. МНЕ ЖЕ БЫЛО ОЧЕВИДНО, что они включают горячую воду. Пришлось вежливо удивиться. Горячую воду в здании в итоге подключили.
Что же надо учесть в техническом задании, кроме описания страниц, чтобы потом не было неожиданностей? По опыту, нужны следующие разделы:
1

Общие требования к реализации

  • Редакция CMS. Либо какой фреймворк и админ-панель к нему используем.
  • Требования к верстке — делаем ли адаптивную версию? Под какими браузерами и начиная с какой версии сайт должен работать.
  • Интеграция с внешними API — что именно подключаем: доставки, эквайринг, фискализация, sms-гейт, рекомендательные системы и т. д. Интеграция с ERP обычно описывается в отдельном документе — протоколе интеграции.
2
Базовая оптимизация:
  • SEO: уникальные классы, требования к ссылкам, редактирование мета-информации, настройка аналитики и т. д.
  • Оптимизация для публикации в социальных сетях.
  • Использование семантической разметки Schema.org.
3
Элементы дизайна: требования к формам, фильтрам и т. д. — чтобы не дорисовывать стейты ошибок или неактивные элементы на этапе программирования.
4
Настройка прав доступа — какие роли пользователей предусмотрены на сайте, что могут пользователи в каждой из ролей.
5
Общие блоки и сервисы — шапку сайта, футер, меню, хлебные крошки, формы — удобно описать в одном месте, чтобы не дублировать описания на каждой странице.
6
Уведомления — какие оповещения, кому, и при каких действиях пользователей приходят.

Как упростить задачу?

Для написания технического задания удобно пользоваться шаблонами. Так делает большинство студий. Многие модули на сайтах — типовые. Нет смысла описывать их каждый раз заново. Если есть шаблон — задача сводится к тому, чтобы сделать копию шаблона, удалить в ней лишнее, а после — описать структуру страниц (по дизайну или прототипам) и нестандартные вещи. Поэтому разработка технического задания на проект у студии займет значительно меньше времени, чем если заказчик будет писать ТЗ самостоятельно.

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

  • Это хардкод? Это написали программисты и никто кроме них это поменять не может?
  • Это включаемая область? Сюда любой пользователь с доступом в админку может писать что угодно, что только позволяет HTML?
  • Это выборка из базы данных?
    • Из какой сущности?
    • Из каких полей?
    • Это случайно не файл?
    • Надо ли при этом что-то считать? Если «да» — то это формула!
    • Кто эти данные сюда вносит? Админ? А ему на это хватит штатных возможностей админ-панели?
    • Импорт? Откуда? Со стороннего ресурса?
  • Это формула?
    • Какая? Да, ее надо написать.
    • Откуда берутся её коэффициенты?
  • Со стороннего ресурса
    • С какого?
    • По какому протоколу? Парсер? API? Добавляйте в ТЗ документацию.

А может вообще без ТЗ?

С техническими заданиями множество проблем:
Писать их трудоемко. Например, для интернет-магазина объем технического задания с достаточной детализацией составляет от 70 до 150 страниц. Чтобы написать такой документ, требуется дней пять работы хорошего аналитика.
Они моментально устаревают. С них чаще всего начинают разработку. Но требования в процессе всегда уточняются. У заказчика появляются пожелания, особенно — когда он видит дизайн. Как итог, на этапе дизайна техническое задание чаще всего уже не актуально. Надо или смириться с этим, или после каждого изменения актуализировать ТЗ. Закладывайте время и деньги.
Для разработчиков они либо слишком подробные, либо не полные. Либо и то и другое вместе. Часто компании проводят тендер на разработку ТЗ, чтобы потом по этому техническому заданию провести тендер на разработку сайта. Только чем подробнее описание задачи, тем больше времени надо, чтобы его понять, и тем больше в нем можно найти нестыковок. Как результат — разобраться в чужом техническом задании зачастую более трудоемко, чем написать свое с нуля.
Для заказчиков они слишком сложные. Чтобы просто прочитать ТЗ целиком, надо потратить часов пять-шесть. Поэтому заказчики часто читают технические задания по диагонали и подписывают не глядя, а потом получают неведому зверюшку вместо проекта, который ждёт начальство и акционеры.
Нужно ли вообще ТЗ — вопрос спорный. Оно позволяет получить относительно точную оценку проекта, но только если его оценивает та же компания, которая техническое задание писала. Позволяет заказчику прикрыть тылы, но только если не давать ему устаревать. С другой стороны, чем детальнее и больше ТЗ — тем быстрее оно устареет и тем больше в нем будет нестыковок.

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

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

Напоследок — все рекомендации в одном месте:

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