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

Классическая проблема B2B-компаний заключается в том, что они пытаются описывать в ТЗ дизайн кнопок, вместо того чтобы описывать потоки данных. Мы разберем анатомию правильного технического задания, которое защитит вас от недобросовестных подрядчиков и бесконечного срыва дедлайнов.

Архитектура данных вместо дизайна

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

Правильное ТЗ фокусируется на функциональных требованиях. Вы должны ответить на ключевые вопросы обмена данными:

  • Откуда сайт берет информацию о ценах и остатках? Из 1С, из МойСклад или через парсинг Excel-таблиц?
  • Как часто происходит синхронизация? Раз в сутки ночью или каждые 5 минут?
  • Если товар закончился на складе, что должен видеть клиент? Кнопку "Под заказ" или товар должен исчезать из выдачи?
  • Куда отправляется заявка с сайта? Просто на почту секретарю или сразу конвертируется в сделку в Битрикс24 с присвоением UTM-меток?
Практический B2B-сценарий:

Завод промышленного оборудования заказал разработку маркетплейса для своих дилеров. В ТЗ было написано: "Сделать синхронизацию каталога с ERP-системой".
Агентство сделало красивый портал, но каталог на 50 000 позиций "ложился" каждый раз, когда происходила полная выгрузка базы из ERP. Агентство заявило: "В ТЗ не было указано, что синхронизация должна быть инкрементальной (обновлять только изменившиеся товары). Сайт работает согласно договору".
Заказчику пришлось доплатить 1.5 млн рублей за переписывание бэкенда. Цена одной неточной формулировки в ТЗ.

Матрица ролей и доступов

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

Например: "Незарегистрированный пользователь" видит только РРЦ (рекомендованные розничные цены). "Дилер уровня Gold" после авторизации видит оптовые цены со скидкой 30%, может скачивать закрытые PDF-инструкции и формировать счета на оплату в один клик. "Менеджер компании" имеет доступ в админ-панель, может модерировать отзывы, но не имеет права удалять товары из базы. Чем детальнее прописана эта матрица, тем меньше сюрпризов будет на этапе тестирования.

Технические ограничения и SLA

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

Они включают в себя:

  • Нагрузку: Портал должен выдерживать 1000 одновременных подключений без падения скорости ответа сервера ниже 500 мс.
  • Безопасность: Все пароли должны хэшироваться, API-запросы должны требовать авторизации через JWT-токены, а формы обязаны иметь защиту от SQL-инъекций и XSS-атак.
  • Технологический стек: Если у вас в штате только Python-программисты, вы обязаны указать в ТЗ, что бэкенд должен быть написан на Django. Если вы этого не сделаете, подрядчик может написать код на PHP, и вы не сможете его поддерживать своими силами.

Критерии приемки (Acceptance Criteria)

Как вы поймете, что проект готов? "Сайт мне нравится" - это не критерий. В ТЗ должен быть железобетонный чек-лист приемки работ.

Например: сайт загружается в зеленой зоне Google PageSpeed (более 90 баллов). Сайт корректно отображается в последних версиях Chrome, Safari, Edge. Сайт проходит автоматизированное тестирование на критические уязвимости. Каталог корректно загружает 10 000 товаров из тестового XML-файла менее чем за 3 минуты. Только после выполнения этих объективных критериев подписывается акт приемки-передачи.

Резюме

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

Проектирование и разработка без рисков

LavrAgency начинает сложные B2B-проекты с этапа предпроектной аналитики. Мы сами пишем детальное техническое задание, проектируем архитектуру баз данных и прописываем интеграции с ERP-системами до написания первой строчки кода, гарантируя предсказуемый результат.

Узнать про разработку сайтов