подписка
Подписаться
Анна Кожевина
Аккаунт-директор, Scrum-студия "Сибирикс"
17/11/2021
Как правильно составить техническое задание на разработку интернет-магазина

Как ничего не упустить при подготовке техзадания? Как все правильно и удобно оформить? Можно ли вообще обойтись без ТЗ? Рассказывает аккаунт-директор scrum-студии Сибирикс Анна Кожевина.

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

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

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

С чего начать?

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

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

17

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

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

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

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

Кстати, очевидные вроде бы вещи, которые не описаны в ТЗ, никому, кроме вас, не очевидны.  И, скорее всего, в итоговый проект не попадут. И это не только в web-разработке. 

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

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

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

  • Редакция CMS. Либо какой фреймворк  и админ-панель к нему используем. 
  • Требования к верстке – делаем ли адаптивную версию? Под какими браузерами и начиная с какой версии сайт должен работать.
  • Интеграция с внешними API – что именно подключаем: доставки, эквайринг, фискализация, sms-гейт, рекомендательные системы и т.д. Интеграция с ERP обычно описывается в отдельном документе – протоколе интеграции.

2. Базовая оптимизация

  • SEO: уникальные классы, требования к ссылкам, редактирование мета-информации, настройка аналитики и т.д.
  • Оптимизация для публикации в социальных сетях.
  • Использование семантической разметки Schema.org.

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

4. Настройка прав доступа. Какие роли пользователей предусмотрены на сайте. Что могут пользователи в каждой из ролей.

5. Общие блоки и сервисы. Шапку сайта, футер, меню, хлебные крошки, формы – все желательно описать в одном месте, чтобы не дублировать описания на каждой странице.

6. Уведомления. Какие оповещения, кому, и при каких действиях пользователей приходят.  

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

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

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

Screenshot_17

Кроме того, готовый документ надо проверить на отсутствие явных "дыр". По сути – везде ответить на вопрос "Откуда это берется на странице?". Вариантов не так много:

1. Это хардкод? Это написали программисты и никто кроме них это поменять не может?

2. Это включаемая область? Сюда любой пользователь с доступом в админку может писать что угодно, что только позволяет HTML?

3. Это выборка из базы данных?

  • Из какой сущности?
  • Из каких полей?
  • Это случайно не файл?
  • Надо ли при этом что-то считать? Если "да" — то это формула!
  • Кто эти данные сюда вносит? Админ? А ему на это хватит штатных возможностей админ-панели?
  • Импорт? Откуда? Со стороннего ресурса?

4. Это формула?

  • Какая? Да, ее надо написать.
  • Откуда берутся ее коэффициенты?

5. Со стороннего ресурса? 

  • С какого?
  • По какому протоколу? Парсер? API? Добавляйте в ТЗ документацию.

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

С техническими заданиями множество проблем:

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

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

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

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

Основные рекомендации в одном месте

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

2. Делегируйте написание подробного технического задания компании-разработчику интернет-магазина. Не менять коней на переправе. Если сменить команду после написания ТЗ – будет ниже вовлеченность и, скорее всего, ТЗ будет переписываться. Это окажется в смете, хотя может и не явно, а вы оплатите разработку технического задания повторно.

3. Начинайте писать техническое задание как можно позже, в идеале – после согласования дизайна. Так есть шанс, что к этапу программирования оно не устареет.

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

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

Прокомментировать
Читайте также
19/11/2021
Alibaba очень эффективно вложил еще полмиллиарда в российскую логистику 1
Удивляет не сумма, удивляет скорость реализации проекта: новый логистический комплекс в Домодедово китайцы построили за 5 месяцев. Рассказываем, сколько там квадратных метров, сотрудников и ежедневно отгружаемых посылок... Подробнее
10/11/2021
Илья Красильщик ушел с поста главы "Яндекс.Лавки". Его сменит Дмитрий Масюк
Рассказываем, чем и где теперь будет заниматься Илья. Ну и это не единственная значимая кадровая перестановка в компании. Там еще и в Яндекс.Еде новый директор... Подробнее
10/03/2021
8 советов, которые помогут интернет-магазинам продвигаться в 2021 году
Каждый год несет в себе какие-то изменения для интернет-бизнеса, к которым надо быть готовым. Новые тренды в маркетинге, серьезные конкуренты, новые рекламные площадки — все это влияет на работу онлайн-бизнеса. Рассказываем, как продвигаться в 2021 году интернет-магазинам... Подробнее
Петр Чернышев
CEO, FriFlex
04/02/2021
Мобильное приложение для интернет-магазина: нужно ли оно, какой функционал, сколько стоит 1
Российские и мировые ритейлеры отмечают рост продаж в мобильных каналах. Кому нужно разрабатывать мобильные приложения, чем это может быть полезно и ритейлеру, и его аудитории... Подробнее
Антон Макаров
Руководитель диджитал-продакшена, Creonit
14/01/2021
Когда нужно выбрать фреймворк вместо готового CMS при создании интернет-магазина
Чем фреймворк отличается от CMS-конструкторов и каким интернет-магазинам он подходит... Подробнее