Микроменеджмент

Микроменеджмент — попытка сверхдетального контроля за работой подчиненного. По моим наблюдениям, в программировании это весьма распространненная практика.

Ведь обычно (проектный) менеджер — это вчерашний программист. Причем программист наверное неплохой, по крайней мере был таковым, когда программировал. Сейчас он проектирует/управляет и кодировать ему некогда, реализацией целая команда занимается.

Тогда и появляется боязнь, что «они» все сделают «не так» и желание проконтролировать процесс реализации, вплоть до выбора имен классов, советов по реализации конкретных алгоритмов и прочее. Причем часто технические вопросы продавливаются авторитетом — «я так сказал».

Проблема в том, что такая «материнская опека» обычно только вредит. Она показывает, что менеджер не доверяет своей команде и не верит, что она способна самостоятельно вытянуть проект. А ведь «как вы яхту назовете ...». Теряется мотивация, инициатива подавляется, в конце концов, это просто раздражает (меня, по крайней мере).

Конечно же, контролировать процесс нужно. Но по возможности незаметно и ненавязчиво. Если команда слабая, то даже самая пристальная опека не поможет. Сильной же команде такое может принести урон значительно больший, чем потенциальные выгоды.

Программисты — как дети — имеют право на ошибку. Без ошибок нет роста. Безответственный программист (за которого все решает менеджер) — плохой программист. Найти же правильный баланс между свободой и контролем — это и есть забота хорошего менеджера.

Теми: менеджмент

will Yarulin 13.04.2011 17:25

Могу очень много поведать про микроменеждмент в тестировании ))

Відповісти

Підтримати

anonymous 03.04.2019 14:54

anonymous 20.09.2010 18:43

Есть право на ошибку, а есть обязанность ее исправления.Если кто-то именует функцию (реальный случай) типаIXMLDomDocumentLoadXMLAsynchronously (...,...) то абсолютно неважно, кто ты — менеджер или кодер. Если кодер — будь добр, прими к сведению руководство по стилю кодирования.Если такие имена навязывает менеджер — все зависит от него.Скорее всего придется сказать "ээээ... йес, афеметив! "Ну или поискать другого.

Прежде всего, следить за качеством кода является задачей не project manager, а ведущего программиста. ПМ не должен, да и попросту у него нет времени вникать в низкоуровневые технические детали проекта.Во-вторых, упомянутая боязнь, что «они» все сделают не так и потому «их» постоянно нужно контролировать, на самом деле не так уж и плоха. Да, в какой-то степени она показывает неопытность менеджера, но с другой стороны она также демонстрирует, что менеджер несет ответственность за результат, производимый командой. Поверьте, я встречал «молодцов», которые без тени смущения заявляли: «Это команда профакапила, я тут ни при чем, люди плохие были».Вопрос в том, как менеджер избавляется от этой боязни. Если он старается всюду совать свой нос, диктовать разработчикам поверх головы своего лида, как именно нужно писать, командует в стиле: «Я сказал! », то это, конечно плохо.Мой опыт мне показал, что от каждого человека можно получить положительный результат, найти к нему подход. Признаюсь, что я тоже вначале своей карьеры менеджера пытался «рулить» на низком уровне, диктуя, как именно нужно делать, но быстро отказался от этой идеи. Вместо этого я предпочитаю теперь «прессовать» своего лида, получая от него нужный мне результат, настойчиво подсказывая, что он также не должен все делать и переделывать за разработчиков, а в свою очередь должен ими командовать. Ну, а если результат меня не устраивает, то не жалею сил и терпения, чтобы объяснить почему он меня не устраивает и потом дать указание переделать. В результате вырастают нормальные, опытные ребята, на которых можно положить и поручать ответственные задачи. Они четко представляют вертикаль организации, знают свои права и обязанности, знают как нужно решать проблемы и достигать нужного результата. Как менеджеру мне остается только отдать указание и проконтролировать его выполнение:) Вуаля!

«я так сказал» должно быть для частей, влияющих на структуру системы, в остальном пускай придерживаются раннее определённых стандартов

«Как бы найти способ избавиться от этого желания контролировать разработку даже в мелочах...» Если реч идет о технических мелочах и попытках бывалого программиста, а ныне руководителя, котролироват даже «выбор имен классов», то почему бы не исползовать подход, когда ПМом является не «техничекии» человек, а руководител, которыи способен оценивать работу и продукт с точки зрения заказчика и потребителя продукта, которыи может организовать и котролировать ПРОЦЕСС разработки? Если реч идет о мелочах вообше, то я думаю, что перфектность во всем является клучем к успеху в конкурентнои борге на таком конкурентном рынке как разработка программного обеспечения.Manager.net.ua — независимый украинский информационный ресурс для руководителей проектов в сфере разработки программного обеспечения.

В точку! Как бы найти способ избавиться от этого желания контролировать разработку даже в мелочах...

Микроменеджмент

6 коментарів

Підписатись на коментарі