Как победить legacy в головах

Изменения — это то, что происходит всегда. Мы можем переходить на новый язык программирования. Например, внедрять Kotlin или переходить на GO, как это сейчас многие делают. У нас могут появляться новые базы данных. Мы можем переезжать в облака (или обратно). Или можем захотеть внедрить у себя новый процесс, будь то Code review, постмортемы или Scrum с Канбаном. Даже для перехода на удаленку нужны новые процессы или инструменты.

Люди реагируют на изменения по-разному — кто-то активно включается в процесс, а кто-то просто мешает. Техлиды могут помочь внедрить изменения быстрее и легче, если будут знать, как влиять на команду.

Конечно, в некоторых случаях всё меняется очень быстро и просто. Привычные вещи — code review, стендап встречи или система контроля версий — большинству разработчиков уже знакомы, поэтому процесс их внедрения может быть легким. Или когда проблема очевидна, а выход — только один. Например, из-за роста бизнеса у вас все больше нод и нагрузки. Понятно, что в какой-то момент вам потребуется централизованное хранилище: вы ставите Elasticsearch, решаете проблему и весь процесс изменений проходит плавно и без препятствий.

Но в общем случае всё будет очень сложно. Люди все разные, каждый к изменениям относится по-своему. Даже эффект новизны не всегда срабатывает, если команда перегружена. Поэтому будьте готовы к возможному сопротивлению. К тому же любое изменение — это еще и отказ от старого. А людям текущее состояние дел может быть дорого своей привычностью. Или кто-то в это старое очень вложился, у него были какие-то планы, ему изменения не нравятся. Не все захотят вас поддержать, а у вас время ограничено.

Чтобы упростить себе эту задачу, у меня есть классификация сотрудников по типам.

Кто ты есть такой?

Лояльный. Это может быть только что пришедший в компанию сотрудник. Он честно работает и пытается разобраться, что от него ожидают, но пока не очень прикипел к компании. Таких честно работающих сотрудников, наверное, большинство. И у нас всегда есть шанс перевести его в ряды приверженных.

Приверженный любит свою работу и руководство, его всё устраивает, и он понимает, что от него требуется. Он прикипел к компании и никуда не хочет уходить. Если при этом он пытается улучшить работу компании, он еще и ваш союзник. Союзников можно выбирать только из приверженных. И этот выбор очень важен для внедрения изменений. И если это не приверженный, ни в коем случае не привлекайте для внедрения изменений того, у которого просто много времени.

Но есть и гиперприверженный, фактически фанат, который относится к работе с излишним воодушевлением. Но при этом он всё понимает на свой лад. И если что-то случится не так, как он ожидал — вы получите истерику. Поэтому от фанатов лучше избавляться. Одно неосторожное высказывание, и фанат станет вашим врагом. Так, например, «переобулся» фанат Илона Маска:

Недовольный делает свою работу почти так же хорошо, как лояльный, но много ворчит (даже на поощрения). Например, мало дали денег, а другим — больше, или еще что-то не так. Он всегда найдет повод поворчать. Наверняка вы таких часто встречали — это отличительная русская черта. Я помню, даже в Google русские на всё ворчали — например, что обеды становятся хуже. Но все ворчуны на самом деле нормально делают свою работу.

Неисполнительный пытается уклониться от работы, но без конфликта. Его очень интересует буква закона и он все пытается делать, как положено — вспоминает Трудовой кодекс, правила, договоренности. Его дух не интересует, главное — чтобы по закону он меньше работал.

Перехватывающий управление — это неформальный лидер. Обычно очень активный и начитанный — все время рассказывает, как и что лучше делать. И если вы не возьмете его возглавлять всё ваше движение, он будет сам перехватывать управление. Поэтому превращайте его в своего союзника, с такими активными неформальными лидерами в общем удобно сотрудничать.

Воюющий напрямую распускает негативные слухи и, возможно, даже ворует ваши данные. Он во всем видит двойное дно (для чего это на самом деле было сделано) — в общем, активно препятствует какой-либо работе. Чем раньше вы покажете, что вы это видите — тем будет лучше.

А теперь давайте посмотрим, как они все себя ведут во время изменений.

Запускаем процесс

Обычно изменения начинаются со стадии сопротивления. Если вы ее пройдете, то у вас будет сначала размышление всей командой над предстоящими изменениями, а потом начнется подготовка и сами действия. Но помните, что мало провести изменения. Их еще надо сохранить, иначе большинство вернется в старую колею.

И, прежде чем мы будем использовать правильные инструменты в нужное время, мы должны понимать, на какой стадии находимся и что там обычно происходит.

Сопротивление

Вначале будет сопротивление первого момента. Лояльные и приверженные будут при этом искренне разбираться, что именно имеется в виду, как придется дальше жить, что делать и какими инструментами. Выстраивайте с ними конструктивный диалог — объясняйте то, что им непонятно. Они могут сопротивляться, если будут объективные причины. А вы сможете рассматривать эту стадию как проверку на серьезность своих намерений, потому что эти сотрудники захотят понять, действительно ли нужно изменение.

Гиперприверженный сотрудник сразу воспримет вас с воодушевлением, но не станет разбираться в сути, а скорее, всё нафантазирует и придумает. Недовольный, конечно, будет ворчать. В принципе, здесь это можно игнорировать, потому что он ворчит всегда.

Неисполнительный будет всё игнорировать, потому что ему неинтересно, работать не хочется, но и на конфликт он не пойдет. Если вы будете его вовлекать, то он будет задавать вопросы, больше напоминающие попытку разрушить идею, чем разобраться в ее сути. И вы еще больше убедитесь в том, что он не хочет что-либо делать.

Человек, перехватывающий управление, как можно догадаться, будет рассказывать, как на самом деле надо делать и как будет лучше. Он об этом что-то уже слышал от друзей и знакомых, и, конечно, знаком с опытом других компаний.

А воюющий будет искать двойное дно и говорить, как на самом деле всё происходит и для чего это сделано. Как я говорил, игнорировать его нельзя, иначе он будет уверен, что вы поддаетесь. Обозначьте, что его выводы неправильные и некорректные — открыто поговорите с ним, показав все карты. Но при этом обязательно покажите готовность его потерять, если он не изменит поведение — воюющему надо четко понимать, что он заменим. Решимость им чувствуется и ставит его на место, помогая войти в конструктив. И если с идеей действительно что-то не так, то в открытом разговоре с ним вы сможете это понять.

Вы можете столкнуться со страхом первого шага — когда, вроде бы, никто уже не сопротивляется, но начало изменений всё время отодвигается. Даже когда уже всё обсудили, вы можете вечно ждать подходящего момента для начала. У нас был случай, когда мы не могли написать несколько месяцев IKR, хотя там было по несколько строчек текста для каждой команды. Здесь хорошо помогают дедлайны.

В западных компаниях активно поощряют разные точки зрения и запрещают неконструктивную критику. И тогда, чтобы сопротивляться, вам сначала нужно подумать над аргументами. А это уже переход на следующую стадию — размышление, и западная культура помогает это сделать легче.

Размышление

Здесь с лояльными и приверженными всё просто — они помогают вам и обдумывают детали того, как лучше произвести внедрение. Гиперприверженный просто радуется, тут всё понятно. Недовольный, разумеется, ворчит, но на самом деле поглядывает, что там готовится и, в принципе, тоже помогает. Воюющий распускает слухи.

На этой стадии, когда все размышляют, появляется много «советников». Главные из них — неисполнительный и перехватывающий управление. Первый надеется, что изменения пройдут мимо. Он помогать точно не будет, потому что на самом деле ждет, когда же всё зафейлится, то есть изменения отменятся. Поэтому он советует просто ничего не делать.

Перехватывающий управление перепроверяет все ваши решения и активно ищет, как это сделано у других, и как еще можно реализовать идею. Даже если вы всё перелопатили сами, он всё равно будет пытаться заставить вас пересмотреть решение или повернуть в свою сторону. Его советы — это всевозможные альтернативные варианты, ему надо показать свое лидерство. Поэтому лучше всего его привлекать на ранней стадии. А здесь будет легче, если вы сразу отметите, какие варианты уже рассмотрели и почему от них отказались. Это немного снизит количество его советов.

На этой стадии начинаются религиозные войны, которые я предлагаю сразу пресекать. Иначе вы утонете в бесконечных обсуждениях неважных деталей и мелочей. И чем больше не важна мелочь, тем дольше ее будут обсуждать, потому что по простым вещам у каждого есть свое мнение. Напоминаю закон Митчелла: "Любую проблему можно сделать неразрешимой, если провести достаточное количество совещаний по ее обсуждению". И любой неисполнительный сотрудник это знает, это их конек — до бесконечности продолжать обсуждения.

Спросите, почему человеку важно обсудить именно эту мелочь. Скорее всего, он не найдет, что ответить, и градус дискуссии снизится. И можно перейти к подготовке.

Подготовка

Когда мы всё более-менее выяснили, обдумали и поняли, мы начинаем готовиться к изменениям. Настраиваем тулзы или пишем вспомогательные инструменты. Все готовятся, устанавливают, настраивают — идет работа.

При этом неисполнительный будет все время ссылаться на занятость: ему некогда, у него есть более важные и срочные дела. Он хочет эту подготовку максимально пропустить, но по уважительной причине. Потому что в дальнейшем он будет пользоваться своим правом на незнание, как прикрытием — он же не знал, как надо делать, и поэтому не делал. А не знал он, конечно, по уважительной причине.

Поэтому на совещания, обсуждения, обучение и любые другие общие встречи он либо вообще не приходит, либо не тем там занимается. У него срочные дела в продакшне, он сидит в ноутбуке и чинит что-то — в общем, пытается не узнать ничего.

Перехватывающий управление готовит свои изменения. Например, мы вводили расписание и хотели написать все под нас. Параллельно одна команда выбрала свой инструмент, поставила его, настроила и сказала: «Давайте им все пользоваться». А через полгода оказалось, что он не устраивает никого, даже эту команду. Непривлечение на ранних стадиях перехватывающих управление чревато именно такими казусами.

Воюющий пытается сделать изменение невозможным: выполняет все плохо, постоянно указывает на недостатки, распускает слухи. Например, мы внедряли компенсации за дежурство. Команда работала бы примерно так же, но получала бы больше денег — казалось, всё должно быть хорошо. Но с одной стороны ворчали недовольные, что денег мало и что они лучше бесплатно будут дежурить. А с другой стороны пошли слухи, что денег платить не будут. Нам не удалось выяснить, кто был их источников, но проект мы завершили благополучно, поскольку все сделали правильно.

Обучение

На этой стадии помните главное — всё, что можно понять неправильно, будет понято неправильно. Даже если люди внимательно слушали вас раньше, здесь вам снова придется к этому вернуться. Например, мы делали не очень большое изменение среди разработчиков, и на обучении выяснилось: большинство не поняли, что требуется CSV-файл, хотя мы проговаривали это несколько раз и показывали примеры. А те, кто понял — перепутали все колонки. Чудеса трактовок людей бесконечны, можно получить удивительные эффекты на этой стадии.

Поэтому делегируйте проработку деталей командам — так недопонимания будет меньше. Занимайтесь только основными параметрами, все детали люди могут додумать сами, и тогда они будут их прекрасно понимать.

У вас в этом процессе будет много общих встреч. И обычно каждый на встрече соглашается про других, но не про себя. То есть каждый думает, что это другие будут делать лучше, быстрее, по-другому, удобнее, а его случай — это всегда исключение. И каждый считает, что все сделают это классное изменение, но ему — в его особенном случае — разрешат действовать по-другому. Поэтому все договоренности на общих встречах обычно так себе. Помните об этом.

Действия

На этапе действий обязательно должен быть контроль — и как ни странно, он нужен всем. Приверженный вообще любит контроль, потому что это его способ показать , что он делает работу классно. Лояльный должен убедиться, что все делает правильно.

Это звёздный час неисполнительного. Он будет делать плохо, но так, чтобы не к чему было придраться. И говорить, что ничего не понял и не знал на предыдущих стадиях, и что идея в целом провалилась. Но под контролем он на открытый конфликт не пойдет и будет работать как надо.

Перехватывающие управление, если вы их не превратили в союзников на ранних стадиях, будут пытаться внедрить свой подход. У нас встречались случаи внедрения под шумок NoSQL-базы и много чего еще. А воюющий мешает внедрению, конечно.

Поэтому контроль должен быть, и непременно регулярным — это самое важное для внедрения изменений. Ни у кого не должно сложиться впечатления, что его бросили одного. Пример хорошего контроля — это всем известное code review — регулярный контроль того, как пишется код. Контроль может быть автоматизированным — например, через линтеры.

Но контроль нам нужен не для наказания! Так мы проверяем, что нас и верно поняли, и правильно действуют. Если выяснится что-то неверно понятое, то здесь уже лучше всего разъяснить это каждому сотруднику или каждой команде на их конкретном примере. Это обычно повышает градус внимания у людей — потому что это про них, это намного интереснее. Конечно, и на более ранних стадиях индивидуальный подход повышает вероятность успешного внедрения.

В этот момент иногда может проявиться новое сопротивление, и я его называю истинным. Потому что на этой стадии оно сигнализирует о чем-то, что действительно идет не так, и надо разбираться — что именно.

Сохранение изменений

Мы правильно действовали и наконец всё внедрили. Можно уменьшать контроль, но руку с пульса не убирайте. Нам важно проверить, сохранились изменения или нет. Если после внедрения люди начинают контролировать друг друга, сами обучают новичков — все закрепилось, мы перешли на новую колею. Теперь вернуться будет сложно, потому что для этого потребуется примерно столько же усилий. Только в некоторых случаях контроль должен оставаться непрерывным, как Code Review.

Но на этой стадии (а может, даже на более ранних) вы также можете выяснить, что что-то внедрили зря — потому что стало хуже. Но нет ничего страшного в том, чтобы признать ошибку и вовремя откатиться. Тот же Илон Маск признал, что ошибся с излишней автоматизацией и сумел перестроиться обратно.

Выводы

1. Для внедрения изменений, если это непростой случай, вам понадобится много времени — в основном вашего, если вы инициатор, но и времени ваших союзников, которых вы выбрали из приверженных.
2. Вам придется контролировать весь процесс. Например, писать автоматизированные тулзы, которые проверяют, перешли ли на новые библиотеки и пр. То есть вам придется все контролировать, и, возможно, делать это вручную.
3. Требования лучше объяснять индивидуально. На это тоже потребуется дополнительное время. Индивидуально — это иногда один на один с человеком, а иногда с командой.
4. Не надо бояться отменить изменения, если стало хуже.

Теперь вы примерно представляете, как разные люди будут относиться к вашим изменениям (все это нормально и бывает во всех компаниях). И я надеюсь, спокойно их внедрите. Неважно, техлид вы большой или маленькой компании. Неважно, сколько у вас в управлении команд и какого они размера. Эти принципы будут одни и те же.

Больше материалов про управление и тестирование смотрите в моих публикациях на Хабре.