Взгляд программиста на работу руководителя глазами руководителя

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

Обычно говорят “работать приходят в компанию, а уходят от руководителя”, что подтверждает и статистика. Но почему программист, который не является управленцем, в какой-то момент начинает считать, что менедмент плох? – Ответ на этот вопрос, на мой взгляд, достаточно прост и заключается в непонимании того, чем занимается руководство. Человек, который с утра до вечера создаёт какой-то продукт чётко понимает что он ни одного часа не прохалявил, может быть даже работал как проклятый и сверхурочно. “Но что сделал вот этот мужик в пиджаке, который то и дело улыбается и постоянно ходит на какие-то собрания, на которых все только и делают, что сидят, слушая друг друга? – Он же и строки кода не написал! Какую пользу он приносит компании? – Не понятно.” Такое умозаключение говорит о том, что работа руководителя слишком непрозрачна для его сотрудников. А они, не будучи управленцами, могут даже не знать его обязанностей. Потом происходит какой-то факап по вине руководителя. И запускает цепную реакцию, приводящую к поиску новой работы подчинёнными.
А теперь обратимся к тому, как же работают руководители в обобщённом виде, чтобы понять, как же им повысить прозрачность для сотрудников. Управление людьми, как и управление компанией, как и управление разработкой продукта, это ряд постоянных улучшений. Программисты выпускают релизы продукта, исправляя баги, добавляя новые фитчи и проводя эксперименты. Руководители делают тоже самое: исправляют проблемы в работе сотрудников (внутри команды, между ними), добавляют новые процессы, инструменты, мероприятия, ритуалы, задачи, планы, бюджеты, проводят эксперименты (а что, если программисты будут сами формулировать свои тикеты?). Разумеется, и у тех, и у других иногда случают факапы. Когда программист часто факапит из-за одного и того же (упорно отказывается тестировать код, например), то это звоночек. Когда руководитель часто факапит в одной и той же сфере (например, а области расчёта зарплат), то это тоже звоночек, как минимум, для его сотрудников. Но если и те, и те другие не допускают одних и тех же ошибок (профакапил, но стал относиться к проблемному месту с двойной внимательностью), то это крутые сотрудники, независимо от их роли в компании. Ошибаться могут все: и программисты, и менеджеры. Тем более, что структура их работы оцень схожа, но если разработчики управляют ИТ-продуктами, то их руководители управляют разработчиками.
Теперь ответим на вопрос о том, как же повысить прозрачность работы менеджмента? – Точно так же, как программисты повышают прозрачность своей работы:
  • чётко сформулированные задачи, которые видит необходимый круг лиц (команды, топ-менеджмент, etc) – это, кстати, и самим руководителям пойдёт на пользу
  • презентация результатов своей деятельности раз в неделю (или реже), как минимум, своим сотрудникам
  • ежедневный отчёт команде о том, чем руководитель занимался вчера и чем собирается заниматься сегодня
На мой взгляд, это лучшие практики, которые сейчас применяются для синхронизации работы программистов (внутри команд и между ними), поэтому легко масштабируются и на их руководителей.
Для программистов, которым не повезло с руководителями, могу порекомендовать книгу «Как работать на идиота? Руководство по выживанию»:

maxvyaznikov

Related Posts

Create Account



Log In Your Account



Было полезно? — Не пропустите новые статьи!