От контроля к самоорганизации в команде

Доклад на конференции AgileDays 23 марта 2018 года. Слайды доклада

Василий Савунов, Agile Coach, ScrumTrek, Москва

Как обычно руководят

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

Управляя директивно, он транслирует своим подчиненным месседж: “Слушай меня, делай что я говорю. Если возникнут вопросы и непонятки — спроси у меня.”. Классика, правда?

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

Если он на справляется — в силу разных причин, то эта модель управления испытывает большие проблемы.

Давайте разберем, какие уязвимые места у этого подхода.

Проблема №1. Менеджер, как источник энергии

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

Если у нас несколько команд, то менеджеру приходится толкать каждую, чтобы она двигалась. Чем больше команд, тем больше менеджер “рвется на части”.

Усугубляет ситуацию еще и то, что менеджер работает с людьми, а значит, чтобы двигать проект дальше, он должен постоянно  вникать в проблемы конкретных людей. Он постоянно расходует много собственной «душевной энергии» (каким бы черствым он ни был). Если он достаточно ответственнен, и будет продолжительное время пытаться всюду успеть и “рвать жилы”, то  произойдет одно из двух — либо он эмоционально выгорит, а потом заболеет или уволится, либо, чтобы сохранить душевное здоровье, закроется и превратиться в бездушного тирана, от которого побегут люди. 

Проблема №2. Отсутствие общего видения и ответственности

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

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

Помните как у Райкина: “К пуговицам претензии есть? К пуговицам претензий нет” — так же и в нашем случае.

Следовательно, при директивном подходе, когда всем “дирижирует” менеджер, вовлеченность людей в создание конечного результата почти нулевая.

Во-первых, по башке все равно получит менеджер. Во-вторых, влияния на конечный результат у людей все равно нет (раз уж они даже не знают, каким он должен быть). Так что они расслабляются и говорят себе: “У менеджера голова большая, пусть бегает, раздает нам задачи и все досконально объясняет. А я сделаю ровно так, как он сказал, даже если он ошибается. Ничего страшного, потом переделаю. Мне ж за конечный результат не платят, а платят за то, чтобы я четко выполнял указания менеджера.” 

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

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

В итоге, мы получаем работников в стиле “еж — птица гордая: пока не пнешь, не полетит”. Но сделали их такими мы сами своими действиями, как менеджеры, как руководители

Работа в сложном проекте

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

Ещё до того, как я заинтересовался Agile, мне довелось поработать в одной проектной компании.  И вот клиент заказал спроектировать большой торговый центр. Представьте себе: колоссальные площади, колоссальные объёмы электричества, водоснабжения, всего-всего-всего. Разные зоны: фуд-корт, магазины, парковки, зоны отдыха, туалеты и т.д. То есть, действительно, очень сложный проект.

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

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

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

Это реальность, которую я видел своими глазами. Вот посмотрите ниже, какой страшный и сложный план ТЦ надо сделать.

Посередине торговый центр с планом коммуникаций. А вокруг него — те ограничения, в которые надо вписаться. Перечислим, что это: 

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

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

3) Есть дорожная ситуация, и надо в ГИБДД договориться, что мы своим проектом не нарушим движение на МКАДе или ещё что-нибудь в этом роде.

4) И как вишенка на торте, проекту надо пройти госэкспертизу.

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

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

Менеджер в сложном проекте

Основные проблемы понятны: узкая специализация, отдельная нормативная база у каждого специалиста, необходимость согласовывать между собой планы. Как в этой ситуации вести себя менеджеру? Может надо поддать жару, и на всех давить, мол, «давай-давай, срок горит, так что работаем в выходные и по ночам». Но это очень чревато, потому что, если людей загнать, то может произойти «взрыв котла» этого поезда, и мы можем потерять отдельных людей, а можем и всю команду.

Что ещё он может сделать? Может усилить контроль и заняться микроменеджентом? Начать вникать вообще во все детали, всем управлять, и может быть даже заменить собой всех специалистов, и делать всё самому? А если он заболеет от перегрузки? Тогда проект встанет, сроки поедут. И… ничего хорошего.

Может ему надо ввести личный KPI? Давайте каждому свой KPI поставим: быстрее свою часть работы сделал — молодец, тебе вот бонус. Но тогда получится как в басне «лебедь, рак и щука» — все тянут в свою сторону, а на выходе получится какой-то уродец, в котором нельзя ни работать, ни торговать, ничего вообще.

Получается, все эти варианты не сработают. 

А обстоит дело с успешностью подобных проектов? Я специально смотрел статистику, и получается, что

70% таких проектов завершаются успешно! 

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

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

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

Но это всё общие слова, давайте разберемся, как конкретно в этом кейсе, который я описал, всё происходило.

Во-первых, общая цель

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

Во-вторых, частые коммуникации

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

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

В-третьих, знание контекста друг друга

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

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

Проблемы самоорганизованных команд

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

Риск №1 — групповая динамика

Она становится понятна, если посмотреть на модель Брюса Такмана.

Такман описал этапы, которые проходит группа,  прежде чем стать командой. Самый страшный этап — это этап «шторминга» (Storming), когда команда только сформирована и начинает делать общее дело. На этом этапе её начинает “штормить”, то есть участники начинают ругаться между собой, например: «Нет, надо делать так!», «Нет — этак!», «Ты не понимаешь! Где тебя учили?» и так далее. На этом этапе команда даже может развалиться, но если она этот этап преодолевает, то дальше начинается этап набора взаимного опыта работы, так называемый «норминг», и они в итоге команда выходит на максимальную эффективность. 

Как можно этап шторминга нивелировать и преодолеть? Нужно хорошо поработать на первом этапе модели Брюса Такмана — форминге (Forming). Это когда люди только-только встретились, только познакомились, и начали вообще что-то делать вместе. Очень важно на этом этапе проработать совсместно с командой общее понимание цели, общее понимание норм поведения в команде (что мы считаем хорошим, что мы считаем плохим), выработать совместные правила работы.

Например, программисты знают такую примету: “в пятницу вечером делать релиз — плохо”. Ну, потому что выходных может не быть в итоге, правильно? 🙂 Это пример нормы. И мы, как команда, об этой норме тоже должны договориться. Если на старте работы команды проговорить и выработать общие цели и нормы, то шторминг можно пройти достаточно безболезненно. 

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

Риск №2 — выйти за рамки допустимого

Если у нас команда самоорганизована, то она, как правило, очень уверена в себе, и она может уйти куда-то не туда в плане реализации своих задач. 

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

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

Риск №3 — команда-банда

Когда команда становится очень уверенной в себе, зрелой, она может начать «звездить». То есть, начинает думать про себя и демонстрировать всем: “мы крутые, а все остальные нет”. Начинается отъедание чужих ресурсов, борьба с другими подразделениями, конфликты и прочие неприятные для организации вещи. Это очень опасная вещь. Чтобы этого избежать, стоит заранее обговорить с командой: «Ребята, хоть вы и работаете в команде, но при этом находитесь в рамках организации. И в этой организации, помимо вас, есть другие отделы, которым тоже надо дать возможность работать. И если вы это не будете учитывать, то как бы вы ни делали хорошо свою работу, нашей компании станет хуже, а не лучше. Поэтому учитесь договариваться». Если этот контекст будет в голове с самого начала, то этот риск можно легко пройти.

Риск №4 — расхождения в видении конечного результата

Для очень зрелых команд может получиться так, что видение команды на будущее продукта отличается от видения организации. Команда уже настолько уверена в себе, что начинают спорить с бизнесом: «Видение бизнеса неправильное, на самом деле должно быть вот так, поэтому пойдем туда». Это хороший, с одной стороны кейс, если компания заинтересована в дочерних компаниях, чтоб организовать внутренний корпоративный стартап, например. Но если таких планов у компании нет, то такое поведение наносит вред. Надо заранее про это проговорить и сказать: «Ребята, туда мы не ходим. Принятия решения о бизнес-целях в другом месте принимаются, а мы просто эти цели реализуем наилучшим образом». 

Предусловия к самоорганизации

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

Условие №1. Коридор для самостоятельного принятие решений

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

Условие №2. Ощущение необходимости изменений

Самый сложный момент — это самоуспокоенность. Часто приходишь в команды, а они говорят, что у них все в порядке, никаких проблем нет, и не надо ничего менять. Тогда очень важной задачей становиться создать ощущение опасности, и необходимости изменений. То есть: «Да, мы так работали раньше, но ситуация на рынке поменялась, и так уже не сработает. Мы в опасности, надо что-то менять». Ну, и дальше можно предложить, какие могут быть варианты, обсудить это с командой, дать им возможность внести свою лепту в принятие решения. 

Условие №3. Открытость системы

Бывает, что в команде собрались очень узко специализированные специалисты и они не пускают к себе никого. Мол, мы сами все знаем, не лезьте. Это “черный ящик” для бизнеса, и как только мы его открываем, делаем более прозрачной его работу, то всё меняется, система становится открытой, но участники начинают ощущать тревогу, даже если никто их не ругает, никак не мешает и т.д. Но все на виду, все прозрачно. Для многих это стресс. Поэтому важно открыто поговорить о необходимости таких изменений, об их причинах.  

Модель Коттера

Чтобы запустить изменения, стоит использовать модель изменений Коттера.

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

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

План действий

С чего стоит начать?

Шаг 1. Общение

Надо встретиться с командой и честно поговорить, каковы наши цели. И задать им вопрос: «вот для того, чтобы нам эти цели достичь, как вы думаете, что сейчас, в нашем текущем процессе нам мешает, чего не хватает? А что, наоборот, может быть точкой роста? На что мы можем опереться и двигаться дальше?» Вот с этого откровенного разговора вообще всё начинается. 

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

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

Шаг 2. Доверие

Есть отличная книжка Патрика Ленсиони «Пять пороков команды», в ней есть очень важные моменты, которые описывают, почему во многом не получается командная работа. Сейчас разберем подробнее. Все базируется на том, что если у нас нет доверия между собой, то, мы не можем разговаривать на откровенные темы, не можем честно давать друг другу обратную связь и это все внешне выглядит, как отсутствие конфликтов. Но если все постоянно уходят от конфликтов, то тогда у нас появляется необязательность к своим обязанностям. «Я знаю, что даже если я ленюсь, даже если я плохо работаю, мне никто ничего не скажет, потому что у нас так принято». 

Следовательно, если я не требователен к себе, то я не буду требователен и к своему коллеге. Даже если я знаю, что он косячит, я ему ничего не скажу. Мы все молчим, у нас есть «подковёрные» интриги, игры, но снаружи тишь да гладь, а внутри “террариум единомышленников”. Вот во что все это превращается. А вершина всего этого — безразличие к общему результату у всех.

А всё начинается с доверия, точнее с его отсутствия. Что же с этим сделать? 

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

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

И конечно, на выходе с ретроспективы должен быть конкретный план улучшения, с конкретными ответственными. Желательно формировать план действий по SMART, чтобы было всем ясно — что мы делаем, как замеряем, при каких условиях считаем, что пункт плана выполнен. Это первые шаги в борьбе с необязательностью. Прозрачность обсуждения и результатов — вот что нам здесь нужно.

Наконец, отсутствие требовательности внутри команды лечится очень просто, если у нас общая цель. Если общий показатель эффективности, за который мы все отвечаем. Тогда мы начинаем понимать, либо мы все вместе выплывем, либо нет. И вот это порождает требовательность друг к другу. Не все к этому готовы, многие уйдут. И это нормально. Останутся, только те, кто действительно готов честно работать и честно друг другу помогать. 

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

Шаг 3. Ответственность за решения

Очень часто команда любые непонятки делегирует руководителю. По любой мелочи, по любому вопросу идет к руководителю и требует у него ответ, решение. У руководителя башка пухнет, но команде хорошо. При этом получается очень интересная вещь: по сути те, кто задают вопросы — становятся для руководителя начальниками. Они ставят ему вопрос, потом подходят и спрашивают: «Ну, что ты решил? Как там с моим вопросом?». Получается, они с него спрашивают, а он должен им дать готовое решение.

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

Для него — здорово. Но не для вас и не для компании. Если вы ушли в отпуск, то сотрудник  скажет: “Нет, нет, я такой вопрос решать не могу, вот вернется гуру из отпуска, тогда я у него спрошу, как это делается и после этого я пойду и что-то буду делать. 

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

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

Выход — использовать коучинговые, развивающие вопросы

Пришёл к тебе человек, например с вопросом: «Вот как мне мне лучше сделать задачу — так или так? Что выбрать?». И первое что надо спросить: «Ты сам-то что думаешь? Ты ко мне ведь не с нуля пришёл? Я вообще, в первый раз об этой проблеме слышу, а ты даже с вариантами пришел ко мне. Расскажи, почему именно эти варианты? А чем они отличаются? В чем сложность выбрать из них один? А у кого можно спросить? У эксперта? А когда ты его встретишь? Давай ты с этим экспертом поговоришь, потом мы обсудим, что получилось и выберем действительно наилучший вариант». То есть, дайте человеку хотя бы подумать чуть-чуть самому. Если он найдет решение сам, у него повысится самооценка, и он будет более уверен себе в следующий раз. И в следующий раз он придёт к вам не с вопросом, а с готовым решением, и обоснует его.           

Ситуационное лидерство Херши-Бланшара

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

1. На первом уровне зрелости, когда еще люди новички и пока ещё ничего не понимают в будущей работе, но мотивация есть, потому что не представляют себе всю сложность работы. Такой вот неосведомленный оптимизм. Вот с ними надо работать в директивном стиле: делай раз, делай два, и не спрашивай «почему». Так как нужно давать работающие, готовые решения, которые дадут результат, и не позволят мотивации упасть. 
2. Следующая стадия, когда команда набила себе шишки, поняла, что не все так просто, он еще опыта особо не приобрела. Мотивация у них падает, потому что оказалось все не так просто, как он думал. Это называется осведомленный пессимизм. Теперь нужно перейти к убеждающему стилю руководства, когда мы объясняем и “продаем” команде решения. Например, говорим: “Смотри есть такие варианты: раз, два, три. А вот этот самый лучший потому что…” и дальше объясняем, почему. То есть, мы даём команде возможность наработать базу кейсов, базу вариантов, чтобы у них уверенность в себе и повысилась мотивация. 
3. И после этого, когда у них достаточно опыта и понимания появится, надо переходить к следующей стадии — делегирование. Говорим: “А давайте вы сами подумаете над вариантами, принесете их мне, мы с вами обсудим, и я выберу наилучший. Ответственность за выбор варианта еще на руководителе. Но мы уже отдаем команде возможность выработать варианты, и обосновать их. 
4. И следующее — идеальное — состояние, когда руководитель может сказать: «Так, вот есть срок, есть задача, соберитесь вместе, выберите вариант решения. Приходите ко мне, обоснуйте, расскажите риски и выгоды, обозначьте, какие ресурсы вам нужны и какая помощь от меня». Это уже визирующий стиль. Когда мы лишь держим руку на пульсе, чтобы в нужный момент подключиться, но всю полноту ответственности за выбор вариантов, обоснование, разработку плана действий и т.д. — передаем в команду. 

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

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

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

Шаг 4. Положительное подкрепление

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

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

И включается древний биологический механизм “прикинуться мертвым”. Подсознательно. Человек думает: «Вот здесь, где я сейчас нахожусь без движения, безопасно. А если я сделаю шаг — меня могут наказать. Потому что я ни разу не видел, чтобы меня хвалили за инициативу, даже если все получалось хорошо. Так что я, пожалуй, ничего делать не буду, и вообще двигаться перестану”. И он перестает проявлять инициативу, не пытается экспериментировать, не пробует ничего нового. Это называется “выученная беспомощность”. 

Что же делать? Нужно обозначать желаемое поведение через положительную обратную связь. Если есть движение в правильную сторону, даже малейшее, то нужно похвалить. Просто прилюдно скажите: «Как здорово у тебя получается! Отлично! Давай, продолжай в том же духе, молодец!». Это даёт понимание, куда можно и нужно двигаться, чего от нас хотят.

Рекомендуемая литература

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

1. «5 пороков команды» Патрика Ленсиони — это про доверие и основы командообразования.
2. «Одноминутный менеджер и обезьяны» — это про то, как учить команду думать самостоятельно. 
3. «Разверните ваш корабль» — это очень интересная книга. Она написана бывшим капитаном подлодки военно-морского флота США, который в силу обстоятельств, попал не на тот тип подлодки, на которую он учился. А в ВМФ США капитан должен свою подлодку знать до винтика, и управлять ею «от и до» — команда лишь исполняет приказы. И автор готовился управлять одним типом подлодок, а его перебросили на другой.  И у него не было другого выхода, как полагаться на команду. В итоге он привел команду к самоорганизации. К чему всё это привело? Во-первых, эта подлодка, изначально была худшей в военно-морском флоте США, благодаря ставке на самоорганизацию стала лучшей, выигрывала несколько лет подряд военные учения и так далее. Кроме того, 15 офицеров, подчинённых этого капитана, сами стали капитанами других подводных лодок. Это очень большой процент.

Самоорганизация в человеческой природе

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

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

Есть пример более глобальной самоорганизации на уровне города. Может, кто-нибудь помнит, в 2017 году был теракт в питерском метро. И вот есть скриншот Яндекс.Карты, на котором видно, что там произошла самоорганизация в рамках города. Таксисты задрали цены, метро закрыли, автобусы и троллейбусы, и прочий общественный транспорт забит людьми. Много пенсионеров не смогли добраться до дома, и растерянно стояли на остановках, не зная, что им делать.

И вдруг частники, на своих машинах стали просто подвозить людей. Например, писали на Яндекс.Карте: «Еду туда-то, могу забрать отсюда». Люди самоорганизовались и стали помогать друг другу! Еще открыли платную дорогу, сделали её бесплатной. И вот это произошло в рамках всего города. 

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