Баланс между менеджерами проектов и разработчиками? [закрытый]
8 ответов
Нет такого понятия, как "золотое отношение разработчиков к PM". Сама по себе проблема вряд ли укоренится в этом соотношении, но если вы чувствуете себя голодным по работе над проектом, то это, скорее всего, означает, что профессиональный менеджер не очень хорошо выполняет свою работу:
- Слишком много людей было выделено для проекта, чтобы начать с него.
- Задача, которой вы назначены, ждет внешней зависимости. PM должен был предоставить вам альтернативные задачи в рамках текущего управления рисками .
- Вы выполнили задачу досрочно, и PM не подготовился воспользоваться ситуацией, позволив вам рефакторинг, внести в документацию актуальные данные или что-то подобное. Способность извлечь выгоду из возможности - это еще одна сторона управления рисками.
- В проектной организации есть узкое место, то есть вещи нельзя охватить, спланировать, обеспечить качество так быстро, как вы можете поставлять новое программное обеспечение.
PM подпадает под классическую ошибку в программном обеспечении #19 :
Потраченное время во время нечеткого фронта. Нечеткий фронт-энд" - это время до начала проекта, время, обычно затрачиваемое на процесс утверждения и составления бюджета. Нередко проект проводит месяцы или годы в нечетком фронте, а затем выходит из ворот с агрессивным графиком. Гораздо проще и дешевле и менее рискованно экономить несколько недель или месяцев в нечетком графике, чем сжимать график разработки на ту же сумму.
Диспетчер проекта никогда не удается напрямую разработчиков. С помощью лидера Tech / Team (который управляет 7-8 людьми). Типичный менеджер будет управлять командой из 30+ разработчиков (наряду с 4-5 свинцом, который ведет по крайней мере 7 разработчиков каждый). Также у нас есть консультант по домену / Техническим консультантом / Бизнес-аналитиком, которые получают требования от клиента и создают системные документы, которые помогут техническому приводу преобразовать эти требования к дизайну спецификации, а затем разработчик реализует его!
менеджер
******* |> Бизнес-аналитик (1-2)
******* |> Ведущий (4-5)
****** * ******* |> Разработчики (7-8)
******* |> Тестовый провод (1-2)
****** * ***** ** |> Тестер (2-3)
У нас разные роли.
Менеджер проекта Управляет разработчиками, может быть до 15, может быть, до 15.
Бизнес-аналитики являются теми, которые предоставляют требования. Пропорция больше похожа на одну из них для двух или трех разработчиков.
Обычно 5 разработчиков на 1 менеджер проекта хорошо работает.
зависит от руководителя проекта и проекта. Я видел несколько PMS рукоять команды от 50 до 80 Devs; Я видел другую борьбу с 2 людьми.
Звучит мне, как этот проект был Greenlight задолго до того, как кто-то не знал, что он должен был сделать. Что означает, что вы можете чувствовать себя хорошо, но ждать до последнего месяца или около того. Все изменится.
Почему руководители проекта получают требования? Где я работаю, у нас есть бизнес-аналитик, который помогает получить требования, хотя порой разработчики могут пойти к концу пользователям, чтобы получить требования в некоторых случаях, поскольку не все известно в начале.
У нас есть горстка разработчиков, один BA и один менеджер проекта. В прошлом у нас было еще один BA, чтобы помочь сопоставить то, что требуется, и насколько сложна общая система.
У нас нет связи между ними. Каждый менеджер проекта будет иметь дело с тем, что многие разработчики доступны и назначены проекту. Если у проекта есть множество разработчиков, вот в том, где старшие / ведущие разработчики и руководители команды разработчиков могут принять участие, а не в PM с ними напрямую напрямую.
При поиске хорошего соотношения, погода будет 5:1, 10:1, и т.д. Я бы больше опирался на разработчика, чем на то, что, по вашему мнению, нужно в среднем. Если возникнет дефицит PM/BA, то мы, как разработчики, можем "неохотно" вступать в роль "PM", чтобы заполнить этот пробел. (На время, надеюсь) Легче превратить девелопера в БМ, чем БМ в девелопера. Это делает команду более адаптируемой.