Методы решения проблем и генерации идей: от мозгового штурма к brainswarming и 5 почему

Обычный разбор проблемы в IT выглядит так: собрали шесть человек в переговорке, кто-то сказал «а давайте поставим Kafka», остальные час обсуждали Kafka, разошлись с задачей «изучить Kafka». Ошибка тут не в Kafka, а в том, что группа перескочила два шага: не сформулировала проблему и не сгенерировала альтернативы. Эта глава — о том, как устроены оба шага и почему самый популярный инструмент для второго (мозговой штурм) работает хуже, чем те же люди, думающие поодиночке. Порядок изложения не случаен: сначала рамка «проблема → причины → идеи → выбор», потом инструменты под каждый этап. Инструмент без рамки бесполезен — «пять почему», применённые к неверно поставленной проблеме, дадут пять неверных ответов быстрее, чем без них.

1. Рамка: сначала проблема, потом идеи

Основной закон этой области сформулирован Британским советом по дизайну как «двойной алмаз» (Design Council, Framework for Innovation): работа состоит из четырёх фаз, а не из двух, и расширение происходит дважды — сначала расширяется понимание проблемы, потом множество решений.

Второй алмаз (идеи и выбор) знаком всем — именно про него говорят «давайте побрейнштормим». Первый алмаз почти всегда пропускают, и это главная причина, по которой хорошо проведённая сессия генерации даёт никому не нужный результат. Три правила рамки: дивергенция и конвергенция не смешиваются во времени (критика на расширении убивает идеи, расширение на сужении не даёт закончить — это единственное правило, ради которого нужен фасилитатор); между расширением и сужением есть третий шаг, группировка (сорок стикеров нельзя оценивать поштучно, сначала их сводят в 6–8 тем); пунктирные стрелки на схеме — норма, а не провал (обнаружить на этапе выбора, что проблема сформулирована неверно, — удача: дальше цена ошибки растёт на порядок).

2. Формулировка проблемы

Problem statement — короткий текст, который отвечает на четыре вопроса: что происходит, у кого, как это измерено и почему это плохо. У него есть жёсткое свойство: в нём не должно быть решения. «Нам нужен Kafka» — не проблема, а решение, замаскированное под проблему; из него нельзя вывести критерий успеха и с ним нельзя сравнивать альтернативы, потому что альтернатив в формулировке нет.

Полезное различение, без которого разбор буксует:

Быстрая структура для сбора фактов — 5W2H: What (что именно происходит), Where (где: сервис, регион, экран), When (когда началось, с какой периодичностью), Who (кого затрагивает и сколько их), Why (почему это важно бизнесу), How (как проявляется, как воспроизводится), How much (сколько это стоит в деньгах, часах, оттоке). Последний пункт пропускают чаще всего, а он определяет, стоит ли вообще собирать людей: проблема без цены не приоритизируется и не выбирается против других проблем.

# Problem statement: сборка перед релизом

Что: сборка релизной ветки падает или требует ручного перезапуска.
Где: CI-пайплайн `release-*`, шаг интеграционных тестов.
Когда: с 3 февраля, 11 из 26 запусков (42%), без явной привязки к содержанию коммита.
Кто: 4 команды, релизный инженер; блокирует релизный поезд по вторникам.
Сколько стоит: в среднем 2,5 часа задержки релиза и ~6 человеко-часов разбора в неделю.
Почему важно: релиз сдвигается на день, срочные исправления уходят мимо пайплайна.

Как поймём, что решено: доля успешных запусков release-* с первого раза > 95%
на горизонте 4 недель; ручных перезапусков — ноль.

Вне рамок: скорость сборки, покрытие тестами, миграция на другой CI.

Последняя строка — то, что отличает работающую формулировку от бесполезной. Без явного «вне рамок» обсуждение за десять минут уедет в «а давайте вообще переедем на другой CI».

3. Анализ причин: от «пяти почему» до дерева отказов

«Пять почему»

Метод Toyota (Тайити Оно): задавать вопрос «почему?» к каждому предыдущему ответу, пока не дойдёшь до причины, устранение которой предотвращает повторение (Lean Lexicon: 5 Whys). Пример:

1. Релиз упал → почему? Интеграционные тесты не прошли.
2. Почему? Тест ждал ответа от заглушки платежей 5 секунд, а получил 12.
3. Почему? Заглушка поднимается в том же поде, что и тесты, и конкурирует за CPU.
4. Почему? Лимиты пода не менялись с момента, когда тестов было втрое меньше.
5. Почему? Нет процесса, при котором рост числа тестов приводит к пересмотру ресурсов CI.

Критика, которую обязательно нужно держать в голове:

• Единственная цепочка. Реальный отказ почти всегда имеет несколько сходящихся причин; метод даёт одну линию и создаёт ложную уверенность. Противоядие — Исикава или дерево отказов до «почему».
• Зависимость от ведущего. Цепочка идёт туда, куда её ведёт задающий вопросы; два фасилитатора получают два разных «корня», и метод оказывается плохо воспроизводимым.
• Остановка на человеке. Самая частая и вредная поломка: цепочка упирается в «разработчик не проверил» и там заканчивается. Правило: если ответ — фамилия, «почему» задано не до конца; дальше идут вопросы «почему систему можно было сломать таким образом» и «почему это не обнаружилось автоматически». И глубина произвольна: пять — красивое число, а не свойство мира.

Диаграмма Исикавы

Каору Исикава предложил раскладывать причины по категориям, чтобы группа не застревала в первой найденной. Классические 6M: Man (люди), Machine (оборудование и инфраструктура), Method (процесс), Material (материалы, в IT — данные и зависимости), Measurement (измерения и мониторинг), Milieu / Mother Nature (среда и внешние условия).

Главная польза не в самой картинке, а в пустых ветвях: если в категории «Измерения» нет ни одной гипотезы, это почти всегда значит, что зону никто не проверял, а не что там всё хорошо. Диаграмма ничего не доказывает — она не даёт остановиться на первой правдоподобной причине, после чего каждую ветвь проверяют фактом (лог, метрика, эксперимент).

Дерево отказов, Парето, A3 и PDCA

Дерево отказов (FTA) идёт сверху вниз от нежелательного события и раскладывает его через логические вентили И/ИЛИ (NRC Fault Tree Handbook, NUREG-0492). Ключевое отличие от Исикавы: FTA различает «нужно, чтобы совпало A И B» и «достаточно A ИЛИ B», а значит, позволяет находить минимальные наборы отсечений — самые дешёвые места, где цепочку можно разорвать. Для распределённых систем это часто честнее «пяти почему»: отказы там обычно комбинационные.

Диаграмма Парето (принцип Вильфредо Парето, введён в качество Джозефом Джураном) — столбцы по частоте или стоимости причин по убыванию плюс кумулятивная кривая: выбрать две-три причины, дающие большую часть боли, вместо равномерного распределения усилий по десяти.

A3-мышление — практика Toyota укладывать весь разбор на один лист формата A3: контекст, текущее состояние, цель, анализ причин, контрмеры, план, проверка; ограничение по размеру работает как фильтр качества мышления (Shook, «Managing to Learn»). Сам цикл проверки — PDCA (Plan-Do-Check-Act): контрмера считается не «внедрённой», а проверенной, и без шага Check разбор превращается в список благих намерений. Оба инструмента — часть Lean-традиции (Lean).

4. Почему классический мозговой штурм проигрывает

Мозговой штурм (brainstorming) — самый популярный метод генерации идей: оперативный способ решения задачи, основанный на стимулировании творческой активности участников, которым предлагают высказывать как можно больше идей. Правила Алекса Осборна (1953) известны: не критиковать, приветствовать необычное, гнаться за количеством, комбинировать чужие идеи. Практические недостатки известны не так хорошо:

• Риск зацепиться за одну идею и зациклиться на ней. Группа идёт по первой предложенной колее.
• Экстраверты доминируют над интровертами в ходе группового обсуждения.
• Социальное давление: закрытые люди стесняются высказать оригинальную идею.
• У опытных участников продуктивность падает рядом с менее опытными — эффект, известный в спорте: тренируясь с кем-то менее умелым, вы опускаетесь до его уровня.

Получается, что некоторые говорят очень мало, а другие за счёт этого слишком много, и полезный выхлоп на участника оказывается низким. Это не только наблюдение практиков. Начиная с эксперимента Тейлора, Берри и Блока (1958) исследования устойчиво показывают: номинальные группы (люди генерируют идеи порознь, потом результаты сводят) дают больше идей и идей лучшего качества, чем реальные группы того же размера. Дитер Диль и Вольфганг Штрёбе в работе «Productivity loss in brainstorming groups» (JPSP, 1987) экспериментально отсекли объяснения «боязнь оценки» и «социальное иждивенчество» и показали, что основной вклад даёт производственная блокировка (production blocking): в один момент времени говорит один человек, остальные вынуждены удерживать идею в памяти, слушать и ждать — и в этом ожидании идея теряется или обесценивается. Мета-анализ Маллена, Джонсона и Саласа (BASP, 1991) подтвердил вывод на двух десятках исследований и добавил деталь: потеря растёт с размером группы. В типичных экспериментах реальные группы из четырёх-шести человек производили примерно вдвое меньше уникальных идей, чем номинальные того же размера.

Честности ради — три оговорки. Эксперименты обычно измеряют количество идей на искусственных задачах, а не ценность решения реальной проблемы. У группового обсуждения есть эффекты, которых нет у одиночной работы: общий контекст, согласие с результатом, обучение участников. И разница почти исчезает, если убрать блокировку, — что и делают все методы ниже. Практический вывод поэтому мягче лозунга «брейншторм не работает»:

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

5. Brainswarming

Альтернативу предложил Тони МакКафри, один из основателей Innovation Accelerator. В основе гипотеза: люди продуктивнее, когда работают в одиночестве, а интроверты зачастую креативнее экстравертов; но без коммуникации и координации командной работы не выстроить — нужен баланс. МакКафри задался вопросом: зачем вообще озвучивать мысли вслух? — и предложил строить общий артефакт молча.

Механика. Нужна большая стена или доска, стикеры и маркеры. На доске рисуется граф: вверху цель — задача, решение которой ищут; пространство делится на две части. Сверху вниз растут варианты действий (цель дробится на подцели и способы), снизу вверх — имеющиеся ресурсы и их свойства. Участники молча пишут идеи на стикеры и вешают в подходящее место графа. Решение возникает там, где ветви встречаются: нисходящая ветвь «нужно ускорить чтение» смыкается с восходящей «есть незанятая реплика».

Пунктирные связи — самое ценное в методе: идея «сверять только крупные расхождения» не была бы выдвинута как абстрактное предложение, но становится очевидной, когда рядом висит факт «93% расхождений меньше 0,5%». Почему это работает:

• Две зоны для разных типов мышления. Кому-то проще решать проблему сверху, глобально; кому-то — оттолкнуться от имеющихся ресурсов. Обе стратегии легальны и не мешают друг другу.
• Тишина уравнивает психотипы: высказаться может каждый независимо от того, насколько он громкий.
• Индивидуальная работа объединяется с командной: пишут поодиночке, строят общий артефакт, и структура графа делает чужой вклад видимым и пригодным для развития — идеи строятся на чужих идеях.
• Нет жёсткого таймбокса. Никто не заперт в кабинете «до результата»: доска может собирать идеи несколько дней, и идеям дают созреть. Электронные доски (Miro, FigJam и подобные) работают так же, а асинхронность делают естественной.

Ограничения тоже стоит назвать: граф требует уже сформулированной цели (то есть пройденного первого алмаза) и плохо работает, когда участники не знают ресурсов системы, — нижняя половина остаётся пустой, и метод вырождается в обычный список идей.

6. Brainwriting 6-3-5 и Note and Vote

Brainwriting 6-3-5 разработал в 1960-х немецкий профессор Бернд Рорбах: 6 участников, 3 идеи на человека, 5 минут на раунд. Каждый молча пишет три идеи на своём листе, затем листы передаются по кругу; получив чужой лист, участник может использовать записанное как основу для новой идеи, развить чужую мысль или просто передать дальше. Раундов шесть — за полчаса получается 108 идей. Дубли и мусор среди них будут, но блокировки нет вовсе: все пишут одновременно.

Раунды 4–5 обычно считают провальными («идеи кончились»), и именно там появляется самое интересное: очевидное исчерпано, и участники вынуждены комбинировать. Резать сессию до трёх раундов — частая ошибка.

Note and Vote — быстрый метод, которым часто пользуются в Google Ventures (GV Sprint). Каждый участник 10 минут молча записывает как можно больше идей; затем 2 минуты выбирает пару лучших из своего списка; выбранные идеи выносятся на общую доску, и в конце участники голосуют. Метод укладывается в двадцать минут и вставляется в любую встречу как блок, а не как отдельное мероприятие.

7. Карта остальных методов

• NGT (номинальная групповая техника) Делбека и Ван де Вена: молчаливая генерация → круговой сбор по одной идее от каждого без обсуждения → уточняющие вопросы → индивидуальное ранжирование (статья 1971 года). Это буквально «номинальная группа» из экспериментов, оформленная как процедура.
• Crazy 8s и Design Sprint Джейка Кнаппа (thesprintbook.com): лист складывается на восемь частей, восемь минут — восемь эскизов, по минуте на каждый. Приём про то же: жёсткий таймбокс на человека вместо общего обсуждения.
• SCAMPER (Боб Эберле) — глаголы-провокации к существующему решению: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse. Полезен, когда идей нет вовсе: даёт не идеи, а операции над тем, что уже есть.
• Шесть шляп мышления Эдварда де Боно (debono.com): вся группа одновременно надевает одну «шляпу» — факты, эмоции, критика, польза, идеи, процесс. Ценность в том, что критика не запрещается, а переносится в отдельный таймбокс, где обязательна для всех.
• Инверсия: вместо «как решить проблему» спрашиваем «как гарантированно её усугубить». Список «как сделать релизы ещё более хрупкими» пишется легко и весело, а потом переворачивается.
• Pre-mortem Гэри Клейна (HBR, 2007): группе говорят, что проект уже провалился через год, и просят написать историю провала. Приём снимает главный барьер — социальную неловкость называть риски вслух: гипотетический провал обсуждать безопасно, и проспективный хиндсайт заметно повышает способность назвать конкретные причины. Это прямой мост к управлению рисками: полученный список идёт в реестр (риски).
• TRIZ Генриха Альтшуллера: задача сводится к противоречию («хотим ускорить сборку, но полный прогон тестов нужен целиком»), а разрешают его разделением во времени, в пространстве или по условию (MATRIZ). В IT это, например, быстрый набор тестов на PR и полный — ночью.
• Delphi (метод RAND): несколько анонимных раундов экспертных оценок со сводкой между раундами — когда нужны оценки без давления авторитетов; вырожденная и всем известная форма — planning poker.

8. Конвергенция: как из сорока идей получить одну

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

1. Группировка (affinity mapping). Идеи сводятся в 6–8 тем участниками молча, вместе, руками: оценивать сорок стикеров поштучно бессмысленно.
2. Dot voting. Каждому даётся N голосов (обычно 3–5), точки ставятся молча и одновременно — сразу, а не после обсуждения, иначе первый высказавшийся задаёт результат. Голосование даёт не решение, а сокращение списка до трёх-пяти кандидатов.
3. Матрица impact / effort. Интересны не «быстрые победы» (их и так сделают), а квадрант «высокий эффект / высокие затраты» — там живут решения, требующие осознанного вложения.
4. Попарное сравнение, когда кандидатов мало (3–5), а разница не очевидна: каждый с каждым, выигрыши суммируются. Метод вскрывает нетранзитивность предпочтений — если A лучше B, B лучше C, а C лучше A, у группы нет общего критерия, и обсуждать надо критерий, а не варианты.
5. Взвешенные критерии (стоимость, срок, риск, обратимость, влияние на клиента) согласуются до того, как варианты оценены: иначе веса подгоняются под уже выбранный ответ — самая распространённая манипуляция в таких таблицах.

И последнее, без чего конвергенция не завершается: кто принимает финальное решение, должно быть известно до сессии. Голосование не назначает ответственного; группа даёт вход, решает названный человек (D в RAPID, A в RACI — см. делегирование). Механику решений — типы решений, ADR, эскалацию, допуски — разбирает следующая глава.

9. Фасилитация и асинхронный формат

Роль фасилитатора — держать процесс, а не содержание: он объявляет фазу, следит за таймбоксом и не высказывает идей. Совмещение ролей «начальник» и «фасилитатор» ломает обе. Подробная механика ведения групповых сессий — в статье про фасилитацию.

Типичные срывы сессии и что с ними делать:

Асинхронный и распределённый формат. Для распределённых команд письменный формат не компромисс, а объективно лучший вариант для этапа генерации — по той же причине, по которой выигрывают номинальные группы: в общей доске никто никого не блокирует. Практика: доска в Miro или FigJam создаётся заранее с готовой структурой (зоны, таймер, правила), задача и problem statement публикуются за сутки, генерация идёт молча и асинхронно 24–48 часов, а синхронная встреча тратится только на группировку и выбор — те фазы, где живой разговор действительно даёт больше. Два требования: анонимность стикеров на этапе генерации (иначе авторитет автора снова заякоривает) и явный дедлайн.

10. Готовый сценарий сессии на 90 минут

Три свойства сценария, которые чаще всего нарушают. Генерация занимает 20 минут из 90 — остальное уходит на формулировку, причины и сведение; ощущение «мы почти не придумывали» правильное. Каждый блок генерации молчаливый. И pre-mortem стоит до конвергенции, а не после решения: найденный риск должен успеть повлиять на выбор.

11. Типичные ошибки

12. Как это выглядит в проде

Флаки-тесты, четыре команды. Проблему сформулировали числом (42% падений релизной ветки), построили Исикаву на 6M, и «Измерения» оказалась ветвью без единой гипотезы — метрик по времени шага никто не собирал. Первым действием стало не решение, а сбор данных; через неделю Парето показал, что 70% падений дают два теста из четырёхсот.

Асинхронный brainswarming в распределённой команде. Доска висела четыре дня, задача — сократить время закрытия месяца. Ключевая идея пришла не из верхней половины графа, а из нижней: аналитик повесил в «ресурсы» факт «93% расхождений меньше 0,5%», через два дня кто-то другой соединил его с веткой «убрать ручную сверку», и получилось решение, до которого на часовой встрече не дошли бы.

Сессия, которая сорвалась. Собрали восемь человек «побрейнштормить архитектуру». Технический директор начал с «я думаю, надо переходить на событийную модель», после чего полтора часа обсуждали событийную модель; итог встречи — задача «сделать PoC». Через месяц PoC показал, что исходная проблема (долгое согласование заказов) вызвана ожиданием ответа внешнего сервиса и от архитектуры не зависела. Стоимость пропущенных десяти минут на problem statement — месяц работы двух инженеров.

Мини-итог

• Сначала проблема, потом идеи. Двойной алмаз расширяет дважды: сперва понимание проблемы, затем множество решений. Пропуск первого алмаза — источник большинства бесполезных сессий.
• Problem statement без решения внутри, с числами и явным «вне рамок». «Нам нужен Kafka» — это решение, а не проблема; 5W2H помогает собрать факты, и пункт «сколько это стоит» пропускать нельзя.
• Причины ищут несколькими инструментами. «Пять почему» дают одну цепочку и останавливаются на человеке; Исикава не даёт пропустить класс причин, FTA работает с комбинационными отказами, Парето выбирает, куда бить, PDCA заставляет проверить результат.
• Классический брейншторм проигрывает номинальным группам из-за производственной блокировки (Diehl & Stroebe, 1987; мета-анализ Mullen et al., 1991), и потеря растёт с размером группы. Вывод: генерировать молча и параллельно, собираться ради группировки и выбора.
• Brainswarming строит граф «цели сверху, ресурсы снизу» и ловит решение там, где ветви встречаются; тишина уравнивает психотипы, отсутствие таймбокса даёт идеям созреть. 6-3-5 даёт 108 идей за полчаса, Note and Vote укладывается в двадцать минут.
• Pre-mortem обязателен и ставится до финального выбора: он делает называние рисков социально безопасным и напрямую питает реестр рисков.
• Конвергенция — отдельная работа: группировка, dot voting, impact/effort, критерии и веса, согласованные до оценки вариантов. Голосование сокращает список, решение принимает названный человек.
• Асинхронный письменный формат для распределённых команд лучше, а не хуже: он устраняет блокировку по построению — при условии анонимности стикеров и жёсткого дедлайна.

Источники

• Design Council, Framework for Innovation (Double Diamond) — рамка «проблема → решение».
• Diehl M., Stroebe W., «Productivity loss in brainstorming groups», JPSP 1987 — производственная блокировка.
• Mullen B., Johnson C., Salas E., «Productivity loss in brainstorming groups: a meta-analytic integration», BASP 1991.
• Delbecq A., Van de Ven A., «A Group Process Model for Problem Identification and Program Planning», JABS 1971 — NGT.
• McCaffrey T., Brainswarming (Innovation Accelerator); «Overcoming Technological Fixation», Psychological Science 2012.
• Klein G., «Performing a Project Premortem», HBR 2007.
• Knapp J., Design Sprint / Crazy 8s и GV Sprint — Note and Vote.
• Lean Lexicon: 5 Whys; Shook J., «Managing to Learn» — A3 и PDCA.
• NRC Fault Tree Handbook (NUREG-0492) — дерево отказов.
• de Bono E., Six Thinking Hats; MATRIZ — ТРИЗ; Delphi Method, RAND.
• Альтернативы мозговому штурму: Brainswarming, Brainwriting, Note and Vote — русскоязычный обзор.

Что дальше

Все методы этой главы заканчиваются в одной точке: на столе лежат два-три варианта, и кто-то должен выбрать. Именно здесь чаще всего рушится вся предыдущая работа — сорок идей, честная конвергенция и аккуратная матрица критериев не спасают, если непонятно, кто решает, какие решения вообще требуют согласования, что делать при несогласии и как через год восстановить, почему выбрали именно это.

Следующая глава — про механику решения как таковую: типы решений и их обратимость, право вето и модели RAPID и DACI на практике, архитектурные записи (ADR) как способ сохранить контекст, эскалация и допуски, по которым решение поднимается на уровень выше.

Читайте: Принятие решений в проекте: типы решений, DACI и RAPID, ADR, эскалация и допуски