Когда меня впервые назначили руководителем отдела разработки, я был уверен, что секрет результата — в скорости. Мы брали больше задач, выкладывали релизы ночью, гордились тем, что «команда вытянула». Через год из семи человек осталось трое: двое ушли по собственному, один — на больничный с нервным истощением. Проект мы всё равно сдали с опозданием на два месяца. Именно тогда я понял, что выгорание — это не слабость отдельных людей, а системная ошибка управления, и лечить её надо не уговорами потерпеть, а перестройкой процессов.
Первое, что пришлось выбросить из головы, — идею героизма. Пока в компании ценят разработчика, который «спасает релиз в ночь перед дедлайном», у людей есть прямой стимул доводить себя до предела. Мы ввели простое правило: если релиз требует аврала, значит, мы неправильно оценили объём, и разбираем это на ретро, а не награждаем героя. Первое время было непривычно и даже стыдно признаваться в промахах, но через пару месяцев план стал реалистичным, а ночные деплои почти исчезли.
Второй шаг — перейти от учёта часов к учёту результата. Раньше я смотрел, кто во сколько залогинился и сколько строк написал. Теперь мы смотрим, сколько задач закрыто, сколько инцидентов и как быстро команда восстанавливается после ошибок. Разработчик, который за пять часов решил сложную проблему, не должен выглядеть хуже того, кто просидел над ней два дня. Как только люди перестали имитировать занятость, у них появилось время на нормальную работу — и на жизнь после работы.
Третье — ритуалы, которые действительно работают. Короткий дейли по утрам, чтобы никто не тонул в неясности. Один на один раз в две недели, где человек говорит не про задачи, а про себя: что бесит, где не хватает поддержки, куда хочется расти. И ретро раз в две недели, с одним железным правилом: ищем причину сбоя в процессе, а не виноватого. За два года мы ни разу публично не разбирали личность — только то, что можно починить в системе.
Четвёртое, и, пожалуй, самое недооценённое — снижать операционную нагрузку. Выгорают не от сложных задач, а от бесконечных мелких пожаров, дежурств и ручного тестирования по ночам. Мы наняли человека на техподдержку второй линии, автоматизировали сборку и деплой, выделили время на технический долг — отдельным блоком в спринте, а не по остаточному принципу. Когда инженер знает, что у него есть два дня в неделю на уборку кода, а не только на новые фичи, работа перестаёт ощущаться бесконечной гонкой.
Пятое — смысл. Людям нужно видеть, как их код меняет жизнь пользователя. Мы начали показывать команде реальные истории клиентов, метрики продукта, отзывы. И разрешили каждому выделять часть времени на своё: кто-то писал открытый инструмент, кто-то учил джунов, кто-то разбирался с новым стеком. Как ни странно, именно эти «непродуктивные» часы дали нам потом два самых полезных внутренних проекта.
Что я советую тем, кто сейчас строит отдел или думает, что его команда вот-вот посыпется. Первое — не путайте занятость с эффективностью, усталый человек пишет код медленнее и с большим числом багов. Второе — договаривайтесь о правилах на берегу: как мы оцениваем работу, что делаем при срыве сроков, кто отвечает за дежурства. Третье — разговаривайте с людьми, а не с их задачами; выгорание почти всегда видно за месяц до того, как человек уходит. Четвёртое — защищайте команду от хаоса сверху; ваша главная работа как руководителя не раздавать задачи, а строить условия, в которых они решаются спокойно. И пятое —выгорает не тот, кто много работает, а тот, кто работает без результата и без признания.
За три года мы прошли путь от текучки в половину состава до команды из четырнадцати человек, где средний срок работы — больше двух с половиной лет, а скорость релизов выросла почти в три раза. Никакой магии — только предсказуемость, честность и уважение к чужому времени. А теперь вопрос к вам, коллеги: какой приём против выгорания сработал в вашей команде лучше всего — жёсткие правила по переработкам, регулярные разговоры один на один или что-то совсем неожиданное? Поделитесь, мне правда интересно собрать копилку рабочих решений.
Первое, что пришлось выбросить из головы, — идею героизма. Пока в компании ценят разработчика, который «спасает релиз в ночь перед дедлайном», у людей есть прямой стимул доводить себя до предела. Мы ввели простое правило: если релиз требует аврала, значит, мы неправильно оценили объём, и разбираем это на ретро, а не награждаем героя. Первое время было непривычно и даже стыдно признаваться в промахах, но через пару месяцев план стал реалистичным, а ночные деплои почти исчезли.
Второй шаг — перейти от учёта часов к учёту результата. Раньше я смотрел, кто во сколько залогинился и сколько строк написал. Теперь мы смотрим, сколько задач закрыто, сколько инцидентов и как быстро команда восстанавливается после ошибок. Разработчик, который за пять часов решил сложную проблему, не должен выглядеть хуже того, кто просидел над ней два дня. Как только люди перестали имитировать занятость, у них появилось время на нормальную работу — и на жизнь после работы.
Третье — ритуалы, которые действительно работают. Короткий дейли по утрам, чтобы никто не тонул в неясности. Один на один раз в две недели, где человек говорит не про задачи, а про себя: что бесит, где не хватает поддержки, куда хочется расти. И ретро раз в две недели, с одним железным правилом: ищем причину сбоя в процессе, а не виноватого. За два года мы ни разу публично не разбирали личность — только то, что можно починить в системе.
Четвёртое, и, пожалуй, самое недооценённое — снижать операционную нагрузку. Выгорают не от сложных задач, а от бесконечных мелких пожаров, дежурств и ручного тестирования по ночам. Мы наняли человека на техподдержку второй линии, автоматизировали сборку и деплой, выделили время на технический долг — отдельным блоком в спринте, а не по остаточному принципу. Когда инженер знает, что у него есть два дня в неделю на уборку кода, а не только на новые фичи, работа перестаёт ощущаться бесконечной гонкой.
Пятое — смысл. Людям нужно видеть, как их код меняет жизнь пользователя. Мы начали показывать команде реальные истории клиентов, метрики продукта, отзывы. И разрешили каждому выделять часть времени на своё: кто-то писал открытый инструмент, кто-то учил джунов, кто-то разбирался с новым стеком. Как ни странно, именно эти «непродуктивные» часы дали нам потом два самых полезных внутренних проекта.
Что я советую тем, кто сейчас строит отдел или думает, что его команда вот-вот посыпется. Первое — не путайте занятость с эффективностью, усталый человек пишет код медленнее и с большим числом багов. Второе — договаривайтесь о правилах на берегу: как мы оцениваем работу, что делаем при срыве сроков, кто отвечает за дежурства. Третье — разговаривайте с людьми, а не с их задачами; выгорание почти всегда видно за месяц до того, как человек уходит. Четвёртое — защищайте команду от хаоса сверху; ваша главная работа как руководителя не раздавать задачи, а строить условия, в которых они решаются спокойно. И пятое —выгорает не тот, кто много работает, а тот, кто работает без результата и без признания.
За три года мы прошли путь от текучки в половину состава до команды из четырнадцати человек, где средний срок работы — больше двух с половиной лет, а скорость релизов выросла почти в три раза. Никакой магии — только предсказуемость, честность и уважение к чужому времени. А теперь вопрос к вам, коллеги: какой приём против выгорания сработал в вашей команде лучше всего — жёсткие правила по переработкам, регулярные разговоры один на один или что-то совсем неожиданное? Поделитесь, мне правда интересно собрать копилку рабочих решений.