Почему кастомную разработку нельзя оценивать без scope review

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

Что нужно понять до оценки

Перед сметой мы собираем предварительные требования: бизнес-цель, роли пользователей, данные, интеграции, ограничения по срокам, критерии приемки и текущую инфраструктуру. После этого scope делится на три части: базовое, optional и client-specific.

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

Где помогает test slice

Если проект рискованный, мы предлагаем малый work slice: одну ограниченную задачу, staging, review и понятный результат. Клиент видит скорость, качество кода, коммуникацию и Git Flow до большого бюджета.

Что получает клиент

• компактную структуру требований вместо размытых обещаний;
• отдельный список интеграционных и data-risk зон;
• понимание, что можно делать этапами;
• решение: stages, T&M, pilot или отказ от большого проекта.

Это не замедляет старт. Наоборот, такой подход защищает бюджет и помогает быстрее перейти к работе, где обе стороны понимают scope.

Если у вас есть задача по кастомной разработке, начните со страницы веб-разработки WGP или посмотрите, как устроен наш процесс.