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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Писать их трудоемко. Например, для интернет-магазина объем технического задания с достаточной детализацией составляет от 70 до 150 страниц. Чтобы написать такой документ, требуется дней пять работы хорошего аналитика.

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

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

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

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

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

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