Извечный спор страдающих менеджеров, не умеющих наладить коммуникацию с командой технических специалистов и технических специалистов, не понимающих зачем нужны планы, оценки, диаграммы, делегирование, встречи, коммуникации, адекватные фидбеки и прочая бюрократия.
И тут появляется тонкая грань: 1. ПМы, доказывающие что достаточно софт скилов — однозначно не достаточно опытны или, в отдельных случаях, глупы. 2. Технические специалисты, уверенные в ничтожности позиции ПМа, как таковой: — однозначно мало/плохо или вообще не разбираются в процессах построения команды и этапах создания продукта (разработка, это один из этапов). — скорее всего, за свою карьеру не встречали опытных менеджеров. — имеют проблемы с социализацией и (только «и», «или» тут не уместно) завышенную самооценку. Есть исключения с заниженной самооценкой и пофигистами, просто пишущими код.
Общие положения ответственностей, обязанностей и полномочий как Проектных менеджеров, так и Продуктовых, давным давно и четко определены. Любые дополнительные софт и хард скилы конечно же являются только плюсом. И глупо с этим спорить. Как уже эти доп. скилы будут влиять на основные, это уже вопрос из другой серии этого душераздирающего сериала.
В условиях работы в аутсорс, когда ПМ может работать с разными проектами, разными технологиями, разными командами, и разными клиентами, складывается такое впечатление, что ПМ обязан быть технически подкован под каждого в команде, каждую технологию и каждую сферу бизнеса. Да! Это действительно было бы большим преимуществом. Но тут будет уместен вопрос: сколько времени понадобится на качественное изучение всего этого?
И следующий вопрос: должен ли технический специалист знать «N» технологий одновременно, да бы небыло проблем в коммуникации между любыми технологиями фронтенда, бекенда, девопс, мобайл, десктоп, тестировщиками, автоматизаторами, embedded?
Или, может, достаточно будет обоим просто сесть и разобраться в том, что от него хотят, кто и почему, и поделиться своим аргументированным мнением и советом на этот счет?
Так же, очень часто путают понятия «управлять» проектом и «руководить» проектом. И руководство подменяют понятием управление. Руководят проектом за частую: Владелец, СЕО, Директор, Фаундер, Синиор/Супер синиор/Програм менеджер.
Проектный менеджер же, это часть всей команды/компании/отдела. Это человек, который связывает выше перечисленных персон и команду (кто бы в нее не входил), консультирует их и направляет. Тем самым, обеспечивая и поддерживая работу всего механизма, а не только команды разработки. Как он это делает и какие дополнительные обязанности и навыки ему требуются для работы с данным проектом и данной командой — это уже отдельный вопрос требующий индивидуального подхода.
Частая ошибка, когда ПМ безосновательно берет на себя роль руководителя и безоговорочного мастера принятия стратегических/тактических решений, не консультируясь при этом ни с кем из участников. В этом случае, человек или не понимает сути Проектного менеджмента, или его позиция не правильно называется, или он не соответствует занимаемой позиции, или он занимает несколько позиций и, возможно, не справляется.
Извечный спор страдающих менеджеров, не умеющих наладить коммуникацию с командой технических специалистов и технических специалистов, не понимающих зачем нужны планы, оценки, диаграммы, делегирование, встречи, коммуникации, адекватные фидбеки и прочая бюрократия.
И тут появляется тонкая грань:
1. ПМы, доказывающие что достаточно софт скилов — однозначно не достаточно опытны или, в отдельных случаях, глупы.
2. Технические специалисты, уверенные в ничтожности позиции ПМа, как таковой:
— однозначно мало/плохо или вообще не разбираются в процессах построения команды и этапах создания продукта (разработка, это один из этапов).
— скорее всего, за свою карьеру не встречали опытных менеджеров.
— имеют проблемы с социализацией и (только «и», «или» тут не уместно) завышенную самооценку. Есть исключения с заниженной самооценкой и пофигистами, просто пишущими код.
Общие положения ответственностей, обязанностей и полномочий как Проектных менеджеров, так и Продуктовых, давным давно и четко определены. Любые дополнительные софт и хард скилы конечно же являются только плюсом. И глупо с этим спорить. Как уже эти доп. скилы будут влиять на основные, это уже вопрос из другой серии этого душераздирающего сериала.
В условиях работы в аутсорс, когда ПМ может работать с разными проектами, разными технологиями, разными командами, и разными клиентами, складывается такое впечатление, что ПМ обязан быть технически подкован под каждого в команде, каждую технологию и каждую сферу бизнеса. Да! Это действительно было бы большим преимуществом. Но тут будет уместен вопрос: сколько времени понадобится на качественное изучение всего этого?
И следующий вопрос: должен ли технический специалист знать «N» технологий одновременно, да бы небыло проблем в коммуникации между любыми технологиями фронтенда, бекенда, девопс, мобайл, десктоп, тестировщиками, автоматизаторами, embedded?
Или, может, достаточно будет обоим просто сесть и разобраться в том, что от него хотят, кто и почему, и поделиться своим аргументированным мнением и советом на этот счет?
Так же, очень часто путают понятия «управлять» проектом и «руководить» проектом. И руководство подменяют понятием управление. Руководят проектом за частую: Владелец, СЕО, Директор, Фаундер, Синиор/Супер синиор/Програм менеджер.
Проектный менеджер же, это часть всей команды/компании/отдела. Это человек, который связывает выше перечисленных персон и команду (кто бы в нее не входил), консультирует их и направляет. Тем самым, обеспечивая и поддерживая работу всего механизма, а не только команды разработки. Как он это делает и какие дополнительные обязанности и навыки ему требуются для работы с данным проектом и данной командой — это уже отдельный вопрос требующий индивидуального подхода.
Частая ошибка, когда ПМ безосновательно берет на себя роль руководителя и безоговорочного мастера принятия стратегических/тактических решений, не консультируясь при этом ни с кем из участников. В этом случае, человек или не понимает сути Проектного менеджмента, или его позиция не правильно называется, или он не соответствует занимаемой позиции, или он занимает несколько позиций и, возможно, не справляется.