Статья подчеркивает необходимость, а также описывает способы разумного уклонения от личного участия в задачах, лежащих вне плана управления проектом, при помощи делегирования и выделения в команде самоорганизованных узлов.
Как и многие руководители в сфере разработки ПО, я вырос в менеджера из программиста (сначала писал встраиваемый, потом околосистемный софт) и в результате столкнулся с различными сложностями смены роли, включая желание решать инженерные задачи самостоятельно в ущерб плану управления проектом. Митигирование риска некачественного выполнения операций неравноценно обменивается на нездоровые процессы и упущенные возможности, которые зачастую влияют на успех проекта в гораздо большей степени. В проекте, где я работаю, мы предоставляем R&D-услуги крупной международной корпорации. R(esearch) сильно перевешивает D(evelopment), и сотрудники в большей мере являются инженерами, чем программистами.
Менеджеры на проекте также вырастают из инженеров, а, значит, они понимают технические детали выполнения задач. Это способствует распространению порочной практики микроменеджмента — руководитель стремится дать совет и лично помочь решить проблему. В такой довольно нередкой ситуации формируется неэффективная командная культура и неправильные ожидания от менеджера: руководитель начинает принимать решения, лежащие на самом деле в зоне ответственности инженера. В то же время здоровое управление проектами предполагает, что менеджер принимает решение, что делать (контролировать содержание), однако не вмешивается в решения, как делать.
В небольшой команде, когда руководитель тоже занимается разработкой и имеет ответы на все вопросы, вмешательство в зону ответственности инженеров еще может быть более или менее эффективным, но в большой по численности или распределенной географически команде зачастую правильность выполнения задачи просто невозможно оценить. Технический вопрос инженера может потребовать самостоятельного воспроизведения его работы. Если руководитель тратит на задачу время, сравнимое со временем, которое тратит инженер, то отпадает необходимость в привлечении инженера. Привыкая к тому, что руководитель справляется со всеми вопросами, инженеры начинают регулярно задавать вопросы по любому поводу. Чем больше становится команда, тем дальше менеджер выходит за рамки своего рабочего времени. В лучшем случае он успевает проверить почту и выполнить пару важных и срочных дел (согласно матрице Эйзенхауера). У руководителя не остается времени на план управления проектом: анализ требований, построение иерархической структуры работ (ИСР, WBS), составление расписания, контроль бюджета, отчёты, управление изменениями и рисками. Помимо этого, тотальная загруженность операционной деятельностью полностью сводит к нулю возможность генерации стратегических идей.
Есть два прямых способа решения этой проблемы:
- сверхурочная работа. Нарушает баланс между работой и отдыхом и приводит к выгоранию. Есть физический предел;
- менеджер уделяет внимание инженерам по остаточному принципу. Выполняет проектную работу, но не успевает контролировать выполнение задач программистами. Этот вариант лучше, но недостаточно эффективен, так как руководитель продолжает принимать решения вне своей области ответственности и становится недостаточно компетентен — возрастает риск одобрить неправильное решение, предложенное инженером.
Как бы странно это не звучало, если менеджер не понимает технических деталей, о которых говорит инженер, это хороший симптом здоровой команды. Дело в том, что менеджер не перегружен информацией, не являющейся необходимой для выполнения его обязанностей и не влияющей на его профессиональное развитие.
Машина проекта
Возможность работать с недостатками вышеупомянутых способов и значительно разгрузить менеджера, освободив место для проектных задач, конечно же есть.
Для того, чтобы управлять автомобилем, необязательно знать, как он устроен. Водителю достаточно задать направление (определить содержание) и скорость движения (ресурсы). Как и детали автомобиля, команды инженеров способны работать самостоятельно. Для этого по подпроектам формируются подкоманды (узлы машины). Узлы способны разобраться с проблемой внутри и инкапсулируют трудности (вспомните как инженер рассказывает вам долгую историю, являющуюся причиной какой-либо ситуации или решения). По всем узлам менеджер продолжает контролировать содержание, вводить-выводить ресурсы, может влиять на приоритет задач (чтобы повысить значимость самостоятельности в команде, лучше делать это в формате рекомендаций на основе более широкого видения). В рамках узла основными задачами остаются контроль расписания, управление изменениями, рисками и осведомленностью (отчёты и коммуникация). Руководителю нет необходимости контролировать технические переписки за инженеров — это отнимает время на понимание технических деталей (дублирует работу инженера) и стимулирует неправильный образ мысли («Я программист, моя работа — программировать»). В узлах из 3+ человек необходимо переложить ответственность за подпроект на одного из инженеров (First Line Manager, FLM) — он может обладать техническим авторитетом, лидерскими навыками, инициативой или просто пониманием бизнес-контекста.
Когда узел сформирован, менеджер позволяет ему полностью решать операционные задачи и частично решать проектные (некоторые со временем можно делегировать):
- проанализировать требования, построить ИСР и оценить операции может весь узел — инженеры будут чувствовать причастность и автоматически разделят с руководителем ответственность за сроки;
- расписание можно составить вместе с FLM и позволить ему следить за изменениями;
- отчёты сначала пишутся вместе, потом через ревью, а потом комментируются постфактум;
- менеджер определяет риски и планы по их митигированию, но владельцами назначает FLM’ов.
Руководитель полностью исключает себя из участия в процессе разработки, а также делегирует часть проектной деятельности FLM-у по мере того, как он способен с ней справиться. Менеджер оставляет свое непрямое присутствие во всех подпроектах и при этом избавляется от ненужной рутины.
Помимо индивидуальных синкапов по запросу узлы могут контролироваться регулярными синкапами со всеми FLM’ами (например, еженедельными) — где обсуждаются, как правило, только риски и возможности. По моему опыту, руководитель может легко контролировать
Некоторые менеджеры склонны бояться стать королем Лиром — делегировать до такой степени, что они потеряют авторитет, контроль ситуации и власть. Давайте будем честны — менеджер проектов, который руководствуется личными интересами, профессионально непригоден. Здоровые ориентиры для руководителя совпадают с интересами компании:
- расширение области ответственности сотрудников является катализатором их роста, удерживает их в компании и митигирует риск потери руководителя. Благодаря возможности взять на себя ответственность за новый подпроект на шесть инженеров, предоставленной в свое время мне моим руководителем, я смог набраться опыта и через какое-то время контролировать несколько команд и брать на себя задачи из плана управления проектом;
- руководитель может взять отгул, отпуск или уволиться, будучи уверенным, что без него проект не развалится и машина продолжит движение. Все мои команды способны работать самостоятельно, и потеря менеджера вызовет эффект гидры — менеджмент размножится. Конечно, процессы пострадают, некоторые возможности будут упущены, но машина продолжит движение, и через некоторое время стагнация сменится процветанием за счет развития новых руководителей;
- разгружаясь, руководитель улучшает проектные процессы, эффективно ускоряет личный рост (способен брать больше проектов, людей), работает над стратегией и видит новые возможности.
«Управляющие привыкли быть героями и действовать соответственно: брать на себя ответственность за все, что происходит, иметь ответы на все случаи жизни, принимать при необходимости смелые решения, хотя бо́льшую часть времени они тратили на удержание корпоративного корабля от раскачивания. Теперь они должны пойти дальше и сделать героями своих сотрудников».
А. Р. Коэн. «Курс MBA по менеджменту»
Автор статьи — менеджер проектов «Ауриги» в
