Каким должно быть идеальное количество отделов/людей для менеджера по продукту/программе?

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

Продукт вышел на стадию продаж и принял клиентов, а значит, нужна группа продаж и обслуживания клиентов, в дополнение к дебиторской задолженности и т. д.

Какое идеальное количество задач должен решить менеджер по продукту/программе, прежде чем он/она должен обратиться к менеджеру и попросить дополнительную помощь в области управления проектами?

Хороший вопрос. Однако я не думаю, что количество задач является ограничением. Вместо этого количество рабочих единиц (людей или отделов), как объяснил Дэвид ниже.
«Задачи» подразумевают, что вы выполняете работу самостоятельно; «программа» подразумевает, что вы управляете несколькими взаимосвязанными проектами. Не могли бы вы уточнить — вы работаете над одним проектом без команды (или с небольшой командой) или управляете более чем одним проектом с более чем одним отчетом?
Спасибо за вопросы. Я координирую несколько различных областей продукта, который мы выпустили. Я общаюсь с отделами продаж, разработки, маркетинга, ИТ и многими другими областями и нахожу работу для разных людей, чтобы поддерживать рост продукта.

Ответы (6)

Похоже, вы больше занимаетесь операциями, чем управлением проектами, но я могу ошибаться. В любом случае применяются одни и те же концепции. Нет никаких правил или ограничений, так как каждый PM отличается. Это просто зависит от вашего собственного стиля управления и от того, насколько комфортно вы себя чувствуете. Это относится к комментарию Дэвида Эспины «Промежуток контроля».

В разное время у меня было 20-25 проектов с 5 отчетами, а у других было 40+ (плюс общие операции) с 9 отчетами. Если управлять ими напрямую, это будет примерно вдвое меньше. Чем больше проектов, тем меньше я становился невмешательным и полагался на отчеты, которые выполняли свою работу и предоставляли мне необходимую информацию. Например, в какой-то момент я отвечал за все проекты в нашем подразделении, а также отвечал за бухгалтерский учет (A/R, A/P). Бухгалтерский учет — не моя область, поэтому у меня был офис-менеджер, который занимался этим и предоставлял мне еженедельные отчеты о состоянии, чтобы я мог отслеживать и решать проблемы на уровне подразделения.

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

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

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

Диапазон контроля . Количество задач, размер проекта в долларах или сложность могут ввести в заблуждение. Диапазон контроля диктует количество людей, за которыми наблюдает человек. Другими словами, если работа расширяется, количество людей, назначенных на нее, также увеличивается. В какой-то момент создается еще один уровень лидерства. Если он расширяется больше, добавьте еще один слой.

Существуют разные взгляды на надлежащий размер того, что контролирует человек. В большинстве случаев я читал, что число, при котором у нас максимальная производительность, в среднем составляет от шести до восьми прямых подчиненных. Совсем недавно это число было оспорено, и было предложено, чтобы у нас было от 15 до 20 прямых подчиненных.

Лично я считаю, что от 8 до 10 — это правильно, по крайней мере, для меня. Так что, если бы я руководил командой из 30 человек, между мной и остальными был бы слой тимлидов.

Трудно дать действительно окончательный ответ. Я бы сказал: это то, с чем может серьезно справиться PM, что зависит от рабочей нагрузки, которую представляет каждый из этих отделов и людей.

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

Я не думаю, что есть такое произвольное число (это было бы 42, если бы оно было...)

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

Часто обновляя такую ​​информацию, вы можете не только обратиться за помощью в таких областях, но и указать на другие решения, такие как обновление программного обеспечения или автоматизация некоторых задач (что является единовременным расходом).

Если говорить о задачах - очень мало. Если вы говорите о мероприятиях или проектах, это будет зависеть от фазы проекта, навыков команды и опыта PM.

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

Действительно, если все задачи независимы, вы можете предсказать точное необходимое усилие: это сумма времени, необходимого для каждой задачи. Настоящая проблема возникает, когда возникают трения между двумя задачами. Обычная иллюстрация следующая: вы управляете развертыванием SAP и управляете командой, состоящей из двух подгрупп A и B. A состоит из людей из отдела кадров, бухгалтерии и т. д. B состоит из инженеров. A и B могут легко выполнять свои задачи. Проблема состоит в том, чтобы заставить A и B сходиться к результату «один размер подходит всем». Тогда все усилия ПМ направлены на уменьшение трения между А и В.

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

Так что мой совет - посчитать количество "жестких" интерфейсов. Если у вас более 4 или 5 таких жестких интерфейсов, вам, вероятно, понадобится помощь.