8–9 июня состоится TechLead Conf. Это онлайн-конференция об инженерных практиках и процессах. Мы будем подробно обсуждать, как разрабатывать без багов, как работать с legacy, как сделать так, чтобы MVP не превратился в техдолг, как выбирать практики в зависимости от проблематики.

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

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



— В чем вообще проблема с внедрением изменений, почему недостаточно сказать, как надо делать?

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

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

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

— Мы говорим не только о процессах, но и инструментах?

Да, я включаю внедрение инструментов сюда же. Например, когда-то давно я внедрял Git. Сейчас это мейнстрим, и, кажется, внедрять тут нечего. А когда-то был SVN, и внедрить Git было той еще задачей.

Инструмент для меня — широкое понятие. В моём понимании, парное программирование или code review — это тоже инструменты. Сюда же я включаю и практики, потому что, мне кажется, это примерно одно и то же. Инструмент — это практика использования этого инструмента.

— Получается, внедрение процесса типа daily meetings не сильно отличается от внедрения среды разработки?

Верно. Например, я пропагандировал среды в Google, потому что с ними удобнее писать код. Но когда разработчику удобнее использовать vim и emacs, попробуй убеди его поменять среду.

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

Сопротивление есть всегда — это базовый принцип.

Бывают изменения, которые идут легко: по накатанной колее. Но иногда изменения будут как раз в том, чтобы остановить изменения, которые идут по накатанной. А вот перепрыгнуть из одной колеи в другую, сменить направление, очень тяжело.

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

Я понимаю изменения, как задачу перепрыгнуть с одной траектории на другую.

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

На то, как люди в компании реагируют на нововведения, в том числе влияет культура компании. Например, на Западе довольно часто в культуре компании заложено, что все мнения важны и надо всех выслушать. Это очень помогает изменениям. А в России нередко бывает что, когда предлагаешь что-то делать по-новому, на тебя тут же обрушивается тонна критики. Если человек не умеет выдерживать критику, то он просто замолкает, и никаких изменений не происходит. На Западе обычно изменения идут легче, потому что как минимум предложения выслушивают.

— Всегда ли можно выстроить итеративный процесс внедрения изменений? И не будет ли движение маленькими шажками только мешать, потому что будет проще скатиться к старому порядку?

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

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

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

Проводя изменения, нужно понимать, с кем работаешь, какая команда, насколько она готова, что они уже умеют делать.

— Кто должен инициировать изменения, а кто внедрять и сопровождать? Обязательно один и тот же человек?

Я считаю, что инициировать изменения должны все, кому небезразлично, независимо от уровня должности.

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

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

— Чтобы что-то внедрить, обязательно обладать специальными полномочиями и задействовать административный ресурс?

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

Тут скорее важно отметить, что в любом случае внедрению изменений нужен контроль.

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

Я часто наблюдаю закон «Если что-то может пойти не так, то оно пойдет не так» в действии. Наоборот, проблески, когда все пошло так, настолько редки и воспринимаются как чудо. А в норме нужно готовиться контролировать.

Контролировать не в смысле административных бесконечных отчетов (хотя иногда и так). Надо проверять, так ли все поняли, так ли все делается и делается ли вообще. Если в это не вложиться, то всё точно пойдет не так.

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

Гуглдоки побеждают удобством, и я сам их с удовольствием использую. Но, если нужно, маленькими хитростями можно переиграть это удобство.

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

С рабочими инструментами тоже можно применять такие хитрости. Гуглдоки это по сути тот самый холодильник, в который не надо нагибаться: очень легко шарить, удобно редактировать и т.д. Это удобство работает против внедрения каких-то новинок. Но можно применять такие же хитрости.

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

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

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

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

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

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

В некоторых случаях без жесткой позиции не обойтись.

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

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

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

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

Конечно, от некоторых изменений приходится отказываться. Например, Илон Маск долго пытался сделать роботизированный завод, чтобы Tesla собирали преимущественно роботы. Это продолжалось, пока не были нарушены все дедлайны. В итоге Маск признал, что поторопился, что технология еще не готова, и сделал чуть более традиционное изготовление.

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

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

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

Например, я недавно наблюдал, как совсем немного времени помогло кардинально изменить мнение. Один молодой сотрудник с пеной у рта доказывал, что ему и его коллегам по команде удобно получать огромную кучу алертов в slack. Якобы смотреть на доску с 1000 событий в день позволяет оперативно понимать, что происходит с системой. А мы пытались его убедить, что алерты должны работать не так: они должны быть редкими и действительно важными. А для рядовых событий должна быть отдельная доска, которую можно посмотреть, когда понадобится почитать что-то типа логов. Мы долго спорили и пришли к такому компромиссу: мы помогаем сделать доску, а он неделю пробует ей пользоваться. Через 2-3 недели тот, кто больше всех сопротивлялся, уже убеждал своего лида моими же аргументами. Хватило всего ничего времени, чтобы осознать, что предложение действительно полезное.

Конечно, тут могут включиться политические моменты: как долго экспериментировать, насколько можно давить, на какой максимальный негатив мы готовы пойти, если он будет. Это серые области.

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

Онлайн-конференция TechLead Conf 2020 состоится 8 и 9 июня. Мы уже протестировали онлайн-формат и смогли сделать именно конференции, а не набор видеодокладов. На следующей неделе запустим РИТ++ и к TechLead Conf будем еще более опытными в организации онлайн-ивентов. Так что не сомневайтесь — подключайтесь :)