Количество страниц удобно посчитать, поэтому за него часто цепляются в начале разговора. Но страница — это контейнер. Реальный объём появляется внутри: в логике, состояниях, данных и исключениях.
Страница — плохая единица сложности
Представьте два проекта. Первый — корпоративный сайт на пятьдесят информационных страниц. Контент различается, но шаблоны повторяются: заголовок, текст, изображение, документы, форма контакта. Второй — личный кабинет на шесть экранов. В нём есть регистрация, четыре роли, статусы заказов, история действий, уведомления и интеграция с учётной системой.
Формально второй проект меньше. Технически он сложнее: каждое действие меняет состояние системы, зависит от прав пользователя и должно корректно отработать при ошибке. Поэтому вопрос «сколько будет страниц?» полезен для контентной архитектуры, но почти ничего не говорит о трудоёмкости продукта.
Шесть факторов реальной оценки
1. Пользовательские сценарии
«Оставить заявку» и «собрать заказ из нескольких позиций, согласовать его и получить документы» могут выглядеть как одна кнопка, но за ними разный объём. Для оценки нужны основные маршруты: кто приходит, что хочет получить и какие шаги проходит.
2. Роли и права доступа
Один посетитель читает одинаковый контент. В B2B‑кабинете менеджер, клиент, бухгалтер и администратор видят разные данные и могут выполнять разные действия. Каждая роль добавляет правила, состояния и тестовые сценарии.
3. Данные и их качество
Если каталог уже структурирован и доступен через API, это одна ситуация. Если характеристики хранятся в таблицах с разными названиями, сначала потребуется нормализация, правила импорта и обработка ошибок.
4. Интеграции
CRM, ERP, платёжный сервис, доставка и корпоративная авторизация — это не просто «подключить API». Нужно согласовать формат данных, безопасность, очередность операций и поведение системы, когда внешний сервис недоступен.
5. Контент и редакторские процессы
Кто готовит тексты? Нужны ли миграция, несколько языков, согласование публикаций и разграничение прав редакторов? Контент влияет на архитектуру и запуск не меньше кода.
6. Нефункциональные требования
Нагрузка, доступность, безопасность, журналирование, резервное копирование и требования инфраструктуры редко видны на макете. Но именно они отличают демонстрацию от продукта, на который можно опереться в работе.
Три уровня, которые выглядят как «сайт»
Ни один уровень не «лучше» другого. Ошибка начинается, когда бизнесу нужен третий, а бюджет и ожидания формируются как для первого. Хорошая предварительная оценка не обязана сразу называть финальную сумму. Её задача — правильно определить класс продукта и главные источники неопределённости.
Что подготовить для первого разговора
Подробное техническое задание не требуется. Полезнее коротко описать контекст, в котором должен работать продукт:
- какую бизнес‑ситуацию нужно изменить;
- кто будет пользоваться продуктом и зачем;
- какие действия пользователь должен выполнить;
- где сейчас находятся данные;
- с какими системами нужно связаться;
- что обязательно должно войти в первый запуск;
- какой результат покажет, что решение работает.
Если ответов пока нет, проект можно начать с исследования. Это не задержка перед разработкой, а способ не кодировать предположения как дорогостоящую функциональность.
Как сравнивать предложения
Сравнивайте не только итоговую цифру. Посмотрите, одинаково ли команды поняли задачу и включили ли в оценку исследование, дизайн состояний, подготовку данных, интеграции, тестирование, запуск и поддержку. Два предложения могут называться одинаково, но покрывать совершенно разный объём ответственности.
Полезный документ оценки показывает границы: что входит, что не входит, какие предположения сделаны и что способно изменить срок или бюджет. Такая прозрачность важнее преждевременной точности.
В LIDBOX веб‑проекты начинаются с разбора сценариев и архитектуры. Посмотреть, как устроен этот подход, можно на странице разработки сайтов и веб‑сервисов.