Когда команда зашла в тупик

· 4 мин

Ситуация на работе. Шесть человек (разработка, UX, продакт) встретились на видеозвонке сделать финальный разбор дизайна для фичи. В какой-то момент один из разработчиков задаёт вопрос, на который нет однозначного ответа, дизайнер начинает отвечать, остальные начинают накидывать идеи и дополнительные вопросы.

Митинг превращается в хаос.

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

Что делать?

Для начала — принять, что в таком формате ничего не решится. Когда на кухне шесть поваров, не получится даже нормально пожарить яичницу.

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

  2. Можно на ходу предложить структуру, которая поможет принять решение. Кто-то должен взять на себя инициативу и нарисовать на доске или общем документе ментальную модель обсуждаемого. Хорошо работают матрицы, диаграммы, деревья (их, кажется, принято называть майндмапами) или элементарно списки. Каждая проблема требует своего подхода, выбирайте механизмы, которые работают. Будьте готовы к тому, что вас закидают гнилыми помидорами, но также будте готовы к тому, что вы поможете команде выбраться из ямы. Это называется «ответственность».

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

И вот дизайнер спросил меня, что я думаю. Стоит отметить, что в этой ситуации у меня «позиция власти», то есть решение в конечном счёте лежит на мне (мета-поинт — power dynamics имеет значение и полезно объективно оценивать свою позицию относительно других). Обычно я стараюсь не прибегать к тому, чтобы говорить людям, что делать. Всегда лучше, если люди примут решение сами, а я вмешаюсь только, если мне есть что добавить или чтобы помочь направить команду в нужном направлении.

Как говорил кто-то великий — «дети перестают учиться, когда их начинают учить». Это касается не только детей.

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

Слушая их, мне стало ясно, где лежит недопонимание. В двух словах, затык был в том, что в проблеме было слишком много подвижных частей. Чтобы помочь команде, я создал в общем документе структуру, которая а) дала определение всем терминам и описала взаимосвязи между ними, чтобы все участники говорили об одном и том же одними и теми же словами, б) сгруппировала все возможные состояния пользовательского интерфейса в матрицу.

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

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

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

Пошаговый алгоритм:

  1. Абстрагироваться от спора и мнений. Задать себе вопрос «что важно пользователю?»
  2. Создать структуру, которая помогает пошагово, линейно оценить ситуацию.
  3. Попросить всех замолчать и линейно провести команду по линии своих мыслей, медленно, методично, используя структуру. Следить за лицами, чтобы отслеживать признаки недопонимания. Не дожидаясь вопросов, повторить ключевые моменты.
  4. Идеально, если кто-то из толпы скажет «так подожди, давай я повторю, чтобы убедиться, что я правильно понял(а)». Тогда а) ты убеждаешься, что хотя бы этот человек понял и б) остальные слушают объяснение повторно. Если по объяснению понятно, что человек понял не так, то возвращайся к пункту 3 и постарайся объяснить более доходчиво.

Мета-поинт номер 2 — коммуникация в разработке продуктов экспоненциально сложнее, чем техническая работа.

# Коммуникация # Продакт менеджмент