Проблемы мозговых штурмов

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

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

Тема мозговых штурмов предоставляет широкие возможности для исследований. Я разработал свою классификацию. Мои критерии включают в себя среду взаимодействия, механику проведения и цели/масштаб, что позволяет рассматривать эту тему с различных точек зрения.

Ниже я делюсь своими мыслями по каждому из выделенных направлений.

Как я писал выше, в реальности почти любое совещание в небольшой компании — это и есть мозговой штурм.

Как я писал выше, в реальности почти любое совещание в небольшой компании — это и есть мозговой штурм.

Представьте себе типичную ситуацию:

В кабинете с маркерной доской небольшая команда (3-7 человек) активно обсуждает задачу/проблему, накидывают идеи, сразу их обсуждают, часть отбрасывают. Спустя некоторое время приходят к какому-то решению. Записи на доске фотографируют, фотографии отправляют себе в чат, и, вдохновленные, возвращаются на свои рабочие места. Подготовились ли они к обсуждению, проводил ли тимлид фасилитацию? В большинстве случаев – конечно же, нет.

Может быть, дело в размерах? Может быть, в компаниях побольше пришли к правильному пониманию процессов мозговых штурмов? Нет, разница заключается только в том, что обсуждение заканчивается не фотографией доски/листка, а составлением протокола совещания, используется термин «рабочее совещание» вместо мозгового штурма. Понятно, что особой разницы нет, но, тем не менее, протоколы добавляют ощущение какого-то процесса.

Замечали ли вы, что на мозговых штурмах в первую очередь чаще всего высказывается тот, у кого в команде больше всего власти и энергии? Именно благодаря своему моральному весу он начинает давить в нужном ему направлении, зачастую даже не осознавая этого, даже если внутренне не желает так поступать. Почти всегда не рассматриваются точки зрения всех присутствующих (по разным причинам: не успели высказаться, стеснительные сотрудники, мысли в духе "да какая разница, что я думаю, меня все равно всерьез не воспринимают, тимлид сделает все по-своему…").

Мозговой штурм провели, а что дальше?

Итак, активная фаза мозгового штурма наконец завершена, и команда получила результат – фотографию своих записей или протокол рабочего совещания. Очевидно, что теперь нужно воплотить их в виде реальных изменений. Однако, как правило, у команд нет отлаженных механизмов для этого, и обычно все полагаются на добрую волю участников процесса. Дальше при попытке применить принятые решения возникают новые вопросы, на которые требуется найти быстрые ответы.

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

Групповой штурм Тони Бьюзена

Рассмотрим методику проведения мозговых штурмов по алгоритму Тони Бьюзена. Он описал его в своей книге «The Mind Map Book» в уже далеком 1994ом году. Название тривиально — «групповой мозговой штурм».

Подход Тони Бьюзена к мозговому штурму значительно отличается от привычного метода, где один человек ведет собрание, записывая идеи всех участников (включая свои) на лист или маркерную доску. Кроме того, автор mind map предлагает использовать mind map при проведении мозговых штурмов.

Алгоритм следующий:

1. В начале группа договаривается о теме и целях штурма.
   

2. Каждый участник рисует свой mind map в течение минимум одного часа.

3. Формируются подгруппы из 3-5 человек, внутри которых происходит обсуждение каждой карты участника в течение 1 часа.
   

4. Группа создает первую версию общего mind map, объединяя (копируя) карты участников.
5. Важно провести паузу — перерыв на отдых, для отдыха мозга и обработки полученной информации.
   
6. Повторить шаги с второго по четвертый и сравнить две большие итоговые карты, чтобы создать третью — результирующую.
   

Бьюзен предложил методику и для индивидуального мозгового штурма. Суть ее заключается в инкрементальном (длящемся до нескольких дней) улучшении своего mind map, начиная с 20-минутной записи всех идей в карту.

Тони провел эксперимент, доказав эффективность групповых мозговых штурмов. Группе участников предложили одно и то же понятие, после чего они должны были в течение одной минуты сгенерировать набор из десяти ключевых слов (не видя результаты других), каждый записывал слова в свой mind map. Затем провели поиск полностью совпадающих общих слов в группе. Эксперимент показал, что у каждого человека были свои ассоциации с определенным словом (даже если это люди одной профессии). Таким образом, в групповом мозговом штурме каждый участник способен принести пользу.

Бьюзен отметил важность использования рисунков внутри mind map — это подключает второе полушарие мозга и позволяет использовать еще больше ассоциаций.

Динамическая фасилитация

Помимо методики группового штурма, предложенной Тони Бьюзеном, существуют и другие подходы, один из которых — динамическая фасилитация. Отмечу, что на моем опыте эффективным будет совместное последовательное использование методов группового мозгового штурма и динамической фасилитации. Её цель — создание творческого пространства для нахождения самого удачного решения на текущем историческом моменте.

Правила динамической фасилитации:

1. Каждый участник обязан высказаться.

2. Учитываются каждый нюанс, каждое опасение по поводу идей каждого из участников.
   

3. Всегда есть ведущий (фасилитатор).
4. Критика идей не предполагается; свое мнение высказывают фактически не другим участникам, а фасилитатору.
   
5. Отсутствие риска принятия случайного решения.
   
6. Важный принцип — согласие каждого из участников с принятым решением.
   
7. Все участники равны.
   
8. Особая атмосфера доверия и комфорта.
   
9. Очередность не имеет значения.
   
10. Избавление от всех текущих идей путем их фиксации.
    

К другим механикам проведения мозговых штурмов можно отнести креативный мозговой штурм, в котором, как например, у моих знакомых из wetware.ru, комбинируются преимущества классического аналитического инструментария и элементы подходов из области технологического искусства.

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

Почему мозговой штурм на созвонах или в мессенджерах – это зло?

Один из популярнейших форматов проведения онлайн-мозговых штурмов — это созвоны. Со стороны такое общение кажется суперудобным, эффективным и решающим проблемы. Тем не менее, рост плагинов для сервисов звонков с расшифровкой и саммаризацией в виде протоколов показывает обратную сторону — созвоны малоэффективны и сжирают у компании львиную долю времени.

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

Если во время офлайн-мозговых штурмов все участники молчат – это одно, но, если они молчат на онлайн-мозговом штурме – это повод задуматься — значит, люди меньше вовлечены в процесс (что вы, наверное, сами часто замечали во время созвонов).

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

Максимальную имитацию офлайн-мозговых штурмов обеспечивают созвоны в сочетании с использованием онлайн-досок, например, Miro. Это хороший способ проведения мозгового штурма: все видят одну и ту же доску, все подключаются к процессу одновременно, фиксируют в основном все результаты сразу в цифровом структурированном интерактивном виде. Однако этот вариант по-прежнему не решает проблему отсутствия структурированности в коммуникациях команды и продолжает нести в себе все те же проблемы офлайн-мозговых штурмов.

Есть еще один вид онлайн мозговых штурмов, который проповедую я сам.

Это распределенные структурированные мозговые штурмы.

Что из себя представляют распределенные структурированные онлайн мозговые штурмы?

В начале инициатор мозгового штурма описывает всю проблематику, которую он хочет структурировано обсудить в цифровом пространстве. Затем он предоставляет доступ участникам к изложенной информации, устанавливая при этом некоторые временные рамки. Участники получают возможность поделиться своими мыслями и оставить комментарии к записям инициатора. Только после этого они синхронизируются в виде звонка или переписки в мессенджере (в зависимости от объема обсуждений). После синхронизации окончательные результаты штурма еще некоторое время фиксируются, дополняя, изменяя или структурируя исходную информацию. Затем эти результаты могут быть использованы в других процессах команды, при этом важно, чтобы сохранялась ссылка на мозговой штурм, в котором были приняты эти решения, т.к. там может быть важный контекст.

Распределенный во времени мозговой штурм фактически представляет собой то, как ранее (и сейчас, но реже) использовались форумы. Топик-стартер задает тему, остальные генерируют решения, обсуждают их — все это происходит в разное время. Однако линейная форма представления топиков порождала проблемы с восприятием контента, и читатели терялись, в прямом смысле, в обсуждениях, забывая, на чем они остановились, и пропускали сообщения. Поэтому на некоторых форумах использовали режим просмотра ленты сообщений в виде иерархически вложенных веток.

Хочу рассказать, как я адаптировал проведение распределенного структурированного мозгового штурма под свои потребности. Для того чтобы сделать пример более иллюстративным, я опишу краткий сценарий стратегической сессии, представляющей собой разновидность мозгового штурма.

1. Планирую цели. Перед началом стратегической сессии провожу декомпозицию текущих целей:

   - Расписываю их по пунктам.

   - Группирую мелкие цели, раскладываю объемные на более конкретные.

   - Использую метод SMART.

2. Делюсь целями с командой.
3. Начинается обсуждение, сначала асинхронно: все члены команды могут ознакомиться с моими записями и оставить свои комментарии, включая сомнения и свои варианты целей.
4. Провожу созвон/совещание, на котором обсуждаем наши планы, оставляем заметки и комментарии к целям, которые я потом структурирую.
5. Составляем дорожную карту:

   - Составляю краткую дорожную карту.

   - Этапы состоят из вех, а вехи из задач.

   Члены команды могут предложить свое видение дорожной карты, дополнив ее по своему усмотрению (асинхронное обсуждение).

6. Результатом проведения мозгового штурма в моем цифровом пространстве становится карта (граф знаний) со структурированными идеями, решениями и вехами.

Другим примером, является ситуация, когда во время Agile-спринтов иногда необходимо найти решение для конкретной задачи или проблемы. Для этого проводим более локальный мозговой штурм:

• Фиксируем возможные решения, создавая дочерние узлы и помещая туда ссылки с другими заметками-узлами для создания контекста.
• При сложных проблемах создаем подзадачи, деля проблему на задачи и группируя их.
  
• Подводим результаты решения задачи и связываем их с другими частями плана, возможно, внося изменения в ожидания "заказчиков" спринта.
  

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

С какими проблемами я столкнулся при проведении мозговых штурмов

Поскольку одним из продуктов нашей команды является система управления знаниями на базе графов знаний, именно ее мы используем в качестве цифрового пространства для мозговых штурмов. Но даже в этой системе, созданной прежде всего под наши запросы и бизнес-процессы, исходя из нашего понимания идеального ведения мозгового штурма, возникли проблемы.

Чаще всего происходит следующее:

• Ход обсуждения фиксируется, но участники команды забывают подводить итоги мозговых штурмов, и ветви часто превращаются в «заброшки».
• Решения, если и фиксируются, то не в типовом виде (в теме ориентируется только человек, который в курсе происходящего, то есть организатор, который держит все знания в своей голове).
  
• После принятия нового решения, старые ветки часто остаются на своих местах или просто попадают в категорию «архив», вместо явного оформления их в истории.
  
• Как правило, если в одной из наших команд нет четких стартовых договоренностей по алгоритмам проведения мозговых штурмов, то и не получается удобной командной работы, в особенности, когда к команде присоединяются новые люди.

Варианты улучшений ситуации

Анализируя эти проблемы, я понял, что частично нам нужно доработать функционал инструмента, но большее значение имеет сама методика проведения мозговых штурмов. Групповой штурм Бьюзена и динамическая фасилитация были придуманы для офлайн-штурмов, и требуется адаптировать их к онлайн-командным взаимодействиям. Одним из шагов в этом направлении является переработка опыта проектирования больших ИТ-систем и адаптация его к планированию коммуникаций в команде.

ADR — Architecture Decision Record

Для структурирования и логирования принимаемых решений при проектировании ИТ-систем используется ADR (Architecture Decision Record). Если дословно перевести ADR на русский, то это запись в логе архитектурных решений. Фактически это документ, в котором фиксируется не только принятое важное решение, но также его контекст и последующее применение в других задачах (с обязательным ведением истории). Это пример формализации принятия решений по проекту (типа "а что мы делаем дальше, после мозгового штурма, а что мы думали до этого решения?"). Можно сказать, что ADR начинается с мозгового штурма, циклично переходящего в динамическую фасилитацию.

Если вы не знакомы с методикой ADR, то короткое и понятное описание можно найти здесь, здесь или в других статьях на Хабре или VC.ru

СИПР — структурированная история принятых решений

Мне кажется, что использовать термин ADR для обозначения способа фиксации процесса, истории и результатов мозговых штурмов на произвольную тему не совсем корректно, поэтому можно использовать обозначение СИПР — структурированная история принятых решений.

Разделы СИПР:

• Обоснование (причины, плюсы/минусы потенциальных вариантов, обсуждение выгод и т. д.).
• Временные метки (зафиксируйте время). Мы вставляем новую информацию в существующий документ с отметкой даты и пометкой о том, что информация поступила после принятия решения.
  
• Ни в коем случае не изменяйте уже занесенную информацию в историю; каждый раз добавляйте новые записи как новые.
  
• Контекст (объясните ситуацию и расставьте приоритеты). Учитывайте навыки членов команды.
  
• Зафиксируйте цели (по SMART), вехи, задачи.
  
• Итоги. Укажите результаты решений, действия, к которым привело это решение.
  
• Отдельно выделите неожиданные/нежелательные реакции, какие процессы потребовали проведения дополнительных мозговых штурмов.
  
• Установите временной интервал, когда вы будете проверять результаты, например, месяц (сравнение принятых решений с тем, что в итоге произошло на практике).
  

Конкретная структура (шаблон записи о принятом решении):

• Заголовок.
• Актуальное состояние (статус: предложено, принято, отклонено, устаревшее, заменено и т. д.).
  
• Содержание (контекст):

  - А в чем проблема?

  - Решение.

  - Перечень предлагаемых изменений/решений.

  - Последствия (заполняются по факту) на что и как эти решения повлияли.

Советы по применению СИПР:

• Фиксируйте как личный, так и коллективный опыт.
• Ведите общий список задач по проекту и дополняйте его списком задач по принятию решений.
  
• Если у вас несколько отделов в компании, сделайте так (доведите до сведения заинтересованных лиц), чтобы доступ к принятым решениям имели все, имеющие отношение к процессам/проекту участники (например, отдел продаж к решениям по производственным процессам).
  
• Обязательно настройте обмен решениями (опять же можно сделать это через базу знаний), ведь многие решения могут повторяться в разных проектах, следовательно, опыт прошлых решений, как хороших, так и плохих, может стать ценным активом.
  

Перед началом обсуждения стоит задать себе и команде вопросы:

• Насколько срочно и важно проведение мозгового штурма?
• Нужно ли его проводить прямо сейчас, или можно подождать, когда накопленных знаний станет еще больше?
  

Плюсы СИПР:

• Как правило, записи решений позволяют командам мыслить умнее и лучше общаться.
• Записи о решениях не имеют никакой ценности, если они представляют собой просто принудительное оформление документов постфактум.
  
• Получается «живой» документ, к обновлению которого имеют доступ все заинтересованные, причем этот документ может быть интегрирован (хотя бы на уровне гиперссылок) с другими элементами общего графа знаний компании.
  
• В документ можно заносить не только решения мозговых штурмов, но и новые предложения, результаты работы, дать доступ к добавлению знаний вообще третьей стороне и т. д.
  

Сейчас я нахожусь на этапе внедрения СИПР в свои ежедневные процессы и процессы внутри моей команды; поделюсь с вами опытом в следующих статьях.

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

#мозговойштурм #коммуникация #команда #эффективность #совещание #фасилитация #управлениезнаниями

✨ Мой telegram-канал о менеджменте проектов и знаний, инструментах для личной и командной продуктивности. Пишу редко, но полезно: