Soft skills. Стрессоустойчивость. Часть III.

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

Вот некоторые моменты, учитывая которые, руководитель может существенно понизить уровень стресса у своих подчиненных.

👉Снять с разработчика необходимость приоритезации экстренных задач. Решать, чья задача важнее: бухгалтера или юриста, которые воют в трубку исполнителю, должен отнюдь не он.
👉Правильно организовать работу с инцидентами. Продолжая предыдущий пример, в идеальном мире они вообще не должны иметь доступ к непосредственному исполнителю, но идеальный мир существует мало где. И если разработчики у Вас выполняют функции первой линии техподдержки и на изменение этого нет ресурсов, попробуйте выделять им «дни без телефона».
👉Внедрить корректную оценку сроков. Где-то выше есть пост про дедлайны и что работа в вечном дедлайне отрицательно сказывается как на моральном состоянии разработчика, так и на качестве его труда. В целом это относится и к задачам, на которые оценка проставляется не от реальных возможностей разработчика, а от желаний проставляющего эту оценку человека.
👉Микроменеджмент. Если разработчик не давал повода (постоянный срыв сроков или частые ошибки на проде) контролировать его работу от и до не стоит. Это приводит к снижению производительности (реальная работа замедляется из-за необходимости постоянных согласований), ухудшению атмосферы (сотрудники чувствуют недоверие и давление), ограничение роста и потеря квалификации (отсутствие возможности самостоятельно принимать решения всегда отрицательно сказывается на развитии)
👉Следовать правилу «хвалить при всех, ругать наедине». Получать персонализированную критику при всей команде – унизительно в рамках нашей культуры. Поэтому идеальный способ донести до сотрудника, где и в чем он ошибся – на персональной встрече. После чего, если Вы считаете нужным привести задачу в качестве примера «обратите внимание, тут случился инцидент, давайте все учтём и так делать не будем», сообщить на общем собрании, желательно без персонализации. В целом, я не считаю этот пункт обязательным. Это очень индивидуально и для людей, и для команд в целом. Кто-то среагирует отрицательно, кто-то просто пожмет плечами, кто-то переложит ответственность. Но, делая так, вы точно не сделаете хуже.
👉Хаос в процессах. Отсутствие хотя бы среднесрочного планирования, постоянное переключение контекста разработки.
👉Фидбек. Сотрудник должен как иметь возможность высказаться, что и кто его не устраивает в рамках выполнения своих рабочих функций, так и знать, какие претензии есть к нему. Это может быть полезно и руководителю, если сотрудника придется увольнять, эмоционально гораздо проще это сделать, когда предупреждения о недопустимости определенных действий уже выносились неоднократно.

В конце я все-таки еще раз напомню, что у всего должны быть границы. Они у всех разные. Я ни в коем случае не призываю терпеть унижения или жить в постоянных условиях дедлайна. Вопрос в том, как увеличить порог вхождения в то, что я определил как «увеличенный уровень стресса». И направлять в конструктивное русло.

#медведьразмышляет #softskills