Я 18 лет в IT. Последние 10 из них руковожу: под моим подчинением в разное время были 200 человек.
Интересно, что я помню каждого, кто из них уволился и по какой причине. Помню не потому, что у меня хорошая память, а потому, что увольнялись они очень редко.
В этой статье я расскажу, что, с моей точки зрения, удерживает человека в команде. Поделюсь приёмами, как сподвигнуть людей по-другому относиться к работе и в конечном итоге побороть проблемы демотивации. А ещё — порассуждаю о том, как мы внутри себя подогреваем разные мысли и интересы, что сильнее всего выжигает, топит людей, и почему утопающие не всегда могут выбраться сами.
С докладом на эту тему я выступал на Badoo TechLeads Meetup №4 (видео). Мой рассказ, скорее всего, не подойдёт тем, чья команда больше 100 человек: я буду рассказывать про уровень тимлида, техлида, технического директора небольшой компании. Сам я начинал с маленькой компании. Когда пришёл в команду mos.ru, у нас было три инженера. За год мы выросли до 40, за два года — до 80. Сейчас, в разное время дня и в зависимости от погоды, нас до сотни человек.
Про них я и расскажу.
Проблемы
Какие существуют проблемы? Выгорание и демотивация.
У кого они есть? Да почти у всех.
Кто-нибудь может дать определение хоть одной из них?
Скорее всего, нет. Потому что каждый болеет по-своему, и говорить про всех будет слишком абстрактно.
Поэтому я сконцентрируюсь на простых, часто встречающихся вопросах:
- Мне перестал нравиться этот проект.
- Мне хочется новых, интересных задач.
- Надоело это всё. Я хочу чего-то другого, свежего.
На собеседовании ты спрашиваешь у кандидатов: «Чего ты хочешь?» — «Интересных задач!» — «Что такое в твоём понимании интересные задачи?» На этом моменте чаще всего возникает пауза, потому что мало кто может объяснить, что такое интересная задача. Тем не менее, все считают, что на работе они должны быть.
Причины
Все эти проблемы — это, конечно, следствие. У следствия есть причины.
Часть причин наверняка многим из вас знакома. В первую очередь приходят в голову:
- процессный диктат: перебор с процессами, который всех мучает. Когда тебе говорят делать именно так, а не по-другому.
- Глухота и слепота коллег и начальства.
- Рутина.
- Скука, неинтересные задачи.
Если мы сейчас начнем перечислять всё, то как минимум сотню наберём. Причем у каждого будут свои, уникальные причины, о которых зачастую стесняются говорить.
Бороться с ними начинают, только когда проблема уже есть. Большинство людей, которые этими проблемами болеют, уже болеют достаточно серьезно. Но когда ты как тимлид ходишь и смотришь на коллектив, то коллектив внешне выглядит достаточно спокойно: всё хорошо, всё работает.
У руководителей в этот момент появляется ложное ощущение стабильности: ты смотришь на ситуацию снаружи и думаешь, что всё хорошо. А если начинаешь это дело ковырять ножиком или подпиливать напильником, оказывается, что это совсем не так.
Кроме этого, возникает сопутствующая проблема — ложное ощущение контроля. Начинаешь думать о том, что весь процесс, который происходит в твоей команде, тобой контролируется: ты молодец, ты знаешь, что с людьми происходит и как, какие нехорошие и хорошие вещи.
В конечном итоге выходит, что ты весь такой хороший, но при этом вокруг все горит, твои люди горят. Им становится скучно, они почему-то уходят. Причина, которую они обычно называют, — больше денег. Но если с людьми поговорить поближе, оказывается, что проблема вовсе не в этом.
Приёмы
Как предотвратить такие ситуации? Я расскажу про приемы, которые применяю не первый год и которые, с моей точки зрения, позволяют сделать жизнь людей более комфортной.
Перед этим немного расскажу о себе. Команда, в которой я сейчас работаю, делает портал mos.ru. Мы абсолютно такие же, как большинство IT-компаний: у нас есть легаси, зоопарк технологий, отсутствие документации. Требования меняются с космическими скоростями.
По большому счёту мы не отличаемся ничем, кроме одного факта: мы с самого начала росли, используя эти приемы.
Приём #0: демонстрация движения
Мы показываем, как наша команда движется вперёд: она развивается, достигает высот, она лажает (кто не лажает, тот ничего не делает). Демонстрации проходят постоянно.
Раньше на них приходили только члены команды. Уже полгода мы приглашаем на демонстрации всех, кому важно видеть, что система движется. Мы проводим внутренние митапы, на которых обсуждаем, какие новые крутые штуки сделали. Эти митапы не только тематические — например, для бэкенда. Нет, на митап для бэкенда приходят все, включая дизайнеров. Им интересно послушать, пообщаться, узнать, что происходит.
Важный момент, о котором многие забывают, — это влияние внешней конъюнктуры: того, что происходит вокруг нас, вокруг команды, проекта. Людям интересно видеть, как движение внутри коллектива соответствует движению, которое происходит вокруг.
Как этот приём помогает в повседневной жизни? Нам, как и многим, иногда приходится перерабатывать: задержаться вечером или выйти в субботу. Я никогда не принуждаю к переработкам, но обязательно объясняю, что и почему происходит. Например, что есть новый крупный проект, социально важный для москвичей, где жители города смогут посмотреть, какие улучшения произойдут в его районе в ближайшем будущем. Что 500 человек прошли по этим дворам, посчитали и записали необходимую информацию. Разработчик понимает, что участвует в большом и сложном процессе, знает, почему он так работает. И в большинстве случаев готов помочь.
Про такие нюансы почему-то обычно не любят рассказывать, хотя никакого секрета в них нет.
Приём #1: не скрывать
Команда должна понимать, что и почему происходит. Где мы находимся в текущий момент времени, как это соответствует планам и обещаниям, какое у нас будущее.
Отсутствие планов — это вещь, которая сильно влияет на внутреннее состояние человека. Когда он понимает, что WP-блог, который он сейчас программирует, ещё пять лет будет WP-блогом, который он будет программировать, разработчику очень грустно. Поэтому мы стараемся рассказывать, какие изменения в ближайшем будущем произойдут во внешней конъюнктуре, что изменится, какие будут большие проекты.
Нам удалось договориться с руководством, что периодически, раз в полгода нам дают информацию об этом. И мы узнаем, что, например, не делаем ничего нового только потому, что что-то новое и клёвое готовится.
К слову, чтобы сделать что-то новое и клёвое в городе, — допустим, перевести какой-нибудь процесс в электронную форму, — очень часто нужно подготовить документацию, законодательную базу.
Возьмем, например, запись ребенка в пионерский лагерь. Казалось бы, что может быть проще: пришёл, формочку заполнил — и пожалуйста. А дальше начинаются детали: как уравнять в правах тех людей, которые подали заявку физически, и тех, кто подал её через электронную форму?
Всё, что связано с государством и обществом, достаточно серьёзно. Поэтому приходится объяснять, почему всё так, а не по-другому. Иногда мы не релизим, потому что некое постановление не доходит до той фазы, когда мы можем зарелизить продукт. Это нечастый эффект, но тем не менее он бывает. Если разработчики про это знают, они понимают, что мы не «накодили и бросили», — просто у нас такой режим работы. Они начинают воспринимать его спокойно.
Приём #2: давать чётко регламентированную свободу
Свобода — это хорошо. Но полная свобода — это плохо.
Мы с детства привыкли, что кто-то за нами ухаживает. Сначала следили родители, потом педагоги в садике, потом педагоги в институте, потом начальник. Если создается впечатление, что начальник за вами не следит, чаще всего возникает вопрос: может быть, ему пофигу, может быть, ему всё это неинтересно, он вообще плевать на это хотел? Полная свобода в итоге оказывается проблемой. Поэтому давать свободу нужно, но не полную, а ограниченную. Говорить людям, что есть канва, и в рамках этой канвы они могут двигаться.
Например, мы договорились, что мы программируем на PHP — так сложилось исторически. Внутри этого — библиотеки, подходы, ООП, не ООП, писать так или сяк, какие-то паттерны — это, пожалуйста, ты сам. Но на PHP.
Когда люди приходят и говорят: «Я хочу Go», я говорю — «Давай подумаем, насколько твоё «хочу» может реализоваться в «могу», во что-то полезное». В итоге разработчик знает, что у него есть возможность выдвигать предложения, но для того, чтобы эти предложения докатились в продакшен, нужно будет поработать. Они знают эти правила игры, знают, что есть такая возможность. Некоторые ей пользуются: поэтому у нас есть не только PHP, но и другие языки программирования.
Приём #3: пускать в процессы
Мы пускаем людей в процессы, но с некоторым ограничением. Ограничение состоит в том, что у нас есть девять команд, девять процессов, и есть и корневой процесс — релиз, который регламентирует выход в продакшен. Он один для всех.
Вокруг этого процесса ребята делают то, что им больше нравится.
Продуктовые, бизнесовые процессы у нас довольно разные. Например, команда, которая пилит поиск, — внутренняя. Требования к поиску чаще всего генерируем мы сами. Есть команды, которые программируют мобильные приложения, там совсем другая кухня. Есть веб, который существует как отдельный продукт, есть веб, который существует как новостная редакция с админкой. Там тоже всё по-разному, но релизные процессы у всех одинаковые.
Ограниченная свобода выглядит так: делай, что хочешь, но вот этот кусок не трогай. Благодаря этому я уже забыл о том, что такое критические ошибки в продакшене. Потому что есть чёткое правило, которое говорит, как надо делать. Хочешь играться — играйся: по факту, у нас сейчас ни одного процесса, кроме релиза, не задокументировано. При этом люди чувствуют себя комфортно.
Приём #4: вращать барабан
Хитрый приём: мы называем его «вращать барабан», но можно вращать карусель или бетономешалку — называйте это как угодно. Смысл в том, что мы совершенно осознанно не привязываем людей к задачам.
У нас нет такого, чтобы кто-то из фроненда, бэкенда или из DevOps не мог сделать какую-то другую задачу. Code ownership — у нас этого просто нет.
Во-первых, это добавляет людям интереса, во-вторых, увеличивает пресловутый bus factor. В-третьих, я совершенно спокойно могу перекидывать людей между командами, собирать на крупные проекты команды из четырёх других команд. Они начинают работать буквально через два дня: два дня заканчивают свои задачи, а потом собрались — и погнали.
Тот самый крупный и важный проект, о котором я говорил выше, делало три команды. Причём одна никогда раньше не взаимодействовала с двумя другими: ребята просто пришли и приняли правила игры. В среднем такие проекты со сборной солянкой из ребят мы делаем раз в полгода. За счёт того, что они в целом не привязаны к каким-то конкретным обязанностям, они прекрасно себя чувствуют.
Есть ещё одна фишка, которую мы пробуем, и у нас получается, — мы не отпускаем просто так людей, мы пытаемся их задержать в команде, пусть даже и в другой области.
Допустим, был у меня инженер-автоматизатор, тестировщик. Писал автотесты на Python. Ему надоело тестировать, он сказал, что хочет быть Python-разработчиком. Казалось бы, можно было ему сказать: «Иди и программируй на Python». Но в этот момент оказалось, что нам нужен Python-разработчик в мобилке. Мы его отправили туда: во-первых, мы не потеряли знания в автотестах, во-вторых, человек не пропал, и мы сэкономили на поиске.
Таких историй у меня несколько. Когда мы внедряли процесс релиз-менеджмента, мы сконвертировали двух тестировщиков в релиз-менеджеров, и они себя прекрасно чувствуют. Верстальщиков мы превращаем во фронтенд-разработчиков. Недавно я узнал, что один из PHP-разработчиков ночами программирует на Python. Казалось бы, тоже можно отпустить, но мы решили поиграть в игру: я пришёл в команду поиска, у которых бэк на Python, и попросил дать мне сложную несрочную задачу. Какая разница, что именно он программирует на Python ночью? Пусть он программирует что-то нужное нам. Если у него получится, то мы его определим туда младшим Python-разработчиком из старшего PHP-разработчика. Бывает такое желание у людей, что поделаешь?
На этих приёмах я не потерял 5-6 человек из команды, я просто их перенаправил.
Самый важный момент
Я рассказал о приёмах, которые использую. На самом деле это общие вещи, то есть воздействие на всю команду целиком. Это касается непосредственно всего коллектива, всех ребят до самого последнего младшего инженера.
Но правда в том, что вопрос выгорания, мотивации, всего остального — он достаточно личный и интимный. Им нужно заниматься чуть ближе к людям, чем я сейчас рассказал. Поэтому у меня выстроена достаточно сложная система мониторинга.
Мониторинг
Она выстраивалась достаточно долго. В этой системе, по большому счёту, задействован весь коллектив.
Не надо путать мониторинг с жалобами, со стукачеством: это просто способ получения информации о том, что происходит на текущий момент в коллективе. От тимлидов, от начальников служб, со встреч один на один.
Причём на этих встречах я не запираюсь с кем-то в переговорке размером метр на метр, не сажаю человека перед собой и не втыкаю лампу ему в лицо: «Колись». Нет, так я не делаю. Чаще это бытовые разговоры, когда ты ловишь коллегу возле кофемашины и спрашиваешь, как дела. Или общаешься в курилке, или даёшь ему ссылку на мероприятие, на которое советуешь сходить, и попутно что-то ещё уточняешь.
Это, в том числе, HR: периодически он приносит очень интересные новости. Несмотря на то, что у нас сейчас целый один HR, он справляется.
О чём я разговариваю?
Обо всём подряд: про погоду, про хобби, про случайно замеченную у коллеги гитару. Я знаю, кто за кого болеет, у кого какие машины, кто на даче, кто не на даче, кто по грибы, у кого что болит. Слушаю классическое нытьё про то, что тестировщики — негодяи, что инфраструктура не работает.
Мне важно понять, чем человек интересуется. Ветераны труда уже смирились с тем, что выбрали не тот путь, а молодёжь ещё мечется между React и Angular, между PHP, Python, Go еще 500 других языков. Чаще всего они чем-то интересуются. В ряде случаев я их интерес могу удовлетворить.
Оказывается, что люди никому о своих интересах не рассказывают не потому, что им неохота, а потому, что их никто об этом не спрашивает. Когда приходишь и спрашиваешь, чего бы он хотел, он говорит, что хотел бы заниматься архитектурой, но у него не получается, потому что мы, негодяи, уже придумали архитектуру, и она у нас железная.
Ты даёшь ему книжку: пусть он идёт и читает. Он её читает, начинает заниматься ревью той архитектуры, которая есть. Начинает предлагать какие-то решения, и так мы снимаем его проблему и боль, что ничего нового он сделать не может.
Зачем всё это?
Чем больше ты знаешь про человека, тем больше шансов, что ты предложишь ему достаточно простое и комфортное решение, которое вас всех удовлетворит. И он не пропадёт, взбодрится, и ты его не потеряешь. Такой портрет человека нужен, чтобы понять, как работать с ним как с индивидуальностью, человеком со своими проблемами.
Видели, как бежит стадо лошадок? Одна отделяется, и все оглядываются: «Куда она ломанулась?». Но продолжают бежать вперед. Потом самая нестойкая срывается за ней. Их уже две. И так далее.
Эти процессы накопительные. Можно очень долго сидеть и ждать, а потом это всё рванет. Поэтому нужно знать, как всё работает, и как можно быстрее реагировать на сигналы.
Билет на волю
Но при этом не стоит забывать о том, что рано или поздно это всё накрывается медным тазом. Уже нет никакой возможности оказывать влияние на человека: он просто сгорел. Приходишь, он ни на что не реагирует, говорит: «Отстань! Не хочу. Не буду. Ничего мне не нравится».
Чаще всего этих людей потом находят где-нибудь на Бали. Они там полгода сидят пузом кверху, ничего не делают, программируют какие-то стартапы и считают, что у них всё здорово.
Может получиться так, что человек больше не может. Важно понимать причины, мотивацию и демотивацию для того, чтобы этого не повторилось.
Типичные разговоры с HR: «Почему ты уходишь?» Чаще всего отвечают одно и то же: «Надоело». Скорее всего, это правда. Большинство из нас меняет работу, потому что надоело. Чуть реже из-за того, что мало платят, а чаще потому, что надоело, а там ещё и денег больше. Мало кто уходит по каким-то более глубинным причинам. И в ряде случаев за хорошую зарплату мы готовы терпеть всякие издевательства.
К этому надо быть готовым. А главное, к этому надо уметь готовить людей, чтобы не получилась та самая лошадка. Совершенно очевидно, что те, кто работает в нашей индустрии плотно, понимают, что средняя продолжительность работы сотрудника в команде 2–2,5 года. Некоторые исследования показывают, что меньше, 1–1,5 года, — и всё, люди меняют работу.
Вместо выводов
Мы все разные, все горим с разной скоростью. Поэтому та групповая терапия, о которой я написал, — хороша, да не очень-то. Она всё равно не воздействует на людей таким образом, чтобы гарантированно покрывать все проблемы.
Внутри у каждого из нас есть своя сила. Обычно эта сила не связана с какими-то материальными благами: чаще это возможность в чём-то поучаствовать. И этим можно управлять — но в итоге всё равно придется работать один на один, добывая пользу в первую очередь для себя. Сохраненный сотрудник — это залог вашего спокойствия.
Мы живём в мире инструкций. Например, есть инструкция о том, как отличить тонущего человека от нетонущего. Если вдруг вы её не знаете, рассказываю. Люди тонут с криками, махая руками, только в мультиках и кино. В жизни люди тонут молча: просто взял и утонул. Это мрачная метафора, но смысл понятен: чаще всего люди выгорают молча. Единственный способ понять, что что-то происходит — либо постоянно за этим следить, либо постоянно быть готовым к тому, что придётся искать новых коллег.
Автор: Роман Ивлиев
