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

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

Чтобы пояснить, что я имею в виду, я хотел бы привести пример из замечательной книги Даниэля Канемана “Думай медленно… Решай быстро”.

“Обсуждая подготовку летчиков, опытные инструкторы отмечали, что похвала за особо мягкую посадку обычно приводит к тому, что следующая посадка получается хуже, а резкая критика за грубую посадку обычно приводит к улучшению в следующей попытке. Инструкторы пришли к выводу, что словесное поощрение губительно для обучения, а словесное наказание полезно, в отличие от общепринятой психологической доктрины”.

То есть инструкторам говорили, что похвала приносит пользу обучению, но они не верили. Их опыт говорил прямо обратное. Они хвалили курсанта за хорошую посадку, и следующая посадка была хуже. От инструкторов ускользало то, что по теории вероятностей после исключительно хорошей посадки, скорее всего, будет посадка хуже, хоть хвали курсантов, хоть ругай, хоть храни молчание. Они же видели результат своими глазами!

Можете кидать обычную игральную кость и хвалить её, когда выпадает шестёрка, и ругать, когда выпадает единичка. Вы увидите, что игральная кость от похвалы “расслабляется” и выкидывает результат хуже, а от критики “собирается” и выкидывает что-то получше. Но с игральной костью все механизмы работы просты и понятны, и всегда можно поэкспериментировать. А на практике наблюдаемый результат может сбить с толку.

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

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

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

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

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

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

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