Хабра приветствует всех, кому интересна эта тема.
Конечно, микроменеджмент встречается не только в ИТ, но именно в этой сфере этот черный ритуал может нанести существенный вред процессу разработки и конечному результату, не говоря уже о профессиональном развитии сотрудников.
Наверное, для начала стоит дать определение этому управленческому катаклизму.
Итак, согласно businessdictionary.com, микроменеджмент — это жесткий, тщательный, постоянный и зачастую демотивирующий контроль над работой, выполняемой сотрудниками.
Другими словами, если ваше начальство не позволяет вам сделать шаг, не проверив, правильно ли вы это сделали, постоянно контролируете все ваши действия и требуете отчета даже за малейшие движения, поздравляю, вы потенциальная или уже полная жертва микроменеджмент. Каковы недостатки микроменеджмента? Самая большая опасность такого стиля управления — превращение творческих, независимо мыслящих, предприимчивых работников в безвольных зомби, регулярно выполняющих приказы без блеска в глазах.
Учитывая, что в ИТ очень высок процент людей, умеющих нестандартно мыслить и генерировать яркие идеи, такой стиль управления, как микроменеджмент, не только неразумен, но в ряде случаев способствует параличу проекта, конфликтам и даже уходу специалистов.
из команды.
Чем еще опасен микроменеджмент? Отсутствие доверия к команде со стороны ее лидера и запрет ему совершать ошибки, что приводит к остановке развития команды.
Если люди чувствуют, что им не доверяют, то тимбилдинг замирает. Правильно, у зомби нет командного духа: их объединяет лишь географическая близость могил, из которых они восстали.
Микроменеджер думает, что знает, когда он может доверять своей команде в принятии решений, а когда нет. Он следует одному принципу – он позволяет своим людям действовать независимо и свободно до тех пор, пока они действуют правильно в его понимании.
Это что угодно, но не независимость или свобода.
Свобода — это возможность поступить иначе, чем действовал бы сам микроменеджер-некромант на месте зомби организованного разработчика.
В более широком смысле это тоже верно: право быть правым (в глазах микроменеджера) не имеет ничего общего со свободой; настоящая свобода — это иметь право ошибаться.
Постоянные проверки и слишком частая отчетность — еще одна прекрасная возможность убить доверие разработчика, уверенность в себе и желание сотрудничать с тимлидом.
Ничто так не разрушает энтузиазм к работе, как ощущение, что с тобой обращаются как с недоразвитым ребенком, за которым нужно присматривать каждую минуту.
Помимо падения морального духа, такая модель управления чревата неэффективным использованием времени руководителя.
Получается, что над задачей разработчика работают два специалиста: сам разработчик и менеджер, и время последнего обходится гораздо дороже.
Еще одним недостатком микроменеджмента является потеря фокуса со стратегического подхода к решению проблем.
Конечно, не такой стратегический подход, как в анекдоте про мудрую сову и мышей, которые хотели стать ежами, а адекватное стратегическое мышление при планировании процесса разработки.
При потере фокуса возникает опасность впасть в крайность тактического планирования, что сделает само управление развитием неэффективным.
Еще один неочевидный враг руководителя – перфекционизм.
Поскольку основным свойством перфекционизма является его неконтролируемое распространение, определить момент, когда перфекционизм превращается в микроменеджмент, бывает очень сложно.
Стремление к совершенству и вера в себя как совершенство творят чудеса: микроменеджер видит себя всемогущим боевым магом предпоследнего уровня, который держит руку на пульсе своего отряда прокачанных бойцов.
Но наступает момент, когда случайный взгляд, как в дурацких фильмах ужасов, вдруг выхватывает вместо привычных, искаженных героизмом лиц милые лица зомби.
Кроме того, разработчик, попавший на какое-то время в зону действия микроменеджера, может не только остановить свое развитие, но и существенно испортить свою карму или даже карьеру.
Сколько маны вам придется потратить, чтобы реабилитировать зомби и интегрировать его в другую команду? Легко разучиться думать самостоятельно, но восстановление этого навыка потребует драгоценного времени и ресурсов.
Неужели всё так плохо и не бывает ситуаций, когда микроменеджмент допустим? Конечно, такое случается.
Если, например, есть проблемы с вовлечением команды в процесс.
Скажем, массовый когнитивный диссонанс, сезонная депрессия или просто предпраздничное настроение, в результате которого команда просто выпадает из процесса и не желает впадать в него по собственному желанию.
Тогда самое время открыть свои некромантические записи и прочитать оттуда хотя бы простое заклинание для создания зомби и управления ими.
Иногда по каким-то личным причинам сотрудник вдруг начинает вести себя деструктивно по отношению к выполняемой работе или по отношению к коллегам.
В этом случае микроменеджмент не навредит, а наоборот, поможет предотвратить неожиданные или неприятные события.
Другими словами, если есть угроза внутренней безопасности (проекта, информации, сотрудников), то микроменеджмент как стратегия поведения и защиты полностью оправдан.
Но оправданное использование микроменеджмента – это скорее исключение, чем правило.
В общем, лучше исключить эту черную магию из процесса разработки.
Как это сделать? Вот несколько рекомендаций для начинающих и состоявшихся микроменеджеров: - помни, что ты - руководитель команды, а не кто-то из разработчиков или тестировщиков.
Ваша роль — помочь вашим людям применить свои знания и опыт развития, а не свой собственный.
Никто не сомневается, что вы перешли на умопомрачительный уровень магии разработки программного обеспечения, и нет необходимости лишний раз напоминать вам об этом.
Не каждый мозг способен справиться с постижением понятия бесконечности.
Постарайтесь совершить свой переход в новое качество – от эксперта к менеджеру – максимально быстро и безопасно для себя и окружающих.
- сосредоточиться на постановка задачи , а не объяснять, как ее решить.
Расскажите ЧТО нужно сделать, а не КАК это нужно сделать.
Сообщите команде, чего вы хотите, чтобы их магические усилия были достигнуты совместными усилиями, и предоставьте все необходимые объяснения параметров или ограничений, которые необходимо учитывать при выполнении задачи.
Пусть команда сама обработает исходные данные, использует свой опыт и креативность и, наконец, найдет правильный путь действий.
Не бойтесь делегировать полномочия, ведь этим вы делегируете ответственность, что само по себе является мотивацией.
— объяснить значение того или иного этапа развития в контексте всего проекта .
Видение полной картины и взаимосвязей между этапами проекта помогает осознанно двигаться вперед, систематизировать уже проделанную работу и прогнозировать предстоящие задачи.
— задайте команде больше вопросов и давайте Меньше готовых ответов.
Как лидер, задавайте вопросы, когда это возможно, и давайте ответы только тогда, когда это действительно необходимо.
- помнить: люди, а не ресурс! (С) При оценке проекта разработчики могут восприниматься как цифры и человеко-часы, но когда менеджер работает с командой, лучше строить партнерство с командой, поскольку цели и разработчиков, и менеджера проекта общие.
Старайтесь избегать использования методов некромантского микроменеджмента, ведь помимо сверхконтролируемых зомби существует еще множество более боеспособных и эффективных юнитов! Очень хотелось бы услышать от уважаемых хабраграждан, как бороться с микроменеджментом в сфере с помощью разработчиков.
Особенно интересны случаи успешной борьбы.
Теги: #Менеджмент #микроменеджмент #разработка #Управление проектами
-
Intellij Idea Стала Открытым Исходным Кодом
19 Oct, 24 -
Дата-Центры Начнут Работу В Апреле
19 Oct, 24
