Комментарии 42
Роль ПМ не может быть перераспределена если ее нет. ПМ, это не продакт и не лид. Это человек управляющий проектом, но не продуктом и не командой. В его представление проект это ресурсы, рамки и дедлайны.
Он начинает свою работу тогда, когда цель продукта уже ясна. Продукт имеет верхнеуровневые требования и некоторые рамки. Цель ПМа в команде — повысить эффективность использования ресурсов для достижения закрепленных целей и синхронизировать работу специалистов с различными навыками.
Он держатель отчетов об эффективности. Он «глаза» владельца проекта. Но он не решает практически ничего. Да он может влиять на проект через операционку, но не решать. Если он вдруг начинает решать что-то, то это уже не ПМ. Точнее не проэктный-менеджер. Это продукт-менеджер. А если он еще и принимает решение о запуске проекта или о его остановке, то это уже владелец.
Самая простая аллегория на тему кто такой ПМ — это генерал на зайце.
Именно неясность ролей приводит к многочисленным спорам о том нужны они или нет. Если роль такая не выделена, вполне возможно, что она не нужна.
Как пример, менеджер проекта не нужен при функционировании рядового подразделения, выполняющего свои функции ежедневно по заведенному порядку.
Он также не нужен когда проект делается в команде 2-10 человек. Т.к. все его полезные функции не имеют смысла в таком тесном коллективе. Все, все и так знают. Разве что как опытный наставник. Но тогда он будет лидом.
P.S. Заголовок вводит в заблуждение о содержании статьи.
Он начинает свою работу тогда, когда цель продукта уже ясна. Продукт имеет верхнеуровневые требования и некоторые рамки. Цель ПМа в команде — повысить эффективность использования ресурсов для достижения закрепленных целей и синхронизировать работу специалистов с различными навыками.
Он держатель отчетов об эффективности. Он «глаза» владельца проекта. Но он не решает практически ничего. Да он может влиять на проект через операционку, но не решать. Если он вдруг начинает решать что-то, то это уже не ПМ. Точнее не проэктный-менеджер. Это продукт-менеджер. А если он еще и принимает решение о запуске проекта или о его остановке, то это уже владелец.
Самая простая аллегория на тему кто такой ПМ — это генерал на зайце.
Именно неясность ролей приводит к многочисленным спорам о том нужны они или нет. Если роль такая не выделена, вполне возможно, что она не нужна.
Как пример, менеджер проекта не нужен при функционировании рядового подразделения, выполняющего свои функции ежедневно по заведенному порядку.
Он также не нужен когда проект делается в команде 2-10 человек. Т.к. все его полезные функции не имеют смысла в таком тесном коллективе. Все, все и так знают. Разве что как опытный наставник. Но тогда он будет лидом.
P.S. Заголовок вводит в заблуждение о содержании статьи.
Во-первых, тут не про продуктовую историю. Я больше писал про аутсорсинг, где есть проект который делается для заказчика, где продукт-менеджера нет в принципе. Все что вы описали отчасти верно, когда есть продукт-менеджер и это продуктовая компания. Но только отчасти.
Принимать решения — то есть решать что-либо можно на любых уровнях. В продуктовой компании аналогично, просто как справедливо замечено — решения ПМ-а находятся на операционном уровне, а продукт-менеджера на стратегическом. Когда ПМ-а нет — значит продукт менеджер совмещает эти две роли. Когда он ничего не решает — это координатор проекта, у него вот власти нет. У проектного менеджера она есть.
Про неясность ролей — так вот именно, что непонимание разницы между продукт и прожект менеджером и координатором рождает споры. Тот факт что она не выделена говорит лишь о том, что тот кто этим занимается её не выделил, больше ничего. Моя мысль как раз в том что она не то что нужна, она есть всегда — всегда кто-то руководит и выполняет эту роль. При этом у него это либо закреплено формально, либо он делает это неформально.
Про рядовое подразделение — пример некорректен, рядовое подразделение по видимому имеется в виду функциональное, занимается тем что выполняет определенную функцию, то есть повторяющуюся работу определенного профиля, это не проект — это функция. Проект это по сути отдельное предприятие которое преследует цель, четко описанную, и у него есть начало и конец, бюджет, ресурсы и т.д. У функции конечной цели нет, и старта и финиша тоже, она занимается постоянной работой по своему профилю.
Как раз в данном посте я и хотел наглядно показать что он необходим и в маленьких командах из 2-10 человек, аутсорсных. Потому что с клиентом надо уметь общаться, общую картину строить, бизнес понимать, людьми руководить — в общем смотрите аргументы выше. Человек без подготовки, а тем более совершенно другой профессии это может выполнять только будучи очень одаренным от природы, и обладая большим жизненным опытом. Но лучше если это будет профессиональный управленец.
Принимать решения — то есть решать что-либо можно на любых уровнях. В продуктовой компании аналогично, просто как справедливо замечено — решения ПМ-а находятся на операционном уровне, а продукт-менеджера на стратегическом. Когда ПМ-а нет — значит продукт менеджер совмещает эти две роли. Когда он ничего не решает — это координатор проекта, у него вот власти нет. У проектного менеджера она есть.
Про неясность ролей — так вот именно, что непонимание разницы между продукт и прожект менеджером и координатором рождает споры. Тот факт что она не выделена говорит лишь о том, что тот кто этим занимается её не выделил, больше ничего. Моя мысль как раз в том что она не то что нужна, она есть всегда — всегда кто-то руководит и выполняет эту роль. При этом у него это либо закреплено формально, либо он делает это неформально.
Про рядовое подразделение — пример некорректен, рядовое подразделение по видимому имеется в виду функциональное, занимается тем что выполняет определенную функцию, то есть повторяющуюся работу определенного профиля, это не проект — это функция. Проект это по сути отдельное предприятие которое преследует цель, четко описанную, и у него есть начало и конец, бюджет, ресурсы и т.д. У функции конечной цели нет, и старта и финиша тоже, она занимается постоянной работой по своему профилю.
Как раз в данном посте я и хотел наглядно показать что он необходим и в маленьких командах из 2-10 человек, аутсорсных. Потому что с клиентом надо уметь общаться, общую картину строить, бизнес понимать, людьми руководить — в общем смотрите аргументы выше. Человек без подготовки, а тем более совершенно другой профессии это может выполнять только будучи очень одаренным от природы, и обладая большим жизненным опытом. Но лучше если это будет профессиональный управленец.
Я больше писал про аутсорсинг, где есть проект который делается для заказчика
Видимо, это и нужно было указать. Потому, что это не общий случай, а частный. И, скажем так, Ваше субъективное мнение. Даже в оутсорсе это работает не так. Сейчас поясню.
Все что вы описали отчасти верно, когда есть продукт-менеджер и это продуктовая компания.
Про продуктовую историю речь идет всегда. Продукт это общая ценность. Именно ее все хотят получить. А вот понимают по-разному. Кто-то со стороны бизнеса, а кто-то со стороны отчетов. Но все эти шумные ребятишки и девчонки собираются в дружные коллективы именно ради продукта. Т.ч. именно роль продут-менеджера, кто бы ее не нес, устранить нельзя. Она является обязательной.
Даже программист-одиночка, пилящий свой пет-проект уже продакт-менеджер. Хотя совсем не проджет-менеджер.
Принимать решения — то есть решать что-либо можно на любых уровнях.
Можно себя тешить сей мыслью сколь угодно. Она, несомненно, справедлива. Но выдернув ее из контекста продукта… Вы ушли от сути мной написанного. Я ставлю под сомнение необходимость роли ПМ как такового при выпуске продукта. Как выше я написал — продукт есть всегда.
У рядового, функционального сотрудника выделенного в проект полномочий по решению в части продукта больше. А дело роли ПМ — фиксировать и согласовывать. Чтобы не отнимать время этого самого специалиста на несвойственную ему деятельность.
Когда ПМ-а нет — значит продукт менеджер совмещает эти две роли.
Я привел пример программиста одиночки. Там никакой ПМ не нужен. Он прекрасно справляется сам. И даже роль такую в себе не несет.
Нужен еще пример? Фрилансеры, 1С программисты на подряде (ГПД), юристы ведущие дело и т.п. Все они ведут проекты. Но ПМ им не нужен. И роль они на себя такую не брали.
Когда он ничего не решает — это координатор проекта, у него вот власти нет. У проектного менеджера она есть.
Опишите пожалуйста какая конкретно у Вас есть власть? Ну или у абстрактного менеджера. Прям интересно. А еще лучше, если вы выдержку из Устава проекта сделаете о роли ПМ, его зоне ответственности и ключевых показателях эффективности.
Про неясность ролей — так вот именно, что непонимание разницы между продукт и прожект менеджером и координатором рождает споры.
Тот факт, что многие ПМы не делают рабочие Уставы проектов рождает споры. Т.к. это ведет к непониманию своей роли. Если бы люди понимали почему в проекте есть те или иные роли, то они бы не писали на Хабре, что менеджеры мешают. Они бы понимали чем именно они им помогают. А донесение роли каждого в проекте — святая обязанность ПМ.
Про рядовое подразделение — пример некорректен, рядовое подразделение по видимому имеется в виду функциональное
Отчего ж? например есть заказ на выпуск 100 000 тапочек красного цвета. Производство и раньше их делало. Но под заказ нужно выделить ресурсы и добиться минимального простоя мощностей незадействованных в выпуске.
Это вполне себе проект. И там никакой ПМ не нужен. Есть директор производства и акаут-менеджер. Это роли, возникшие по причине постоянной необходимости функции планирования и работы с клиентами. Объединив их в кучу ты не получишь ПМ. А ПМ, как я уже сказал, там без надобности.
ПМ тут понадобится тогда, когда, внезапно, директор предприятия захочет полностью контролировать выпуск этих тапочек от начала и до конца. Тогда он объявит выпуск тапочек ценностью, определит ей приоритет, выделит ресурсы и поставит г-на Сидорова, который будет ему каждое утро приносить отчеты об эффективности выпуска тапок. А если тапки не будут эффективно выпускаться, по мнению Сидорова, тот тот будет строить грозные моськи, стращать всех именем ГД и у последнего просить наказать всех повинных в срыве его дедлайнов. Разве не так это работает?
это не проект — это функция
1С программист программирует программы. Каждому клиенту по программе. Он приходит к клиенту, спрашивает какая программа нужна и делает программу. Это функция?
Как раз в данном посте я и хотел наглядно показать что он необходим и в маленьких командах из 2-10 человек, аутсорсных.
Тогда по стандарту управления проектами, Вы видимо сейчас собираете обратную связь? Пользуясь возможностью, я фиксирую наличие риска о недостаточном качестве подготовки материала для донесения целевого смысла документа.
Как-то так это должно фиксироваться? ;)
Потому что с клиентом надо уметь общаться, общую картину строить, бизнес понимать, людьми руководить — в общем смотрите аргументы выше.
Мне кажется у Вас есть стратегическая ошибка в понимании роли ПМ. Он не руководит проектом. Он управляет проектом.
Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK)
Продукт это общая ценность.— а как насчет услуги?
Я согласен, возможно следовало указать что я больше про аутсорсинг, я посчитал это очевидным когда сразу начал говорить про проекты и нигде не упомянул про продукт.
Это все-таки разные истории. Я согласен с большинством ваших утверждений, с поправкой что это продуктовая история. Поясню — это долгосрочное, целенаправленное развитие своего собственного продукта, под руководством продукт-менеджера конечно. Более того в продуктовых компаниях никто особо не ставит под сомнение необходимость менеджера, всем очевидно что он делает и зачем нужен. Также я не согласен что в рамках одного продукта, помимо продукт-менеджеров, есть менеджер(ы) проекта, которые занимаются операционкой, постановкой задач — в Яндексе судя по их видео так. Мне кажется наименование роли в этом случае просто для удобства понимания, по факту это не ПМ-ы, а условно исполнительные продукт-менеджеры (только что придумал, не воспринимайте слишком серьезно).
Насчет функций — не буду цитировать, отвечу глобально. Исходя из 2-х ваших комментариев мне кажется что вы не совсем правильно понимаете понятие проект, и организацию работы функционально, проектно, смешанно (матричная структура). Отсюда и выводы. С тапочками — это не проект. Проект подразумевает внедрение чего-то нового, или способа, или продукта. Это предприятие, бизнес. Наметили цель, выделили ресурсы, сделали устав, план и так далее — вижу вы с теорией и так знакомы. С тапочками устав, план, ресурсы — все это не нужно, так как уже есть и не отличается от предыдущих заказов, то же оборудование, те же люди, у которых те же обязанности. В проекте это все пишут как раз потому что это не совпадает с обычным функционалом сотрудника и надо подстраиваться под конкретную цель.
Поэтому если это не разработка новой модели тапочек — это не проект. И ресурсы как уже сказал не выделяют, просто запускают конвейер (не эксперт в тапочном производстве), но они не работают только на этот заказ, они постоянно делают тапочки.
В 1С — это все проекты, у каждого заказчика свои нюансы внедрения и свои запросы, хоть суть — тот же 1С, и если это фрилансер то вопрос ресурсов тоже редко стоит.
Упрощенно функции в рамках компании — финансы, маркетинг, логистика и т.д. Это функциональные подразделения, которые занимаются работой по своему профилю. В рамках эти подразделений могут быть проекты, опять же говорю абстрактно, когда нужно сделать что-то новое, добиться какой-то цели. Для них назначается менеджер. И тут уже где как, кто-то дает этому менеджеру полномочий почти как функциональному руководителю, и у сотрудника получается 2 начальника, кто-то не дает. Но когда в целом вся операционная деятельность строится на проектах, как во всех кто пишет приложения под ключ к примеру — я убежден что ПМ должен быть их руководителем и в том числе заниматься развитием, мотивацией, поощрениями и наказаниями, совместно. Хоть потому что ПМ ответственен за проект. А человек не может нести за что-то ответственность, не имея полномочий на это влиять, в данном случае на исполнителей.
Да, и PMBoK вещь хорошая, но охватывает не всё. Руководить и управлять это синонимы. Там и там есть команда которой руководят, дальше зависит от конкретной среды. Не спорю есть компании где менеджер занимается больше бумажной работой, а вся власть в руках функционального руководителя.
В целом — я не знаю какой у вас бэкграунд и опыт, думаю разный. Скажу за себя — я знаю о чем говорю, у меня как опыт управления проектами в IT и в реальной сфере, так и профессиональное управленческое образование, то есть я все это не с потолка взял и не сам придумал.
а как насчет услуги?
Продукт — результат труда. Если результат труда услуга, то это такой же продукт.
Думаю, я расширенно отвечу на ваши комментарии статьей. Создалось у меня впечатление, что она не будет лишняя.
Спасибо за статью!
P.S.
… я все это не с потолка взял и не сам придумал.уфов малова-то для такого утверждения.
Статью с удовольствием почитаю.
Насчет продукта — согласен. Просто у услуги много специфических моментов с точки зрения организации ее предоставления, про которые я собственно и написал.
Так или иначе я свои выводы сделал, вернусь тоже с другими материалами по теме.
Насчет продукта — согласен. Просто у услуги много специфических моментов с точки зрения организации ее предоставления, про которые я собственно и написал.
Так или иначе я свои выводы сделал, вернусь тоже с другими материалами по теме.
В тему — из телеграм-канала Темная сторона
Услуга как продукт
1. Может ли услуга быть продуктом? Может. Если она а) стандартизована по составу, процессу, результату и цене, б) многократно повторяема и в) вы можете научить оказывать ее кого-то другого.
2. Можно ли быть бизнесом, оказывая услуги, но не имея продукта? Нельзя. Этот «бизнес» умрет, как только основатели устанут, уйдут или умрут.
3. А как же, например, большие консалтинговые компании — они же под каждого клиента подстраиваются? А у них просто продукт другой — система набора, тренировки, контроля и продвижения людей, которые способны такие нестандартизованные услуги оказывать. Именно этот продукт создали основатели, и он продолжает жить, даже когда люди в компании сменились.
4. В общем, продукт — это когда что-то стандартно, повторяемо и передаваемо. На этом фоне меня умиляют люди, которые строят «бизнес», выдвигая в качестве своего конкурентного преимущества свой «высокий профессионализм» в продаваемой области. Тем самым они намекают, что обладают уникальным и неповторимым умением.
Услуга как продукт
1. Может ли услуга быть продуктом? Может. Если она а) стандартизована по составу, процессу, результату и цене, б) многократно повторяема и в) вы можете научить оказывать ее кого-то другого.
2. Можно ли быть бизнесом, оказывая услуги, но не имея продукта? Нельзя. Этот «бизнес» умрет, как только основатели устанут, уйдут или умрут.
3. А как же, например, большие консалтинговые компании — они же под каждого клиента подстраиваются? А у них просто продукт другой — система набора, тренировки, контроля и продвижения людей, которые способны такие нестандартизованные услуги оказывать. Именно этот продукт создали основатели, и он продолжает жить, даже когда люди в компании сменились.
4. В общем, продукт — это когда что-то стандартно, повторяемо и передаваемо. На этом фоне меня умиляют люди, которые строят «бизнес», выдвигая в качестве своего конкурентного преимущества свой «высокий профессионализм» в продаваемой области. Тем самым они намекают, что обладают уникальным и неповторимым умением.
Я встречал позиции, подобные вашей, которые коротко описываются фразой «ПМ — это прораб». Не разделяю, людей с такой позицией на роль ПМа не нанимал.
Это человек управляющий проектом, но не продуктом и не командой. В его представление проект это ресурсы, рамки и дедлайны.
ПМ командой очень даже управляет. Проектная команда — это ведь один из видов его же ресурса. Он может не быть линейным руководителем, но как только из подразделений выделяется рабочая группа проекта, она передаётся в функциональное подчинение ПМу, и как раз он ставит им задачи в рамках проекта и контролирует их выполнение.
Я выше описал определение «Управление проектами». Повторю.
ПМ — это роль. Роль носит человек, котрый, да, может управлять и командой. Но в этом случае, он становится уже функциональным руководителем для тех кем управляет. Т.к. должен заниматься мотивированием, управлением времени выделенных сотрудников и т.д. Все это не входит в круг обязанностей ПМ. ПМ запрашивает ресурсы, получает ресурсы. Сегодня у него на проекте Петя, завтра Галя. Функция у Гали и Пети идентичная. Для ПМ это ресурс, который остался без изменений.
Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK)
ПМ — это роль. Роль носит человек, котрый, да, может управлять и командой. Но в этом случае, он становится уже функциональным руководителем для тех кем управляет. Т.к. должен заниматься мотивированием, управлением времени выделенных сотрудников и т.д. Все это не входит в круг обязанностей ПМ. ПМ запрашивает ресурсы, получает ресурсы. Сегодня у него на проекте Петя, завтра Галя. Функция у Гали и Пети идентичная. Для ПМ это ресурс, который остался без изменений.
Все это не входит в круг обязанностей ПМ. ПМ запрашивает ресурсы, получает ресурсы. Сегодня у него на проекте Петя, завтра Галя. Функция у Гали и Пети идентичная. Для ПМ это ресурс, который остался без изменений.
Входит. В понятии «управление проектами» главное слово «управление». Любое управление — это анализ ситуации, воздействие (например, отдача распоряжений в случае управления людьми), обратная связь (контроль выполнения распоряжений).
Поэтому ПМ всегда ставит задачи участникам проектной группы и контролирует их выполнение. Даже если Галя и Петя взаимозаменяемы. Эта функция не отделима от роли ПМ, и её некорректно рассматривать как часть другой роли, даже если в PMBoK утверждается обратное. Эйнштейны тоже ошибаются.
… даже если в PMBoK утверждается обратное
Ну так-то да… так в целом можно легко что угодно утверждать. Ведь не Боги горшки обжигают. Не думаю, что тут остаются перспективы для дискуссии.
Поэтому ПМ всегда ставит задачи участникам проектной группы и контролирует их выполнение.
Тут ключевым является наличие или отсутствие слова «участники». Если ПМ по совместительству (но не «по науке», как в большинстве случаев и происходит) является линейным руководителем разработчиков — да. Но такая «архитектура» построения команды в корне не верна. В команде должна быть роль тех-лида, с которым ПМ согласовывает работы, и через которого ставит задачи команде. И только тех-лид отвечает перед ПМ-ом по срокам, срывам и прочим радостям. За команду, а не конкретно за Петю или Галю. Поскольку разделение обязанностей и разделение ответственности. Чтобы потом небыло «я поручил этим тупицам написать гугл за пару ночей, а они не справились!».
Согласен в целом с тем что вы описали.
Лично мое мнение — эффективнее когда все работают со всеми, и каждый имеет право голоса. То есть ПМ ставит задачи напрямую команде совместно с тех-лидом. И спрашивает с каждого члена команды, опять же в связке с техлидом. Для этого конечно важно чтобы ПМ и Техлид отлично друг друга понимали и эффективно взаимодействовали. Плюсы же в том что исключается один уровень передачи информации, больше коммуникаций и открытости. Но это лично мое мнение, работать разумеется будет не везде.
И только тех-лид отвечает перед ПМ-ом по срокам, срывам и прочим радостям.
Лично мое мнение — эффективнее когда все работают со всеми, и каждый имеет право голоса. То есть ПМ ставит задачи напрямую команде совместно с тех-лидом. И спрашивает с каждого члена команды, опять же в связке с техлидом. Для этого конечно важно чтобы ПМ и Техлид отлично друг друга понимали и эффективно взаимодействовали. Плюсы же в том что исключается один уровень передачи информации, больше коммуникаций и открытости. Но это лично мое мнение, работать разумеется будет не везде.
Описанное вами возможно только тогда, когда ПМ является частью команды разработки. Такое тоже возможно, но не всегда именно так оно и есть. А если ПМ не является частью команды — он может ровным счетом ничего не знать о компетенциях каждого члена команды. Более того, это и не нужно. Для него ресурс — продуктовая команда, а не участник этой команды. Адресная постановка задач в этом случае становится невозможной.
В остальном — очень тяжело спорить о необходимости налаженных коммуникаций ))) Да, без них вообще ничего никуда не взлетит.
В остальном — очень тяжело спорить о необходимости налаженных коммуникаций ))) Да, без них вообще ничего никуда не взлетит.
Склонен считать что нормального управления на бумажке с ресурсами не получится. Поэтому выступаю за то чтобы как раз знать максимально о членах команды, и ресурсами воспринимать именно членов команды, ставя им задачи. У тимлида и без этого задач хватает.
Оба подхода имеют место быть, но я за то чтобы выстраивать все горизонтально, без лишних уровней.
Оба подхода имеют место быть, но я за то чтобы выстраивать все горизонтально, без лишних уровней.
А если ПМ не является частью команды — он может ровным счетом ничего не знать о компетенциях каждого члена команды
А как ПМ сможет, например, спрогнозировать сроки выполнения тех или иных задач, если он не в курсе про компетенции команды? Техлид ведь именно техлид, микроменеджмент задач и контроль их сроков, это в общем случае не его ответственность. Поэтому ПМ здесь коммуницирует непосредственно с исполнителями, либо, если там на проекте много уровней, с соответствующими линейными руководителями подразделений.
А ПМ, если он сам не вышел из разработки, не сможет спрогнозировать сроки ровным счетом НИКАК. То-есть, для первичной оценки ему в любом случае нужен технический специалист(ы). Ну а дальше вы описываете ровно те два случая
про которые говорил я. Если честно, никаких противоречий не вижу. Просто изначально вы рассмотрели только один из двух (не факт) возможных вариантов.
UPD: ну и да, ничто не мешает быть ПМу еще и тех-лидом. Если хватает компетенций. Но, опять же, это частный случай, при котором есть и ПМ и тех-лид, просто они присутствуют в одном лице.
Поэтому ПМ здесь коммуницирует непосредственно с исполнителями, либо...
про которые говорил я. Если честно, никаких противоречий не вижу. Просто изначально вы рассмотрели только один из двух (не факт) возможных вариантов.
UPD: ну и да, ничто не мешает быть ПМу еще и тех-лидом. Если хватает компетенций. Но, опять же, это частный случай, при котором есть и ПМ и тех-лид, просто они присутствуют в одном лице.
ну и да, ничто не мешает быть ПМу еще и тех-лидом. Если хватает компетенций.
Это мое профессиональное хобби — исследовать насколько много специалистов которые могут совмещать, и как они к этому пришли. Пока выводы сводятся к тому что таких людей катастрофически мало, и это зачастую талантливейшие профессионалы. И компании которые таких хотят зачастую сталкиваются с трудностями. Ну или берут человека который явно проседает по каким либо из компетенций.
А ПМ, если он сам не вышел из разработки, не сможет спрогнозировать сроки ровным счетом НИКАК. То-есть, для первичной оценки ему в любом случае нужен технический специалист(ы). Ну а дальше вы описываете ровно те два случая
Согласен, в прогнозах ПМ опирается исключительно на техлида, или команду разработчиков если его нет. Но он таки может какие-то вещи понимать, особенно когда команда уже сплотилась — например оценивать разработчиков с точки зрения софт-скиллов — что собственно его непосредственная обязанность. А также понимать что они делают на начальном уровне — где ему нужна общая техническая грамотность. Ну и разумеется анализировать все с точки зрения пользователя.
Просто с другой стороны, даже если он вышел из разработки, он может а) не знать языки на котором пишется проект; б) быть уже не в теме. В итоге тоже проблематично и нужен техлид.
Не должен он являться членом команды разработки, чтобы коммуницировать с командой. Можно заимствовать практики скрама, когда вся команда без формальных лидов общается с владельцем продукта и сама решает кто какие задачи делает
Верно, если при разработке продукта отсутствуют такие понятия как «подряд», «субподряд» и еще куча разных. А при их наличии, project owner становится для конечных разработчиков величиной практически недосягаемой.
Вот вам простой пример из жизни: есть компании, которые разрабатывают системы для внутреннего использования (финансы, телеком, сырье и так далее). У них есть свой штат разработчиков, несколько ПМов. Часть задач уходит на аутсорс, поскольку задачи огромные, разноплановые и часто требуют различного инструментария, по которому нет компетенций. Подрядчики отдают часть своей работы на субподряд. И тут все замечательные практики скрама отправляются в помойку, поскольку субподрядчик может даже не знать, на кого он в конечном итоге работает. Может ли мой ПМ что-то знать о скилах разработчиков у подрядчика и субподрядчика? Какие он может ставить им задачи директно? Не может и никакие.
Повторюсь: случаи бывают разные, и что хорошо в одном, абсолютно непременимо в другом.
Вот вам простой пример из жизни: есть компании, которые разрабатывают системы для внутреннего использования (финансы, телеком, сырье и так далее). У них есть свой штат разработчиков, несколько ПМов. Часть задач уходит на аутсорс, поскольку задачи огромные, разноплановые и часто требуют различного инструментария, по которому нет компетенций. Подрядчики отдают часть своей работы на субподряд. И тут все замечательные практики скрама отправляются в помойку, поскольку субподрядчик может даже не знать, на кого он в конечном итоге работает. Может ли мой ПМ что-то знать о скилах разработчиков у подрядчика и субподрядчика? Какие он может ставить им задачи директно? Не может и никакие.
Повторюсь: случаи бывают разные, и что хорошо в одном, абсолютно непременимо в другом.
Продукт-оунер это не представитель клиента, конечного бенефициара, это часть команды скрама.
Почему же — субподрядчик может юзать скрам у себя внутри. Продукт-оунер у него свой, который получает все задачи, обсуждает их вносит в бэклог команды.
тут все замечательные практики скрама отправляются в помойку, поскольку субподрядчик может даже не знать, на кого он в конечном итоге работает.
Почему же — субподрядчик может юзать скрам у себя внутри. Продукт-оунер у него свой, который получает все задачи, обсуждает их вносит в бэклог команды.
Продукт-оунер у него свой, который получает все задачи, обсуждает их вносит в бэклог команды.
Задачи в бэклог заносит ПМ. ПО учавствует только в приоритезации.
И вы опять смотрите не с той стороны. Вы говорите о команде субподрядчика, которая юзает у себя скрам, в которой есть Вася и Галя, и которая может делать все как ей больше нравится. А я говорю о команде бенифициара, ПМ которой ничего не знает о Васе и Гале для постановки задач адресно. Для такого ПМа не то что Вася и Галя, для него даже вся команда субподрядчика не является ресурсом.
Задачи в бэклог заносит ПМ. ПО учавствует только в приоритезации.
Откуда ПМ в скраме?
Еще раз — я изначально говорил о проекте, и больше про аутсорс — когда проект выполняет подрядчик, и все что написано это про него. Речь не про продуктовую разработку.
Странная у нас получается дискуссия, я вам про Фому и всех прочих, а вы мне — «А вот у Еремы...»
Обобщу все то, что писал выше:
Скрам, да и вообще аджайл, применим далеко не во всех случаях. Пример я вам привел.
Я как минимум трижды написал про то, что варианты бывают разные. А не только
Ну и тяжело не согласится с отсутствием роли ПМ в скраме. Только вот какой тогда смысл писать про скрам в комментариях статьи, которая про роль ПМа в проектах? Вещи-то несовместимые ;)
UPD: Извиняюсь, не сразу заметил что отвечаю сразу двоим ))
Обобщу все то, что писал выше:
Скрам, да и вообще аджайл, применим далеко не во всех случаях. Пример я вам привел.
Я как минимум трижды написал про то, что варианты бывают разные. А не только
о проекте, и больше про аутсорс — когда проект выполняет подрядчик, и все что написано это про негоВы рассматриваете частный случай, а не все возможные варианты.
Ну и тяжело не согласится с отсутствием роли ПМ в скраме. Только вот какой тогда смысл писать про скрам в комментариях статьи, которая про роль ПМа в проектах? Вещи-то несовместимые ;)
UPD: Извиняюсь, не сразу заметил что отвечаю сразу двоим ))
Ну и тяжело не согласится с отсутствием роли ПМ в скраме.
Я бы сказал, что роль ПМ в большинстве случаев подразумевается в скраме, пускай не чисто по пмбуку, но кто-то должен выполнять такие функции как обеспечение проекта необходимыми ресурсами хотя бы. Мне сложно представить настолько организованную скрам-команду которая ставит в известность (кого?) "мы тут решили, что нам нужен девопс разработчик с экспертными знаниями в области девопс, провели собесы, нашли спеца — обеспечьте его рабочим местом и платите вот такую зарплату, ну и нам повысьте до его уровня, у нас же все равны"
Об этом собственно я писал — что менеджер он есть всегда. В скраме это распределено примерно так: продуктовые вопросы на продакт оунере, вопросы организации, фасилитации, решения проблем — на скрам-мастере, вопросы непосредственно принятия решений, как технических так и нетехнических по разработке — на всей команде, без выделения главного. ПМ по сути во всех.
И да это могут реализовать только оч крутые команды, с высоким скиллом.
Это и ПМ не решает. Это организация условий работы — не часть проекта, это решает по факту работодатель, владелец компании, или кто-то еще. ПМ формируя команду на проект — запрашивает ресурсы, ему их дают, он максимум может поучаствовать в их собеседовании и принятии решения, но это по сути подготовка к проекту, а не сам проект.
Организация подразумевается что работ непосредственно по разработке проекта. Все остальное другие люди делают зачастую, функциональные руководители компании.
И да это могут реализовать только оч крутые команды, с высоким скиллом.
«мы тут решили, что нам нужен девопс разработчик с экспертными знаниями в области девопс, провели собесы, нашли спеца — обеспечьте его рабочим местом и платите вот такую зарплату, ну и нам повысьте до его уровня, у нас же все равны»
Это и ПМ не решает. Это организация условий работы — не часть проекта, это решает по факту работодатель, владелец компании, или кто-то еще. ПМ формируя команду на проект — запрашивает ресурсы, ему их дают, он максимум может поучаствовать в их собеседовании и принятии решения, но это по сути подготовка к проекту, а не сам проект.
Организация подразумевается что работ непосредственно по разработке проекта. Все остальное другие люди делают зачастую, функциональные руководители компании.
Пару раз встречал (один раз участвовал с нуля, другой раз наблюдал со стороны и консультировал), как подготовка проекта заключалась по сути в обсуждении с заказчиком вопроса "цель-бюджет-сроки", в остальном полный карт-бланш: нанимай людей, увольняй людей, арендуй помещения, если хочешь. Договорились — время пошло. Остальные службы компании привлекались ПМом даже не по мере необходимости, а на конкурентной основе с независимыми поставщиками, кроме чисто юридических вопросов — те же кадры лишь оформляли человека, которого в первый раз видели, всем остальным рекрутинговое агентство занималось, а бухгалтерия счета оплачивала. И то, будь нужда у ПМа, думаю, мог бы настоять вообще на отдельном ООО для проекта, со своим штатом, пока в бюджет влезало. Что характерно, оба проекта были успешны, но больше такая практика не применялась. И даже не потому что дорого, а не понравилось топам, что все процессы, решения, замкнуты на ПМе и его правой руке, сами топы ни на что влиять не могут, только уволить ПМа по реальной причине "у нас так не принято". Но с большой вероятностью это потребовало бы перезапуска проекта.
ПМ ни в коем случае не должен обеспечивать проект ресурсами. Он должен ими управлять. Персонал обеспечивают кадры, деньги — бухгалтерия/собственники, инфраструктуру — IT-поддержка, ручки/блокнотики — АХО.
А что касается организованности, если моя команда придет с такими «известиями», они не то что «нам повысьте», они рискуют и без премии остаться, поскольку это, ОЧЕНЬ мягко говоря, совсем не их уровень принятия решений.
А что касается организованности, если моя команда придет с такими «известиями», они не то что «нам повысьте», они рискуют и без премии остаться, поскольку это, ОЧЕНЬ мягко говоря, совсем не их уровень принятия решений.
Смотря что понимать под "обеспечивать". Со стороны команды разработки очень часто именно ПМ обеспечивает всё это. Нужна ручка — говоришь ПМу, а он там как-то разруливает, хочешь повышения ЗП — идешь к ПМу, надоело заниматься настройкой серверов и CI — идешь к ПМу "или нанимайте админа/девопса, или на проекте никого не останется через 2 недели, кто это вообще может сделать". Для команды разработки ПМ часто единственный вход к ресурсам компании. Некоторым ПМам это даже нравится, некоторым нет "ты знаешь кто в компании ручками занимается, пиши заявку — я заапрувлю, если на меня отправят". Некоторые ограничивают себя от ручек вообще, выбивая постоянный апрув для своей команды на мелочевку, даже если в компании так не принято. В общем вариантов может быть множество, но если ПМ не участвует в обеспечении команды ресурсами, то у него, как минимум, могут быть проблемы с авторитетом в командах привыкших работать в иерархических структурах.
Я как минимум трижды написал про то, что варианты бывают разные. А не только
ну так публикация моя ) и обсуждение ведется того что я написал, а я писал про проекты, про продукты вообще не заикался.
Скрам по ходу всплыл, даже и не помню когда именно. Но это разное — согласен, просто опыт у меня есть и в том и в том.
Он начинает свою работу тогда, когда цель продукта уже ясна. Продукт имеет верхнеуровневые требования и некоторые рамки.
Согласен. Возьмём для примера издателя видеоигр, у которого во владении есть несколько игровых студий. Для чего нужен пример? Поясню ниже.
Издатель формирует свою линейку игр. Он решает, что через год или полтора в апреле месяце должна быть выпущена игра по определённой тематике. Таким образом, определяются сроки выпуска игры, длительность её разработки, тематика и, вероятнее всего, есть какие-то прикидки по бюджету. После этого проект стартует.
Но он не решает практически ничего. Да он может влиять на проект через операционку, но не решать. Если он вдруг начинает решать что-то, то это уже не ПМ. Точнее не проэктный-менеджер.
Тут я с Вами не согласен. Ряд игровых студий ставит во главе франшизы (игрового продукта разрабатываемого на основе определённой IP) игрового продюсера. Но ряд других студий ставит во главе проекта (продукта) ПМ. Во втором случае именно ПМ нанимает продюсера, который сформирует облик будущего продукта. Именно ПМ нанимает технических руководителей, которые разработают архитектуру продукта и выберут технологии, при использовании которых продукт будет реализован.
Понятно, что ПМ не будет напрямую вмешиваться как в разработку дизайна продукта, так и в разработку технического дизайна. Но у ПМ есть ограничители — сроки, бюджет и тема.
Второе — быть единым контактным лицом для всех. Вся информация должна проходить через него, иначе сразу начнется бардак. Заказчик договорится с отдельным разработчиком, или предъявит ему баги, тот никому не скажет, баги касаются и других и пошло-поехало.
Если ПМ станет единым контактным лицом для всех, то он быстро превратится в «бутылочное горлышко», в результате чего весь процесс разработки застопорится, т.к. все будут ждать его решения, а он хронически будет не успевать.
Кроме того, он ещё рискует превратиться в «испорченный телефон», т.к. вольно или невольно будет искажать детали задачи. Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую, а в случае необходимости выполнения отдельной задачи, которая не учитывалась при оценке проекта, её нужно вносить в систему контроля задач и помещать в бэклог. Новая задача только тогда поступает на выполнение, когда она согласована ПМ с соответствующим представителем заказчика.
Риски справедливы, но при описанном методе имхо их еще больше.
Во-первых это не их работа. Во-вторых не все умеют. В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях. В таком случае это будет сплошной поток разных договоренностей. Один договорился об одном, другой о другом, что полностью или частично идет в разрез с первой договоренностью из перечисленных и это порождает еще большую неразбериху чем бутылочное горлышко с испорченным телефоном, кстати в случае коммуникации большего количества людей — он портится еще больше.
Переговоры всегда ведет один человек, это не с потолка взято, когда все под контролем у одного менеджера, спрос тоже с него, и вопросы тоже к нему. Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую
Во-первых это не их работа. Во-вторых не все умеют. В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях. В таком случае это будет сплошной поток разных договоренностей. Один договорился об одном, другой о другом, что полностью или частично идет в разрез с первой договоренностью из перечисленных и это порождает еще большую неразбериху чем бутылочное горлышко с испорченным телефоном, кстати в случае коммуникации большего количества людей — он портится еще больше.
Переговоры всегда ведет один человек, это не с потолка взято, когда все под контролем у одного менеджера, спрос тоже с него, и вопросы тоже к нему. Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
Риски справедливы, но при описанном методе имхо их еще больше.
Распределённая работа позволяет убрать эффект «бутылочного горлышка», но требует управления коммуникациями и синхронизацией между членами одной команды и разными командами.
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Во-первых это не их работа.
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами. Если требуется продуктовый менеджер на стороне исполнителя, то согласен — вопросы к продюсеру проекта со стороны заказчика можно задавать через него.
Спорю.
Кто сказал что он будет один? Это в целом другая тема, как управлять в таком масштабе, как дробить команды, есть свои методологии, сейчас не совсем про это, так что опущу.
Вы описываете один конкретный случай из множества возможных. Кто сказал что автор фичи и заказчик одно лицо? Выше уже было обсуждение — я говорил именно о проектах, то есть о то что имеет начало и конец, скоуп и так далее, не продукт. Проект зачастую делают для кого-то внутреннего или внешнего заказчика, и в 90% случаев краткосрочная история разработки. Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее. Он не описывает детально фичу. Это делается на стороне исполнителей на основе условных «хотелок» заказчика. И соответственно с этим надо идти к тому кто руководил процессом — к менеджеру.
Обещать не значит жениться. Должен и делает это разное. Я согласен что в современной разработке это обязательно, но многие ли из них по факту комфортно себя чувствуют в общении и умеют четко доносить свои мысли? Особенно учитывая что это зачастую их прямая обязанность разработка, коммуникация на третьем плане. Еще раз — я не спорю что должен, я лишь утверждаю что практика (моя и коллег) показывает что часто на этом спотыкаются. Многим просто лень подойти к коллеге из другой команды и пообщаться, или в чат ему написать. У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Это один частный случай. Про продюссера ответил выше. Про документацию — в Agile вообще документация стоит ниже по приоритету, согласно принципам. И документация мертва, а древо жизни зеленеет. Живое общение всегда лучше, можно задать вопрос и сразу получить ответ. Также нужно дублировать минимум на два канала, потому что всегда есть вероятность что в документацию не заглянут в нужный момент. Нужно страховаться.
Нет, совсем нет. Продуктовый менеджер занимается стратегией продукта, метриками, он дает фичи в достаточно общем виде, без деталей. В том же Яндексе к примеру ровно наоборот — есть продуктовый, он главный, есть проектный, он занимается операционкой и ежедневной координацией. Ну и я сразу сказал что речь идет про проекты, не про продукты, и про проектных менеджеров. Скоуп работ сроки и ресурсы — из классического PMBok — кто им пользуется в разработке софта? И то это не исключает того что он руководит проектной командой и заботится о коммуникации.
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Кто сказал что он будет один? Это в целом другая тема, как управлять в таком масштабе, как дробить команды, есть свои методологии, сейчас не совсем про это, так что опущу.
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Вы описываете один конкретный случай из множества возможных. Кто сказал что автор фичи и заказчик одно лицо? Выше уже было обсуждение — я говорил именно о проектах, то есть о то что имеет начало и конец, скоуп и так далее, не продукт. Проект зачастую делают для кого-то внутреннего или внешнего заказчика, и в 90% случаев краткосрочная история разработки. Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее. Он не описывает детально фичу. Это делается на стороне исполнителей на основе условных «хотелок» заказчика. И соответственно с этим надо идти к тому кто руководил процессом — к менеджеру.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
Обещать не значит жениться. Должен и делает это разное. Я согласен что в современной разработке это обязательно, но многие ли из них по факту комфортно себя чувствуют в общении и умеют четко доносить свои мысли? Особенно учитывая что это зачастую их прямая обязанность разработка, коммуникация на третьем плане. Еще раз — я не спорю что должен, я лишь утверждаю что практика (моя и коллег) показывает что часто на этом спотыкаются. Многим просто лень подойти к коллеге из другой команды и пообщаться, или в чат ему написать. У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Это один частный случай. Про продюссера ответил выше. Про документацию — в Agile вообще документация стоит ниже по приоритету, согласно принципам. И документация мертва, а древо жизни зеленеет. Живое общение всегда лучше, можно задать вопрос и сразу получить ответ. Также нужно дублировать минимум на два канала, потому что всегда есть вероятность что в документацию не заглянут в нужный момент. Нужно страховаться.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами.
Нет, совсем нет. Продуктовый менеджер занимается стратегией продукта, метриками, он дает фичи в достаточно общем виде, без деталей. В том же Яндексе к примеру ровно наоборот — есть продуктовый, он главный, есть проектный, он занимается операционкой и ежедневной координацией. Ну и я сразу сказал что речь идет про проекты, не про продукты, и про проектных менеджеров. Скоуп работ сроки и ресурсы — из классического PMBok — кто им пользуется в разработке софта? И то это не исключает того что он руководит проектной командой и заботится о коммуникации.
Вы описываете один конкретный случай из множества возможных.
Я привёл лишь пример, при котором предлагаемая Вами схема коммуникации очень быстро будет перегружена.
Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее.
Я с этим не спорю. Я лишь показываю, что в качестве Заказчика может выступать коллектив людей, и эти люди могут иметь разную специализацию.
У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Этот пример показывает, насколько важно налаживать коммуникацию между представителями Заказчика и представителями Исполнителя. Входе реализации проекта коммуникациями нужно управлять, а не замыкать их на одного или нескольких менеджеров. Нужно устанавливать горизонтальные связи «специалист — специалист».
И документация мертва, а древо жизни зеленеет.
Если документация выполнила свою задачу, и в неё больше никто не заглядывает, то её бесполезно менять. Другой вопрос — должны последовать изменения, которые затрагивают работу других людей. Например, изменены условия задачи для программиста (или поставлена другая задача), а также — должны быть обновлены тест-кейсы. Последовательность и каналы информирования других заинтересованных лиц должны быть предусмотрены в плане коммуникаций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем нужен менеджер в IT проекте и что будет происходить когда его нет