— а как насчет услуги?
Я согласен, возможно следовало указать что я больше про аутсорсинг, я посчитал это очевидным когда сразу начал говорить про проекты и нигде не упомянул про продукт.
Это все-таки разные истории. Я согласен с большинством ваших утверждений, с поправкой что это продуктовая история. Поясню — это долгосрочное, целенаправленное развитие своего собственного продукта, под руководством продукт-менеджера конечно. Более того в продуктовых компаниях никто особо не ставит под сомнение необходимость менеджера, всем очевидно что он делает и зачем нужен. Также я не согласен что в рамках одного продукта, помимо продукт-менеджеров, есть менеджер(ы) проекта, которые занимаются операционкой, постановкой задач — в Яндексе судя по их видео так. Мне кажется наименование роли в этом случае просто для удобства понимания, по факту это не ПМ-ы, а условно исполнительные продукт-менеджеры (только что придумал, не воспринимайте слишком серьезно).
Насчет функций — не буду цитировать, отвечу глобально. Исходя из 2-х ваших комментариев мне кажется что вы не совсем правильно понимаете понятие проект, и организацию работы функционально, проектно, смешанно (матричная структура). Отсюда и выводы. С тапочками — это не проект. Проект подразумевает внедрение чего-то нового, или способа, или продукта. Это предприятие, бизнес. Наметили цель, выделили ресурсы, сделали устав, план и так далее — вижу вы с теорией и так знакомы. С тапочками устав, план, ресурсы — все это не нужно, так как уже есть и не отличается от предыдущих заказов, то же оборудование, те же люди, у которых те же обязанности. В проекте это все пишут как раз потому что это не совпадает с обычным функционалом сотрудника и надо подстраиваться под конкретную цель.
Поэтому если это не разработка новой модели тапочек — это не проект. И ресурсы как уже сказал не выделяют, просто запускают конвейер (не эксперт в тапочном производстве), но они не работают только на этот заказ, они постоянно делают тапочки.
В 1С — это все проекты, у каждого заказчика свои нюансы внедрения и свои запросы, хоть суть — тот же 1С, и если это фрилансер то вопрос ресурсов тоже редко стоит.
Упрощенно функции в рамках компании — финансы, маркетинг, логистика и т.д. Это функциональные подразделения, которые занимаются работой по своему профилю. В рамках эти подразделений могут быть проекты, опять же говорю абстрактно, когда нужно сделать что-то новое, добиться какой-то цели. Для них назначается менеджер. И тут уже где как, кто-то дает этому менеджеру полномочий почти как функциональному руководителю, и у сотрудника получается 2 начальника, кто-то не дает. Но когда в целом вся операционная деятельность строится на проектах, как во всех кто пишет приложения под ключ к примеру — я убежден что ПМ должен быть их руководителем и в том числе заниматься развитием, мотивацией, поощрениями и наказаниями, совместно. Хоть потому что ПМ ответственен за проект. А человек не может нести за что-то ответственность, не имея полномочий на это влиять, в данном случае на исполнителей.
Да, и PMBoK вещь хорошая, но охватывает не всё. Руководить и управлять это синонимы. Там и там есть команда которой руководят, дальше зависит от конкретной среды. Не спорю есть компании где менеджер занимается больше бумажной работой, а вся власть в руках функционального руководителя.
В целом — я не знаю какой у вас бэкграунд и опыт, думаю разный. Скажу за себя — я знаю о чем говорю, у меня как опыт управления проектами в IT и в реальной сфере, так и профессиональное управленческое образование, то есть я все это не с потолка взял и не сам придумал.
Во-первых, тут не про продуктовую историю. Я больше писал про аутсорсинг, где есть проект который делается для заказчика, где продукт-менеджера нет в принципе. Все что вы описали отчасти верно, когда есть продукт-менеджер и это продуктовая компания. Но только отчасти.
Принимать решения — то есть решать что-либо можно на любых уровнях. В продуктовой компании аналогично, просто как справедливо замечено — решения ПМ-а находятся на операционном уровне, а продукт-менеджера на стратегическом. Когда ПМ-а нет — значит продукт менеджер совмещает эти две роли. Когда он ничего не решает — это координатор проекта, у него вот власти нет. У проектного менеджера она есть.
Про неясность ролей — так вот именно, что непонимание разницы между продукт и прожект менеджером и координатором рождает споры. Тот факт что она не выделена говорит лишь о том, что тот кто этим занимается её не выделил, больше ничего. Моя мысль как раз в том что она не то что нужна, она есть всегда — всегда кто-то руководит и выполняет эту роль. При этом у него это либо закреплено формально, либо он делает это неформально.
Про рядовое подразделение — пример некорректен, рядовое подразделение по видимому имеется в виду функциональное, занимается тем что выполняет определенную функцию, то есть повторяющуюся работу определенного профиля, это не проект — это функция. Проект это по сути отдельное предприятие которое преследует цель, четко описанную, и у него есть начало и конец, бюджет, ресурсы и т.д. У функции конечной цели нет, и старта и финиша тоже, она занимается постоянной работой по своему профилю.
Как раз в данном посте я и хотел наглядно показать что он необходим и в маленьких командах из 2-10 человек, аутсорсных. Потому что с клиентом надо уметь общаться, общую картину строить, бизнес понимать, людьми руководить — в общем смотрите аргументы выше. Человек без подготовки, а тем более совершенно другой профессии это может выполнять только будучи очень одаренным от природы, и обладая большим жизненным опытом. Но лучше если это будет профессиональный управленец.
Я согласен, возможно следовало указать что я больше про аутсорсинг, я посчитал это очевидным когда сразу начал говорить про проекты и нигде не упомянул про продукт.
Это все-таки разные истории. Я согласен с большинством ваших утверждений, с поправкой что это продуктовая история. Поясню — это долгосрочное, целенаправленное развитие своего собственного продукта, под руководством продукт-менеджера конечно. Более того в продуктовых компаниях никто особо не ставит под сомнение необходимость менеджера, всем очевидно что он делает и зачем нужен. Также я не согласен что в рамках одного продукта, помимо продукт-менеджеров, есть менеджер(ы) проекта, которые занимаются операционкой, постановкой задач — в Яндексе судя по их видео так. Мне кажется наименование роли в этом случае просто для удобства понимания, по факту это не ПМ-ы, а условно исполнительные продукт-менеджеры (только что придумал, не воспринимайте слишком серьезно).
Насчет функций — не буду цитировать, отвечу глобально. Исходя из 2-х ваших комментариев мне кажется что вы не совсем правильно понимаете понятие проект, и организацию работы функционально, проектно, смешанно (матричная структура). Отсюда и выводы. С тапочками — это не проект. Проект подразумевает внедрение чего-то нового, или способа, или продукта. Это предприятие, бизнес. Наметили цель, выделили ресурсы, сделали устав, план и так далее — вижу вы с теорией и так знакомы. С тапочками устав, план, ресурсы — все это не нужно, так как уже есть и не отличается от предыдущих заказов, то же оборудование, те же люди, у которых те же обязанности. В проекте это все пишут как раз потому что это не совпадает с обычным функционалом сотрудника и надо подстраиваться под конкретную цель.
Поэтому если это не разработка новой модели тапочек — это не проект. И ресурсы как уже сказал не выделяют, просто запускают конвейер (не эксперт в тапочном производстве), но они не работают только на этот заказ, они постоянно делают тапочки.
В 1С — это все проекты, у каждого заказчика свои нюансы внедрения и свои запросы, хоть суть — тот же 1С, и если это фрилансер то вопрос ресурсов тоже редко стоит.
Упрощенно функции в рамках компании — финансы, маркетинг, логистика и т.д. Это функциональные подразделения, которые занимаются работой по своему профилю. В рамках эти подразделений могут быть проекты, опять же говорю абстрактно, когда нужно сделать что-то новое, добиться какой-то цели. Для них назначается менеджер. И тут уже где как, кто-то дает этому менеджеру полномочий почти как функциональному руководителю, и у сотрудника получается 2 начальника, кто-то не дает. Но когда в целом вся операционная деятельность строится на проектах, как во всех кто пишет приложения под ключ к примеру — я убежден что ПМ должен быть их руководителем и в том числе заниматься развитием, мотивацией, поощрениями и наказаниями, совместно. Хоть потому что ПМ ответственен за проект. А человек не может нести за что-то ответственность, не имея полномочий на это влиять, в данном случае на исполнителей.
Да, и PMBoK вещь хорошая, но охватывает не всё. Руководить и управлять это синонимы. Там и там есть команда которой руководят, дальше зависит от конкретной среды. Не спорю есть компании где менеджер занимается больше бумажной работой, а вся власть в руках функционального руководителя.
В целом — я не знаю какой у вас бэкграунд и опыт, думаю разный. Скажу за себя — я знаю о чем говорю, у меня как опыт управления проектами в IT и в реальной сфере, так и профессиональное управленческое образование, то есть я все это не с потолка взял и не сам придумал.
Принимать решения — то есть решать что-либо можно на любых уровнях. В продуктовой компании аналогично, просто как справедливо замечено — решения ПМ-а находятся на операционном уровне, а продукт-менеджера на стратегическом. Когда ПМ-а нет — значит продукт менеджер совмещает эти две роли. Когда он ничего не решает — это координатор проекта, у него вот власти нет. У проектного менеджера она есть.
Про неясность ролей — так вот именно, что непонимание разницы между продукт и прожект менеджером и координатором рождает споры. Тот факт что она не выделена говорит лишь о том, что тот кто этим занимается её не выделил, больше ничего. Моя мысль как раз в том что она не то что нужна, она есть всегда — всегда кто-то руководит и выполняет эту роль. При этом у него это либо закреплено формально, либо он делает это неформально.
Про рядовое подразделение — пример некорректен, рядовое подразделение по видимому имеется в виду функциональное, занимается тем что выполняет определенную функцию, то есть повторяющуюся работу определенного профиля, это не проект — это функция. Проект это по сути отдельное предприятие которое преследует цель, четко описанную, и у него есть начало и конец, бюджет, ресурсы и т.д. У функции конечной цели нет, и старта и финиша тоже, она занимается постоянной работой по своему профилю.
Как раз в данном посте я и хотел наглядно показать что он необходим и в маленьких командах из 2-10 человек, аутсорсных. Потому что с клиентом надо уметь общаться, общую картину строить, бизнес понимать, людьми руководить — в общем смотрите аргументы выше. Человек без подготовки, а тем более совершенно другой профессии это может выполнять только будучи очень одаренным от природы, и обладая большим жизненным опытом. Но лучше если это будет профессиональный управленец.