@lahomie93

Как спасти разработчика от выгорания? И стоит ли спасать?

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

При разработке мобильных приложений я использую такой флоу работы:
  • Менеджер проектов описывает задачу и предоставляет все ресурсы по ней - дизайны, апи, описание валидаций, эдж-кейсов
  • Разработчики декомпозируют полученную задачу и расставляют часы по подзадачам. Подзадачи раскладываются самим разработчиками в планировщике по дням на неделю вперед. В среднем в день ставится задач на 4-5 часов
  • При работе в течение дня разработчикам даются условия для сосредоточенной работы. Каждый разработчик ведет только один проект. В течение дня не более одного созвона с менеджером на 15-30 минут
  • В конце рабочей недели менеджер смотрит сколько было выполнено относительно плана/факта


При работе с новым разработчиком я слышал несколько раз фразы про "выгорание", про то, что он устает от кодинга и что ему приходится часто оставаться после работы.
Этим словам я не предавал особого значения, так как считал, что личные проблемы должны оставаться вне работы и вообще такие вещи странно слышать от нового сотрудника.

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

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

Мне хотелось бы услышать ваше мнение/истории по поводу того как вы работали с такими программистами? Удавалось ли вам вернуть разработчиков в строй или же вам приходилось увольнять таких сотрудников. И как мне следует поступить в такой ситуации.
  • Вопрос задан
  • 306 просмотров
Пригласить эксперта
Ответы на вопрос 2
@dmshar
Очень интересный кейс. И не простой.
Но, во-первых, что-то у вас не так в организации проекта, если любой может лЁгко снести свой код за два дня до дедлайна. А где копии, а где контроль удаления?
Есть над чем поработать даже без относительно к ситуации, которую мы рассматриваем.

Во-вторых, проблема "выгорания" - это проблема психологии. Мне такие проблемы при удаленной работе попадались один раз. И честно говоря, даже при офисной работе с ними справиться не легко - но тут как-бы человек на виду, всегда можно поговорить на диванчике, за чашкой кофе. А на удаленке контакт значительно слабее, поэтому надо сказать , что и шансы на успех будут на порядок ниже.
Вы должны вообще-то говоря понять, что как только вы - как работодатель и как исполнитель - приняли решение об удаленной работе - все личные проблемы исполнителя остаются вне поля вашего внимания. Вы должны его об этом поставить в известность сразу-же. Это его плата, которую он несет в обмен на удобства его работы дома. Он должен понимать, что это не он, это вы согласились на то, что-бы он не тратил время-деньги на дорогу, на присутсвие в офисе, на завязывание галстука и шнурков на ботинках, на жесткий контроль часов и т.д. "Выгорел" - это не COVID-19 подхватил, не ногу сломал, упав с дивана и не кошка любимая заболела, срочно надо к ветеринару. "Выгорел? - ну пойди соберись и работай дальше. Не можешь - поезжай на Бали, расслабся, как вернешся - подавай резюме на свободную к тому моменту вакансию, тогда и будем решать". Тем более, что участник проекта из новых, а с новыми - всегда легче прощаться, чем с теми, с кем ты сделал десяток проектов. И после десятого совместного проекта я бы "выгорел" - еще потерпел-бы, дав человеку передышку. А если это начинается на втором-третьем месяце первого проекта?

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

Пока писал - понял, что на самом деле тут таки таки два разных решения.

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

Второе - "удалил код". После такого - решение однозначно. Прощание без финансовой компенсации, без сожаления и без "простите меня пожалуйста".

Ну вот как-то так.
Удачи вам в решении проблемы.
Ответ написан
@vitaly_il1
DevOps Consulting
1) Насчет удаления кода - решение зависит от используемого сервиса, но, насколько знаю, у всех (GitHub, ...) есть возможность предотвратить это
2) Но даже если бы остался код - он почти бесполезен если разработчик писал его в одиночку, не по стандартам компании, без code reviews.
3) Как сказали, выгорание за пару месяцев - это очень странно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы