Хабрахабр

Спасение утопающих — наше дело: как бороться с демотивацией в команде

Я 18 лет в IT. Последние 10 из них руковожу: под моим подчинением в разное время были 200 человек. 

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

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

Мой рассказ, скорее всего, не подойдёт тем, чья команда больше 100 человек: я буду рассказывать про уровень тимлида, техлида, технического директора небольшой компании. С докладом на эту тему я выступал на Badoo TechLeads Meetup №4 (видео). Когда пришёл в команду mos.ru, у нас было три инженера. Сам я начинал с маленькой компании. Сейчас, в разное время дня и в зависимости от погоды, нас до сотни человек.  За год мы выросли до 40, за два года — до 80.

Про них я и расскажу.

Проблемы

Какие существуют проблемы? Выгорание и демотивация.
 
У кого они есть? Да почти у всех. 

Кто-нибудь может дать определение хоть одной из них? 

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

Поэтому я сконцентрируюсь на простых, часто встречающихся вопросах:

  • Мне перестал нравиться этот проект. 
  • Мне хочется новых, интересных задач. 
  • Надоело это всё. Я хочу чего-то другого, свежего. 

На собеседовании ты спрашиваешь у кандидатов: «Чего ты хочешь?» — «Интересных задач!» — «Что такое в твоём понимании интересные задачи?» На этом моменте чаще всего возникает пауза, потому что мало кто может объяснить, что такое интересная задача. Тем не менее, все считают, что на работе они должны быть. 

Причины

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

  • процессный диктат: перебор с процессами, который всех мучает. Когда тебе говорят делать именно так, а не по-другому. 
  • Глухота и слепота коллег и начальства. 
  • Рутина. 
  • Скука, неинтересные задачи. 

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

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

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

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

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

Приёмы

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

Команда, в которой я сейчас работаю, делает портал mos.ru. Перед этим немного расскажу о себе. Требования меняются с космическими скоростями.  Мы абсолютно такие же, как большинство IT-компаний: у нас есть легаси, зоопарк технологий, отсутствие документации.

По большому счёту мы не отличаемся ничем, кроме одного факта: мы с самого начала росли, используя эти приемы. 

Приём #0: демонстрация движения

Мы показываем, как наша команда движется вперёд: она развивается, достигает высот, она лажает (кто не лажает, тот ничего не делает). Демонстрации проходят постоянно. 

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

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

Нам, как и многим, иногда приходится перерабатывать: задержаться вечером или выйти в субботу. Как этот приём помогает в повседневной жизни? Например, что есть новый крупный проект, социально важный для москвичей, где жители города смогут посмотреть, какие улучшения произойдут в его районе в ближайшем будущем. Я никогда не принуждаю к переработкам, но обязательно объясняю, что и почему происходит. Разработчик понимает, что участвует в большом и сложном процессе, знает, почему он так работает. Что 500 человек прошли по этим дворам, посчитали и записали необходимую информацию. И в большинстве случаев готов помочь. 

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

Приём #1: не скрывать

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

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

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

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

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

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

Приём #2: давать чётко регламентированную свободу

Свобода — это хорошо. Но полная свобода — это плохо. 

Сначала следили родители, потом педагоги в садике, потом педагоги в институте, потом начальник. Мы с детства привыкли, что кто-то за нами ухаживает. Полная свобода в итоге оказывается проблемой. Если создается впечатление, что начальник за вами не следит, чаще всего возникает вопрос: может быть, ему пофигу, может быть, ему всё это неинтересно, он вообще плевать на это хотел? Говорить людям, что есть канва, и в рамках этой канвы они могут двигаться.  Поэтому давать свободу нужно, но не полную, а ограниченную.

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

В итоге разработчик знает, что у него есть возможность выдвигать предложения, но для того, чтобы эти предложения докатились в продакшен, нужно будет поработать. Когда люди приходят и говорят: «Я хочу Go», я говорю — «Давай подумаем, насколько твоё «хочу» может реализоваться в «могу», во что-то полезное». Некоторые ей пользуются: поэтому у нас есть не только PHP, но и другие языки программирования.  Они знают эти правила игры, знают, что есть такая возможность.

Приём #3: пускать в процессы

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

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

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

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

Приём #4: вращать барабан

Хитрый приём: мы называем его «вращать барабан», но можно вращать карусель или бетономешалку — называйте это как угодно. Смысл в том, что мы совершенно осознанно не привязываем людей к задачам. 

Code ownership — у нас этого просто нет.  У нас нет такого, чтобы кто-то из фроненда, бэкенда или из DevOps не мог сделать какую-то другую задачу.

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

Причём одна никогда раньше не взаимодействовала с двумя другими: ребята просто пришли и приняли правила игры. Тот самый крупный и важный проект, о котором я говорил выше, делало три команды. За счёт того, что они в целом не привязаны к каким-то конкретным обязанностям, они прекрасно себя чувствуют.  В среднем такие проекты со сборной солянкой из ребят мы делаем раз в полгода.

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

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

Когда мы внедряли процесс релиз-менеджмента, мы сконвертировали двух тестировщиков в релиз-менеджеров, и они себя прекрасно чувствуют. Таких историй у меня несколько. Недавно я узнал, что один из PHP-разработчиков ночами программирует на Python. Верстальщиков мы превращаем во фронтенд-разработчиков. Какая разница, что именно он программирует на Python ночью? Казалось бы, тоже можно отпустить, но мы решили поиграть в игру: я пришёл в команду поиска, у которых бэк на Python, и попросил дать мне сложную несрочную задачу. Если у него получится, то мы его определим туда младшим Python-разработчиком из старшего PHP-разработчика. Пусть он программирует что-то нужное нам. Бывает такое желание у людей, что поделаешь? 

На этих приёмах я не потерял 5-6 человек из команды, я просто их перенаправил. 

Самый важный момент

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

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

Мониторинг

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

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

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

Несмотря на то, что у нас сейчас целый один HR, он справляется.  Это, в том числе, HR: периодически он приносит очень интересные новости.

О чём я разговариваю?

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

Ветераны труда уже смирились с тем, что выбрали не тот путь, а молодёжь ещё мечется между React и Angular, между PHP, Python, Go еще 500 других языков. Мне важно понять, чем человек интересуется. В ряде случаев я их интерес могу удовлетворить.  Чаще всего они чем-то интересуются.

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

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

Зачем всё это?

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

Одна отделяется, и все оглядываются: «Куда она ломанулась?». Видели, как бежит стадо лошадок? Потом самая нестойкая срывается за ней. Но продолжают бежать вперед. И так далее.  Их уже две.

Можно очень долго сидеть и ждать, а потом это всё рванет. Эти процессы накопительные. Поэтому нужно знать, как всё работает, и как можно быстрее реагировать на сигналы. 

Билет на волю

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

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

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

А главное, к этому надо уметь готовить людей, чтобы не получилась та самая лошадка. К этому надо быть готовым. Некоторые исследования показывают, что меньше, 1–1,5 года, — и всё, люди меняют работу.  Совершенно очевидно, что те, кто работает в нашей индустрии плотно, понимают, что средняя продолжительность работы сотрудника в команде 2–2,5 года.

Вместо выводов

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть