Почему я не называю фиксированную цену до discovery
Фраза «скажите фиксированную цену» звучит нормально.
Я сам как клиент хочу понимать бюджет до того, как начнётся работа. Особенно если речь про сайт, e-commerce или внутренний портал, где легко утонуть в деталях.
Но в кастомной разработке фиксированная цена до discovery часто означает не контроль бюджета, а лотерею.
Кто-то угадает. Кто-то заложит огромный запас. Кто-то назовёт приятную цифру, а потом начнёт спорить за каждую мелочь.
Я видел все три варианта.
Что обычно прячется за «просто сайтом»
На первом звонке проект может звучать коротко: новый frontend, каталог, личный кабинет, интеграция с CRM, немного SEO, форма заявки.
Потом открывается реальность:
- у каталога не один тип товара, а семь;
- остатки приезжают из 1C с задержкой и конфликтами;
- у менеджеров разные роли и права;
- старые URL нельзя потерять, потому что они кормят органику;
- поиск должен учитывать синонимы, опечатки и коммерческие приоритеты;
- приёмка зависит не от «страница открывается», а от десятков бизнес-сценариев.
Это не плохой клиент. Это нормальный production.
Проблема начинается, когда команда делает вид, что всё это уже известно, и продаёт точную цену по трем абзацам в брифе.
Как я предпочитаю считать
Сначала - короткий discovery.
Не на месяц. Не ради 80 страниц документа. Обычно достаточно собрать компактную структуру требований, которую может прочитать владелец продукта, CTO или founder.
Я смотрю на пять вещей:
- Scope. Что действительно входит в первую версию, а что приятно иметь позже.
- Data. Откуда приходят товары, цены, остатки, пользователи, заявки.
- Integrations. CRM, ERP, платежи, доставка, email, аналитика, поиск.
- Roles and workflows. Кто что делает в системе и где нельзя ошибиться.
- Acceptance criteria. Как мы поймём, что задача готова, а не просто «почти работает».
После этого можно отделить базовое от client-specific.
Например: карточка товара - базовая. А вот логика цены для B2B-клиента с индивидуальными скидками, остатками по складам и ограничениями по региону - уже не базовая.
Где fixed price всё-таки уместен
Фиксированная цена нормально работает там, где продуктовый формат уже упакован.
Например, есть понятный пакет, повторяемый scope, известные ограничения, заранее описанный результат. Тогда команда продаёт не догадку, а отработанный процесс.
В WGP так можно думать про продуктовые Frontbox-форматы: subscription, white-label или другой заранее собранный offer.
Но если речь про кастомный replatform, нестандартный e-commerce, интеграции, headless поверх Bitrix или личный кабинет с ролями - я не считаю честным называть финальную фиксированную цену до discovery.
Можно назвать hourly rate. Можно показать team capacity. Можно предложить маленький paid work slice, чтобы клиент увидел скорость, качество review, staging, Git Flow и коммуникацию.
Но обещать «всё под ключ за X» до карты рисков - это не прозрачность. Это продажа спокойствия в кредит.
Что это даёт клиенту
Нормальный discovery не удорожает проект. Он удешевляет ошибки.
Клиент раньше видит, где есть обязательный scope, где optional, а где фантазия, которую лучше не тащить в первый релиз.
Команда раньше видит интеграции, которые могут сломать сроки.
Обе стороны раньше понимают, можно ли начинать с пилота, Catalog Probe, архитектурного аудита или маленького production slice.
Мне нравится такая рамка, потому что она не требует верить в магию.
Есть требования. Есть риски. Есть проверяемый кусок работы.
А дальше уже можно говорить о скорости.
Если у вас на столе сейчас лежит предложение «переписать всё» или «сделать фикс за две недели», я бы начал не с цены. Я бы начал с карты scope и рисков.
Связанные материалы: как я объясняю headless клиенту через деньги и три разговора до старта проекта.
Если нужен спокойный pre-project разбор для e-commerce или сложного сайта, можно начать с WGP: описать задачу.