Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori. Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий. Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом  на конференции TeamLead Conf 2021 можно посмотреть здесь. Про самоорганизацию сейчас говорят из каждого утюга. Лиды и SCRUM-мастера применяют случайные техники и практики в команде, чтобы её добиться. Методом больших чисел это иногда срабатывает, но чаще всего — нет. Тогда все винят SCRUM, говорят, что продакт-менеджеры какие-то не такие, а организация — не бирюзовая. Я считаю, что добиться самоорганизации (или автономности — для адептов правильной терминологии) можно в практически любой организации и команде. Есть 5 шагов для самоорганизующейся команды, из которых первые три — это анализ, подготовка и построение дизайна системы (культуры), в которой будет вариться команда. Конечно, все говорят, что люди и взаимодействие важнее инструментов и процессов, но ваша команда живет не в вакууме, а в системе, и именно система формирует этих людей. Ваша задача создать систему и запустить в неё команду. Цель — основа для самоорганизации. Без нее люди будут работать работу и решать свои проблемы. Или команда объединится вокруг неформальногоо лидера и пойдет за его целью, которая необязательно будет совпадать с вашей.  Цель (в терминологии 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%. Еще один важный критерий лично для меня: цель (или награда от неё) должны зажигать. Если цель вас не зажигает, то вы либо выгорите, либо потеряете интерес к проекту до его окончания. Да и люди вам просто не поверят — про какую цель он говорит, если сам в неё не верит? В процессе выявления цели мы понимаем, что нам нужно и по каким критериям нас и команду будут оценивать.  Благодаря этому команда сможет измерить результат и понять, туда ли она идет. После того как цель мы нашли, определим то, что мешает нам ее достичь или ограничивает наши действия. Я выделяю 4 типа ограничений: Корпоративные — бизнес-домен (банки, телеком, здравоохранение), внутренние правила. Это самые жесткие ограничения, которые вы никак не поменяете. Например, если это банк, то в ограничениях будут: шифрование, регуляторка и какая-нибудь шина. Проектные — бюджет, сроки, контракт. Человеческие — ваша команда, руководство, заказчик. Технические — стек, инфраструктура, требования к коду/тестам. Рассмотрим два реальных примера из жизни с одинаковой целью: мигрировать legacy-продукт с нуля на новые технологии за 1,5 года, но с разными типами ограничений. Команде слева дают полный карт-бланш: можно работать с PROD, нанимать DevOps, ошибаться и вообще делать, что хочешь. И самое главное, у команды есть 5 «чёрных поясов», с которыми можно идти в разведку. Справа — классический энтерпрайз. Денег нет, заказчик (PO) — классический менеджер из большой компании, который планирует уйти на пенсию. Только он знает, как работает старый продукт, и только он может придумать требования. Срок в полтора года указан даже в цели, потому что после этого он уходит на пенсию. По технике тоже все плохо.  Казалось бы, цель одна и та же, но ощущения и привкус от проектов разные :-)  Выявление ограничений крайне критично для правильного выбора людей. Если вы берете в команду инженеров, которых демотивируют существующие ограничения, то самоорганизации не будет. Это будет группа вечно ноющих и токсичных людей, которые уйдут при первой удачной возможности или просто выгорят. Выявляются они так же как и цель: говорим с менеджментом; говорим с заказчиком. В дополнению к этому: читаем контракт; читаем требования; смотрим стек и его ограничения; читаем внутренние документы; читаем бэклог, Jira, Confluence. Пример из жизни, как бывает, если этого не делать. В одном контракте было написано: 75% покрытия тестами. Мы покрыли бэк, так как на фронте не было никакой логики. Но оказалось, что нужно покрыть и фронт, который был написан на первом Angular. Чтобы закрыть эту бессмысленную галочку, потребовалось довольно много нервов и овертаймов. Ограничения позволяют не ломиться в закрытые двери и не тратить время на заведомо неработающие решения. А также дают понимание, можно ли вообще достичь цели.  Тем не менее многие тимлиды и коучи пропускают этот этап, а вместо него сразу пытаются внедрить, например, идеальный SCRUM в классическую энтерпрайз-команду. Тогда как благодаря ограничениям можно понять, стоит ли вообще ввязываться в проект. Мы выявили первые два пункта, и можем переходить к созданию дизайна системы, в которой будет работать команда. Это похоже на архитектуру софта: есть функциональные и нефункциональные требования, есть ограничения, и вы из знакомых вам кубиков строите дизайн. Основные части, которые я обычно включаю в дизайн: Методология/фреймворк и его уровень; Структура команды; Планы на развитие людей, их желания и амбиции; Время жизни и жизненные этапы команды и проекта; Взаимосвязи и влияние. Давайте разберем дизайн на сквозном примере с классическим менеджером (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 диаграммы.  Процедуры входа, запуска или перезапуска команды хорошо описаны у Agile-коучей, поэтому я не буду на них подробно останавливаться. Наши основные задачи на этом этапе: Дать понять, что мы стартовали; Транслировать цель и ограничения; Рассказать/совместно установить правила; Показать следующие шаги; Создать доверие. Самое главное, чтобы вы пришли в команду и показали, что что-то поменялось. Вы начинаете транслировать цель и ограничения, и повторяете это постоянно. Если на ретро или митингах возникают предложения что-то убрать, то напоминаете про ограничения, что это поменять нельзя. Процедуры по установке правил и протокол команды гораздо лучше знают SCRUM-мастера. Поэтому этот этап можно отдать на откуп им. Если таких нет, а вы сами не любите этим заниматься, то проведите серию обычных встреч. Внимательный читатель заметит в шагах прохождение по модели Херши-Бланшар. Самый последний и самый простой этап, но довольно механический. После того как вы создали систему и подобрали соответствующих людей, их нужно подвести к самоорганизации. Конечно, люди смогут это сделать и сами, но это займет больше времени. На этом этапе вы проверяете свои гипотезы и показываете, как добиться успеха. На каждом шаге вы рассказываете и показываете команде, что и зачем вы делаете. Тут важно все-таки добиться успешного спринта/дедлайна или выполнения какой-то значимой задачи. На базе вашего дизайна вы начинаете «продавать» задачи нужным людям. Для этого нужно выделить тех людей, которым это может быть интересно. Поговорите с ними и начинайте делегировать. Когда предлагаете взять сложную задачу, то всегда обещайте помощь и обучение (и выполняйте обещание, в разумных пределах). Рассказывайте все детали и досконально объясняйте причины и следствия, передавая свой опыт. Потом дайте им попробовать еще пару таких же задач. Если у человека получается, то вы все меньше и меньше вовлекаетесь в этот процесс. Но, конечно, если вопросы возникают, то помогаете. На этом этапе люди поверили в себя и готовы брать ответственность. Вы все меньше и меньше детализируете задачи, то есть урезаете инструкции и информацию в бэклоге.  И вот теперь начинается магия самоорганизации. Правильно подобранные люди понимают, куда идти можно, куда — нельзя, а куда — не нужно. Вы им показали, что можно общаться, что успех возможен. И научили их, что нужно делать. Дальше они начинают креативить, а вы должны оставаться доступным для ответов или советов, но общаться в режиме сильных вопросов: «А ты что думаешь?». Естественно, на прямые вопросы вы отвечаете, но в целом смотрите на процессы со стороны. Тут самое главное — не сорваться и не начать делать всё самому. Если человек не научился решать проблему, то он еще не готов к самоорганизации. Если команда не прошла без вас через проблему, то она не умеет этого делать и не будет устойчива к кризисам. На этом последнем этапе вы входите в режим поддержки и своей обычной работы. Теперь вы — участник процесса и рядовой сотрудник в самоорганизующейся команде. Вы уважаете решение команды и имеете такое же право голоса, как и все остальные. То есть вы можете только продавать ваше решение, а не директивно его проталкивать, иначе вся самоорганизация рассыпется. У вас могут поменяться требования извне, то есть цели и ограничения. В этом случае вы начинаете эти циклы заново. Иначе, в случае какого-то кризиса или серьезного изменения команда может рассыпаться, потому что она привыкла жить в старых ограничениях и целях, а новые вы ей не сообщили. Люди сами могут о них не узнать. Поэтому вы постоянно мониторите всё, что происходит сверху, и, в случае изменений, меняете систему, а люди уже сами в ней самоорганизуются. Когда система готова, а команда самоорганизована, вы можете заниматься любимым делом. Я обычно ухожу из команды, но кто-то может начать писать код или заниматься SCRUM-мастерингом. Понимание вашей команды как системы поможет в осознанном создании самоорганизации, трансформации, поиске проблем и починке сломанного взаимодействия.  Система формирует людей. Если вы создадите систему с понятными правилами, целями и ограничениями, транслируя их и закрепляя культуру своими действиями, то наступит самоорганизация или, как минимум, автономность. Можно, конечно, пробовать рандомные методы, но результативность будет гораздо хуже (проверено). Alarm! Разыскиваются самые популярные time-killers! Помогите нам их найти, а мы поможем найти оружие против них! Для этого мы подготовили опросник (заполнение займёт не более пяти минут). А по результатам опроса мы напишем статью, расскажем о самых убийственных time-killers и как от них избавиться. Конференция TeamLead Conf 2022 пройдет 21 и 22 марта совместно с KnowledgeConf. Доклады по Knowledge будут отдельным треком. Билеты продаются здесь. А если вы хотите выступить как спикер, то подать заявку на выступление можно здесь.