Решён
Как внутри команды устроить краш-тест идей?

Scrum Master Управление проектами
2.4k
6

Руковожу продуктовой командой из 9 человек. Столкнулся с проблемой: идеи обсуждаются формально, никто не критикует, все кивают, а потом проект тихо умирает через 3 месяца. Классический groupthink.

Пробовал:

  • Мозговые штурмы - превращаются в монолог самого громкого
  • Анонимные опросы - люди пишут "все ок" чтобы не палиться
  • Pre-mortem (представьте что проект провалился) - получаю общие фразы типа "не хватило ресурсов"

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

Стек: Notion, Miro, Slack. Команда распределенная, 3 часовых пояса.

UPDATE: Попробовал Red Team из первого ответа. Назначил двух самых тихих ребят "адвокатами дьявола" на последнем ревью фичи. Сработало лучше чем ожидал, они реально нашли дыру в юнит-экономике которую все остальные пропустили. Спасибо!
Решение
42
Участник • 1 ответ

Red Team / Blue Team. Формат из кибербезопасности, отлично ложится на продукт.

Суть: перед каждым ревью идеи разбиваешь команду на две группы. Blue Team (2-3 человека) защищает идею и готовит питч. Red Team (2-3 человека) получает задание УБИТЬ идею. Не покритиковать, а найти аргументы почему она гарантированно провалится.

Критическое отличие от pre-mortem: роль назначена формально. Человек не критикует от своего имени, он выполняет задание. Это снимает социальное давление. Ты не токсичный коллега, ты Red Team на этой неделе.

Практическая реализация для распределенной команды:

  1. В Notion создаешь шаблон "Краш-тест" с секциями: гипотеза, целевая метрика, ресурсы, риски
  2. Blue Team заполняет за 2 дня асинхронно
  3. Red Team получает 2 дня на подготовку контраргументов
  4. Синхронный созвон 45 минут: 15 мин питч, 20 мин атака, 10 мин вердикт
  5. Вердикт трехступенчатый: GO / PIVOT / KILL

Роли ротируются каждый спринт. Через 3-4 итерации люди привыкают и начинают критиковать конструктивно даже вне формата.

Аватар Scrum Master

Огонь, буду пробовать. Вопрос: что делать если в Red Team попадает человек который органически не может критиковать? Есть у меня пара таких.

Аватар Just Passing

Дай им чеклист вопросов: "Что будет если конверсия окажется в 3 раза ниже?", "Что если конкурент запустит аналог через месяц?", "Откуда цифра в прогнозе?". Не нужно критиковать, нужно задавать неудобные вопросы по списку.

26
Участник • 1 ответ

У нас в компании используем формат "Адвокат дьявола". Перед каждым крупным решением один человек назначается на роль оппонента. Обязан подготовить минимум 5 аргументов против.

Еще хороший прием: "Ставка деньгами". Каждому даешь условные 1000 баллов и он распределяет их между идеями. Если готов поставить 800 из 1000 на одну идею, значит веришь в нее. Если размазывает по 100 на все, значит ни во что не верит. Сразу видно реальную картину.

34
Участник • 1 ответ

Проблема не в формате, проблема в культуре. Если люди боятся критиковать, никакой фреймворк не поможет. Они будут играть в Red Team так же формально как играют в мозговой штурм.

Начни с себя. Когда ты последний раз публично признал что твоя идея была плохой? Когда последний раз поблагодарил человека за критику, а не просто покивал? Люди считывают реакцию руководителя мгновенно. Один раз нахмуришься после критики и все, следующие полгода будут кивать.

Почитай про psychological safety, Эми Эдмондсон. Пока не построишь безопасную среду, любые форматы это карго-культ.

19
Участник • 1 ответ

Попробуй async-формат "Silent Critique" в Miro. Выкладываешь идею на доску, каждый участник в течение суток клеит стикеры с вопросами и сомнениями. Анонимно. Без созвона.

Плюс для распределенной команды: не надо искать окно в 3 часовых поясах.

14
Участник • 1 ответ

А может не надо краш-тестить идеи? Может надо быстрее запускать и смотреть на цифры?

Серьезно, 9 человек обсуждают идею неделю, готовят Red Team, Blue Team, созвоны... За это время можно было собрать MVP и получить реальные данные от пользователей. Никакой внутренний краш-тест не заменит столкновения с реальностью.

Большинство стартапов умирают не от плохих идей, а от медленного исполнения.

7
Эксперт • 1 ответ

у нас в команде работает правило "10 причин почему это провалится"

перед любой новой фичей каждый должен написать в слак 10 причин провала, без обсуждения, просто список. потом смотрим на пересечения, если 4 из 5 человек написали одну и ту же причину значит это реальный риск

звучит тупо но реально работает, попробуй

Написать ответ

Премодерация гостей

Вы отвечаете как гость. Ваш ответ будет скрыт до проверки модератором. Чтобы ответ появился сразу и вы получали репутацию — войдите в аккаунт.

Будьте вежливы и соблюдайте правила платформы.