BLOG_Продуктовый лабиринт_Как я борюсь с выгоранием команды

Всем привет. Меня зовут Шеризат, я работаю в маркетплейсе JMart, это часть эко системы Jusan. В своих предыдущих статьях я рассказывал о том, как мы запускали продукты. Решил начать BLOG - продуктовый лабиринт, в этом блоге буду делиться успехами и неудачами, логикой принятия решений и интересными показательными историями. В своей первой статье хочу рассказать о том, как я борюсь с проблемой выгорания в команде.

Быстрые победы. Суть - периодически давать разработчику задачи которые он сможет быстро закрыть и увидеть результат работы в короткое время.
Эту идею мне подсказал мой коллега, PM смежной команды, он столкнулся с проблемой - разработчик полгода занимался одним большим проектом и по итогу просто выгорел. Не прошло и двух недель как data scientist с моей команды попросил дать ему другую задачу так как он 2 месяца занимался построением сервиса пуш уведомлений.

Переработки. Несколько раз замечал, что data scientist уточняет вопросы по проекту в ночное время, сразу внимание не обратил, но позже задал вопрос а зачем ты работаешь ночью? Ответ меня отправил в глубокий нокдаун - плановый срок реализации до конца месяца, а я не успеваю. Тогда мы действительно хотели как можно скорее выкатить задачу с виртуальным ассистентом на базе AI, но ценность скорого наката была гораздо ниже чем мотивация сотрудника. В итоге спустя несколько месяцев data scientst ушел с компании, но по иным причинам (по крайней мере она так сказала, и я хочу в это верить). В целом кейс ночными работами у технических специалистов распространённая практика, в данном случае важно удостовериться, в том, что у него остается время на личную жизнь, отдых и все остальное.

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

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

Остальные причины одной строкой:

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