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

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

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

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

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

Однако:

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

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

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

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

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

Чтобы занести самоорганизацию, есть инновационные игры. Например, ball game, апельсины. Самый простой - нарисовать на флипчарте структуру коммуникаций через тимлида и спросить у команды, где тут узкое место? И дальше вести дискуссию.

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

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

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

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