Вспомните какое-либо изменение из тех, которые у вас удались и сейчас приносят пользу вашей компании. В какой момент вы поняли, что оно приживается? Вы контролировали его или в какой-то момент ему доверились? Подумайте об этом. Я вернусь к этому в конце статьи.
Трансформация финтех-компании
Я хочу рассказать о трансформации одной финтех-компании и показать разные управленческие решения сквозь призму трех не столь распространенных подходов.
Кейс выглядит примерно так. Есть финтех-компания, которая, как и большинство финтех-компаний, внедряет Scrum. Внедрение идет с 2014 года, но Scrum используется скорее как некоторое подспорье основным процессам: команды применяют отдельные его элементы.
В 2017 году я прихожу в эту компанию как agile-коуч, а впоследствии становлюсь руководителем agile-коучей и Scrum-мастеров. В 2019 году мы понимаем, что это долгое, почти пятилетнее внедрение не принесло тех плодов, о которых рассказывают консультанты, объясняя, зачем вообще нужен Scrum. При этом стратегия компании подразумевала, что нам нужно быстро вносить изменения и быстро проверять продуктовые гипотезы – собственно, делать то, для чего Scrum и предназначен.
Было принято решение форсировать трансформацию. Перед нами встал вопрос, как это сделать.
Стандартный подход к управлению изменениями обычно опирается на два базовых фреймворка: восемь шагов Коттера или модель ADKAR. Их суть сводится к тому, что нужно взять всю компанию, засунуть ее в базовый лагерь и начать успешное восхождение к вершинам трансформации.
В нашем случае применять такой подход было бы странно. Во-первых, трансформация уже шла. Во-вторых, причина, по которой мы ее перезапускали, была связана с последствиями подобных способов управления изменениями – с сопротивлением внутри компании.
Индустриальные подходы к управлению изменениями, как правило, не учитывают нелинейность организации и очень ограниченно работают с сопротивлением конкретных людей, команд и групп. Когда организация на пути к изменениям или уже в процессе сталкивается с сопротивлением, трансформация зачастую просто останавливается или откатывается. В рамках этих фреймворков разрешить сопротивление невозможно, и не очень понятно, что делать дальше.
Наша идея состояла в том, чтобы идти не от планов трансформации, а от того сопротивления, которое изначально не позволило нам двигаться дальше.
Такие фреймворки на рынке тоже есть. Это векторная теория изменений Дэйва Сноудена, создателя Cynefin, опирающаяся на теорию сложности; Lean Change Management – модель, которая помогает организовать эксперименты внутри компании; Белфастская модель – одна из гештальт-моделей, сфокусированная на непосредственном сопротивлении на местах и методах взаимодействия с ним.
Дальше я разберу несколько видов сопротивления, с которыми мы сталкивались, подсвечу отдельные нюансы этих моделей и покажу, какие управленческие решения мы принимали, руководствуясь идеями данных фреймворков.
Сопротивление 1: У нас тут Скрам (но без обязательных элементов), отстаньте
Первое сопротивление выглядело следующим образом. Мы приходим в команду, а нам говорят: «Нет, у нас тут Scrum. Scrum-мастера нет, инкрементов нет, спринтов нет, дейликов нет, но у нас Scrum. Отстаньте от нас, пожалуйста».
Первый взгляд на эту ситуацию дал нам понимание, что она, похоже, подвержена так называемому Хоторнскому эффекту. Суть эффекта заключается в следующем: когда вы запускаете какой-то пилот или трансформацию в ограниченном пространстве, вы ведете усиленное наблюдение за ним, потому что вам очень важно, чтобы трансформация состоялась. Поведение людей меняется не в силу самой идеи трансформации, а потому, что за ними наблюдают.
Это проблема: когда наблюдение исчезает, вместе с ним исчезает трансформация. Люди просто откатываются назад, выдыхают и говорят: «Слава богу, наблюдатели ушли, теперь можно поработать нормально».
Так эта ситуация выглядит с точки зрения векторной теории изменений. В ней Хоторнский эффект является одной из ключевых методических опор.
Второй взгляд, который позволил нам раскрутить ситуацию, – взгляд через Белфастскую модель. Она говорит о том, что в компании есть определенные традиции. Условно традициями называется то, на что мы тратим время, силы и энергию, несмотря на то что смысл этого уже давно утерян. Посмотрев на ситуацию сквозь эти две призмы, мы приняли несколько решений.
Первое – полностью отказались от пилотов. Почему? Потому что пилот забрасывает в систему идею о том, что изменение еще может откатиться. Мы решили, что играем по-настоящему. Для этого, конечно, пришлось совершить некоторый прыжок веры и поверить в то, что Scrum действительно поможет нам достичь бизнес-результатов. Но бенчмарков и кейсов на рынке было достаточно, чтобы этот прыжок совершить.
Второе решение – распараллеливание элементов и сознательный отказ от любых плейбуков, то есть от единых для всей компании правил, которые определяют, как нужно правильно вести себя в Scrum.
Почему это важно? Потому что тогда каждая команда получает возможность найти собственный путь к цели, к которой мы идем, и опираться не столько на общие правила, сколько на свой текущий контекст и положение по отношению к общей цели.
Результатом такого подхода стало то, что во всех командах очень быстро появились базовые элементы. Как только они возникли, мы получили возможность развивать ситуацию с их помощью: улучшать те или иные элементы процесса и смотреть, где эксперименты проваливаются или тормозятся и что с этим можно сделать.
Кроме того, необязательным, но крайне желательным элементом Scrum является кросс-функциональное развитие команд и сотрудников. Мы буквально сразу получили этот эффект, потому что строили развитие команд именно из этой логики. Команды стали меньше времени тратить на проработку требований – плюс один шаг к нашей общей цели.
Сопротивление 2: Если вы внедрите это изменение, то мы уйдем
Без нюансов, естественно, не обошлось. Следующий вид сопротивления, с которым мы столкнулись, звучал так: «Если вы внедрите это изменение, мы уйдем». И такие заявления поступали далеко не от одного человека.
Мы смотрели на это сопротивление следующим образом. Есть система, и у системы есть иммунитет. Все правила, которые до сих пор действовали, при попытке их изменить создают некоторый иммунный ответ. Значит, наша задача должна сводиться к тому, чтобы убрать этот иммунный ответ и дать системе развиваться в нужном для нас направлении.
Наше первое решение: мы сознательно не боролись за таких людей и совершенно точно не останавливали трансформацию. Мы говорили: «Хорошо, мы тебя услышали. Давай обсудим, как мы можем сотрудничать в этой ситуации, но изменения будут происходить несмотря на это». Кто-то ушел, кто-то не ушел. В конечном итоге мы практически этого не заметили.
Но мы сделали еще одну вещь. Поскольку нам было важно снизить иммунный ответ, мы вывели из продуктовых команд всех проектных менеджеров. Если мы внедряем продуктовую разработку, то давайте избавимся от проектной составляющей внутри нее. Мы также частично вывели аналитиков, а проектных менеджеров – всех без исключения.
Чтобы нивелировать эффект от этого решения, мы добавили для команд требование самостоятельно заниматься детальной проработкой требований. И снова получили прекрасный результат.
Во-первых, ушли далеко не все. Во-вторых, поскольку команды теперь сами прорабатывали требования, а не получали их от кого-то другого, они стали лучше разбираться в системах. Они смогли выполнять работу на стыках систем и даже работать в чужих системах, с которыми раньше никогда не взаимодействовали.
В результате у нас начали появляться своеобразные команды спецназа, которым можно было доверить любую работу в любом продукте, и они с ней прекрасно справлялись, потому что им пришлось взять на себя ответственность за процесс и за то, как именно они выполняют свою работу. При этом больше не было конкурирующего процесса в виде проектного управления, который создавал бы иммунный ответ.
Сопротивление 3: У меня и так работы много, а тут еще и вы всех моих подручных уволили, наймите новых
Дальше – больше. Мы вывели проджект-менеджеров из команд, сократили количество аналитиков, и, естественно, началось недовольство со стороны владельцев продуктов. Работа, связанная с договорами, синхронизацией между продуктами и другими подобными задачами, полностью легла на них. Владельцы продуктов говорили: «Наймите мне обратно этих прекрасных людей».
Дэйв Сноуден называет такую ситуацию лиминальностью: старые возможности в системе уже отсутствуют, а новые еще не появились и не прижились.
Выбираться из этой ситуации мы пытались с помощью подходов векторной теории изменений. Проверяя свои шаги, мы учитывали традиционное представление о том, что любой менеджер должен заполнить свой календарь чем-то очень важным, какой-то операционной деятельностью, чтобы чувствовать себя незаменимым и находиться в безопасности. В условиях изменений это в принципе нормально.
В какой-то момент мы забросили в систему новый вектор. В командах, где возникало такое сопротивление, мы говорили: «Давайте будем снижать количество операционки, которая падает на владельца продукта».
Пример на изображении немного синтетический: я не мог использовать реальные данные, но суть именно в том, как мы ставили эти векторы. Здесь нет конкретной цели или измеримого результата. Есть только направление, в котором мы идем, потому что направление создает пространство для движения.
Если бы мы поставили туда KPI, то получили бы простое выполнение KPI вместо того, чтобы привить системе новое поведение. Такое проявление системы при постановке целей достаточно хорошо известно и описано в большом количестве литературы.
Самое важное здесь – мы поняли, что за изменение отвечает вся команда. Значит, всю команду нужно синхронизировать вокруг одного вектора.
Большинство векторов, когда мы расписывали, что нужно сделать для продвижения в выбранном направлении, всегда включало всю команду целиком. Что-то должна была сделать команда разработки, что-то – Scrum-мастер, что-то – директор по развитию продукта или, например, я. Таким образом каждая команда нащупывала собственный маршрут продвижения.
Ситуация сдвинулась с мертвой точки, и у нас появился следующий вид сопротивления, который во многих компаниях даже не распознается как сопротивление.
Сопротивление 4: Покажите нам Best practice в нашей компании
Почему просьба показать best practice – это сопротивление? Когда вы внедряете что-то новое, очевидно, что внутри вашей компании никаких best practices еще не существует. Люди, как правило, апеллируют к ним, чтобы мягко намекнуть, что не хотят быть первыми в этом прекрасном процессе нанесения непоправимой пользы.
Это ловушка. Если мы берем поведение какой-то одной команды за образец, то сразу получаем то, что называется карго-культом: имитацию процесса без его смысловой составляющей.
Наше решение сводилось к тому, что команда изменений – это вся Scrum-команда, а не только Scrum-мастер, тимлид, которого, кстати, в Scrum нет, но у нас он был, владелец продукта или кто-то другой, отдельно назначенный ответственным.
По большому счету KPI по изменениям – точнее, по продвижению в рамках трансформации – распространялись на всю команду. Тем самым мы синхронизировали процесс изменений и фокусировали его. Не было ситуации, когда у тимлида одна адженда, у Scrum-мастера – другая, у владельца продукта – третья, и лебедь, рак и щука тянут в разные стороны. Такой подход позволял хорошо фокусировать и синхронизировать команду в одном направлении.
Вторая важная история – неделя организационного развития. Ее суть заключается в том, что, когда я погружен в операционку, мне некогда делать что-то по-новому. Это ключевой момент.
Поэтому мы стали работать с изменениями накатами, волнами. Мы вывозили людей на неделю, практически останавливали работу и помогали им продвинуться в каком-то направлении, связанном с трансформацией.
Где-то речь шла об операционке, где-то – о взаимодействии продуктов, где-то – о том, чтобы у владельцев продуктов появились адекватные роуд-мэпы, гипотезы и способы их проверки.
Когда мы вырывали людей из привычного темпа, они работали с новыми подходами и практиками. Возвращаясь в привычную среду, они уже имели новые инструменты, которые могли использовать сразу.
В результате у нас появились общие границы изменений: например, все команды работали по Scrum. Но то, как именно он был устроен внутри, зависело от каждой отдельно взятой команды. У команд были разные практики и разные календари, за исключением общего синхронизационного календаря компании.
Мы получили возможность распространять хорошие практики – не best practices, а именно хорошие практики – горизонтально. У нас были сообщества, где люди могли рассказывать друг другу, как у них получилось сделать те или иные вещи. Кроме того, существовали гостевые спринты: можно было пригласить к себе человека из другой команды, чтобы он поработал вместе с вами и показал, как они выполняют определенную задачу. Или, наоборот, можно было самому пойти в другую команду, поработать вместе с ней и посмотреть, что у нее хорошо получается.
Основная задача трансформации заключалась в том, чтобы разогнать, то есть ускорить, продуктовую разработку.
В результате у нас появились команды спецназа и примерно стандартный процесс, несмотря на отсутствие плейбука и best practices. Самое главное – мы получили возможность усиливать один продукт другими командами.
Предположим, конкретному владельцу продукта требуются дополнительные ресурсы. Вместо того чтобы полгода ждать, пока наймут новых людей, мы можем взять команду любого другого продукта и переместить ее в этот продукт. Поскольку базовые правила у всех одни и те же, ребята очень быстро погружаются в процесс и продолжают работать.
Откуда мы без метрик знали, что идем в правильном направлении?
Отдельная история, конечно, связана с измерением. Здесь надо понимать, что мы сознательно не ставили никаких специальных метрик, потому что основной метрикой для нас была выручка компании. Все остальные метрики – вспомогательные.
Такой подход позволяет не закреплять вспомогательные метрики. Например, не продолжать работать над скоростью, когда уже пора работать над мощностью или производительностью, а выбирать показатели локально – под задачи конкретного продукта, конкретной команды и конкретной ситуации.
Общее направление движения мы отслеживали с помощью векторов. Вначале речь шла о том, что люди в командах не ходят на дейлики или не очень хотят следовать процессу. Это, откровенно говоря, мало влияет на бизнес или, по крайней мере, непонятно, как именно влияет.
Со временем уровень векторов возрастал и становился все ближе к бизнес-значимости. Например, один из финальных векторов, которые я видел у некоторых команд, звучал так: нам нужно научиться создавать кросс-продуктовые решения для ситуаций, когда клиенты приходят не за одним продуктом, а за пакетом из нескольких продуктов.
Благодаря тому, что мы могли наблюдать за движением этих векторов, мы видели положительные изменения. А глядя на основную метрику – выручку, – мы тоже были довольны тем, как все происходило.
В какой момент изменению можно довериться
Вернемся к вопросу, который я задал в самом начале. Я хорошо помню момент, когда у меня переключилось восприятие этой трансформации.
Когда вы построили план и поставили себе KPI, команды воспринимаются как некоторая помеха: они мешают мне получить годовой бонус за трансформацию. Но когда вы вынуждены ходить от команды к команде, от продукта к продукту и помогать людям сделать шаг в нужном направлении, у вас меняется оптика.
Ходя от костра к костру, от команды к команде, я понял, что моя задача не столько в том, чтобы выполнить KPI и смотреть на людей как на сопротивляющиеся препятствия, сколько в том, чтобы помочь им продвинуться в сторону, в которую мы считаем нужным двигаться.
Тогда это изменение состоялось для меня. Тогда я смог ему довериться.
Четыре совета
Если вы хотите попробовать такую оптику у себя в офисе, есть четыре вещи, о которых имеет смысл подумать.
Первое – избавьтесь от чего-то ненужного. У вас совершенно точно есть застаревшие артефакты, которые требуют поддержки непонятно зачем, давно устаревшие процессы, роли, которые больше не нужны, или встречи, которые уже давно не генерируют никакого результата. Выкиньте их. Просто выкиньте. Они тормозят ваше движение.
Второе – если у вас идет изменение, найдите человека, у которого получилось продвинуться чуть дальше, у которого что-то получается лучше. Походите за ним денек, посмотрите, что он делает такого, что позволяет ему находиться на этом уровне. Так можно подсмотреть и почерпнуть много интересных идей.
Третье – поговорите с главным нытиком. Я знаю, что мы все не любим нытиков. Но нытики – это люди, которые очень восприимчивы к системе. Скорее всего, то, о чем они ноют, – ситуация, с которой действительно нужно работать. Просто преподносится она не в очень хорошей форме. Это очень полезные люди. Поговорите с ними, спросите, что они видят такого, чего не видите вы.
И четвертое. Забронируйте в календаре время, чтобы сделать что-то по-другому. Не бегать со встречи на встречу, а сесть и придумать новый способ выполнения задач или процессов – добавить что-то новое в вашу рабочую жизнь.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
