Сергей Рогачев развивает в России две темы: Scaled Agile Framework (SAFe) и Objectives and Key Results (OKR), а также проводит исследование «Agile в России» (выборка включает полторы тысячи респондентов). Благодаря ему, мы уже системно, как страна, подходим к ответу на вопрос: в каких отраслях у нас Agile работает, где не работает и какие результаты он дает. Опираясь на статистику можно понять, где ваша компания находится, нужен ли вам Agile, для чего, и что вы можете с его помощью достигнуть.
На TeamLead в этом году Сергей рассказал о том, как Agile трансформируется в большой организации и, соответственно, как меняется ваше окружение (тимлиды и команды) и какие новые требования к вам, как к лидерам, предъявляются. И показал весь процесс Agile с фотографиями.
Если у вас уже есть Agile, как вы принимали решение? Самостоятельно и осознанно решили, что именно этот процесс (Scrum или Kanban) вам нужен и что именно он поможет решить ваши проблемы? Первое ваше знакомство с Agile было таким?
…или у вас так происходило?
В больших организациях обычная история, когда приходит руководитель: «Всё, завтра всем Scrum! Некогда разбираться — ты Scrum-мастер или Product Owner». Причем из исследования «Agile в России» по цифрам видно: чем больше масштаб, тем чаще эта история встречается. Но неважно, как вас угораздило вляпаться в Agile, разберёмся, куда вы попали, что это окружение собой представляет и какие требования предъявляет к вам и вашим командам. Если с этим не разобраться, очень часто внедрение Agile превращается фабрику фич.
Раньше разработчики брали тикеты с Jira. Сейчас они делают то же самое, но берут из того, что теперь называется бэклог: к вам подкатывают бэклог, вы из него берёте — и конвейер идёт. При этом где-то ваши продакты знакомят пользователя с тем, что получилось в итоге: юзер и продукт, поцелуйтесь!
Неужели это Agile? Мы же не для этого его делали.
Вы знаете, что Agile — это подход к тому, как выполнять проекты в условиях большой неопределенности. Это матрица запутанности Стейси:
Agile-подход хорошо работает в ситуации, если у вас есть две большие неопределенности:
или
то вы попадаете в сложную среду, в которой вам предлагается:
В результате у ваших команд и вообще у всей организации получается два фокуса:
В системе есть два актёра: вы, как лиды, и ваши команды. Рассмотрим простой пример: команда делает продукт, но клиент недоволен. Что мы как лиды должны сделать, в чем наша задача в этой истории? Конечно, разобраться, в чём проблема: вы, как эксперт, идете и разбираетесь. Допустим, команда разработки передаёт на тестирование в последний день, поэтому огромное количество проблем дотягивается до пользователя. Что мы дальше делаем?
Мы уже знаем, в чём проблема, мы ее идентифицировали. Самое простое, что теперь можно сделать, это прийти к команде и сказать: «Слушайте, чуваки, вы сейчас так делаете — давайте вы так не будете делать! Давайте вы будете делать правильно». Так обычно поступают с детьми. Я говорю своему семилетнему сыну: «Владик, не делай так, пожалуйста!» И это, кстати, реально работает — он перестает так делать. Правда, мне потом жена говорит, что он только при мне так не делает. А когда я на работе, все продолжается по-прежнему.
Так что это не работает. Что мы тогда делаем? Меняем процесс, задаем команде вопросы, что можно было бы сделать, чтобы не делать плохо. По сути всё, что мы можем как руководители — это настраивать окружение, которое определяет поведение наших команд. Мы создаем среду, которая делает невозможным негативное поведение и мотивирует людей вести себя по-другому:
Например, вы внедряете Scrum. Отныне становится невозможным не поставлять результат хотя бы раз в 2 недели. Нет, разработчик может так делать, но получит мотивирующую и стимулирующую обратную связь, когда вы, как руководитель, пригласите на обзор спринта людей, которые скажут всё, что они думают про продукт, не стесняясь в выражениях. Постепенно ему становится почему-то немножко стыдно каждый день тащить одну и ту же задачу — приходится каждый день на Daily Scrum отвечать, что делал вчера, что будет делать сегодня, да еще и со злой добавкой «в рамках цели спринта».
То есть вы создаете среду, которая постепенно меняет мышление людей, и они начинают вести себя по-другому. Наша задача — постоянно думать над тем, как настроить окружение. В этом смысле мы становимся не руководителями людей, а механиками для настройки системы. Представьте систему — винтики-болтики крутятся сами (это наши умные специалисты), и между ними есть трение. Вы бегаете с масленкой и подливаете там, где что-то начинает трещать — настраиваете систему, которая работает самостоятельно.
И самые крутые из нас делают так, что система почему-то начинает сама развиваться. Например, вы делаете такую среду, в рамках которой команда умеет смотреть на результаты своей работы и, что называется, коучить самих себя: что еще можно сделать, чтобы стать еще круче? Правда, если вы настроили такую систему, для вас беда-печаль (или радость) — вы больше не нужны этой системе (как минимум, на каждодневной основе), система начинает развиваться сама. Это то, что называется самоорганизованная команда.
Но как этого добиться?
Пойдем с низов – просто возьмем одну Scrum-команду, пока никакого масштаба. Вопрос к вам: за что у вас отвечают команды по итогам спринта? Когда спринт закончился, за что вы их журите?
Обычный ответ — за фичи. Если команда — это фабрика фич, то как тогда фичи связаны друг с другом? Почему именно эти фичи делаем, а не другие? Ответа на эти вопросы нет — такой среды еще не создано. Классический пример — доска команды из Авито примерно 2,5 года назад. Видно, что в конце спринта очень много задач еще недоделано – готово примерно только 40%:
Разберемся, в чем проблема. Одна из частых проблем на старте — команды не умеют оценивать. Надо научить их, что такое Story Point, как правильно к нему подходить, если в команде бэк, фронт и т.д. Покажите им на примере, как это делается.
Есть и другая проблема — они всё это умеют, но у них нет фокуса. Тогда приводим команду на ретроспективу спрашиваем: «В чем была цель вашей работы?» В ответ взгляд козы на баян и вопрос: «А что такое цели спринта?» ОК, давайте запишем в крупную клетку, что вы делали в течение последних двух недель. Они озвучивают, вы записываете. После этого каждый анонимно ставит оценку на стикер: «Насколько вы как команда достигли этих целей спринта?» То есть команде приходится отвечать на вопрос, обозревая все, что сделано:
Рассмотрим на примерах.
По сути это обычные задачи. Более того, я создавал среду, которая показывала, что у каждого сотрудника своя собственная цель (задача). И когда отвечал другой человек, я брал маркер другого цвета:
Видно, что у каждого были собственные работы. А понимание того, насколько мы достигли цели, у команды совершенно разное. После этого обычно задается вопрос: «Насколько мы команда?» Ибо выглядит так, что каждый пилил только свою работу. Наверное, чувак, поставивший двойку, реально тащил тяжелую задачу и, кажется, ему никто не помогал. Особенно не помогал товарищ с девяткой — он свою задачу запилил и, наверное, в конце спринта занимался саморазвитием, хотя в другой части команды бомбило и была нужна помощь.
Это другая команда, но ситуация такая же. Понимание действительности уже возле 8-9, но есть шестерка. Это как раз лид команды — он лучше всех понимал, насколько они приблизились к цели:
Сжимаем цели. Забавно, но здесь уже нормальное распределение. 3-4-5 и 7-8-9 — это две подкоманды по три человека внутри команды, которые вместе тащили одну работу, и у них более-менее всё получилось. У ребят с 3-4-5 была тяжелая фича, они не справились. Но они примерно одинаково понимают, что они продолбали. Три шестерки — это сеньоры, которые лучше всего понимают, что происходит, потому что они помогали джунам в обоих частях:
Что, если вообще зажать? Чем меньше целей спринта, тем больше понимание действительности, — что мы на самом деле делали и насколько этого добились, — начинает у людей в голове совпадать:
Зачем я всё это показал? Почему круто, если у команды одна цель?
Потому что Agile от классики этим и отличается:
В классике мы обещаем набор фич и дальше можем играть: или больше ресурсов вкладывать в разработку, или продалбывать сроки. Есть только эти два параметра, потому что нужно весь объём сделать.
В Agile мы заранее понимаем, что находимся в области неопределенности и не знаем, какой набор фич реально нужен нашим потребителям: у нас есть только гипотезы. Иногда говорят — галлюцинации, — и в них самый большой эксперт — наш Product Owner. Он галлюцинирует в рамках двух ограничений: ресурсы закреплены (full-time команда, все на 100% выделены) и спринт закончится ровно тогда, когда он закончится, не раньше и не позже. Оба параметра зафиксированы, а мы хотим, чтобы скоуп был плавающим. Это не плохое, это классное свойство: мы хотели бы иметь возможность менять скоуп, получая обратную связь — то мы делаем или не то. Но нужен измеритель – это цель. Когда ещё цель стреляет?
Есть два варианта проведения обзора спринта.
Команда показывает владельцу продукта работающий продукт по завершению спринта. Посмотрите, как он на него смотрит. Там был задан самый ключевой вопрос: «Product Owner, дай нам обратную связь: насколько мы добились цели спринта? И как нам нужно изменить дальнейший бэклог?» У Product Owner закрытая поза: «Что я вам тут могу сказать? Ну да, кнопки вроде работают». Возникает недоумение: как может владелец продукта дать обратную связь по работающим кнопкам, если нет реальной информации о том, как это будет работать в полях, то есть нет обратной связи от конечных потребителей:
Второй вариант — моя любимая история одной из команд компании Авито, которой тоже примерно 2 года. Эта команда связывает продавцов и покупателей в мессенджере. У нее две ключевые метрики:
Команда внутри спринта реализовала банальную фичу — кругляшок, который показывает, что на том конце провода покупатель или продавец сейчас онлайн: можно быстро написать, и он сразу ответит. Они на обзоре спринта показывали результаты А/В-теста, выкатив фичу на продуктив на ограниченное количество клиентов и посмотрев, действительно ли она коррелирует с этими двумя метриками. Явной корреляции замечено не было и команда попросила еще неделю, чтобы поснимать данные и понять: если эта фича всё-таки нужна, то как ее модифицировать?
Это два различных варианта. Ваша цель будет работать тогда, когда вы ее не просто как лозунг ставите, а когда она формулируется в метриках, которые реально можно измерить. Иначе это опять профанация.
Можно ставить цели на основе контрольных точек: сделать релиз к такой-то дате и т.п. Здесь снова мало информации: как вы измерите, что это то, что нужно вашим потребителям?
OKR предлагает другой подход: ставим цели от метрик, причем клиентских. Как клиент взаимодействует с вашим продуктом? Как это влияет на то, что он решает свои проблемы быстрее, лучше, качественнее и т.д. и готов за ваш бизнес голосовать деньгами? Поэтому у вас должны быть измерители.
Одним из свойств цели, как OKR говорит, должен быть уровень амбициозности. То есть мы за спринт хотим улучшить жизнь клиента не просто, а на сколько — до 80%, 52% и т.д. Это измеритель, куда вы хотите прыгнуть:
Бэклог продукта — это только набор гипотез. Мы, как механики этой системы, на уровне команды должны ментально менять отношение людей к бэклогу. У вас в бэклоге лежат галлюцинации. Поэтому задавайте всегда вопрос владельцу продукта, бизнесу и т.д. — зачем мы это делаем? Почему вы уверены, что это то, что нужно нашим клиентам? Если не уверены, то как мы можем измерить, что это действительно то, что им нужно? Меняйте ментальность и в команде, и ваших бизнес-заказчиков, чтобы вместе отказаться от ощущения, что вы всё знаете заранее.
Команда берет обязательства по цели спринта. Пожалуйста, не берите с команд обязательства за скоуп работ. Так вы по сути их толкаете в Waterfall, хотя называете это Scrum. Речь не о том, что надо сделать все фичи в спринте. Нет, ваша команда внутри спринта Scrum-процесса может даже менять бэклог вашего продукта, если вдруг обнаружится, что то, что вы галлюцинировали неделю назад, оказалось не тем, что приближает вас к цели. Конечно, две недели — это небольшой временной промежуток, и в конце, может быть, не сильно что-то у вас поменяется. Тем не менее, меняйтесь ментально — на масштабе эта проблема во всей красе выходит.
Бэклог продукта и спринта — это только план достижения цели. План нужно регулярно сверять с результатом и изменять при отклонении. Я уже говорил, что на Daily Scrum нужно каждый день задавать вопрос: «То, что мы делаем, с целью вообще коррелирует?» Постепенно вы приучите людей думать больше о цели, чем о скоупе. Но вначале нужно несколько раз это повторить, чтобы люди наконец поняли, зачем мы это делаем.
Фокус на конечный результат больше, чем на предсказуемость сроков поставки. Больше фокусируемся на том, чтобы добиться изменения каких-то метрик, чем просто затащить фичи. Даже можно какие-то фичи не доделывать: может быть, выполнив 2/3 вашего бэклога спринта, вы добьётесь улучшения ключевых метрик для клиента, и будет уже неважно, что 2 фичи не доделали. Цель-то в другом.
Обзор спринта — оценить степень достижения цели на основе обратной связи от клиентов. Причём, от реальных клиентов. Это челлендж для всех сотрудников, связанных с инженерной практикой, которую использует ваша команда: Continuous Integration, Continuous Deployment и т.д. Именно это сейчас штормит в других отраслях, где пытаются Agile применять.
Например, компания «Сибирский Гурман» в Новосибирске, которая делает пельмени, решила поэкспериментировать с областью неопределенности: а что, если менять вкусовую начинку пельменей или обертку, как это повлияет на покупаемость товара? Классно! — сейчас будем эксперименты проводить и получать обратную связь. Но что значит эксперимент? Они приходят к ритейлеру с новым форматом пельменей, а ритейл не хочет делать мелкие закупки и предлагает большую поставку на полгода — так эксперимент длится год. В результате «Сибирский Гурман» открыл собственный магазин, в котором можно быстро получить обратную связь, но магазин — это полностью затратная часть проекта.
В IT, как видите, всё проще. Уже всё придумано. А в других отраслях люди занимаются творчеством, чтобы как можно быстро получать обратную связь. Но происходит это у всех.
Где-то здесь на рисунке ваша командочка. И начинается: у каждой команды есть свой бэклог, своя цель, вы понимаете, кто ваш клиент, но почему-то к вам прибегает очень много людей (подрядчики, стейкхолдеры и т.д.), которые что-то еще от вас хотят (например, свои галлюцинации всунуть в ваш бэклог), и вы почему-то тоже их должны делать:
На уровне конечных симптомов мы имеем следующее:
Откуда на масштабе всё это берется и почему возникает? Рассмотрим на примере классического примера получения кредита, откуда в банке возникают все эти зависимости.
Первое, что банк должен сделать — это рассказать людям о том, что у него классные условия кредита: качественные, быстрые и т.д. На самом деле работа с клиентом начинается с маркетинга. Дальше идут оценка, оформление и т.д., вплоть до полного закрытия кредита. В компании есть операционные службы, которые непосредственно обслуживают клиента и общаются с ним:
Дальше уже появляются IT-системы, которые поддерживают, ускоряют, автоматизируют — в общем, делают так, чтобы клиент классно и быстро получил кредит. Здесь появляются наши люди, наша оргструктура. Здесь надуманный пример: в IT-департаменте Москвы 310 разработчиков, в Эстонии 30 человек и еще вендор в Америке (150 человек):
Реальный пример про меня. Когда я получал третью ипотеку в моем любимом банке, на стадии №2 (быстрая оценка заявок) мне пришел отказ. Вечером этого же дня мне звонит мой ВИП-менеджер с классическим вопросом: «Сергей, все ли хорошо у вас с нашим банком? Может, чем-то могу вам помочь?» Конечно, я на него наезжаю: «Чувак, что случилось? Я же ваш VIP-клиент. Почему мне отказали в ипотеке, когда у меня всё нормально по параметрам?» Он попросил таймаут и перезвонил мне вечером — он не смог сразу ответить на вопрос, потому что заглянул в CRM и не увидел там вообще никакой информации о том, что я даже заявку подавал.
Причиной было то, что в те годы этот банк первую часть операционного обслуживания передал на аутсорс своему партнеру. То есть был головной банк и банк-партнер, который на входе обслуживал клиентов — грубо говоря, мне отказал не головной банк, который меня любит, а его партнер. Так как ответственность одного банка закончилась на стыке с ответственностью другого, — интеграция сломалась. Небольшая ошибка привела к тому, что головной банк не знал, что с его любимым клиентом не очень хорошо обошелся банк-партнер. На таких стыках бизнес очень часто теряет своих клиентов и, как следствие, — деньги.
К чему я это? Представьте, что ваша Scrum команда — кросс-функциональная относительно бэк, фронт и т.д., — находится где-то внутри этой структуры. Ключевой вопрос: насколько кросс-функциональны ваши команды относительно решения проблем клиента? В идеале кросс-функциональность должна быть такой, что вы можете помочь клиенту на любом этапе его жизненного цикла общения с компанией. Представляете, сколько компетенций надо засунуть в одну Scrum-команду, например, на 11 человек?
К сожалению, на большом масштабе это основная проблема: команда перестает быть кросс-функциональной относительно клиента. Решение такое: давайте соберем большую команду команд, которые в совокупности будут максимально кросс-функциональны.
Вот пример (два красных стикера). Стикер с надписью «Ипотека» означает, что мы меняем оргструктуру таким образом, что появляется ипотечное подразделение (стрим, трайб, поезд и т.п., в разных компаниях это по-разному называется). Мы объединяем бизнес (отвечает за финансовые метрики по выдаче ипотеки) и команды (живут в Москве и в Эстонии), чтобы развивать системы в первой части этого стрима, исправлять любые ошибки интеграции и т.д.:
В моей истории вендора не удалось затащить в эту тему. Они сказали: «Напишите нам ТЗ, мы всё сделаем». Но в любом случае, вы формируете подразделение, которое максимально широко смотрит на своего клиента. Часто звучит тост: «Фокус на клиента, ценность», но посчитайте, какое количество шагов закрывает это подразделение. Чем больше оно закрывает, тем оно более крутое, точнее, постепенно станет крутым и сможет решать все проблемы клиента.
Зачем я это рассказываю? Задача лида — не просто выстраивать окружение для развития команды. Для начала вам нужно понять:
Для примера представляю три варианта кросс-функциональности подразделений.
Одно из них — это по сути весь веб-канал, там все веб-разработчики. Например, для банка основные метрики будут по привлечению, чтобы клиент попробовал кредитным калькулятором посчитать и превратился уже в ипотечного заемщика.
Мобильное приложение (iOS, Android и т.д.) уже с метриками, связанными с активацией и обслуживанием. Может быть также платформенное подразделение, то есть делающее компонент, потребителями которого являются другие подразделения:
Второй вариант более крутой: вы оргструктуру меняете таким образом, что каждое подразделение становится кросс-функциональным относительно каналов. Нужно что-то в кредитах починить — мы это и в веб-канале делаем, и в мобилке, то же самое с дебетовыми картами. Подразделение полностью может изменять любые каналы. Но вам нужно сделать так, чтобы подразделения могли вносить изменения в одну и ту же кодовую базу.
Это более сложный, но более крутой вариант. Он очень нравится бизнесу, потому что дебетовый стрим зарабатывающий: можно понять, сколько мы зарабатываем, плюс есть фонд оплаты труда команд разработки. Как следствие, вы соедините выручку с затратами. Ваше подразделение становится маленькой компанией внутри огромной, потому что у него есть свой P&L и можно смотреть, насколько вы как микро-организация эффективны:
В сложных кейсах есть огромное количество подразделений, и каждое отвечает за сет метрик. В больших организациях это наиболее популярный вариант:
На масштабе мы создаем такое же окружение, что и на уровне одной команды. Оно на самом деле решает ту же задачу, но мы растим кросс-функциональность относительно всего клиентского пути. Поэтому есть море сложностей: коммуницирование с бизнесом, другими командами, более сложные циклы (не двухнедельные, а квартальные):
Хорошо. Ваша команда уже понимает, что вы не можете помочь вашему клиенту на всех его этапах. Но вы понимаете, что есть бизнес, вместе с которым вам нужно планировать изменение клиентских метрик. Понимаете, что есть еще куча народу: порядка 150 других специалистов (10-12 команд). И с которыми, похоже, придется общаться, потому что вы от них зависите, а они — от вас.
Как общаться? Во всех подходах Agile даёт простой рецепт: «Just talk: есть у тебя с кем-то зависимость, пойди да поговори с ним». Разработчики, особенно те, которые любят больше общаться с монитором, чем с другими людьми, говорят: «Ну, я не могу так — как просто just talk?» Поэтому все фреймворки предлагают принуждение к общению: «Хорошо, вы не умеете общаться. Сейчас будете общаться, но по следующему алгоритму».
Сейчас набирает популярность совместное планирование OKR (в другом подходе называется PI Planning). Идея в том, что на длинный промежуток времени (квартал) мы вместе, всей толпой, понимая, кто наш бизнес и зависимости внутри, планируем общие цели. Это двухдневное мероприятие, но некоторые умудряются провести его за день, если команды уже научились общаться между собой. Грубо говоря, это двухдневное фасилитированное мероприятие в формате вопрос – ответ, типа:
То есть мы делаем так, чтобы все со всеми договорились и выработали, куда мы хотим прибежать к концу квартала. Это реальные фото, когда три года назад Сбербанк первый пробовал запускать такие мероприятия:
Совместное планирование OKR или PI Planning проводятся этапами.
На старте брифинг обязателен. Бизнес должен сказать: «Хотелось бы, чтобы к концу квартала…» И на примере здесь сверху Сбербанк года 3 назад, а снизу – GameDev-компания Xsolla из Лос-Анджелеса. Американцы, кстати, рассказали простую историю, что у них нет никаких проблем с активацией новых клиентов: с метриками по активации всё классно. Но есть проблема с повторными покупками: почему-то процент повторных покупок очень низкий. И вторая проблема в том, что почему-то допуслуги не покупают, средний чек низкий. И бизнес попросил: «Пожалуйста, все фичи в этом квартале нацеливаем на повторные покупки и повышение среднего чека (допуслуги)»:
Это один из вариантов, как может выглядеть хороший vision: когда мы говорим про контекст бизнеса и финансовые метрики. Но заранее мы не знаем, что получится сделать в квартале. Что происходит дальше?
В IT-компаниях мы обязательно слушаем архитектора. Для него — интересная история! — тоже меняется окружение. Архитекторы наконец-то на таких сессиях понимают, кто является их заказчиком (большинство корпоративных архитекторов думают, что это бизнес):
Этот архитектор хотел быстро доложить про «страшный» ландшафт Сбербанка и убежать: «Я же все сказал! Более того, дал концептуальную архитектуру на 50-100 страниц. Что мне тут еще делать? Всё же понятно, но если что — звоните». Но после презентации один из тимлидов задал ему вопрос:
Тут архитектор понимает, к чему вопрос. И команда его попросила остаться с ними, чтобы когда они будут планировать свои фичи, они вместе подумали, как делать нецелевое решение.
Дальше команды отправляются в свободное плавание. У них есть три часа, и они должны сгенерировать цели, за которые они готовы взять ответственность на квартал. Называется это Swarming (роение, жужжание). Это такой нетворкинг, но в рамках работы:
Конечно, не всё так просто. Ребятам задается алгоритм дохождения до того, какие адекватные цели они могут взять на квартал. Они делают флипчартные листы, на которых отображены предположительные бэклоги спринтов на квартал вперед. Это нужно, чтобы после того, как они с учетом своей доступности примерно наполнят свои бэклоги и поговорят с другими командами по зависимостям (кто, кому, что когда сделает/не сделает), задать им вопрос: «Если вы все эти работы затащите, каких целей вы добьетесь, и с помощью какого измерителя (метрики) можно будет измерить степень достижения?»
То есть мы планируем бэклоги работ, потом по ним формулируем цели, после этого от этих бэклогов отказываемся. Это просто методика того, как прийти к адекватной постановке цели. Ни в коем случае не думайте, что ребята коммитят на квартал все команды на этот сет работ:
Нет, мы фасилитируем, то есть помогаем прийти к более-менее адекватным целям.
На фото представители команд, которых заставили общаться. Они на эту сессию иногда приходят с ощущением: «Да мы понимаем, что будем делать, и вроде бы даже знаем зависимости от других команд, потому что говорили с ними на прошлой неделе». Но когда прямо просишь проговорить, что команды будут делать в этом квартале, наконец-то вскрываются зависимости:
Мы даём им инструмент для того, чтобы они, проговорив про свои зависимости, отобразили их и видели, кто от кого зависит. Вертикальные отбивки — это спринты внутри квартала, горизонтальные отбивки — команды. На пересечении команда ставит, какую фичу она будет делать, и красной стрелочкой подтягивает: «А вот они нам обещали сделать на спринт раньше API, тогда мы кнопку на фронте сделаем». Это протокол договоренности, что мы с вами договорились, кто, кому, когда и что:
Дальше на презентации владельцы продуктов показывают результаты своих команд:
Единственный, кто в этот момент пытается склеить в мозгу, как будет работать сквозной сценарий, — это бизнес. Любой вопрос к Product Owner на старте типа: «Какой сквозной сценарий будет работать?», — часто остается без ответа: «Подождите, мы за этот компонент отвечаем. У нас это будет работать, ваш вопрос не к нам. Пули с нашей стороны вылетели, ищите в других командах ответ на ваш вопрос». На старте бизнес ничего не понимает, но пытается в голове эту картинку склеить.
В компании Xsolla предпоследняя строчка Tech Ops. Ребята уже понимают, что надо DevOps заниматься, соответственно поддержку сред заносить внутрь команд. Но на тот момент (полгода назад) это было внешнее подразделение. Руководитель эксплуатации тоже презентовал — он шел по красным стикерам и подтверждал: «Да, вы мне тут впихнули, что надо такие-то среды развернуть. Я беру ответственность, мы будем это делать»:
Интересно, что когда на одном стикере он проговорил, что они будут делать, его команда поправила:
С юристами, маркетингом, дизайнерами у них прямо проблема была — эти ребята в Америке (в Лос-Анджелесе), и они не приехали на эту встречу. Поэтому зависимости от них повесили, но был страх: может быть, они сделают, но надо отдельно созваниваться, общаться и т.д. Вывод для этой компании был, что на следующий квартальное планирование они их также приглашают.
Есть определенный алгоритм того, как обрабатываются риски. Ключевая идея: мы создаем окружение, в котором, оказывается, топ-менеджменту можно ставить задачи. И это даже не страшно, они готовы их брать. Они смотрят: «Если я тут починю контракт с нашими аутсорсерами, оказывается, мы сможем больше сделать того, что я хочу», — и так вовлекаются.
Это примеры решения проблем, которые можно принять, если у вас все есть на этой встрече:
Последний этап — мы проверяем, действительно ли команды готовы брать ответственность за те цели, которые они выработали. Мы просим поднять пальцы:
Вы смотрите общую картину и, если видите низкую уверенность в компании, просите оглянуться вокруг: «Посмотрите, кажется, вы сами не верите в свои цели. Идите переделывайте, сделайте так, чтобы вы сами верили в свои планы. В вас же никто их не впихивает (по крайней мере, старается)»:
В конце квартала опять собираем всех вместе. По сути это большая ретроспектива (в OKR называется OKR Review):
Что там происходит, покажу на реальном примере. Выписаны цели, которые команда брала на себя на этот квартал. У них есть плановая оценка влияния на метрики, то есть на те цели, которые бизнес хотел от команды и компании. Оценивается фактическое достижение:
Здесь опять стреляет: умеете ли вы оценивать план-факт не просто как «Нам кажется, эта фича, наверное, повлияла», а собрали ли продакты с бизнесом реальные метрики с А/В-тестов, с каких-то вариантов дотягивания до клиентов.
Другой вариант: если команда еще инженерку не настроила, не умеет быстро дотягиваться до клиента, они оценивают, как в Planning Poker, только пальцами: «Нам кажется, что мы достигли этой цели на столько-то»:
Они ставят себе по сути процент достижения: видно, что команда достигла за квартал 88%. Идея в том, что такая метрика показывает:
В конце проходит обычная ретроспектива и каждая команда работает по отдельности. Ключевой момент: вытаскиваются общие проблемы: не отдельно каждой команды, а те, которые стреляют по нескольким сразу. Обычно мы делали критерий 3+ команды. Если у них общая проблема, значит, надо решать ее на уровне всего подразделения:
В чем задача для нас во всей этой истории? Вроде бы понятно, что делать. Но вы находитесь в контексте большой среды: другие команды, бизнес, понимание, какие части клиентского пути вы решаете и для каких клиентов. На самом деле нас, таких лидов и тимлидов, очень много:
Какое требование к нам на масштабе формируется? В чем проблема лидера? В том, что размер имеет значение… :)
Чебурашка мутировал в крокодила для лучшей выживаемости в тяжелых средах крупных компании… По другому говоря, вам нужно саморазвиваться. Это набившее оскомину высказывание, но на самом деле, если вы не саморазвиваетесь, люди под вами тоже это не делают. А в условиях огромной компании требования безжалостны к тому, каким вы должны быть лидером. Вам нужно уметь настраивать среду на огромное количество команд, то есть саморазвиваться в разы активнее.
По сути вам нужно перестать управлять людьми. Формируйте среды, в которых люди самоуправляются. Перестаньте быть экспертом, станьте «договаривателем».
Вот то, что стоит верифицировать, насколько вы круто развились по всем этим направлениям:
На TeamLead в этом году Сергей рассказал о том, как Agile трансформируется в большой организации и, соответственно, как меняется ваше окружение (тимлиды и команды) и какие новые требования к вам, как к лидерам, предъявляются. И показал весь процесс Agile с фотографиями.
Первое знакомство с Agile
Если у вас уже есть Agile, как вы принимали решение? Самостоятельно и осознанно решили, что именно этот процесс (Scrum или Kanban) вам нужен и что именно он поможет решить ваши проблемы? Первое ваше знакомство с Agile было таким?
…или у вас так происходило?
В больших организациях обычная история, когда приходит руководитель: «Всё, завтра всем Scrum! Некогда разбираться — ты Scrum-мастер или Product Owner». Причем из исследования «Agile в России» по цифрам видно: чем больше масштаб, тем чаще эта история встречается. Но неважно, как вас угораздило вляпаться в Agile, разберёмся, куда вы попали, что это окружение собой представляет и какие требования предъявляет к вам и вашим командам. Если с этим не разобраться, очень часто внедрение Agile превращается фабрику фич.
Раньше разработчики брали тикеты с Jira. Сейчас они делают то же самое, но берут из того, что теперь называется бэклог: к вам подкатывают бэклог, вы из него берёте — и конвейер идёт. При этом где-то ваши продакты знакомят пользователя с тем, что получилось в итоге: юзер и продукт, поцелуйтесь!
Неужели это Agile? Мы же не для этого его делали.
Что такое и зачем Agile?
Вы знаете, что Agile — это подход к тому, как выполнять проекты в условиях большой неопределенности. Это матрица запутанности Стейси:
Agile-подход хорошо работает в ситуации, если у вас есть две большие неопределенности:
- что нужно делать для ваших потребителей, чтобы они проголосовали за вашу компанию и продукт деньгами;
или
- вы не знаете, с помощью каких технологий это реализовать,
то вы попадаете в сложную среду, в которой вам предлагается:
- отказаться от мнения, что вы знаете, что нужно вашим пользователям;
- выставить гипотезы;
- провести серию экспериментов;
- получить обратную связь от конечного потребителя (вначале недовольного, а в дальнейшем мы надеемся нащупать, как решать его проблему).
В результате у ваших команд и вообще у всей организации получается два фокуса:
- Что такое ценность для клиента? Нужно научиться измерять ее, работая с ценностью клиента системно.
- Делать это быстро. Иногда говорят, что крутость команды измеряется количеством гипотез, проверяемых за единицу времени.
Как это всё приземлить на наши реалии?
В чем задача лидера?
В системе есть два актёра: вы, как лиды, и ваши команды. Рассмотрим простой пример: команда делает продукт, но клиент недоволен. Что мы как лиды должны сделать, в чем наша задача в этой истории? Конечно, разобраться, в чём проблема: вы, как эксперт, идете и разбираетесь. Допустим, команда разработки передаёт на тестирование в последний день, поэтому огромное количество проблем дотягивается до пользователя. Что мы дальше делаем?
Мы уже знаем, в чём проблема, мы ее идентифицировали. Самое простое, что теперь можно сделать, это прийти к команде и сказать: «Слушайте, чуваки, вы сейчас так делаете — давайте вы так не будете делать! Давайте вы будете делать правильно». Так обычно поступают с детьми. Я говорю своему семилетнему сыну: «Владик, не делай так, пожалуйста!» И это, кстати, реально работает — он перестает так делать. Правда, мне потом жена говорит, что он только при мне так не делает. А когда я на работе, все продолжается по-прежнему.
Так что это не работает. Что мы тогда делаем? Меняем процесс, задаем команде вопросы, что можно было бы сделать, чтобы не делать плохо. По сути всё, что мы можем как руководители — это настраивать окружение, которое определяет поведение наших команд. Мы создаем среду, которая делает невозможным негативное поведение и мотивирует людей вести себя по-другому:
Например, вы внедряете Scrum. Отныне становится невозможным не поставлять результат хотя бы раз в 2 недели. Нет, разработчик может так делать, но получит мотивирующую и стимулирующую обратную связь, когда вы, как руководитель, пригласите на обзор спринта людей, которые скажут всё, что они думают про продукт, не стесняясь в выражениях. Постепенно ему становится почему-то немножко стыдно каждый день тащить одну и ту же задачу — приходится каждый день на Daily Scrum отвечать, что делал вчера, что будет делать сегодня, да еще и со злой добавкой «в рамках цели спринта».
То есть вы создаете среду, которая постепенно меняет мышление людей, и они начинают вести себя по-другому. Наша задача — постоянно думать над тем, как настроить окружение. В этом смысле мы становимся не руководителями людей, а механиками для настройки системы. Представьте систему — винтики-болтики крутятся сами (это наши умные специалисты), и между ними есть трение. Вы бегаете с масленкой и подливаете там, где что-то начинает трещать — настраиваете систему, которая работает самостоятельно.
И самые крутые из нас делают так, что система почему-то начинает сама развиваться. Например, вы делаете такую среду, в рамках которой команда умеет смотреть на результаты своей работы и, что называется, коучить самих себя: что еще можно сделать, чтобы стать еще круче? Правда, если вы настроили такую систему, для вас беда-печаль (или радость) — вы больше не нужны этой системе (как минимум, на каждодневной основе), система начинает развиваться сама. Это то, что называется самоорганизованная команда.
Но как этого добиться?
За что отвечает Scrum-команда?
Пойдем с низов – просто возьмем одну Scrum-команду, пока никакого масштаба. Вопрос к вам: за что у вас отвечают команды по итогам спринта? Когда спринт закончился, за что вы их журите?
Обычный ответ — за фичи. Если команда — это фабрика фич, то как тогда фичи связаны друг с другом? Почему именно эти фичи делаем, а не другие? Ответа на эти вопросы нет — такой среды еще не создано. Классический пример — доска команды из Авито примерно 2,5 года назад. Видно, что в конце спринта очень много задач еще недоделано – готово примерно только 40%:
Разберемся, в чем проблема. Одна из частых проблем на старте — команды не умеют оценивать. Надо научить их, что такое Story Point, как правильно к нему подходить, если в команде бэк, фронт и т.д. Покажите им на примере, как это делается.
Есть и другая проблема — они всё это умеют, но у них нет фокуса. Тогда приводим команду на ретроспективу спрашиваем: «В чем была цель вашей работы?» В ответ взгляд козы на баян и вопрос: «А что такое цели спринта?» ОК, давайте запишем в крупную клетку, что вы делали в течение последних двух недель. Они озвучивают, вы записываете. После этого каждый анонимно ставит оценку на стикер: «Насколько вы как команда достигли этих целей спринта?» То есть команде приходится отвечать на вопрос, обозревая все, что сделано:
Рассмотрим на примерах.
Цели спринта – 8 штук
По сути это обычные задачи. Более того, я создавал среду, которая показывала, что у каждого сотрудника своя собственная цель (задача). И когда отвечал другой человек, я брал маркер другого цвета:
Видно, что у каждого были собственные работы. А понимание того, насколько мы достигли цели, у команды совершенно разное. После этого обычно задается вопрос: «Насколько мы команда?» Ибо выглядит так, что каждый пилил только свою работу. Наверное, чувак, поставивший двойку, реально тащил тяжелую задачу и, кажется, ему никто не помогал. Особенно не помогал товарищ с девяткой — он свою задачу запилил и, наверное, в конце спринта занимался саморазвитием, хотя в другой части команды бомбило и была нужна помощь.
Цели спринта – 6 штук
Это другая команда, но ситуация такая же. Понимание действительности уже возле 8-9, но есть шестерка. Это как раз лид команды — он лучше всех понимал, насколько они приблизились к цели:
Цели спринта – 5 штук
Сжимаем цели. Забавно, но здесь уже нормальное распределение. 3-4-5 и 7-8-9 — это две подкоманды по три человека внутри команды, которые вместе тащили одну работу, и у них более-менее всё получилось. У ребят с 3-4-5 была тяжелая фича, они не справились. Но они примерно одинаково понимают, что они продолбали. Три шестерки — это сеньоры, которые лучше всего понимают, что происходит, потому что они помогали джунам в обоих частях:
Цели спринта – 2-3 штуки
Что, если вообще зажать? Чем меньше целей спринта, тем больше понимание действительности, — что мы на самом деле делали и насколько этого добились, — начинает у людей в голове совпадать:
Зачем я всё это показал? Почему круто, если у команды одна цель?
Важность цели в Agile
Потому что Agile от классики этим и отличается:
В классике мы обещаем набор фич и дальше можем играть: или больше ресурсов вкладывать в разработку, или продалбывать сроки. Есть только эти два параметра, потому что нужно весь объём сделать.
В Agile мы заранее понимаем, что находимся в области неопределенности и не знаем, какой набор фич реально нужен нашим потребителям: у нас есть только гипотезы. Иногда говорят — галлюцинации, — и в них самый большой эксперт — наш Product Owner. Он галлюцинирует в рамках двух ограничений: ресурсы закреплены (full-time команда, все на 100% выделены) и спринт закончится ровно тогда, когда он закончится, не раньше и не позже. Оба параметра зафиксированы, а мы хотим, чтобы скоуп был плавающим. Это не плохое, это классное свойство: мы хотели бы иметь возможность менять скоуп, получая обратную связь — то мы делаем или не то. Но нужен измеритель – это цель. Когда ещё цель стреляет?
В чем цель обзора спринта?
Есть два варианта проведения обзора спринта.
Команда показывает владельцу продукта работающий продукт по завершению спринта. Посмотрите, как он на него смотрит. Там был задан самый ключевой вопрос: «Product Owner, дай нам обратную связь: насколько мы добились цели спринта? И как нам нужно изменить дальнейший бэклог?» У Product Owner закрытая поза: «Что я вам тут могу сказать? Ну да, кнопки вроде работают». Возникает недоумение: как может владелец продукта дать обратную связь по работающим кнопкам, если нет реальной информации о том, как это будет работать в полях, то есть нет обратной связи от конечных потребителей:
Второй вариант — моя любимая история одной из команд компании Авито, которой тоже примерно 2 года. Эта команда связывает продавцов и покупателей в мессенджере. У нее две ключевые метрики:
- Снижение времени заключения сделки, чтобы люди быстро попереписывались в чате и договорились, когда, по какой цене и т.д.
- Чтобы люди покупки не уводили мимо платформы, и доска объявлений Авито получала комиссию со сделок.
Команда внутри спринта реализовала банальную фичу — кругляшок, который показывает, что на том конце провода покупатель или продавец сейчас онлайн: можно быстро написать, и он сразу ответит. Они на обзоре спринта показывали результаты А/В-теста, выкатив фичу на продуктив на ограниченное количество клиентов и посмотрев, действительно ли она коррелирует с этими двумя метриками. Явной корреляции замечено не было и команда попросила еще неделю, чтобы поснимать данные и понять: если эта фича всё-таки нужна, то как ее модифицировать?
Это два различных варианта. Ваша цель будет работать тогда, когда вы ее не просто как лозунг ставите, а когда она формулируется в метриках, которые реально можно измерить. Иначе это опять профанация.
Какими могут быть цели спринта?
Можно ставить цели на основе контрольных точек: сделать релиз к такой-то дате и т.п. Здесь снова мало информации: как вы измерите, что это то, что нужно вашим потребителям?
OKR предлагает другой подход: ставим цели от метрик, причем клиентских. Как клиент взаимодействует с вашим продуктом? Как это влияет на то, что он решает свои проблемы быстрее, лучше, качественнее и т.д. и готов за ваш бизнес голосовать деньгами? Поэтому у вас должны быть измерители.
Одним из свойств цели, как OKR говорит, должен быть уровень амбициозности. То есть мы за спринт хотим улучшить жизнь клиента не просто, а на сколько — до 80%, 52% и т.д. Это измеритель, куда вы хотите прыгнуть:
Итог: какое окружение мы создаём?
Бэклог продукта — это только набор гипотез. Мы, как механики этой системы, на уровне команды должны ментально менять отношение людей к бэклогу. У вас в бэклоге лежат галлюцинации. Поэтому задавайте всегда вопрос владельцу продукта, бизнесу и т.д. — зачем мы это делаем? Почему вы уверены, что это то, что нужно нашим клиентам? Если не уверены, то как мы можем измерить, что это действительно то, что им нужно? Меняйте ментальность и в команде, и ваших бизнес-заказчиков, чтобы вместе отказаться от ощущения, что вы всё знаете заранее.
Команда берет обязательства по цели спринта. Пожалуйста, не берите с команд обязательства за скоуп работ. Так вы по сути их толкаете в Waterfall, хотя называете это Scrum. Речь не о том, что надо сделать все фичи в спринте. Нет, ваша команда внутри спринта Scrum-процесса может даже менять бэклог вашего продукта, если вдруг обнаружится, что то, что вы галлюцинировали неделю назад, оказалось не тем, что приближает вас к цели. Конечно, две недели — это небольшой временной промежуток, и в конце, может быть, не сильно что-то у вас поменяется. Тем не менее, меняйтесь ментально — на масштабе эта проблема во всей красе выходит.
Бэклог продукта и спринта — это только план достижения цели. План нужно регулярно сверять с результатом и изменять при отклонении. Я уже говорил, что на Daily Scrum нужно каждый день задавать вопрос: «То, что мы делаем, с целью вообще коррелирует?» Постепенно вы приучите людей думать больше о цели, чем о скоупе. Но вначале нужно несколько раз это повторить, чтобы люди наконец поняли, зачем мы это делаем.
Фокус на конечный результат больше, чем на предсказуемость сроков поставки. Больше фокусируемся на том, чтобы добиться изменения каких-то метрик, чем просто затащить фичи. Даже можно какие-то фичи не доделывать: может быть, выполнив 2/3 вашего бэклога спринта, вы добьётесь улучшения ключевых метрик для клиента, и будет уже неважно, что 2 фичи не доделали. Цель-то в другом.
Обзор спринта — оценить степень достижения цели на основе обратной связи от клиентов. Причём, от реальных клиентов. Это челлендж для всех сотрудников, связанных с инженерной практикой, которую использует ваша команда: Continuous Integration, Continuous Deployment и т.д. Именно это сейчас штормит в других отраслях, где пытаются Agile применять.
Например, компания «Сибирский Гурман» в Новосибирске, которая делает пельмени, решила поэкспериментировать с областью неопределенности: а что, если менять вкусовую начинку пельменей или обертку, как это повлияет на покупаемость товара? Классно! — сейчас будем эксперименты проводить и получать обратную связь. Но что значит эксперимент? Они приходят к ритейлеру с новым форматом пельменей, а ритейл не хочет делать мелкие закупки и предлагает большую поставку на полгода — так эксперимент длится год. В результате «Сибирский Гурман» открыл собственный магазин, в котором можно быстро получить обратную связь, но магазин — это полностью затратная часть проекта.
В IT, как видите, всё проще. Уже всё придумано. А в других отраслях люди занимаются творчеством, чтобы как можно быстро получать обратную связь. Но происходит это у всех.
А что происходит на масштабе?
Где-то здесь на рисунке ваша командочка. И начинается: у каждой команды есть свой бэклог, своя цель, вы понимаете, кто ваш клиент, но почему-то к вам прибегает очень много людей (подрядчики, стейкхолдеры и т.д.), которые что-то еще от вас хотят (например, свои галлюцинации всунуть в ваш бэклог), и вы почему-то тоже их должны делать:
На уровне конечных симптомов мы имеем следующее:
- Огромное количество зависимостей.
- Мы часто заранее не знаем, от кого зависим — это низкая прозрачность того, с кем я должен договориться, чтобы выкатить какую-то фичу. Вы начинаете её делать внутри спринта и в этот момент узнаете: оказывается, API мы не можем изменить сами, надо бежать к тем-то; а тут нужно согласовать регламент, информационную безопасность и т.д. То есть заранее неизвестно, к кому бежать.
- Как следствие, коммуникации становятся странными и неэффективными. Нам бы заранее знать, с кем и что мы должны согласовывать. Тогда бы мы просто строили план общения с этими людьми, и было бы всё классно. А так мы носимся все ко всем.
- Как следствие — медленное принятие решений. Если у вас какая-то проблема возникает, как найти тех людей, которые полномочны разрешить эту проблему? Сначала вы выясняете, от кого вы зависите, при этом неэффективно коммуницируете, и только потом решаете эту проблему. Всё замедляется.
- Бизнес и разработка разобщены — это прямо священная битва. Бизнес говорит: «Ну сделайте уже то, что я сказал! Идите и делайте!» — «А что тебе надо?» Это взаимное непонимание.
Откуда на масштабе всё это берется и почему возникает? Рассмотрим на примере классического примера получения кредита, откуда в банке возникают все эти зависимости.
Первое, что банк должен сделать — это рассказать людям о том, что у него классные условия кредита: качественные, быстрые и т.д. На самом деле работа с клиентом начинается с маркетинга. Дальше идут оценка, оформление и т.д., вплоть до полного закрытия кредита. В компании есть операционные службы, которые непосредственно обслуживают клиента и общаются с ним:
Дальше уже появляются IT-системы, которые поддерживают, ускоряют, автоматизируют — в общем, делают так, чтобы клиент классно и быстро получил кредит. Здесь появляются наши люди, наша оргструктура. Здесь надуманный пример: в IT-департаменте Москвы 310 разработчиков, в Эстонии 30 человек и еще вендор в Америке (150 человек):
Реальный пример про меня. Когда я получал третью ипотеку в моем любимом банке, на стадии №2 (быстрая оценка заявок) мне пришел отказ. Вечером этого же дня мне звонит мой ВИП-менеджер с классическим вопросом: «Сергей, все ли хорошо у вас с нашим банком? Может, чем-то могу вам помочь?» Конечно, я на него наезжаю: «Чувак, что случилось? Я же ваш VIP-клиент. Почему мне отказали в ипотеке, когда у меня всё нормально по параметрам?» Он попросил таймаут и перезвонил мне вечером — он не смог сразу ответить на вопрос, потому что заглянул в CRM и не увидел там вообще никакой информации о том, что я даже заявку подавал.
Причиной было то, что в те годы этот банк первую часть операционного обслуживания передал на аутсорс своему партнеру. То есть был головной банк и банк-партнер, который на входе обслуживал клиентов — грубо говоря, мне отказал не головной банк, который меня любит, а его партнер. Так как ответственность одного банка закончилась на стыке с ответственностью другого, — интеграция сломалась. Небольшая ошибка привела к тому, что головной банк не знал, что с его любимым клиентом не очень хорошо обошелся банк-партнер. На таких стыках бизнес очень часто теряет своих клиентов и, как следствие, — деньги.
К чему я это? Представьте, что ваша Scrum команда — кросс-функциональная относительно бэк, фронт и т.д., — находится где-то внутри этой структуры. Ключевой вопрос: насколько кросс-функциональны ваши команды относительно решения проблем клиента? В идеале кросс-функциональность должна быть такой, что вы можете помочь клиенту на любом этапе его жизненного цикла общения с компанией. Представляете, сколько компетенций надо засунуть в одну Scrum-команду, например, на 11 человек?
К сожалению, на большом масштабе это основная проблема: команда перестает быть кросс-функциональной относительно клиента. Решение такое: давайте соберем большую команду команд, которые в совокупности будут максимально кросс-функциональны.
Вот пример (два красных стикера). Стикер с надписью «Ипотека» означает, что мы меняем оргструктуру таким образом, что появляется ипотечное подразделение (стрим, трайб, поезд и т.п., в разных компаниях это по-разному называется). Мы объединяем бизнес (отвечает за финансовые метрики по выдаче ипотеки) и команды (живут в Москве и в Эстонии), чтобы развивать системы в первой части этого стрима, исправлять любые ошибки интеграции и т.д.:
В моей истории вендора не удалось затащить в эту тему. Они сказали: «Напишите нам ТЗ, мы всё сделаем». Но в любом случае, вы формируете подразделение, которое максимально широко смотрит на своего клиента. Часто звучит тост: «Фокус на клиента, ценность», но посчитайте, какое количество шагов закрывает это подразделение. Чем больше оно закрывает, тем оно более крутое, точнее, постепенно станет крутым и сможет решать все проблемы клиента.
Зачем я это рассказываю? Задача лида — не просто выстраивать окружение для развития команды. Для начала вам нужно понять:
- В каком контексте вы находитесь?
- Какие шаги и проблемы клиента ваша команда или подразделение решает?
- Кто ваш бизнес?
- Какая конечная клиентская KPI у вашего подразделения? То есть что вы улучшаете, причем не только ваша команда, а весь контур.
Для примера представляю три варианта кросс-функциональности подразделений.
Вариант 1: по каналам с платформой
Одно из них — это по сути весь веб-канал, там все веб-разработчики. Например, для банка основные метрики будут по привлечению, чтобы клиент попробовал кредитным калькулятором посчитать и превратился уже в ипотечного заемщика.
Мобильное приложение (iOS, Android и т.д.) уже с метриками, связанными с активацией и обслуживанием. Может быть также платформенное подразделение, то есть делающее компонент, потребителями которого являются другие подразделения:
Вариант 2: по продуктам с платформой
Второй вариант более крутой: вы оргструктуру меняете таким образом, что каждое подразделение становится кросс-функциональным относительно каналов. Нужно что-то в кредитах починить — мы это и в веб-канале делаем, и в мобилке, то же самое с дебетовыми картами. Подразделение полностью может изменять любые каналы. Но вам нужно сделать так, чтобы подразделения могли вносить изменения в одну и ту же кодовую базу.
Это более сложный, но более крутой вариант. Он очень нравится бизнесу, потому что дебетовый стрим зарабатывающий: можно понять, сколько мы зарабатываем, плюс есть фонд оплаты труда команд разработки. Как следствие, вы соедините выручку с затратами. Ваше подразделение становится маленькой компанией внутри огромной, потому что у него есть свой P&L и можно смотреть, насколько вы как микро-организация эффективны:
Вариант 3: по шагам Value Stream
В сложных кейсах есть огромное количество подразделений, и каждое отвечает за сет метрик. В больших организациях это наиболее популярный вариант:
Какое окружение мы создаем на масштабе?
На масштабе мы создаем такое же окружение, что и на уровне одной команды. Оно на самом деле решает ту же задачу, но мы растим кросс-функциональность относительно всего клиентского пути. Поэтому есть море сложностей: коммуницирование с бизнесом, другими командами, более сложные циклы (не двухнедельные, а квартальные):
Совместное планирование квартальных целей: OKR Planning (PI Planning)
Хорошо. Ваша команда уже понимает, что вы не можете помочь вашему клиенту на всех его этапах. Но вы понимаете, что есть бизнес, вместе с которым вам нужно планировать изменение клиентских метрик. Понимаете, что есть еще куча народу: порядка 150 других специалистов (10-12 команд). И с которыми, похоже, придется общаться, потому что вы от них зависите, а они — от вас.
Как общаться? Во всех подходах Agile даёт простой рецепт: «Just talk: есть у тебя с кем-то зависимость, пойди да поговори с ним». Разработчики, особенно те, которые любят больше общаться с монитором, чем с другими людьми, говорят: «Ну, я не могу так — как просто just talk?» Поэтому все фреймворки предлагают принуждение к общению: «Хорошо, вы не умеете общаться. Сейчас будете общаться, но по следующему алгоритму».
Сейчас набирает популярность совместное планирование OKR (в другом подходе называется PI Planning). Идея в том, что на длинный промежуток времени (квартал) мы вместе, всей толпой, понимая, кто наш бизнес и зависимости внутри, планируем общие цели. Это двухдневное мероприятие, но некоторые умудряются провести его за день, если команды уже научились общаться между собой. Грубо говоря, это двухдневное фасилитированное мероприятие в формате вопрос – ответ, типа:
– От кого мы зависим?
– Что мы делаем в этом квартале?
– Какие финансовые метрики мы хотим получить? Бизнес, ответь, пожалуйста.
То есть мы делаем так, чтобы все со всеми договорились и выработали, куда мы хотим прибежать к концу квартала. Это реальные фото, когда три года назад Сбербанк первый пробовал запускать такие мероприятия:
Совместное планирование OKR или PI Planning проводятся этапами.
Брифинг
На старте брифинг обязателен. Бизнес должен сказать: «Хотелось бы, чтобы к концу квартала…» И на примере здесь сверху Сбербанк года 3 назад, а снизу – GameDev-компания Xsolla из Лос-Анджелеса. Американцы, кстати, рассказали простую историю, что у них нет никаких проблем с активацией новых клиентов: с метриками по активации всё классно. Но есть проблема с повторными покупками: почему-то процент повторных покупок очень низкий. И вторая проблема в том, что почему-то допуслуги не покупают, средний чек низкий. И бизнес попросил: «Пожалуйста, все фичи в этом квартале нацеливаем на повторные покупки и повышение среднего чека (допуслуги)»:
Это один из вариантов, как может выглядеть хороший vision: когда мы говорим про контекст бизнеса и финансовые метрики. Но заранее мы не знаем, что получится сделать в квартале. Что происходит дальше?
Выступление архитектора
В IT-компаниях мы обязательно слушаем архитектора. Для него — интересная история! — тоже меняется окружение. Архитекторы наконец-то на таких сессиях понимают, кто является их заказчиком (большинство корпоративных архитекторов думают, что это бизнес):
Этот архитектор хотел быстро доложить про «страшный» ландшафт Сбербанка и убежать: «Я же все сказал! Более того, дал концептуальную архитектуру на 50-100 страниц. Что мне тут еще делать? Всё же понятно, но если что — звоните». Но после презентации один из тимлидов задал ему вопрос:
– Уважаемый архитектор! Третий сверху правый кубик — знаешь ли ты, что эта система ещё не находится в эксплуатации?
– Конечно, знаю. Я же сам эти кубики рисовал.
– Ты знаешь, что она будет введена в эксплуатацию через полгода?
– Да, конечно же.
– А теперь вспомни, что мы на сессии планирования цели на квартал, а бизнес от нас хочет функционал, который по идее должен через эту систему проходить.
Тут архитектор понимает, к чему вопрос. И команда его попросила остаться с ними, чтобы когда они будут планировать свои фичи, они вместе подумали, как делать нецелевое решение.
Swarming (генерация цели)
Дальше команды отправляются в свободное плавание. У них есть три часа, и они должны сгенерировать цели, за которые они готовы взять ответственность на квартал. Называется это Swarming (роение, жужжание). Это такой нетворкинг, но в рамках работы:
Конечно, не всё так просто. Ребятам задается алгоритм дохождения до того, какие адекватные цели они могут взять на квартал. Они делают флипчартные листы, на которых отображены предположительные бэклоги спринтов на квартал вперед. Это нужно, чтобы после того, как они с учетом своей доступности примерно наполнят свои бэклоги и поговорят с другими командами по зависимостям (кто, кому, что когда сделает/не сделает), задать им вопрос: «Если вы все эти работы затащите, каких целей вы добьетесь, и с помощью какого измерителя (метрики) можно будет измерить степень достижения?»
То есть мы планируем бэклоги работ, потом по ним формулируем цели, после этого от этих бэклогов отказываемся. Это просто методика того, как прийти к адекватной постановке цели. Ни в коем случае не думайте, что ребята коммитят на квартал все команды на этот сет работ:
– Команда, придумайте себе цель!
– … Вот такая!
– А вы уверены, что ее достигнете?
– Нет, ты ж попросил просто придумать.
Нет, мы фасилитируем, то есть помогаем прийти к более-менее адекватным целям.
На фото представители команд, которых заставили общаться. Они на эту сессию иногда приходят с ощущением: «Да мы понимаем, что будем делать, и вроде бы даже знаем зависимости от других команд, потому что говорили с ними на прошлой неделе». Но когда прямо просишь проговорить, что команды будут делать в этом квартале, наконец-то вскрываются зависимости:
Мы даём им инструмент для того, чтобы они, проговорив про свои зависимости, отобразили их и видели, кто от кого зависит. Вертикальные отбивки — это спринты внутри квартала, горизонтальные отбивки — команды. На пересечении команда ставит, какую фичу она будет делать, и красной стрелочкой подтягивает: «А вот они нам обещали сделать на спринт раньше API, тогда мы кнопку на фронте сделаем». Это протокол договоренности, что мы с вами договорились, кто, кому, когда и что:
Презентация Product Owners
Дальше на презентации владельцы продуктов показывают результаты своих команд:
Единственный, кто в этот момент пытается склеить в мозгу, как будет работать сквозной сценарий, — это бизнес. Любой вопрос к Product Owner на старте типа: «Какой сквозной сценарий будет работать?», — часто остается без ответа: «Подождите, мы за этот компонент отвечаем. У нас это будет работать, ваш вопрос не к нам. Пули с нашей стороны вылетели, ищите в других командах ответ на ваш вопрос». На старте бизнес ничего не понимает, но пытается в голове эту картинку склеить.
Внешние зависимости
В компании Xsolla предпоследняя строчка Tech Ops. Ребята уже понимают, что надо DevOps заниматься, соответственно поддержку сред заносить внутрь команд. Но на тот момент (полгода назад) это было внешнее подразделение. Руководитель эксплуатации тоже презентовал — он шел по красным стикерам и подтверждал: «Да, вы мне тут впихнули, что надо такие-то среды развернуть. Я беру ответственность, мы будем это делать»:
Интересно, что когда на одном стикере он проговорил, что они будут делать, его команда поправила:
– Подожди, чувак, мы не это тебя просили, а другое. Понял?
– Понял.
– Сделаешь?
– Сделаю.
– ОК.
С юристами, маркетингом, дизайнерами у них прямо проблема была — эти ребята в Америке (в Лос-Анджелесе), и они не приехали на эту встречу. Поэтому зависимости от них повесили, но был страх: может быть, они сделают, но надо отдельно созваниваться, общаться и т.д. Вывод для этой компании был, что на следующий квартальное планирование они их также приглашают.
Обработка рисков
Есть определенный алгоритм того, как обрабатываются риски. Ключевая идея: мы создаем окружение, в котором, оказывается, топ-менеджменту можно ставить задачи. И это даже не страшно, они готовы их брать. Они смотрят: «Если я тут починю контракт с нашими аутсорсерами, оказывается, мы сможем больше сделать того, что я хочу», — и так вовлекаются.
Это примеры решения проблем, которые можно принять, если у вас все есть на этой встрече:
Голосование пальцами
Последний этап — мы проверяем, действительно ли команды готовы брать ответственность за те цели, которые они выработали. Мы просим поднять пальцы:
- 5 пальцев — прямо очень уверены в своих целях;
- 1 палец — с целями вообще беда, их надо переделывать.
Вы смотрите общую картину и, если видите низкую уверенность в компании, просите оглянуться вокруг: «Посмотрите, кажется, вы сами не верите в свои цели. Идите переделывайте, сделайте так, чтобы вы сами верили в свои планы. В вас же никто их не впихивает (по крайней мере, старается)»:
Совместная ретроспектива в конце квартала: OKR Review (Inspect & Adapt)
В конце квартала опять собираем всех вместе. По сути это большая ретроспектива (в OKR называется OKR Review):
Что там происходит, покажу на реальном примере. Выписаны цели, которые команда брала на себя на этот квартал. У них есть плановая оценка влияния на метрики, то есть на те цели, которые бизнес хотел от команды и компании. Оценивается фактическое достижение:
Здесь опять стреляет: умеете ли вы оценивать план-факт не просто как «Нам кажется, эта фича, наверное, повлияла», а собрали ли продакты с бизнесом реальные метрики с А/В-тестов, с каких-то вариантов дотягивания до клиентов.
Другой вариант: если команда еще инженерку не настроила, не умеет быстро дотягиваться до клиента, они оценивают, как в Planning Poker, только пальцами: «Нам кажется, что мы достигли этой цели на столько-то»:
Они ставят себе по сути процент достижения: видно, что команда достигла за квартал 88%. Идея в том, что такая метрика показывает:
- Насколько амбициозные цели вы вместе с бизнесом ставите;
- Насколько слаженно умеете их дотаскивать:
В конце проходит обычная ретроспектива и каждая команда работает по отдельности. Ключевой момент: вытаскиваются общие проблемы: не отдельно каждой команды, а те, которые стреляют по нескольким сразу. Обычно мы делали критерий 3+ команды. Если у них общая проблема, значит, надо решать ее на уровне всего подразделения:
Резюме. В чем проблема лидера?
В чем задача для нас во всей этой истории? Вроде бы понятно, что делать. Но вы находитесь в контексте большой среды: другие команды, бизнес, понимание, какие части клиентского пути вы решаете и для каких клиентов. На самом деле нас, таких лидов и тимлидов, очень много:
Какое требование к нам на масштабе формируется? В чем проблема лидера? В том, что размер имеет значение… :)
Чебурашка мутировал в крокодила для лучшей выживаемости в тяжелых средах крупных компании… По другому говоря, вам нужно саморазвиваться. Это набившее оскомину высказывание, но на самом деле, если вы не саморазвиваетесь, люди под вами тоже это не делают. А в условиях огромной компании требования безжалостны к тому, каким вы должны быть лидером. Вам нужно уметь настраивать среду на огромное количество команд, то есть саморазвиваться в разы активнее.
Какие лидеры выживают в Agile
По сути вам нужно перестать управлять людьми. Формируйте среды, в которых люди самоуправляются. Перестаньте быть экспертом, станьте «договаривателем».
Вот то, что стоит верифицировать, насколько вы круто развились по всем этим направлениям:
В этом году мы проведем проведём вторую TeamLead Conf в Москве вместо Saint TeamLead Conf в Санкт-Петербурге. Уже 16 и 17 ноября мы встретимся вживую и обсудим, что изменилось за это время. Мы уже истосковались по настоящим очным конференциям. Таким, чтобы видеть харизму спикера на сцене и потом еще час расспрашивать его в холле. Чтобы выпить месячную норму кофе и повидать сразу всех знакомых тимлидов. И еще месяц после этого разбирать записи с контактами, книгами и ключевыми словами.
Приходите на конференцию для тимлидов, поговорим о том, как изменились команды, компании и процессы в них за время карантина, и исследуем последствия масштабного эксперимента по перёходу всех сотрудников на удалёнку. Тем будет много: и управление командой, и личное развитие, и бизнес-процессы, и инструментарий тимлида, и много чего ещё.
Расписание. Билеты. Какие будут доклады. Как это было в 2019 году.
