Как правильно внедрять изменения, которые никто не хочет
Типичная история тимлида. Съездил на конференцию, узнал новые вдохновляющие идеи и загорелся ими. Начал сходу внедрять то, что (по его мнению) точно сработает, и получил закономерный отпор команды: «Зачем нам вообще что-то менять?»
«Но доклад был классный! Это точно рабочий инструмент!» — думает тимлид. Он начинает поддавливать, иногда уговорами, иногда — другими способами. Команда — «в штыки». Лид получает странный опыт: пришел с благой целью, а получил негатив. Теперь он больше ничего не хочет менять, даже когда это на самом деле нужно. Команда тоже пострадала: после неумелого change-менеджмента она не готова к изменениям вообще. Знакомая история?
И что же, теперь обходить конференции и заразительные идеи стороной? Не внедрять изменения в рабочие процессы команды, пока коллеги сами их не захотят? Совсем нет. Сейчас я ведущий разработчик в облачной платформе Selectel, возглавляю команду Compute. На собственном примере расскажу, как правильно внедрять новые идеи в работу команды и можно ли собрать целый «фреймворк» для улучшений.
Когда я был еще «зеленым» лидом, информации было много, а ее практического применения мало. Приходилось все проверять самостоятельно. Тогда я работал в продуктовой команде, нашими клиентами были госзаказчики.
История про метрики
Как-то я услышал доклад про метрики эффективной команды и понял, что мне не хватает трекинга времени в задачах. Без этих данных мне было сложно делать выводы об эффективности: мы делали много, но тонкий fine-tuning в условиях нашей Jira был невозможен.
Я поделился идеей с более опытными коллегами-лидами, на что они мне задали простой вопрос: «А зачем ты это делаешь, в чем смысл?» Несмотря на боевой запал после конференции, я задумался, все ли я понимаю в том, что буду менять? И осознал, что я как молодой лид хотел внедрить эти метрики, привнести что-то новое, но в действительности не знал, как это сделать.
В поисках ответа я исследовал доклад, понимал, что мне помог бы некий чек-лист, чтобы начать внедрять то, о чем говорил спикер. К сожалению, его я не нашел, поэтому перешел к самостоятельному изучению теории.
Я выяснил, что изменения — это досконально изученный и довольно управляемый процесс. А еще они неизбежны: команда вырастет и изменится, сам проект изменится.
Есть множество книг по теории управления изменениями. Придумано много разных методов, метрик и способов их отобразить — например, ADKAR, теория изменений (модель Левина). Ответом для меня стала формула успешности изменений Бекхарда, которая выражается простым неравенством:
Если левая часть неравенства больше правой, изменения успешно внедряются. Заметьте, что в левой части неравенства показатели перемножаются, а не складываются. Все потому, что если мы не работаем с каким-то элементом, то он превращается в ноль. И тогда, даже если мы хорошо проработали остальные элементы, итоговый эффект будет нулевым.
D — Неудовлетворенность ситуацией
Я начал рефлексировать:, а в чем мое недовольство текущей ситуацией? Почему у меня возникло желание что-то изменить, трекать время? Какие вообще есть проблемы в команде?
Это не про то, что «горит» прямо сейчас, а, скорее, про потенциальные риски. Чувствуется, что что-то где-то идет не так и может выстрелить. Главное — не натягивайте сову на глобус, не придумывайте проблему. Даже если вам очень хочется внедрить крутой инструмент.
Важно ответить для себя на простые вопросы:
- Какую проблему решает инструмент, о котором вы узнали?
- Есть ли вообще такая проблема у вас? Есть ли ощущение, что она есть?
- Зачем это лично вам? Что вы приобретаете от того, что в вашей команде появляется новый инструмент или что-то методически новое?
- Зачем это команде? Что она от этого получит? Это не должно быть только ваше решение или вещь, которая полезна только вам.
Если ответы есть, это добавит силы вашему изменению. Определившись с болевыми точками, вы поймете, как воздействовать на показатель D, который говорит о вашем недовольстве ситуацией.
Поделись печалью своей
После рефлексии приходит время разговора с командой. Расскажите, как вы видите проблему, четко, без воды: «Есть наблюдение, мне это не нравится. Что вы сами думаете по этому поводу?»
Выслушайте мнение команды, желательно каждого человека. Вполне возможно, они не видят проблему так же, как вы. Разговор может вылиться в дискуссию, но он даст вам новое видение на ваши опасения, поможет сформулировать, что же на самом деле является проблемой. Здесь мы не только до конца формулируем недовольство ситуацией (D), но и работаем с сопротивлением (R). Уменьшаем его за счет появления точки синхронизации, из которой все одинаково смотрят на проблему.
Как в итоге выглядела ситуация. Я хотел быть увереннее в долгосрочном планировании, но мне не хватало контекста: сколько мы реально что-то делаем. Плюс хотел удачнее закрывать спринты — на тот момент 40–50% от взятых задач не закрывались. Мы брали задачи, но никто не мог сказать, сколько времени уйдет на их решение. Даже попытки оценить сразу отбрасывались.
У команды было желание не таскать задачи из спринта в спринт и не гореть в овертайме. Процесс переноса задач между спринтами или отказ от них сильно демотивировал. Вопросов, почему мы так делаем и как к такой ситуации пришли, при этом не возникало.
В результате мы пришли к одной боли: мы хотели уменьшить страх от неизвестности объемов задач. Это было очень общее понимание проблемы, но оно неплохо у всех отозвалось. Оказалось, мы испытывали боль не от того, что не успеваем. А потому, что не понимали, какой объем займет работа — было бесконечное месиво из задач, которое сложно объять и понять.
Я тогда выскочил на белом коне: «У нас есть непонимание, так давайте трекать время! Это классная идея!» На что получил реакцию: «А зачем?»
Объясняя себе эту реакцию, я понял, что трекинг времени — это абсолютно контринтуитивная вещь, которую непросто привнести в мир IT. В заказной разработке эта история еще плюс-минус понятна, потому что заказчик выставляет бюджет и вы в рамках этого бюджета тратите время на решение поставленных задач. В продуктовой же истории вообще нет прямой связи, как работать с оценками времени.
Я вернулся к теории и понял, что наступил момент, когда мы предлагаем решение, выдвигая гипотезу.
V — Видение будущего
Мы не говорим, что точно знаем секрет успеха. Мы делаем предположение: «Вот это, скорее всего, даст нужный результат и решит нашу проблему. Наверное». Ключевое слово — наверное.
Это очень важный момент — честно сказать об отсутствии 100% уверенности, что идея сработает. Потому что ни вы, ни команда не знаете, получится ли у вас. То же самое делают продакты, когда тестируют гипотезы.
Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
Так, четко проговаривая, через какие действия мы придем к цели, можно проработать Vision, или видение будущего (V).
Сбор урожая
После выдвижения гипотезы собираем первичный фидбэк и опасения. Это может быть как «Точно не сработает!», так и техническая мантра, которую мы часто себе повторяем: «Работает — не трогай!»
Часто на реакцию влияет негативный опыт, который был в другой компании или в этой же команде. Вспомнятся все вьетнамские флешбэки. Еще мы склонны возводить дурной опыт в абсолют: «Тогда пробовали, и это не сработало. Было так плохо, что повторять не хочется!»
Будет и страх изменений. Нашему мозгу энергозатратно выстраивать новые нейронные связи, создавать другие паттерны для действий, поэтому мы интуитивно избегаем изменений.
Страхи — это то, с чем нужно работать. Поэтому важно выслушивать и фиксировать все опасения. Делайте это максимально прозрачно, четко проговаривайте: «Так, я услышал это опасение и записал его». Это уменьшает сопротивление изменению (R) просто за счет того, что человек чувствует себя услышанным.
Мы с командой выявили три опасения:
- Опасение #1: Но ведь к нам потом придут и скажут, что мы не дорабатываем. Мы же не работаем 8 (16–20–40) часов в день.
- Опасение #2: Мы будем забывать отмечать время, а потом мучительно вспоминать, сколько было затрачено. И вообще, это новая история, непонятно, как и зачем трекать.
- Опасение #3: Слишком много контекстов и переключений. В мире разработки это частая история: мы постоянно переключаемся между этапами задачи и уже не можем понять, где мы делали одну задачу, а где перешли ко второй.
Мне эти опасения тоже откликались. Но на тот момент я прекрасно осознавал, что у меня нет решения, которое бы их снизили. Это самый сложный момент: вам набрасывают охапку опасений и критики, а вы не знаете, что с этим делать. Чисто интуитивно я предложил просто попробовать.
F — Первые конкретные шаги
«Я не знаю, вы не знаете, но давайте попробуем». Ни у команды не было серьезных аргументов против моего решения, ни у меня, чтобы пытаться его продавить. Удивительно, но команда согласилась. Я всего-то заменил «нужно трекать время» на «давайте попробуем трекать время». В чем же тут разница?
Волшебство «Давайте попробуем»
Я снова обратился к теории и выяснил, что «давайте попробуем» воспринимается как «интересно, безопасно и не навсегда». Мы не обязываем людей что-то делать, а проводим эксперимент. Всем интересно, каким будет результат. Некоторых подстегивает возможность доказать лиду, вернувшемуся с конференции, что он ошибается. В любом случае, эта история про новые открытия и выводы.
Здесь мы начинаем делать первые шаги (F). Волшебство работает, потому что мы проработали проблематику, Vision, и у нас еще остался большой запас инерции. Когда вы стоите на месте и вам нужно сдвинуться с него, «Давайте попробуем» отлично работает.
Но, конечно, без плана, что конкретно делать, ничего не выйдет.
Нам нужен план!
Во-первых, очень важно четко описать инициативу и зафиксировать этапы внедрения. В чем цель эксперимента, какие у него сроки? Необходимо установить контрольные точки внутри и определить метрики успеха эксперимента. Опирайтесь на ранее зафиксированные опасения — подтверждаются ли они в ходе эксперимента или нет.
Для синхронизации хорошо подходят ретроспективы. Если у вас SCRUM-like мир или просто SCRUM, который работает на 100%, такие периодические встречи очень удобны. Вам не придется проводить дополнительные мероприятия для обсуждения внедренного изменения. Вы просто «ретроспективите», как в команде изменяются процессы.
Здесь вы работаете на Vision (V), потому что есть конкретный план внедрения изменения. Также мы уделяем время первым шагам (F): мы услышали существующие опасения и рассмотрели их на первом этапе синхронизации. Все это также хорошо для уменьшения сопротивления ®. Люди видят, что все ими сказанное было учтено, что их мнение важно.
В результате у нас с командой получился следующий план:
- Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
- Срок: 3 спринта.
- Контрольные точки: ретроспективы каждого спринта.
- Метрики. Количественная: более 80% задач, взятые в спринт, выполняются. Качественная: ощущение страха перед неизвестным уменьшилось. Страх практически невозможно измерить объективно, но можно оценить по ощущениям.
Мне бы хотелось написать, что после старта все было весело и прекрасно, но это не так. Все трудности вскрылись на первом же этапе. На первой ретроспективе я получил фидбек, что «все ломается, рушится и ничего не работает». Из трех опасений не сработало только первое, про недоработку часов. Два других проявили себя во всей красе: половина команды забывала трекать время, а множество переключений лишь ухудшали ситуацию.
R — Сопротивление изменениям
Проблемы точно будут. Это единственное, в чем можно быть уверенным на 100%. Важно не останавливаться. В какой-то момент у нас была сложная дилемма. Опасения сбывались, появились первые предложения забросить эксперимент. Здесь важно поддержать первоначальную идею: «Мы же хотим проверить нашу гипотезу. Мы столкнулись с проблемами, которые подтвердили некоторые опасения. Но давайте попробуем что-то с этим сделать».
Это «Давайте попробуем» будет с вами на протяжении всего пути внедрения изменений. Результаты можно получить, только реально пытаясь что-то сделать.
- Важно друг друга поддерживать. У некоторых ребят получалось трекать время, и они делились своим опытом. Их пример помогал разрушать опасения коллег — все поддерживали и были готовы услышать друг друга.
- Мы не изобретали сложных инструментов. Попробовали Toggle — удобно, можно быстро переключаться между задачами. Немного помогла техника Pomodoro. Она была очень просто реализована, чтобы мы могли подходить к задачам итерационно.
- Очень важно не пропускать контрольные точки, чтобы не упустить момент, когда что-то пошло не так. Не скипайте ретроспективы, иначе у вас накопится такой ворох нерешенных вопросов, что вы его не сможете разгрести и сдадитесь.
- Ведите процесс прозрачно. Это не должно быть исследование, которое вы ведете в секретных дневниках, как тайный гуру. Все договоренности и зафиксированные опасения должны быть максимально публичными.
- Будьте честны с командой и с самим собой. Важно озвучить, что вы сами не знаете, что получится в итоге. Повторяйте, что эксперимент безопасный, потому что он конечный и короткий по времени. Мы просто проверяем, получится или нет, и сделаем какие-то выводы по итогу.
Такая работа над снижением сопротивления (R) должна быть на всех этапах эксперимента. Важно, чтобы команда вам доверяла. Вы как лид этот процесс фасилитируете, но не ведете людей за ручку к целям, которые интересны только вам. Потому что проект — не лида, а команды. Вы делаете что-то вместе и меняете команду к лучшему. Дополнительные бенефиты достигаются за счет того, что вы сплачиваете команду не вокруг рабочих процессов (выполнения задач и реализации продукта), а вокруг идеи «самонастройки».
После эксперимента
В конце мы проверяем, сработало или нет. Для этого замеряем целевые метрики, которые можно собирать как в процессе, так и в конце эксперимента. Если сработало, забираем в работу.
Если не сработало, то рефлексируем почему. Здесь может возникнуть соблазн продавить изменение: «Мы уже какое-то количество времени с этой штукой поработали. Чуть-чуть не зашло, но мы же ее уже взяли, она у нас идет!» Боритесь с ним. Запишите результат и отложите изменение. Мы четко даем понять команде, что следуем договоренностям.
Так мы работаем и с сопротивлением (D), и с недовольством текущей ситуацией (R): проблема осталась, но конкретно это решение для нас не сработало.
Заключение
Конкретно эта история завершилась успешно, но опыт был разный. Что у нас получилось:
- Не рассыпались по пути. Опасения, которые мы поймали на первой ретроспективе, удалось достаточно быстро решить. Команда делилась инструментами, совместно мы научились трекать время удобным всем способом.
- Мы подошли к метрике в 70% закрытых задач за спринт. Но это не главное.
- Главное — уменьшился страх перед неизвестным объемом работы. Ребята на планировании стали четко говорить: «Так, я понимаю, что, делая такие же задачи, я затратил гораздо больше времени. Наверное, в следующий спринт я не буду брать столько задач. Лучше сделаю то, что поможет успешней закрыть спринт, и буду меньше волноваться из-за сроков».
- Появился запрос от команды: научиться декомпозировать задачи. В процессе эксперимента у команды появились вопросы, как абстрактные задачи разбивать на шаги.
- Появилась необходимая аналитика для последующих внедрений. Наработки по трекингу времени мы потом смогли использовать (и использовали) для понимания, где именно мы застревали. Без этих цифр мы бы не понимали, что происходит.
Чем усилить процесс внедрения изменений
Мощное сопротивление — больше пруфов. Если вы встречаете мощное сопротивление, не давите, а приводите больше фактов в качестве доказательств.
Напарники — для сложных изменений. Если у вас суперсложное внедрение, например, изменения, которые нужно провести в нескольких командах, то ищите себе напарников. Это не значит, что вы засылаете в команду казачков, чтобы они говорили, как вы классно все придумали. Напарники нужны, чтобы эксперимент шел одинаково для всех команд.
Fail — это на самом деле win. У вас была идея, которую вы хотели применить. Вы ее проверили и получили результат — теперь у вас больше информации, чем до эксперимента.
И самое главное: изменения в любом случае происходят. Вопрос в том, будете ли вы им просто отдаваться или же управлять этим процессом. Пробуйте, экспериментируйте, не стесняйтесь что-то менять. Это интересно!
Видео моего выступления по этой теме на конференции TeamLead Conf 2021 можно посмотреть здесь.
Конференция TeamLead Conf 2022 пройдет 21 и 22 марта совместно с KnowledgeConf. Доклады по Knowledge будут отдельным треком. Билеты продаются здесь. А если вы хотите выступить как спикер, то подать заявку на выступление можно здесь.
