Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.

Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.

Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.

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

Я считаю, что добиться самоорганизации (или автономности — для адептов правильной терминологии) можно в практически любой организации и команде.

Как я это делаю

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

I. Цель

Цель — основа для самоорганизации. Без нее люди будут работать работу и решать свои проблемы. Или команда объединится вокруг неформальногоо лидера и пойдет за его целью, которая необязательно будет совпадать с вашей. 

Цель (в терминологии Scrum) — это Vision/Goal. Многие компании сейчас активно транслируют цель или миссию и многие Agile-коучи и SCRUM-мастера ищут этот Грааль — Vision. Но вот мало кто доносит или декомпозирует цель до уровня команды.

Типичные симптомы отсутствия цели — команда молчит на ретроспективе, обсуждает «цвет стаканчиков для кофе» или троллит скрам-мастера.

Как выявлять цель?

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

После чего переформулируйте все собранные данные в измеримые единицы и проведите повторное согласование целей с менеджером и заказчиком.

Критерии хорошей цели

Раньше это был SMART, сейчас все любят говорить про OKR (Objective & Key Results).

Хорошая цель должна быть согласована с руководством и заказчиком вплоть до дат и понятных критериев ее достижения. Например, «поставить релиз к 31.12.2021 года», «поставлять продукт каждые 3 недели заказчику с таким-то процентом качества» или «помогать бизнесу развивать продукт по оговоренным показателям».

Пример из практики. Недавно меня попросили «поставить команду на рельсы». Когда я начал выяснять, что менеджер имеет в виду, то оказалось, что требуется создать процесс поставки в команде из трёх человек. Чтобы определить критерии успешности, я поговорил с заказчиком и выяснил, что если команда будет ошибаться один раз в 5 спринтов, то это не будет считаться провалом. 

В итоге у нас получилось два критерия: поставка раз в 3 недели с 80% успешности и оценка команды заказчиком — 4-5 из 5. Дополнительной целью стал рост команды до 5 человек и реализация новых модулей в разработке.

Более классический пример. Меня назначили тимлидом в команду вместо другого лида. Цели озвучили как «Нужно чтобы ничего не падало, внедрить SCRUM и починить процессы». Но фактически оказалось, что нужна поддержка и развитие продукта до 31.12.2022 года в рамках запросов бизнеса с предсказуемой поставкой раз в месяц и следующими критериями успешности:

• Релизы с частотой раз в месяц с уровнем качества выше текущего;

• Уровень текучки людей не более 15% от размера команды;

• Оценка PO/бизнеса «4-5 из 5» для команды;

• Velocity = xx, предсказуемость поставки = 85%.

Еще один важный критерий лично для меня: цель (или награда от неё) должны зажигать. Если цель вас не зажигает, то вы либо выгорите, либо потеряете интерес к проекту до его окончания. Да и люди вам просто не поверят — про какую цель он говорит, если сам в неё не верит?

Резюме

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

II. Ограничения

После того как цель мы нашли, определим то, что мешает нам ее достичь или ограничивает наши действия. Я выделяю 4 типа ограничений:

• Корпоративные — бизнес-домен (банки, телеком, здравоохранение), внутренние правила. Это самые жесткие ограничения, которые вы никак не поменяете. Например, если это банк, то в ограничениях будут: шифрование, регуляторка и какая-нибудь шина.

• Проектные — бюджет, сроки, контракт.

• Человеческие — ваша команда, руководство, заказчик.

• Технические — стек, инфраструктура, требования к коду/тестам.

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

Команде слева дают полный карт-бланш: можно работать с PROD, нанимать DevOps, ошибаться и вообще делать, что хочешь. И самое главное, у команды есть 5 «чёрных поясов», с которыми можно идти в разведку.

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

Казалось бы, цель одна и та же, но ощущения и привкус от проектов разные :-) 

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

Выявление ограничений

Выявляются они так же как и цель:

• говорим с менеджментом;

• говорим с заказчиком.

В дополнению к этому:

• читаем контракт;

• читаем требования;

• смотрим стек и его ограничения;

• читаем внутренние документы;

• читаем бэклог, Jira, Confluence.

Пример из жизни, как бывает, если этого не делать. В одном контракте было написано: 75% покрытия тестами. Мы покрыли бэк, так как на фронте не было никакой логики. Но оказалось, что нужно покрыть и фронт, который был написан на первом Angular. Чтобы закрыть эту бессмысленную галочку, потребовалось довольно много нервов и овертаймов.

Резюме

Ограничения позволяют не ломиться в закрытые двери и не тратить время на заведомо неработающие решения. А также дают понимание, можно ли вообще достичь цели. 

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

III. Дизайн системы

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

Основные части, которые я обычно включаю в дизайн:

• Методология/фреймворк и его уровень;

• Структура команды;

• Планы на развитие людей, их желания и амбиции;

• Время жизни и жизненные этапы команды и проекта;

• Взаимосвязи и влияние.

Давайте разберем дизайн на сквозном примере с классическим менеджером (PO). Что у нас есть? Контроль за фазами, проблема сдачи спринтов (у нас много технических ограничений по проверке кода и покрытия), интеграция в кучу систем и не обученный PO. Цель: мигрировать legacy-продукт с нуля на новые технологии за 1,5 года

Фреймворк

Сначала выбираем фреймворк — это база для наших внутренних процессов. У меня есть три любимых инструмента:

Для нашего примера чистый SCRUM не подойдет, но у нас есть PO и необходимость обратной связи. Поэтому берем Scrumban. Kanban позволит контролировать поток до и после, а SCRUM — получать обратную связь.

Обязательно делаем для себя пометку — внимание на обучение PO, контроль потока и использование SCRUM-практики. При найме SCRUM-мастера предупреждаем его, что чистый SCRUM у нас работать не будет, объясняя — почему.

Структура команды

Дальше выбираем то, как команда будет организована внутри. Она отлична от фреймворка! Я обычно использую один из трех вариантов:

• Плоская структура — это когда все «черные пояса», все равны и все общаются со всеми, в том числе с PO/руководством. Есть личная и командная ответственность. Этот вариант хорошо работает со Scrum.

• Классика — это иерархический подход, в котором вы — самый главный, и вся ответственность лежит на вас.

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

Структура тоже зависит от ограничений и цели.

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

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

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

Люди и планы

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

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

Итак, опишите условный профиль нужных вам людей, чтобы отделить тех, кто в пять вечера в пятницу хочет ехать на дачу (классических выгоревших специалистов) или гик-фриков, которым скучно, если они не работают по 16 часов в сутки (если только именно они вам не нужны). На схеме такой профиль может выглядеть так:

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

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

Резюме

Для этого небольшого проекта алгоритм выглядит так:

На этом этапе вы проектируете, как будет работать команда. Дизайн помогает осознанно выбрать фреймворк и структуру и создать базу для разговоров с людьми. После чего определить границы за которые не стоит вести команду и создать правила общения со всеми людьми внутри и вне вашей команды. Так вы создадите каркас культуры. Это, кстати, можно делать при помощи System Thinking диаграммы. 

IV. Запуск/вход в команду

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

Наши основные задачи на этом этапе:

• Дать понять, что мы стартовали;

• Транслировать цель и ограничения;

• Рассказать/совместно установить правила;

• Показать следующие шаги;

• Создать доверие.

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

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

V. Делаем

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

Показываем, как надо

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

Даём попробовать

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

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

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

Встаём за спину

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

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

Естественно, на прямые вопросы вы отвечаете, но в целом смотрите на процессы со стороны. Тут самое главное — не сорваться и не начать делать всё самому.

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

Отходим в сторону

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

Важный нюанс про наблюдение и поддержку. 

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

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

Резюме статьи

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

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

Alarm! Разыскиваются самые популярные time-killers! Помогите нам их найти, а мы поможем найти оружие против них! Для этого мы подготовили опросник (заполнение займёт не более пяти минут). А по результатам опроса мы напишем статью, расскажем о самых убийственных time-killers и как от них избавиться.

Конференция TeamLead Conf 2022 пройдет 21 и 22 марта совместно с KnowledgeConf. Доклады по Knowledge будут отдельным треком. Билеты продаются здесь. А если вы хотите выступить как спикер, то подать заявку на выступление можно здесь.