Техническое задание на интернет-магазин: что проверить до тендера

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

Я была по обе стороны этого стола — и составляла ТЗ как заказчик, и разбирала чужие ТЗ, когда нужно было по ним считать сроки. Разница в качестве предложений между чётким и расплывчатым техническим заданием — это не 10–15%, а иногда разница в разы по срокам и бюджету. Причём не потому, что кто-то демпингует: агентства просто по-разному додумывают за вас то, что вы не указали явно.

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

Интеграции. «Интеграция с 1С» без деталей — не техническое требование, а тема для отдельного созвона. Какая конфигурация, какой объём каталога синхронизируется, в реальном времени или раз в сутки, кто пишет и поддерживает коннектор. Одно агентство прочитает это как выгрузку раз в сутки, другое заложит синхронизацию в реальном времени — и разница в архитектуре, а значит и в цене, будет огромной.

Похожая история с нагрузкой. «Высоконагруженный проект» одна команда воспримет как «выдержит акцию два раза в год», другая — как повод сразу закладывать отдельную инфраструктуру. Здесь помогают именно цифры: текущий трафик, пиковые часы, ожидаемый рост за год — а не прилагательные.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13735 тендеров
проведено за восемь лет работы нашего сайта.

Дальше — граница результата. Что вы называете готовым проектом: минимальный запуск или полный функционал? Условный пример: без этого разграничения одна команда может оценить MVP в два месяца, другая — полную версию в шесть, и это будут два разных предложения по одному и тому же документу, хотя формально оба «ответили на ваше ТЗ».

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

Отдельно — поддержка после запуска: срок и объём. Без этого пункта торг начинается заново после сдачи проекта — что уже входит в гарантию, а что новая задача с отдельным счётом.

И последнее, но не менее важное — критерии приёмки. Не «по согласованию сторон», а конкретный список: скорость загрузки, поведение интеграций под нагрузкой, корректность расчёта доставки. Без этого списка приёмка легко превращается в бесконечный раунд правок, потому что у заказчика и подрядчика в голове разные версии слова «готово».

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

Итог

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