09.04.2020 Экспертиза, МенеджментСтатья подчеркивает необходимость, а также описывает способы разумного уклонения от личного участия в задачах, лежащих вне плана управления проектом, при помощи делегирования и выделения в команде самоорганизованных узлов. Как и многие руководители в сфере разработки ПО, я вырос в менеджера из программиста (сначала писал встраиваемый, потом околосистемный софт) и в результате столкнулся с различными сложностями смены роли, включая желание решать инженерные задачи самостоятельно в ущерб плану управления проектом. Митигирование риска некачественного выполнения операций неравноценно обменивается на нездоровые процессы и упущенные возможности, которые зачастую влияют на успех проекта в гораздо большей степени. В проекте, где я работаю, мы предоставляем R&D-услуги крупной международной корпорации. R(esearch) сильно перевешивает D(evelopment), и сотрудники в большей мере являются инженерами, чем программистами. Менеджеры на проекте также вырастают из инженеров, а, значит, они понимают технические детали выполнения задач. Это способствует распространению порочной практики микроменеджмента — руководитель стремится дать совет и лично помочь решить проблему. В такой довольно нередкой ситуации формируется неэффективная командная культура и неправильные ожидания от менеджера: руководитель начинает принимать решения, лежащие на самом деле в зоне ответственности инженера. В то же время здоровое управление проектами предполагает, что менеджер принимает решение, что делать ...
читать далее.
