Более здоровые команды с Core Protocols

Коммуникация — один из главных факторов продуктивности команды. Оказывается, она влияет на успех команды сильнее, чем индивидуальная результативность участников [1]. В 2013 году мне повезло попасть на воркшоп с Jim McCarthy, где я узнал о Core Protocols и о том, как они выводят коммуникацию команды на новый уровень. С тех пор не перестаю удивляться, насколько это мощный инструмент. Однако понадобилось несколько лет практики, чтобы полностью понять потенциал — вот почему.

Что такое Core Protocols по сути?

Начнём с определений. Что такое протокол? Collins Online Dictionary, например, даёт несколько значений:

несколько значений

Если читать между строк, за всеми четырьмя видна общая логика. Во-первых, в обмене участвуют две или больше сторон. Во-вторых, есть набор правил. Затем — типичные ситуации, когда обмен происходит. Наконец, стороны соглашаются использовать правила во время обмена в этих типичных ситуациях. Именно это и есть Core Protocols. Это набор правил, которые команда использует в ежедневной коммуникации, чтобы сделать её проще и яснее. На практике это маркерные фразы. Когда кто‑то произносит маркерную фразу — протокол запущен, и все члены команды должны ответить вполне определённым образом.

Вот пример. Допустим, вы хотите попросить обратную связь. Обычная проблема: обратная связь часто бесполезна. И не намеренно — другой человек просто не знает, чего вы ждёте. Но это легко улучшить. Используйте Perfection Game — один из Core Protocols. Как это работает? Вы запускаете его словами «Would you perfect this thing for me?» — и точно говорите, что улучшать — «My presentation today. Can you rate it on the scale of 1 to 10?». Другой человек получает ясный маркер, что начался Perfection Game. Он уже знает, как продолжить: оценивает презентацию по шкале от 1 до 10 и говорит, что понравилось. Добавляет пару предложений, что нужно сделать, чтобы это стало 10. Вы только что сэкономили много времени и получили ценные — и actionable — советы.

Core Protocols — просто ещё одна техника фасилитации?

Некоторые протоколы особенно популярны в Agile-сообществе. Perfection Game кажется всеобщим фаворитом и часто всплывает в блогах и статьях. Другие тоже иногда получают внимание. Но Core Protocols редко обсуждают как целое.

Core Protocols удобно описывать railroad diagram. Здесь — Perfection Game. Создано с Railroad Diagram Generator.

Действительно, многие из них можно использовать просто как техники фасилитации — и это хорошая точка старта для неопытной или скептичной команды. Но в Core Protocols гораздо больше. У них более глубокие цели, чем просто помочь проводить регулярные встречи. Ожидаемые эффекты включают[2]:

  1. Более близкая межличностная связь.
  2. Более эффективное коллективное принятие решений и связанное распределение ответственности.
  3. Лучший alignment команды и личности.
  4. Достижение общего видения.

Команда, которая применяет Core Protocols системно, может ожидать фундаментального изменения способа коммуникации и в итоге культуры.

В чём сила Core Protocols?

Мне нравится думать о Core Protocols как о способе «перепрограммировать» людей реагировать на типичные (возможно неприятные) ситуации здоровее. Что я имею в виду? Многие проблемы коммуникации возникают из‑за нашего собственного восприятия. Эмоции вызывают не внешние события сами по себе, а убеждения человека — особенно иррациональные [3]. С Core Protocols вы можете перепрошить схему, договорившись в команде, как реагировать, когда становится туго.

Хороший пример — протокол Check Out. Идея проста. Любой человек может покинуть любую активность, если чувствует, что больше не может участвовать. Причины разные: не добавляет ценности, устал и засыпает, слишком эмоционально заряжен и т. д. Просто выйти из комнаты оскорбит людей, потому что общее убеждение — это невежливо. Особенно если человек уходит в раздражении. Check Out даёт изящный выход. Он позволяет команде договориться: любой имеет право сказать «I check out» и выйти. Когда это происходит, все знают, как реагировать, и что не нужно обвинять человека или допрашивать о причинах. В обмен «ушедший» обещает не устраивать сцену и обязуется вернуться к команде, как только сможет. По сути, согласившись использовать Check Out, члены команды заменяют традиционное убеждение (это невежливо) новым (это ожидаемо, так мы общаемся).

Другое, что делает Core Protocols такими сильными, — как они спроектированы. Каждый протокол сформулирован очень тщательно. Каждая фраза подталкивает к конструктивным и конкретным результатам. Возьмём Decider и Resolution. Вместе они образуют простой механизм голосования. Начинается с предложения человека и приглашения голосовать («one-two-three»). Голосующие выбирают «Yes», «No» или «Support It» (есть ещё «Absolute No» — по сути вето, но оставим это пока). Предложение проходит, если достаточно «Yes» и нет «No». Если есть «No», но не слишком много, их можно разрешить через Resolution. Предлагающий спрашивает группу «What can I do to get you in?» Всмотритесь в формулировку. Она намеренно направляет ответ к предложению улучшения или альтернативы. Не оставляет места жалобам или бессмысленной болтовне. Сравните с вопросом «Why didn't you like my proposal?»

Кажется, нужна большая self-awareness. Не слишком ли сложно?

Некоторые протоколы гораздо требовательнее к self-awareness и доверию. Check In в чём-то уникален — его легко начать, но нужно много self-awareness, чтобы дать максимум ценности.

Слишком механично / слишком touchy-feely. А если команда не купит?

Окей, а если команда изначально не покупает идею? Я много раз слышал, что Core Protocols делают коммуникацию слишком механической. Видел и людей, которым неудобно, как протоколы заставляют открываться перед товарищами. Во-первых, с графиком выше можно подогнать протоколы под уровень готовности команды. А если всё равно ждёте сильного отпора — просто не говорите, что это такое. Начните использовать протоколы сами без объяснений. Пусть команда учится делая. Можно даже слегка менять формулировки, чтобы звучало естественнее и менее «протокольно». Например, начинать check-in на каждую встречу или проводить Decider без объявлений. Когда видите, что команда привыкает к протоколу, объясните и добавьте следующий. Надеюсь, через время сможете ввести Core Protocols формально. Но даже если нет — проблема невелика: можно оставаться «под прикрытием» бесконечно и всё равно получать много ценности.

Когда и как лучше всего начать?

Core Protocols — часть моего стартового набора для новых команд (подробнее в будущих постах), и я думаю, что это лучшее время вводить их. Чем раньше начнут — тем раньше научатся. Также предположительно это поможет команде быстрее пройти storming, потому что коммуникация будет более открытой и конструктивной. Однако ничто не мешает начать протоколы и в существующих командах.
Мне нравится вводить Core Protocols короткой сессией, обычно 1,5 часа. Начинаю с объяснения, что такое Core Protocols и какую пользу получит команда. Затем даю команде прочитать Core Commitments — фундамент Core Protocols, список утверждений, чем-то похожий на Agile Manifesto, которому команда обязуется следовать. Когда commitment сформирован, быстро проходим каждый протокол, и я объясняю механику. Многие протоколы сбивают с толку при первом взгляде, поэтому критично давать примеры. В конце провожу Decider-голосование, чтобы получить согласие на использование Core Protocols. Если команда согласна — можно начинать. Если идея не получает полной поддержки, вместе с командой подгоняю набор протоколов, как описано выше. И конечно, совершенно нормально, если команда отвергнет это целиком. Крайне важно, чтобы Core Protocols использовались только при мотивации и принятии.
Следующие несколько недель я даю команде учиться делая и слежу, чтобы хватало коучинга по использованию протоколов. Мне нравится этот формат, потому что в рабочей среде часто непросто выкроить время на полноценный тренинг. Но если есть возможность провести нормальный тренинг — всегда берите тренинг.

← Блог