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