Что происходит, когда мы говорим клиенту, что его бриф неверен (и почему делаем это всегда)

Стандартная процедура в разработке ПО — сказать «да». Когда компания присылает бриф, большинство студий соглашается со списком функций, называет сроки и начинает писать код. Лишь 29% программных проектов были признаны успешными, то есть завершены в срок, в рамках бюджета и с удовлетворительным результатом — Standish Group CHAOS Report, 2015.

В Webiland операционная модель построена на другом принципе: сначала исследование, потом код. На практике это означает, что мы регулярно смотрим на бриф потенциального клиента и говорим, что его допущения неверны, список функций преждевременен, а выбранный технологический стек не подходит под бизнес-цель.

Проблема студий, которые всегда соглашаются

Согласие с брифом без его проверки предполагает, что клиент безошибочно перевёл бизнес-задачу в техническую архитектуру. Это редко так даже у сильных технических команд.

Когда студия соглашается с непроверенным брифом, она обязуется не решить бизнес-задачу, а собрать конкретный набор функций. Если эти функции не принесут выручки и не привлекут пользователей, студия всё равно получит оплату. Финансовый риск целиком остаётся на клиенте.

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

Что на самом деле значит «бриф неверен»

Говоря клиенту, что его бриф неверен, мы указываем на один из трёх структурных изъянов:

Несоответствие объёма. Бриф требует монолитное приложение там, где лёгкое веб-приложение проверит рынок быстрее. Или наоборот: просит «простой MVP», но включает сложные интеграции с унаследованными ERP-системами, требующие месяцев инфраструктурной работы.

Техническая нереализуемость. Бриф диктует стек, который конфликтует с ключевыми требованиями продукта: требует кроссплатформенный фреймворк для приложения, которому нужна глубокая низколатентная интеграция с нативными аппаратными API.

Отсутствие этапа исследования. Бриф подробно описывает, что строить, но не определяет, зачем это нужно и как измеряется неудача. Без базовых метрик и целевых показателей инженеры не могут осознанно выбирать архитектурные компромиссы.

Разговор: прозрачность до обязательств

Сказать клиенту, что его бриф нуждается в принципиальной перестройке, требует определённой рамки разговора. Мы не отвергаем брифы, мы их аудируем.

На одной из консультаций корпоративный клиент принёс бриф на заказную CRM с нуля. Список функций был обширным и повторял крупные платформы. Вместо того чтобы оценить сборку, мы разобрали их процессы. Анализ показал, что корневая проблема не в отсутствии заказного ПО, а в разрозненности данных между тремя существующими платформами.

Разговор сместился с «сколько стоит построить CRM» на «как объединить ваши конвейеры данных». Итоговый проект сосредоточился на интеграциях через API и хранилище данных — решение обошлось дешевле предложенной заказной CRM и сняло реальное узкое место.

Почему возражения дают лучший результат

Клиенты, работающие со студиями, которые оспаривают их допущения, выигрывают в трёх вещах:

Меньше потерь капитала. Отсеивание ненужных функций до начала разработки сохраняет средства для маркетинга, привлечения пользователей и итераций после запуска. Эффективно построить не то — всё равно полная потеря капитала.

Точные сроки. Тщательно разобранный бриф даёт закалённую техническую спецификацию. Когда краевые случаи, ограничения сторонних API и сложности миграции данных описаны заранее, оценка сроков превращается из оптимистичной догадки в предсказуемый график.

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

Как оценить подход студии

Ответ студии на ваш бриф — самый точный индикатор того, как она поведёт себя в проекте. Если в течение 48 часов приходит коммерческое предложение без единого уточняющего вопроса о вашей стратегии привлечения, структурах данных или унаследованных ограничениях, вам оценили список функций, а не решение.

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