Руководство проектом инженерной группы

Этот ответ немного зависит от вашей культуры. Матричная структура не является редкостью в США. При таком варианте инженеры будут отчитываться о своих технических проблемах перед одним руководителем, возможно, перед архитектором или ведущим инженером. Однако по нетехническим вопросам премьер-министр обеспечит необходимое руководство. Эта матричная структура позволяет работникам получать то, что им нужно, от тех, кто лучше всего может это обеспечить, сохраняя при этом формальность структуры.

В некоторых странах, например во Франции, рабочим обычно нелегко принять идею иметь двух начальников. По этой причине матричная структура в этих странах встречается крайне редко.

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

TL:DR В вашем сценарии используйте ведущего инженера, который хорошо разбирается в методах управления проектами, а также в технических вопросах.

Подробный ответ Конечно, существует множество оттенков и вариаций, и на этот вопрос нет действительно правильного ответа. Но я считаю, что вы ошибаетесь в некоторых из ваших основных принципов. Если вы говорите о руководстве проектом, где проект представляет собой поставку программного обеспечения, то для этого руководства следует рассматривать только две из ваших ролей; Руководитель проекта и ведущий инженер.

Архитектор не является лидером группы разработчиков программного обеспечения, он является ее членом со своими собственными результатами (архитектурное видение и дизайн и т. д.).

Владелец продукта (если только вы не говорите об Agile, и в этом случае я не уверен в своей позиции) не является лидером группы разработки программного обеспечения, он вводит требования в команду от имени пользовательской базы и облегчает тестирование результатов на от имени пользовательской базы.

Таким образом, с точки зрения лидерства вы должны (массивное обобщение) рассматривать только PM и TL из вашего списка.

Я бы сказал, что для небольшой команды, такой как вы описали, технический руководитель (ведущий инженер) должен перейти на роль лидера проекта, но только на том основании, что он понимает, что руководство технической командой — это НЕ то же самое, что управление проектом (я вернусь к этому).

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

Проблема в том, что управление проектами требует иных вещей, чем техническое/инженерное руководство, и вы выделили некоторые из них выше. Но одно из ключевых отличий в этом сценарии заключается в том, что PM рассматривает реализацию проекта в целом, а не только действия по кодированию и разработке. Таким образом, они будут планировать и проводить тестирование, семинары для пользователей и управление ожиданиями, отчитываться перед старшими заинтересованными сторонами об общем ходе проекта, управлении рисками и проблемами, которые могут не иметь ничего общего с проектированием, и многое другое. Таким образом, ваш ведущий инженер должен быть сообразительным в области управления проектами, или ваш менеджер по управлению проектами должен быть немного техническим специалистом.

Вы также должны иметь в виду, что кодеры/разработчики/технические инженеры часто плохо относятся к управлению проектами («это будет сделано, когда это будет сделано»), и именно здесь вам действительно нужен технический интерфейс между менеджером проектов и разработчиками. .

Если я правильно понял ваш вопрос, то поможет провести различие между руководством проектом и командным руководством.

Руководство проектом, то есть руководство по вопросам, связанным с самой работой над проектом, можно довольно легко разделить, и вы можете извлечь большую пользу из совместного руководства. Самый большой успех, которого я добился (и видел в других командах), заключается в том, чтобы разные люди были последним словом в разных областях: PM — ваше последнее слово в процессе, PO — в решениях о функциях и функциональности, архитекторе дизайна программного обеспечения и т. д. Хотя они и являются последним словом, каждый может высказать свое мнение. Это обычно удерживает всех вложенными и вовлеченными, но последнее слово остается за вами, как только разговор только начинает крутиться и больше не добавляет ценности.

Под командным лидерством я подразумеваю людей, которые непосредственно обеспечивают лидерство в вопросах членов команды. Это может включать такие вещи, как неудовлетворительная работа, карьерный коучинг и т. д. В группах, которые слишком малы, чтобы иметь специального менеджера, я видел, что менеджеры проектов хорошо выполняют эту роль. PO слишком много поставлено на карту при доставке, поэтому, когда они предъявляют требования к команде, это корыстно. Это может сработать, если PO возглавит команду, но я думаю, что PM работает лучше. Заставить члена команды сделать это очень сложно, потому что он слишком далеко в сорняках. Это не значит, что другие люди не заставили это работать, но это не то, что я бы рекомендовал.

Надеюсь, это поможет. Хороший вопрос!

Забудьте о «лидерстве» и подумайте об «ответственности». «Кто за что отвечает» — гораздо более важный и правильный вопрос, чем «кто нами руководит?»

Ваш архитектор должен нести ответственность за технические решения, и его слово должно быть окончательным. Ваш product owner будет говорить, как должен выглядеть продукт, и его слово является окончательным и т. д. Такое отношение создаст гораздо более здоровую среду, чем та, где люди борются за «лидерство».