У друга был проект. Заказчик пришёл с «небольшой CRM для отдела продаж». На первой встрече набросали требования — получилось 47 пунктов. Бюджет был на 15, ну может на 20, если ужаться.

«Давайте всё сделаем, потом посмотрим» — говорит заказчик. Классика, за которой бессонные ночи, переработки, «а вы же обещали» и недовольный заказчик в конце. Пришлось торговаться.

Почему это задача аналитика

Разработчики не будут, менеджер хочет продать, заказчик хочет всё. Аналитик — единственный, кто видит картину целиком: что реально нужно, что «хотелось бы», и что «написали, потому что пришло в голову на встрече».

Просто записываешь требования и передаёшь дальше — ты секретарь, а не аналитик.

Как друг это сделал

Разложил по MoSCoW. Все 47 требований — по приоритету:

MoSCoW: 47 требований разложены на Must 12, Should 18, Could 11, Won't 6 — бюджета хватает примерно на 15
  • Must have — без этого система бесполезна (12);
  • Should have — важно, но можно запуститься без (18);
  • Could have — было бы круто (11);
  • Won't have — хотелки на будущее (6).

Привязал к боли. Пошёл не со списком, а с вопросом: «какую проблему решаем в первую очередь?» Оказалось — менеджеры теряют сделки, потому что забывают перезвонить. Вот это боль. Сразу 20 требований отвалились — они её не решали.

Показал trade-offs. Не «это не влезает в бюджет», а: «делаем интеграцию с телефонией сейчас — запуск через 4 месяца; откладываем на v2 — через 2 месяца уже работаем и собираем обратную связь». Заказчик сам выбрал быстрый запуск — это уже не ты режешь скоуп, это он принимает решение.

Зафиксировал письменно. «В MVP входит … В следующую версию … » плюс подпись. Теперь «а вы же обещали» не работает.

Что в итоге

Запустились через 2,5 месяца с 16 требованиями — проблема с потерянными сделками решена. Через полгода пришли за v2, и половину отложенного выкинули сами: не нужно. Сделали бы всё сразу — потратили бы втрое больше времени на фичи, которыми никто не пользуется.

Что забрать

  • Приоритизация — твоя работа, не заказчика. Он хочет всё; твоя задача — помочь выбрать.
  • Привязывай к боли: «это решает вашу проблему?» — главный вопрос.
  • Показывай trade-offs, а не говори «нет».
  • Фиксируй письменно — память ненадёжна, особенно на дедлайне.
MVP — это не «урезанная версия», это версия, которая решает главную проблему.