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