У друга был проект. Заказчик пришёл с запросом: "небольшой 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