Как хорошему разработчику не стать плохим менеджером - страница 7

В менеджменте такое происходит постоянно. В моей практике был очень забавный пример, как одни и те же результаты интерпретировались по-разному. Я тогда работал в очень большой IT-компании, где группе из примерно 30 менеджеров поставили задачу увеличить производительность их команд. Разработчики выполняли некоторые задачи, каждая из которых фиксировалась тикетом в Jira. Количество зафиксированных (созданных и закрытых) тикетов и определяло производительность.

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

На общем собрании один из менеджеров, очень активный парень по имени Пётр, так прокомментировал наблюдаемое: “Уважаемый менеджмент, поглядите, как здорово мы выполнили ваше задание. Вы попросили увеличить производительность, и мы всего за пару недель производительность фактически удвоили”.

Ему ответил вице-президент компании, Густаво: “Глядя на этот график, становится очевидно, что раньше разработчики просто не заводили тикеты на многие свои задачи. Теперь они серьёзно относятся к отчётности и в Jira зафиксировано всё, что они делают. Ваша задача как менеджеров теперь проанализировать происходящее и увеличить производительность, а не просто улучшить числа в отчёте”.

Через неделю график производительность обзавёлся очередным скачком:

Менеджер Пётр снова прокомментировал происходящее: “Вы требовали от нас увеличения производительности – мы оптимизировали процессы. На графике вы с очевидностью можете видеть результаты наших усилий. Производительность выросла не так сильно, как в прошлый раз, но всё равно значительно”.

Вице-президент, глядя на тот же график, сказал: “На этом графике вы можете наблюдать нередкое явление. Люди, не видя очевидных решений проблемы и не имея достаточно желания прикладывать усилия, решили обмануть систему. Очевидно, что просто в Jira было добавлено много тикетов, которые не имеют отношения к делу. Пожалуйста, проверьте отчётность своих команд. На следующей неделе я сам проконтролирую, что в Jira нет мусорных записей, искажающих статистику. Тем временем я по-прежнему жду от вас плана действий по повышению производительности”.

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

Со мной периодически кто-нибудь спорит:

– Константин, твои методы слишком сложные. Любую проблемную ситуацию в команде можно решить, просто пригрозив увольнением. Вот жалуется человек на что-то. А я ему говорю: “Увольняйся!” – и сразу все претензии пропадают.

– Но ведь так никакой команды не построить! – в шоке возмущаюсь я.

– Зато люди делают то, что им сказано. А больше ничего не надо. Это эффективно.

Неопытный менеджер просто не знает, как работать с людьми правильно. Возникают ситуации, которые он не знает, как решить. И вдруг оказывается, что если на людей наорать, пригрозить увольнением и объявить выговор, то проблемы как бы уходят. Это кажется простым решением, а  негативные последствия носят очень сложный и отложенный характер. Да, почему-то люди увольняются, но не сразу ведь. Да, новых людей становится искать всё сложней, а некоторые резко отказываются рассматривать любые вакансии этой компании, но это же рынок труда скудный. Да, разработчики ведут себя пассивно, но для этого и нужен менеджер, чтобы их “активизировать”. Так и продолжают существовать неэффективные, вредные и просто опасные приёмы менеджмента.