Самоорганизация

2021.02.28 (ред. 2021.10.08)

Самоорганизованная команда. Зачем? Коллективная ответственность за достижение важной цели - это утопия. Каждый сам за себя. Так всегда было, есть и будет. Все эти ваши аджайлы не работают. Может быть где-то там, на Западе, где море ресурсов и времени - да. А у нас в России нет.

Наверное каждый скрам мастер или аджайл коуч встречался с таким возражением. И правда, чего мы упираемся и так не любим титул "тимлид" (руководитель команды, постановщик задач). Создавая карту компетенций в свежеиспечённый команде, я послушно вписываю туда "общее руководство процессом" или "координация всех" или "постановка и контроль выполнения задач", чтобы затем они сами убрали эту, с позволения сказать, компетенцию.

Хочу подчеркнуть, что под словом "тимлид" в контексте данной статьи я имею в виду не человека (должность), а роль. Команда создается для достижения конкретной цели, и тот, кто владеет этой целью, также является руководителем. Однако, это иная роль. Руководитель компании (организации) не может позволить себе заниматься микроменеджментом в команде - ему просто не до этого. Если говорить о должностях, то в этой статье речь скорее о наемном менеджере-координаторе, единственная функция которого - отвечать за достижение поставленной цели в рамках бюджета и сроков. Эта роль появляется в процессе создания команды, или позже. Бывает как формальной, так и неформальной. Часто эта роль совмещается с лидерством по продукту, архитектуре, компоненту, технологии.

И где проблема?

В чем проблема роли, которая содержит в себе ответственность за достижение цели? Это ведь так прекрасно, когда есть конкретный человек, который отвечает за:

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

В итоге получается, что самоорганизация нужна только скрам-мастеру? И все играют в аджайл только ради соответствия каким-то новомодным стандартам в индустрии, лучшим традициям разработки из кремниевой долины, и, наконец, вишенка на торте - религиозным принципам от Кена Швабера и Джеффа Сазерленда. Да, да, вы не ослышались. Аджайл - это секта. Не надо пытаться понять скрам-гайд логикой, надо просто поверить в него и да пребудет с нами сила.

Однако:

Можно подумать, что это просто частный случай конкретной организации. Кто-то просто не умеет работать. Неужели?

Менеджер-снежинка

Есть такое понятие - координационные издержки. Чем больше неопределенности и рисков, тем выше эти издержки. Даже если у нас кросс-функциональная команда, которая в курсе про проблему мультизадачности и поэтому все full-time заняты только одним проектом, координация через тимлида всё равно создает издержки. Когда исполнитель встречается с препятствием, он в лучшем случае уведомляет тимлида и бдительно ждет коррекции. В худшем случае (он же не бездельник), он находит себе другую задачу на время, пока первая заблокирована. И чем дольше тилмид реагирует, тем больше задач рискуют оказаться заблокированными in-progress. Кроме того, взять другую задачу на время, пока первая висит недоделаной, означает добровольно вернуть назад проблему мультитаскинга.

Когда сроки продалбываются, а цели не достигаются, тимлид ищет оправдание вне зоны своей ответственности. И конечно же самая распространенная - не хватает человеческих ресурсов. Скрытое желание любого нормального менеджера - усилить свою власть и влияние через увеличение количества подчиненных, что вместе с риском остановки процесса из-за выключения отдельных членов команды усиливает эту позицию. И в итоге, в лучших традициях Ноя с его знаменитым ковчегом, команда пополняется дубликатами уникальных специалистов, которые затем делят ответственность внутри своей функции на под-функции (или компоненты), что ещё больше увеличивает издержки на координацию и, как ни странно, усиливает зависимость. Даже если в функциональной подгруппе ответственность не делится, один непременно будет старшим с аналогичной тенденцией стать большим начальником через раздувание штата, что также приведет к увеличению координационных издержек.

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

Как перейти к новому стилю управления?

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

Это не быстрый процесс. Но если вы уже оказались в такой ситуации, то лучше уж медленно, чем никак.

Как создать самоорганизованную команду?

Что если у вас ещё нет команды с тимлидом, и вы хотите создать команду? И хотите создать сразу правильно, самоорганизованно, без тимлида. Как нужно действовать? С чего начать?

Начните со встроенной нестабильности. Это такая ситуация, когда у команды есть общая задача, общая цель, направление движения, целевое состояние, но нет определенности как действовать - только какие-то понятные границы. Например, для scrum-команды такой целью будет целевое значение бизнес-метрики (см. OKR). В такой ситуации команда вынуждена искать свой собственный процесс, свою уникальную коммуникационную структуру, свою систему управления - систему самоуправления. Вы поймёте, что у вас самоорганизованная команда, когда в ней проявятся три основных свойства: автономность, самопревосхождение и перекрестное опыление.

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

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

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

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

Иначе говоря, характер управления должен быть смещён в сторону бесструктурного:

Бесструктурное управление и тонкий контроль требует наличия обслуживающего лидера в команде, о котором шла речь выше. Servant leader - это специалист по командообразованию и командной работе. Такая специализация уже включена в распространенные на рынке профессии: Agile-коуч, Scrum-мастер, фасилитатор, трэкер предпринимателей.

Инструменты фасилитатора

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

Матрица компетенций

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

  1. Выписываем по вертикали (строки) все необходимые навыки и умения, которые нужны для достижения результата.
  2. Выписываем по горизонтали (колонки) имена всех потенциальных членов команды.
  3. Проставляем всей команде степень владения навыками и умениями с помощью звёзды или плюса.

Варианты заполнения клеток следующие:

Фасилитируем команду в процессе заполнения. Выделяем риски - смотрим на отдельные строки:

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

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

Нередко встречаю путаницу кросс-функциональности с T-shaped и M-shaped навыками. Это разное. Кросс-функциональная команда ещё не означает, что каждый член команды может делать любую работу. Необходимо и достаточно, чтобы все члены команды в совокупности могли сделать всё. Команда, укомплектованная всеми необходимыми узкими специалистами, каждый из которых может сделать только "свою" работу и кроме него в команде никто её не может сделать, уже является кросс-функциональной.

Матрица компетенций помогает команде взять ответственность коллективно. Однако, сама по себе, в отрыве от других мер по командообразованию она не поможет.

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

Agile-игры на самоорганизацию

Можно вдохновиться Agile и самоорганизацией через книги, статьи, общение, наставничество, через практику, и наконец обучение на курсах, тренингах. Самый простой и быстрый способ убедить команду попробовать работать самоорганизованно (без тимлида) - нарисовать на флипчарте структуру коммуникаций через тимлида и спросить у команды, где тут узкое место? И дальше вести дискуссию в нужном ключе. Это может сработать, а может и нет.

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

Перед началом игр, договоритесь с группой о следующем:

Строевая (Line-up)

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

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

Давайте попробуем снова. Чтобы было честно, попросите выстроиться в другую линию, поперек предыдущей. И уже не по возрасту, а по времени работы в текущей должности. Укажите крайнюю точку которая будет для тех, кто "сегодня первый день на новой должности", и противоположную крайнюю точку для тех, кто "уже 40 лет проработал на текущей должности", а все остальные "располагаются между этими двумя точками в порядке длительности работы на текущей должности". Скажите, что на эту задачу у всех тоже только одна минута.

Задайте вопрос, убедитесь, что все всё поняли: "какие есть вопросы?". Громко объявите старт и запустите таймер. Через минуту остановите таймер, у вас скорее всего будет отличный результат. Если людей мало (15-20 чел), то они справляются гораздо раньше, чем минута истечет.

Попросите группу поделиться своими ощущениями: "Как это было по сравнению с работой под руководством? Это было легко, не смотря на то, что изначально никто не знал, каким именно будет результат."

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

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

Попросите участников поделиться своими мнениями и комментариями о самоорганизации.

Треугольники

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

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

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

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

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

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

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

Самоорганизация нужна всегда и везде?

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

В каких ситуациях самоорганизация не нужна:

Встречал такую ложную ассоциацию: самоорганизация = скрам. Да, чтобы применить scrum, потребуется создать самоорганизованную комнаду. Однако, создание самоорганизованной команды ещё не означает применение scrum-фреймворка. Самоорганизация является лишь одним из шести принципов scrum. Чтобы разобраться зачем бизнесу нужен скрам и в каких ситуациях, можно почитать мою статью на эту тему. Однако, кроме scrum, самоорганизация может помочь и в операционке. Коллектив, который работает в simple/complicated доменах, всё равно сталкивается с потерями типа "мури" и "муда", не говоря уже о том, что сотрудники - это люди, и они болеют, стареют, выгорают, умирают, и т.д. Для управления коллективом можно применить самоорганизацию в составе бесструктурного подхода (аля teal-организация).

А как же product owner? Почему он должен быть single person, а не comittee? Это очень хороший вопрос, и отдельная тема для статьи. Всем спасибо, кто дочитал до конца.

Источники