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