Начните воркшоп «Надежды и опасения» с двух вопросов: «Какие возможности, по вашему мнению, должен открыть этот проект?» и «Что вас беспокоит?» Дайте участникам время записать мысли самостоятельно, обсудите смысл записей и объедините близкие темы. Затем выберите несколько ожиданий или опасений, на которые нужно конкретно ответить до начала работы.
Упражнение подходит для старта проекта, когда цель общая, а представления об успехе могут различаться. На общей онлайн-доске Boardmix удобно держать рядом ожидания, опасения и итоговые договорённости. Вопрос может остаться открытым: не обязательно превращать каждое опасение в позитивную формулировку.
Для чего нужен этот воркшоп
Упражнение помогает открыто обсудить ожидания. Команда может договориться «запустить новую базу знаний», но один участник надеется сократить повторяющуюся работу, другой — повысить качество ответов, а третий опасается непосильной нагрузки на поддержку материалов. Эти различия влияют на организацию работы.
В инструментарии IBM Enterprise Design Thinking упражнение описано как способ выявить цели и опасения группы перед началом совместной работы. Базовый формат включает отдельные области для надежд и опасений, индивидуальные записи, объединение по темам и совместный разбор.
Доска не заменяет опрос всей организации, модель вероятностей или подтверждение общего согласия. Даже единственное опасение может быть важным. Рассматривайте записи как отправную точку для уточняющих вопросов.
Задайте конкретную ситуацию для обсуждения
Укажите проект, рассматриваемый период и решение, на которое может повлиять встреча. «Наше будущее» — слишком широкая тема. «Первый месяц использования общей базы знаний поддержки» задаёт понятную ситуацию.
В нашем примере участвуют специалисты поддержки, редактор, руководитель команды и инженер, который помогает поддерживать поиск. Ведущий начинает так:
Мы готовим небольшой запуск базы знаний для одного потока обращений в поддержку. Сегодня обсудим, чего хотим достичь за первый месяц и что может затруднить использование базы. Мы можем изменить порядок работы в пилотном проекте. Более широкие вопросы штата и бюджета потребуют отдельного решения.
Объясните, кто видит доску и что с ней будет после встречи. Дайте возможность пропустить ответ или сообщить о деликатном вопросе лично по подходящему каналу. Не обещайте анонимность на общей редактируемой доске и не просите размещать конфиденциальные сведения о сотрудниках.
Сначала соберите индивидуальные мнения
Попросите записывать по одной мысли на стикер. Несколько минут тишины позволят сформулировать собственную позицию до того, как разговор пойдёт за первым выступающим. Можно предложить такие начала фраз:
- «Я надеюсь, что этот проект поможет нам…»
- «Для людей, выполняющих работу, полезным результатом было бы…»
- «Меня беспокоит, что…»
- «Чтобы участвовать в этой работе, мне нужно…»
Не требуйте одинакового количества надежд и опасений. У человека может быть несколько тревог и одно сильное ожидание. Руководителю тоже не стоит сразу отвечать на каждый стикер. Сначала дайте команде увидеть весь спектр мнений.
Если кто-то написал «коммуникация», уточните, что это значит в данном проекте. «Хочу легко понимать, изменилась ли статья со времени моей предыдущей смены» — уже конкретное ожидание. Его можно обсуждать, не предрешая выбор инструмента или решения.
Разберитесь в смысле записей, прежде чем выбирать действия
Ниже приведён условный пример запуска базы знаний, а не результаты исследования клиентов. Записи показывают, как перейти от общего настроения к вопросу, на который команда может ответить.
| Исходная запись | Уточняющий вопрос | Что узнаёт команда |
|---|---|---|
| Надежда: «Перестанем писать один и тот же ответ много раз». | Ответ на какой повторяющийся вопрос сделает пилот полезным? | Специалистам нужен надёжный ответ о неудачной настройке, а не большая библиотека редко используемых материалов. |
| Опасение: «Статьи быстро устареют». | Какие изменения сегодня трудно заметить? | Изменения формулировок в продукте не всегда доходят до сотрудников, обрабатывающих обращения. |
| Надежда: «Новички смогут находить ответы, не отвлекая коллег». | Что они должны уметь делать самостоятельно? | Нужно находить нужную статью и понимать, когда следует передать обращение дальше. |
| Опасение: «Придётся обновлять базу после смены». | Откуда возьмётся время на поддержку материалов? | Для пилота нужно согласовать рабочее время; одного энтузиазма недостаточно. |
| Опасение: «Люди будут следовать статье там, где требуется самостоятельное решение». | Что поможет распознать эту границу? | В статьях нужны заметные указания на исключения и передачу обращения, а не инструкция для любого возможного случая. |
Объединяйте записи только после того, как понятен их смысл. Устаревающие формулировки и нехватка времени могут относиться к поддержке материалов, но причины у них разные. Сохраните отдельные записи внутри общей темы, чтобы различие не потерялось.
Прежде чем объединять похожие стикеры, спросите: «Они описывают одну и ту же проблему?» Если участник не согласен, сохраните различие. Аккуратная доска — недостаточная причина, чтобы убрать мнение меньшинства.
Выберите несколько рабочих договорённостей
Теперь определите, на какие ожидания или опасения команда может отреагировать до следующего этапа. Избегайте обещаний вроде «лучше общаться» или «поддерживать актуальность контента». Запишите наблюдаемое действие, человека, согласившегося отвечать за него, и момент проверки результата.
| Тема | Согласованное действие | Ответственность и проверка |
|---|---|---|
| Полезные первые материалы | Начать с ответа о неудачной настройке и указать, когда передавать обращение дальше. | Редактор и специалист поддержки проверяют черновик до начала пилота. |
| Изменения формулировок в продукте | Включить соответствующие изменения в существующую передачу информации о выпуске. | Инженер выясняет, кто отвечает за эту передачу; первое обновление команда проверяет вместе. |
| Время на поддержку материалов | До расширения пилота попросить руководителя выделить время на обновление базы. | Руководитель даёт ответ на встрече по планированию пилота. До этого расширение остаётся открытым вопросом. |
Не каждой записи требуется действие. Некоторые надежды описывают желаемый результат, а для некоторых опасений пока не хватает информации. Подпишите эти различия, чтобы «открытый вопрос» не приняли за «согласованное действие». Если вопрос выходит за полномочия команды, укажите, как получить решение.
Используйте простую схему доски Boardmix
В верхней части доски Boardmix напишите тему проекта. Ниже создайте две большие области: «Надежды» и «Опасения». Сбоку оставьте третью — «Договорённости и открытые вопросы».
Участники добавляют записи в первые две области. Во время обсуждения перемещайте близкие по смыслу стикеры рядом и давайте группам понятные названия. Отличайте договорённость от вопроса текстовыми метками: цвет может помогать навигации, но не должен быть единственным носителем смысла.
Итоговые действия размещайте рядом с записями, на которые они отвечают. Уточнения можно оставлять в комментариях, не перегружая исходный стикер. Участник должен видеть, какое опасение привело к договорённости и что ещё не решено.
Области, тематические группы и договорённости команда оформляет сама. Для этого упражнения не нужны автоматический анализ настроений или оценка рисков.
Когда нужен другой формат
Если вопрос звучит как «Из-за чего проект может провалиться и какие сигналы нас предупредят?», вынесите его на премортем проекта. Если нужно понять, какое предположение проверить первым, используйте карту предположений. Эти методы решают другие задачи; не стоит пытаться вместить их целиком в стартовую встречу.
На следующей контрольной встрече вернитесь к договорённостям и открытым вопросам. Уточните, изменились ли ожидания после начала работы. Сохраняйте исходные записи, чтобы изменения были видны, а не переписывайте прошлое так, будто все заранее предвидели результат.
Для подготовки встречи откройте доску Boardmix и сначала сформулируйте конкретную тему. Две колонки добавьте потом: главное — заранее понять, на какие рабочие условия группа действительно может повлиять.
