Как торговаться за скоуп и не стать врагом заказчика
Как торговаться за скоуп и не стать врагом заказчика
У друга был проект. Заказчик пришёл с "небольшой CRM для отдела продаж".
На первой встрече набросали требования. Получилось 47 пунктов. Друг такой: "Окей, а бюджет какой?"
Бюджет был на 15 пунктов. Может на 20, если сильно ужаться.
"Ну давайте всё сделаем, потом посмотрим" — говорит заказчик. Классика.
Друг уже видел, чем это заканчивается. Бессонные ночи, переработки, "а вы же обещали", и в конце — недовольный заказчик, которому "не совсем то сделали".
Пришлось торговаться.
Почему это вообще задача аналитика
Потому что разработчики не будут. Менеджер хочет продать. Заказчик хочет всё.
Аналитик — единственный, кто видит картину целиком: что реально нужно, что "хотелось бы", и что "написали, потому что пришло в голову на встрече".
Если ты просто записываешь требования и передаёшь дальше — ты секретарь, а не аналитик.
Как друг это сделал
Разбил на категории. Взял все 47 требований и разложил:
🔸 Must have — без этого система бесполезна (12 пунктов) 🔸 Should have — важно, но можно запуститься без (18 пунктов) 🔸 Could have — было бы круто (11 пунктов) 🔸 Won't have — хотелки на будущее (6 пунктов)
Это MoSCoW, если что. Но название не важно — важен принцип.
Привязал к боли. Пошёл к заказчику не со списком, а с вопросом:
"Какую проблему мы решаем в первую очередь?"
Оказалось — менеджеры теряют сделки, потому что забывают перезвонить. Вот это боль. Остальное — "ну было бы неплохо".
Сразу 20 требований отвалились. Они не решали эту проблему.
Показал trade-offs. Не "это не влезает в бюджет", а:
"Если делаем интеграцию с телефонией сейчас — запуск через 4 месяца. Если откладываем на вторую версию — через 2 месяца уже работаем и собираём обратную связь."
Заказчик сам выбрал быстрый запуск. Это уже не ты режешь скоуп — это он принимает решение.
Зафиксировал письменно. "По итогам обсуждения в MVP входит: ... В следующую версию планируем: ..."
Подпись заказчика. Теперь "а вы же обещали" не работает.
Что в итоге
Запустились через 2.5 месяца с 16 требованиями. Заказчик доволен — проблема с потерянными сделками решена.
Через полгода пришли за второй версией. Половину из отложенных требований выкинули сами — оказалось, не нужно.
Друг говорит: если бы сделали всё сразу, потратили бы в 3 раза больше времени на фичи, которые никто не использует.
Воть, выводы
🔸 Приоритизация — твоя работа, не заказчика. Он хочет всё. Твоя задача — помочь выбрать.
🔸 Привязывай к боли. "Это решает вашу проблему?" — главный вопрос.
🔸 Показывай trade-offs, а не говори "нет". Пусть заказчик сам выбирает.
🔸 Фиксируй письменно. Память — штука ненадёжная, особенно когда дедлайн горит.
🔸 MVP — это не "урезанная версия", это "версия, которая решает главную проблему".
Да не суть, но умение говорить "давайте это в следующей версии" — это не слабость. Это профессионализм.
А вы как торгуетесь за скоуп? Работает или заказчики давят?
@analyst_exe