Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, 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 будут отдельным треком. Билеты продаются здесь. А если вы хотите выступить как спикер, то подать заявку на выступление можно здесь.