Привет, Хабр! Меня зовут Кристина, я скрам-мастер в МТС Web Services. Два года назад я попала в трайб, который резко начал масштабироваться и быстро вырос с двух до девяти команд — продуктовых и сервисных. Процессы за этим ростом не успевали: коммуникации начали сыпаться, терялись зависимости и регулярно ехали сроки. Кроме того, конфликты между командами приходилось лично разруливать C-level. А главной сложностью было то, что каждое планирование начиналось с чистого листа.
Мне предстояло во всем разобраться и наладить процессы. Вот только для команд я выглядела как «засланец» от бизнеса, который просто наблюдает, как все работают, а затем доложит руководству. А для топ-менеджмента — как сомнительная инвестиция, которая еще должна доказать свою полезность.
Но несмотря на все сложности, за год мы выстроили квартальное планирование на базе адаптированного SAFe: специалисты научились проводить его сами, зависимости сократились до минимума, а руководители перестали тратить управленческое время на выяснение, кто за что отвечает. Расскажу, как мы к этому шли, какие подходы сработали и какие уроки я для себя вынесла.
Методология: SAFe и ADKAR
В компании есть внутренний плейбук по методологиям, и SAFe — рекомендованный подход для масштабирования планирования и релизов. Нам было важно оставаться понятными внутри кластера, чтобы наши планы быстро могли считывать коллеги из соседних трайбов. Также единый формат квартального планирования помогает корректно оценивать зрелость команд.
Правда, использовать SAFe в совсем неизменном виде не получилось бы. Чтобы методология закрывала реальные проблемы и потребности, ее пришлось адаптировать с учетом уже существующих процессов, а также использовать и другие инструменты.
Так в рамках трансформации коммуникаций между командами я опирались на модель ADKAR как на практический фреймворк изменения поведения и рабочих привычек.
На этапе Awareness важно было зафиксировать саму проблему: между командами регулярно возникали сложности с согласованием, а приоритеты отдельных команд иногда препятствовали тому, чтобы взять задачу в работу. Это создавало разрывы в сквозном потоке поставки и снижало предсказуемость исполнения.
На этапе Desire нужно было сместить фокус с локальных командных приоритетов на общий результат для клиента. Команды начинали воспринимать себя не как изолированные единицы, а как часть одного продукта и единого value stream, где критично не просто «закрыть» свою часть работы, а обеспечить delivery end-to-end в срок.
Этап Knowledge стоило посвятить формированию общей модели взаимодействия: кто является владельцем какой зоны ответственности, как выстраивается межкомандная коммуникация, какие каналы и ритуалы используются для синхронизации. Это позволило бы снизить количество потерь на стыках задач и сделать взаимодействие более прозрачным.
На этапе Ability опираться на готовность команд к совместной работе: взять наиболее лояльные команды, уже настроенные на эксперимент, в качестве пилотной площадки для улучшения коммуникаций и проверки новых практик взаимодействия. Они помогли бы обкатать новый подход в реальных рабочих условиях.
И наконец, на этапе Reinforcement мы масштабировали бы удачные кейсы: результаты, полученные в пилотных командах, были представлены остальным участникам, чтобы закрепить новый способ работы через обмен практиками и внутренний peer learning.
В итоге все задуманное получилось, но главное то, с какими нюансами мы столкнули в процессе.
Первое планирование и неудача
Первое квартальное планирование я провела по той схеме, которую мне предложили коллеги. В департаменте уже был разработан стандартный формат для этого мероприятия, поэтому зять готовое, запустить, а уже потом адаптировать — показалось мне разумной стратегией. И это было первой ошибкой.
Потому что со стороны команд все это выглядело несколько иначе. К ним пришел новый человек, заставил всех что-то заполнить и провел мероприятие, результат которого не был никому понятен. Что произойдет дальше и будет ли так теперь всегда — никто не объяснил. Я поработала с руководством, согласовала формат, обсудила, что будем менять по итогам, но с командами этот разговор не состоялся. Получается, они остались вне контекста.
Мы решили выстроить процесс сверху вниз и не учли, что люди, которые будут в нем жить, должны понимать, как все работает, зачем и почему именно так. Поэтому коллеги как и раньше поучаствовали в планировании, а дальше ничего не происходило, ведь в командах его по-прежнему считали бюрократией.
Я сделала вывод, что недостаточно просто объявить, что теперь мы работаем по-новому. Важно объяснить, для чего это нужно, и убедиться, что все друг друга поняли. А для этого нужно погрузиться в контекст каждой команды — разобраться, как ее участники воспринимают информацию, сколько раз ее нужно повторить и на каком языке говорить с каждой.
Сначала доверие, затем процессы
После первого планирования я поняла, что нужно было начинать с людей. Девять команд, у каждой свой техлид, своя динамика, свое отношение к переменам. И к новому скрам-мастеру — тоже.
Некоторые были готовы пробовать изменения. Пара продуктовых команд согласились стать пилотными, и с ними мы считали нагрузку на команду, capacity, выделяли техдолг и прорабатывали зависимости. Это были мои «первенцы», через которых потом заработало сарафанное радио. «С Кристиной, хоть она и вредная, работать можно», — примерно так они обо мне отзывались.
Были команды, которые заняли выжидательную позицию. Техлиды наблюдали за мной как за новым человеком и пока не шли в изменения, аргументируя занятостью. С ними я работала аккуратно, например, приходила на ретро, если команда не против, наблюдала за дейликами и закрытием спринтов, а потом делилась наблюдениями с техлидом один на один. У нас был документ, доступный только руководителям, где я фиксировала зоны внимания по каждой команде — то, что нужно было улучшить и зачем. Там же всплывали вещи вроде тихих конфликтов, которые никто не хотел решать. Документ с зонами роста отдавался техлиду, и он на свое усмотрение вносил изменения в команду. С тихими конфликтами старались выводить их в ясную, хоть иногда и неприятную коммуникацию.
Были и те, кто сопротивлялся. Не напрямую, конечно, ведь в моих командах все очень умные люди. Коллеги саботировали, уводили разговор в сторону, подкидывали другие темы, чтобы отвлечь от основной повестки. Для таких у меня было правило трех заходов — три итерации попыток выстроить контакт. Если не получается — я шла к «заказчику изменений» и честно говорила, что с этим техлидом дальше двигаться не готова. Кстати, один из таких потом уволился сам, с кем-то другим мы просто договорились не реализовывать командные изменения, но продолжали работу с системными процессами трайба. На масштабе девяти команд это была рабочая тактика. Лучше начинать двигаться с теми, кто открыт к изменениям, чем застревать там, где контакт не выходит.
Что помогло на этом этапе
Моим главным инструментом стали one-to-one. Причем про конкретные запросы человека в рамках команды и его профессионального роста, а не про процессы. После этих диалогов я уже понимала, какие процессы реально стоит поменять, а где для этого еще не пришло время и команде нужно помочь в том, что болит здесь и сейчас.
Например, один техлид не мог уволить слабого сотрудника и из-за этого переживал. Пойти с таким запросом к CTO он не мог, ведь тот наверняка бы ответил: «Это же твоя работа». А со мной можно было проговорить по сути обо всем. Обсудить свои чувства, и вместе пройти через стадии от «ты не виноват» до конкретного решения.
С кем-то у меня даже были дополнительные встречи — коучинг по запросу. Например, с новым техлидом, которого выбрали на эту позицию из сеньоров. В самом начале он терялся и не до конца понимал, что делать с продуктовой командой. На встрече я дала понять, что на его стороне, и понимаю, в какой ситуации он находится. А еще помогла снизить уровень тревожности обозначив, что в рамках процесса нет гонки и есть время для проб и экспериментов.
Так что благодаря таким небольшим коуч-сессиям коллеги постепенно сами понимали, зачем вообще вместе со мной что-то делать и чем именно я могу быть для них полезной.
Как раз после таких встреч и появилось доверие — сначала лично ко мне, а затем и к тем решениям или изменениям, которые я продвигала.
Перестраиваем планирование и находим смыслы
Когда команды стали больше доверять, настало время модернизации самого планирования. Его центральным артефактом была доска в Miro — единое для всех команд пространство, которое по факту почти не работало.
Проблема была в том, что коллеги просто заполняли доску и забывали про нее до следующего квартала. Оказалось, многие просто не понимали, кто и зачем потом эту доску смотрит. Когда я объяснила, что на доску смотрит C-level и что она помогает предотвращать конфликтные ситуации до их эскалации, отношение начало меняться. Но понадобилось несколько циклов.
Как менялась доска и к чему мы пришли
По новому процессу коллеги должны были приносить на планирование цели на квартал, согласованные с бизнесом, затем описать риски, а также обозначить зависимости. Например, стикер на доске, ссылку на задачу в Jira, результат встречи с командой-исполнителем или подтверждение, что зависимость принята и ушла в оценку. Также нужно было обозначить дедлайны.
Поставки клиентам решили фиксировать отдельно: в каком спринте, какая команда и какую фичу запускает. Релиз, демо и момент, когда клиент реально может потрогать функционал, — три разных события, поэтому мы сознательно их разводили.
На доске у каждой команды были место для подсказок-шпаргалок. Со временем некоторые команды стали заносить туда свою информацию — это был индикатор, что инструмент становится «своим».
Зрелые команды с сильными проджект-менеджмент скиллами могли планироваться по-своему. У нас была договоренность о том, что есть обязательный базовый минимум, который нужно показать на общем планировании и сделать понятным для других команд и бизнеса. А внутренняя кухня работала на усмотрение техлида.
Если техлид ставил стикер с риском «нехватка ресурсов» и дальше ничего не заполнял, я сразу понимала, что планирование сделано для галочки. С такими случаями я работала индивидуально: садились вместе, разбирали, какие риски реально есть, в чьей зоне ответственности управление ими. Иногда выяснялось, что техлид просто не привык думать в категориях рисков. Иногда — что не хотел «светить» проблемы команды перед руководством. Каждый случай требовал своего подхода.
Когда блок на доске заполнялся формально или не заполнялся вообще — для меня это был сигнал о том, что команды не понимают, зачем он нужен, и надо или объяснить им ценность, или вообще его убрать. Так мы, например, отказались от отдельной доски зависимостей.
Обратную связь я собирала с трех сторон:
от команд — что нравится, что лишнее, каким языком говорить;
от C-level — как они используют доску для принятия решений, что им нужно, чего не хватает;
от коллег из методологического блока МТС — как они оценивают зрелость процессов и нужны ли корректировки с точки зрения методологии.
Последние три планирования мы специально не меняли формат доски. Вокруг было много нового — организационные изменения, ротация техлидов — и команды просили стабильности хотя бы здесь. CTO трайба поддержал эту идею.
А еще помогало просто присутствие. Когда команда уже знала, что делать, но новый процесс еще не превратился в привычку, я приходила на встречу и просто находилась вместе с ними. Сам факт, что рядом знающий человек, помогал не бросить дело на полпути. Так что со временем я уже стала чем-то вроде информационной поддержки или даже рабочего фона.
В какой-то момент я хотела убрать Miro и оставить только Jira, но команды не согласились. Для них доска стала способом посмотреть на команды рядом и квартал целиком и как бы овеществить процесс. Так что мы решили оставить геймификацию — это правда было важно.
Что еще хорошо сработало
Еще у нас был общий чат, куда любая команда могла написать о проблемах и сложностях. А также так называемая PO Sync — ежеспринтовая синхронизация всех команд. Туда приходили как CTO, CPO, архитектор и команды. Вместе в моменте решали то, что болит, что плохо и где нужна помощь. Там же договаривались о встречах и распределяли ресурсы. Со временем, когда структура трайба изменилась и появилось два стрима, эти встречи отпали сами собой.
Результаты
Прошло уже шесть циклов планирования, поэтому я готова поделиться изменениями:
C-level вернул себе управленческое время. Раньше CTO и CPO регулярно подключались к разруливанию конфликтов — кто отвечает за фичу, почему одна команда не выполнила обязательства перед другой, кто виноват в сорванных сроках. Теперь зоны ответственности фиксируются на планировании, команды разбираются между собой.
Зависимости сократились кратно. В первых итерациях доска зависимостей была огромная, за ресурсы шла борьба — вплоть до борьбы за конкретных инженеров. Через год доска стала почти пустой, потому что само планирование подсветило, где зависимости самые болезненные. Команды увидели, что им выгоднее нарастить компетенции внутри, чем каждый раз ходить к соседям.
Появились цели трайба. Раньше каждая команда планировала свои цели, и они не обязаны были пересекаться. Через несколько циклов совместного планирования команды сами увидели, что часть фич катится несколькими командами одновременно. Я подсвечивала пересечения, команды сами пришли к тому, что на такие задачи нужны одинаковые приоритеты и общие цели. На доске появились цели трайба, а не только цели отдельных команд.
Стали видны серые зоны. Квартальные точки синхронизации помогли увидеть места, где непонятно, кто за что отвечает. Раньше это всплывало только в момент конфликта. Теперь — на этапе планирования.
Команды проводят планирование самостоятельно без напоминаний. Техлиды сами заполняют бэклог, приносят цели, фиксируют риски и приходят на общее планирование подготовленными. Я стала ненужной — в том смысле, в каком скрам-мастер и должен стать ненужным после большой проделанной работы.
В итоге мы стали соответствовать требованиям к планированию еще до того, как их официально зафиксировали для всех команд. Когда в МТС только выкатили новые требования к продуктовой культуре и техническим минимумам, наш трайб уже им соответствовал. Так что планирование, которое мы изначально выстраивали для себя, в какой-то мере даже стало образцовым.
Мои инсайты
Для себя я вынесла много полезного. Отмечу основные моменты.
Во-первых, решает спонсор изменений. Без CTO трайба (Андрей, привет тебе!), который разделял цели и временами прикрывал спину, все остановилось бы на первой итерации. Мы с ним заранее договаривались, какую одну привычку планирования команды усвоят в этом цикле. Это снимало давление от необходимости «поменять все сразу» и давало фокус — как для команд, так и для нас самих.
Во-вторых, принцип «усвоили — идем дальше, не усвоили — повторяем» стал для меня базовым. Ведь как обычно бывает: устраиваешь встречу по какой-то повестке, но половина коллег прийти не могут. Напишешь памятку, но часть коллег все равно забудет или проглядит. Покажешь алгоритм на примере конкретной команды — кто-то поймет и запомнит, но точно не все. Мы разные, поэтому важно повторять и объяснять до того момента, пока новое не приживется.
В-третьих, «потому что так по SAFe» на практике не работает. Каждое внедрение я в итоге обосновывала в терминах затрат: сколько времени, сколько ресурсов, что это даст конкретно. С руководством и с командами одинаково.
В-четвертых, важно быть именно «руками техлида». Если нужно было что-то изменить в процессе команды, я шла и делала это вместе с техлидом. Открывали Jira, разбирали доску, считали нагрузку. Шесть лет технического проджект-менеджмента здесь помогли — я могла разбираться в самом сложном и неприятном вместе с командой.
Так я менялась вместе со всеми. В какой-то момент пришло время отстраниться от команд, к которым уже прикипела, и перейти к чисто системному взгляду. Постепенно я перестала быть «своей» и стала просто той, кто делает структуру понятной для всего трайба — благодаря проделанной совместной работе это наконец стало возможным.