Comments 57
UFO just landed and posted this here
В моём понимании грамотный и правильный ПМ — человек, понимающий проект и знающий, как и что работает. При этом в основном он ставит задачи и разговаривает с менеджментом.
А если ПМ только и занимается индексами производительности и эффективности, то стоит задуматься. Ну а если он при этом совершенно не понимает, как проект, который он ведёт работает или не может адекватно оценить трудозатраты на поставленные задачи, то хреновый он ПМ, и крокодила с ним не поймать, кокос не выростить. В шею его гнать надо.
Когда-то, лет 5 назад я работал в одной компании с директором самодуром и совершенно не понимающими в программировании менеджерами, которые часто ставили задачи программистам. Так вот, в нашей небольшой группе программистов был действительно грамотный ПМ, сглаживающий неровности недопонимания кодеров, работающих по ТЗ и менеджеров, которым лишь бы продать уже разработанный продукт под другим соусом, и пофигу что требуется учитывать специфику и гнаться за сроками. Главное заключить контракт и наобещать с три короба.
Вот кстати от последнего конторка и развалилась. Переобещали малость.
А если ПМ только и занимается индексами производительности и эффективности, то стоит задуматься. Ну а если он при этом совершенно не понимает, как проект, который он ведёт работает или не может адекватно оценить трудозатраты на поставленные задачи, то хреновый он ПМ, и крокодила с ним не поймать, кокос не выростить. В шею его гнать надо.
Когда-то, лет 5 назад я работал в одной компании с директором самодуром и совершенно не понимающими в программировании менеджерами, которые часто ставили задачи программистам. Так вот, в нашей небольшой группе программистов был действительно грамотный ПМ, сглаживающий неровности недопонимания кодеров, работающих по ТЗ и менеджеров, которым лишь бы продать уже разработанный продукт под другим соусом, и пофигу что требуется учитывать специфику и гнаться за сроками. Главное заключить контракт и наобещать с три короба.
Вот кстати от последнего конторка и развалилась. Переобещали малость.
По верхам…
От «формирования функциональных требований заказчика» переходим сразу к «распределению задач по разработчикам»
Если честно — не увидел особой разницы с диалогом с ПМ-ом который вообще не в курсе
От «формирования функциональных требований заказчика» переходим сразу к «распределению задач по разработчикам»
Если честно — не увидел особой разницы с диалогом с ПМ-ом который вообще не в курсе
Начинаю с выкидывания резюме кандидатов, не имеющих PMI PMP (PRINCE2 Pactitioner) и не знакомых с CMMI. Оставшихся уже зовём на очное собеседование с кейсами. В РФ такая практика у меня приводит к минимуму кандидатов с максимумом эффекта: нанимал человека после собеседований максимумум 4-5-ти кандидатов. В Европе кандидатов приходит значительно больше, среди них больше неопытных (буквально сразу после вуза), но зато можно найти несколько относительно недорогих сотрудников с горящими глазами, которые будут хорошо вести проекты (под руководством наставника).
Никогда не пробовал, но можно взять в сервис PM'а из IT компании, которая специализируется на разработке ПО. Думаю, что это будет хорошим вариантом для небольших компаний с небольшими проектами.
Никогда не пробовал, но можно взять в сервис PM'а из IT компании, которая специализируется на разработке ПО. Думаю, что это будет хорошим вариантом для небольших компаний с небольшими проектами.
PMI, CMMI… Ну да, когда надо оставить 4-5 из 100 резюме, то любой метод подходит. Можно просто выкинуть случайные. А что, компании не нужны неудачники :)
Я вот нанимал вообще с одного вопроса/ответа кандидату, даже не смотря в резюме. И очень доволен. Но глубокомысленных выводов не делаю, слава богу.
PMBok задает структуру знаниям об управлении проектами. Вводит язык. Этот корпус знаний формировался десятилетиями. Мне было бы странно, если бы человек серьезно подходящий к профессии ПМа игнорировал бы PMBok.
Знание PMBok позволит избежать недопонимания в ходе общения.
А вообще про вопросы. Адекватность ПМа проверяется одним вопросом: «С чего начинается проект?». Большая часть неадекватов будет выявлена на этом этапе.
Знание PMBok позволит избежать недопонимания в ходе общения.
А вообще про вопросы. Адекватность ПМа проверяется одним вопросом: «С чего начинается проект?». Большая часть неадекватов будет выявлена на этом этапе.
Просто у MMik в одном абзаце говориться про отсеивание не имеющих сертификат PMP (а имеющих сертификат PMP на всю Россию дай бог 1,5 тыщи человек), а дальше упоминаются «недорогие сотрудники». Сочетание требований забавное. Конкурс на должность суровый, наверное условия сказочные.
Отсеиваем не имеющих PMP в России (и платим им много), а недорогих вчерашних студентов с PMP получаем в Европе — там в некоторых вузах нарабатывают часы проектного управления и сдают экзамены. С сочетанием требований в том абзаце всё отлично.
С точки зрения наличия ачивки PMP — отличный лайфхак. С точки зрения «шашечки или ехать» — не очевидное решение.
Шашечки и ехать. С вашей же оценкой российского рынка в 1,5 тысячи человек с PMP, нам вполне удаётся находить в нем для себя 4-6 человек в год. Плюс несколько внутренних кандидатов, и нам хватает закрыть потребности.
Заказчики приветствуют наличие ачивок у наших специалистов. Сама сертификация вполне доступна. Все в выигрыше.
Заказчики приветствуют наличие ачивок у наших специалистов. Сама сертификация вполне доступна. Все в выигрыше.
Мне много раз приходилось работать с ПМ без ИТ знаний, и я почти всегда был доволен, при этом находился в разных ролях и в том числе как ПМ проекта в портфеле как раз такого ПМ без ИТ знании. После работы с опытными ПМ лично я для себя понял, управление проектами это не какой-то второстепенный скил и он не приходит с опытом просто потому что ты разработчик, архитектор и т.д. этому надо учиться.
А разве главная задача ПМ-а не управление бюджетом?
Управление ресурсами
Нет. Задача ПМ обеспечить, чтобы проект был внутри треугольника: срок, бюджет, содержание (качество) + заказчик должен быть доволен.
Понасмотрелись уже на этих эффективных менеджеров. Зачем вообще браться за внедрение чего-либо о чем очень отдаленное представление имеешь, особенно в ИТ?
Я, честно говоря, не вижу никаких причин, почему в ИТ не справился бы ПМ с опытом работы в другой отрасли. Вы так описали кейсы, как будто бы у вас не чувак с опытом управления людьми, а дитя неразумное. В реальной жизни ПМ, приходя в ИТ из строительства, логистики, станкостроения или любой другой отрасли, сядет и прочтет книгу «Методологии управления проектами в ИТ», и после этого он будет знать ответы на указанные вопросы, и сможет приступать к работе.
Вот такие, которые прочитали книжки, а руками ничего в своей жизни никогда не трогали из ИТ тематики (даже эникеями не работали) как раз и топят на дно ИТ проекты. Наличие профессионального фотоаппарата не делает человека профессиональным фотографом.
В чем принципиальное отличие в управлении проектами в различных отраслях?
Только в специфике производства и дистрибуции готового продукта?
Выпуск в продакшн готовой комплексной системы это тоже своего рода процесс дистрибуции. Да, вероятнее данный проект будет уникальным или будет иметь малое количество возможность к репликации.
А еще какие отличия? Всё те же этапы и все те же роли в команде. Называются просто по разному.
У меня огромная просьба к сообществу не придумываете себе искусственный мирок элитарности. И разработчики и эникейщики и хелпдескеры и девопсы и пмщики и маркетологи и прочие. Понимаете ваши знания специфики не является уникальным преимуществом. Ваше умение эффективно применять ваши знания о специфике является вашим уникальным преимуществом.
Только в специфике производства и дистрибуции готового продукта?
Выпуск в продакшн готовой комплексной системы это тоже своего рода процесс дистрибуции. Да, вероятнее данный проект будет уникальным или будет иметь малое количество возможность к репликации.
А еще какие отличия? Всё те же этапы и все те же роли в команде. Называются просто по разному.
У меня огромная просьба к сообществу не придумываете себе искусственный мирок элитарности. И разработчики и эникейщики и хелпдескеры и девопсы и пмщики и маркетологи и прочие. Понимаете ваши знания специфики не является уникальным преимуществом. Ваше умение эффективно применять ваши знания о специфике является вашим уникальным преимуществом.
Т.е. нет разницы в проектах создания Буратино и Модели Буратино, я правильно понял? Как строить Буратин изучали с того момента как люди спустились с деревьев, а вот строить модели каких-то несколько десятков лет, вот вам и специфика и пропасть различий между ними.
Построить пирамиду и построить жилой многоквартирный дом, кроме специфики применяемых технологий есть отличия?
Произвести программный межсетевой экран и тот же межсетевой экран накатанный на железку какие отличия?
Внедрение комплексной системы для торговли и внедрение комплексной системы для архивного дела?
Производство танкера для транспортировки газа и производство авианосца?
В чем технологические отличия кроме специфики производимых работ?
Архитектор как-то по особенному производит расчеты?
Конструктора делают расчеты по особым уникальным методикам? Какие-то особые таблицы по материалам? Особые законы природы на каждом квадратном метре планете? Скорость света в двух соседних и одинаковых по составах кубах морской воды будет отличаться?
Я к тому, что глобально отличий нет. Производство продукции в любых отраслях уникальное, но глобально управление производством продукции одинаковое. И разработчик программного обеспечения и тот кто занимается развитием и поддержанием комплексной информационной системы и телеком оператор это все производители «готового продукта».
Произвести программный межсетевой экран и тот же межсетевой экран накатанный на железку какие отличия?
Внедрение комплексной системы для торговли и внедрение комплексной системы для архивного дела?
Производство танкера для транспортировки газа и производство авианосца?
В чем технологические отличия кроме специфики производимых работ?
Архитектор как-то по особенному производит расчеты?
Конструктора делают расчеты по особым уникальным методикам? Какие-то особые таблицы по материалам? Особые законы природы на каждом квадратном метре планете? Скорость света в двух соседних и одинаковых по составах кубах морской воды будет отличаться?
Я к тому, что глобально отличий нет. Производство продукции в любых отраслях уникальное, но глобально управление производством продукции одинаковое. И разработчик программного обеспечения и тот кто занимается развитием и поддержанием комплексной информационной системы и телеком оператор это все производители «готового продукта».
Построить пирамиду и построить жилой многоквартирный дом, кроме специфики применяемых технологий есть отличия?
Это один и тот же объект материального мира. А я сравниваю проектирование реального мира (Буратино) и виртуального (модель Буратино) и если вы не видите различий я не понимаю предмета вашего обсуждения.
Расскажите же, в чём отличие. Я в упор не понимаю, чем последовательность работ «составить модель БД», «разработать дизайн UI», «разработать такой-то API», «реализовать такой-то сервис», «разработать тесты» и т.д. в управлении отличается от последовательности работ «провести геодезическую разведку», «вырыть котлован», «вдавить сваи», «залить ростверки», «сварить арматуру нулевого этажа» и т.д.?
Тем, что во втором случае будет меньше правок по обратной связи? Ну так это просто фича, которую нужно иметь в виду, она на саму методику управления не влияет.
Нет, не топят. Есть плохие управленцы, есть хорошие. Плохой утопит, даже если он всю жизнь только в ИТ проработал. Хороший не утопит, даже если ему на компьютере секретарь тексты набирает. Тем более что ПМу навык из молодости обжимать витую пару и ставить винду примерно так же полезен, как навык плести макроме.
Тем, что во втором случае будет меньше правок по обратной связи? Ну так это просто фича, которую нужно иметь в виду, она на саму методику управления не влияет.
Вот такие, которые прочитали книжки, а руками ничего в своей жизни никогда не трогали из ИТ тематики (даже эникеями не работали) как раз и топят на дно ИТ проекты.
Нет, не топят. Есть плохие управленцы, есть хорошие. Плохой утопит, даже если он всю жизнь только в ИТ проработал. Хороший не утопит, даже если ему на компьютере секретарь тексты набирает. Тем более что ПМу навык из молодости обжимать витую пару и ставить винду примерно так же полезен, как навык плести макроме.
Согласен, макроме имеет такое же отношение, как и ИТ к ПМ. Очень жаль, что мало кто этого понимает. Эффективными менеджерами уже наелись, теперь очередь специализированных ПМ'ов. Внутри своей компании пусть хоть все по очереди ПМами будут и это иногда даже работает.
Да, давайте ещё доказывать, что ИТ-проекты настолько исключительны и необычны, что ими надо управлять каким-то особенным, доступным лишь избранным, способом. Как будто инженер-архитектор или инженер-электронщик, или инженер, проектирующий лыжи, это люди какого-то иного сорта, который поддаётся традиционному управлению, а разработка софта — ни-ни.
В отличие от строительных и производственных проектов у ИТ-проектов нет нормативов затрат для типовых операций, да и сами типовые операции являются таковыми лишь очень укрупнённо и в рамках схожих проектов
В отличие от строительных и производственных проектов у ИТ-проектов нет нормативов затрат для типовых операций
Это миф. Весьма распространённый. В софтверных ИТ-проектах планирование даже легче, чем, например, в строительстве. У нас основную долю затрат составляет всего один ресурс — человеческий. Непрогнозируемая творческая составляющая? Бывает. Иногда. В одном из десяти проектов в лучшем случае. Остальные 90% прекрасно нормируются. Вы разве не можете прикинуть, сколько времени нужно для написания десяти моделей по десять полей? А десяти форм к ним с известными правилами валидации?
Боитесь, что оценка будет неточной? А чего бояться? Это нормально, и это везде. Вы думаете, на стройке будет точная оценка? Да там всё то же самое. Вон, грунт в котловане поплыл, понадобились неучтённые работы по водоотводу и дополнительному укреплению стен котлована. На экскаваторе патрубок гидравлики лопнул — работы по замене, ожидание. Срыв поставок битума. Подорожал цемент. И т.д., этот самый «эджайл» под изменения на лету есть практически в любом проекте в любой индустрии. Мы ничуть не особенные.
Вы разве не можете прикинуть, сколько времени нужно для написания десяти моделей по десять полей?
Если я не специалист в ИТ (разработке ПО), соответственно не смогу даже близко прикинуть. Также не смогу правильно выбрать технологии которые необходимо применить при разработке.
Если я не специалист в ИТ (разработке ПО), соответственно не смогу даже близко прикинуть. Также не смогу правильно выбрать технологии которые необходимо применить при разработке.
А, я понимаю, в чем ваше заблуждение. Вы просто считаете, что это должен уметь делать человек, который управляет проектом. Нет, вы ошибаетесь. Он это делать не должен, и не делает. Ни в разработке ПО, ни на стройке, ни в других сферах. В разработке ПО для него список задач с оценками готовят тимлиды/сеньоры, на стройке — технологи и сметчики.
Руководитель проекта физически не может быть достаточным экспертом в вопросах оценки сроков и стоимости, если проект не совсем крохотный. Поэтому его задача не в том, чтобы все оценить, а в том, чтобы собрать оценки у профильных экспертов. Согласитесь, не нужно быть гуру в ИТ, чтобы у архитектора БД попросить оценить, сколько ему нужно времени для проектирования БД по данному ТЗ?
Согласитесь, не нужно быть гуру в ИТ, чтобы у архитектора БД попросить оценить, сколько ему нужно времени для проектирования БД по данному ТЗ?
Соглашусь что гуру не нужно быть.
Поэтому его задача не в том, чтобы все оценить, а в том, чтобы собрать оценки у профильных экспертов.
И как предлагается оценивать оценки профильных экспертов, соответствуют ли они истине без знаний в ИТ?
Откройте PMBoK — там всё написано, не надо изобретать велосипед. Стандартные лучшие практики оценки длительности:
1. Экспертная оценка на основе исторической информации.
2. Оценка по аналогам.
3. Параметрическая оценка — на основе исторических данных с поправкой на данные проекта. Если в прошлый раз 25 метров кабеля прокладывали час, то 1000 метров скорее всего можно проложить за 40 часов.
4. Оценка по трём точкам — используется треугольное или бета-распределение по данным пессимистичной, наиболее вероятной и оптимистичной оценки длительности.
5. Групповые методы — мозговой штурм, метод Делфи, метод номинальных групп.
6. Анализ резервов — ко всему вышеперечисленному добавляем резерв. «резерв на возможные потери может выражаться в процентах от оценочной длительности операций, в фиксированном числе рабочих периодов или может быть рассчитан с помощью методов количественного анализа, например имитации методом Монте-Карло».
Или хотя бы вспомним про народную шутку: длительность, названную программистом, надо умножить на 2, так как программист забыл про тестирование. Если при этом программист собрался использовать новую технологию, то длительность надо умножить на 3.
1. Экспертная оценка на основе исторической информации.
2. Оценка по аналогам.
3. Параметрическая оценка — на основе исторических данных с поправкой на данные проекта. Если в прошлый раз 25 метров кабеля прокладывали час, то 1000 метров скорее всего можно проложить за 40 часов.
4. Оценка по трём точкам — используется треугольное или бета-распределение по данным пессимистичной, наиболее вероятной и оптимистичной оценки длительности.
5. Групповые методы — мозговой штурм, метод Делфи, метод номинальных групп.
6. Анализ резервов — ко всему вышеперечисленному добавляем резерв. «резерв на возможные потери может выражаться в процентах от оценочной длительности операций, в фиксированном числе рабочих периодов или может быть рассчитан с помощью методов количественного анализа, например имитации методом Монте-Карло».
Или хотя бы вспомним про народную шутку: длительность, названную программистом, надо умножить на 2, так как программист забыл про тестирование. Если при этом программист собрался использовать новую технологию, то длительность надо умножить на 3.
UFO just landed and posted this here
Простите, а зачем нам нужен такой пиэм, который даже не может понять смысла слов, которые ему говорят работники и архитекторы
В точку!
Вы видите смысл, которого нет в написанном. PM получает от экспертов список работ и их оценочную продолжительность/стоимость. И для этого достаточно обычного русского языка, конечно желательно с некоторой отраслевой специализацией, но без фанатизма. iSCSI там или FibreChannel, C# или Java — вообще без разницы, это заботы профильных специалистов.
Простите, а зачем нам нужен такой пиэм, который даже не может понять смысла слов
Если он что-то не понимает, он может взять и спросить. Но если он умеет работать с людьми, если он может мотивировать, может организовывать работы, он проект будет двигать. А если он не умеет этого делать, то будь он трижды техническим экспертом, у него ничего не выйдет.
Ага! И респект от команды будет собирать каждый день, как репей на штаны в терновнике
Получит консультацию Архитектора? Который фрагментарно видит свою задачу и не представляет, что «до» и что «после»?
Извините, но чисто терминологически, такой фрагментарно видящий «архитектор» вообще профпригоден?
Конечно нет, тоже удивился с такой формулировки, она скорее всего сделана, для того чтобы выставить ПМ в плохом свете, что никто ему бедному не поможет.
Я бы не хотел быть таким РП, который шарит в технологиях, но всего лишь управляет разработкой и внедрением, хотелось бы быть продакт менеджером и рулить всеми аспектами продукта.
Я бы не хотел быть таким РП, который шарит в технологиях, но всего лишь управляет разработкой и внедрением, хотелось бы быть продакт менеджером и рулить всеми аспектами продукта.
Тут есть тонкая разница между «проектом» и «проектом». Есть проекты, целью которых является нечто имеющее отношение к программированию: новый продукт, новые фичи, пилот новой технологии, и т.д. И руководя этим проектом, ПМ-у будет очень трудно без знания специфики отрасли. Тут нужен «программистский ПМ».
Есть проекты уровнем выше, когда задачи ставятся уже на уровне целого бизнеса. Этот ПМ будет руководить людьми, которые будут руководить людьми, которые будут решать (в том числе) задачи связанные с программированием. Ему уже можно и без особых знаний специфики отрасли жить.
Вообще, многие авторы отмечают, что чем ниже по управленческой лестнице, тем более важны прикладные навыки и особенности отрасли. Чем выше — тем более важно уметь управлять проектами, временем и «ресурсами вообще», и тем больше там управления людьми, чем отраслевых особенностей.
Есть проекты уровнем выше, когда задачи ставятся уже на уровне целого бизнеса. Этот ПМ будет руководить людьми, которые будут руководить людьми, которые будут решать (в том числе) задачи связанные с программированием. Ему уже можно и без особых знаний специфики отрасли жить.
Вообще, многие авторы отмечают, что чем ниже по управленческой лестнице, тем более важны прикладные навыки и особенности отрасли. Чем выше — тем более важно уметь управлять проектами, временем и «ресурсами вообще», и тем больше там управления людьми, чем отраслевых особенностей.
А зачем брать в область ИТ человека, который специализируется на других областях и дока именно в них? Особенно, если мы говорим про частный сектор и госсектор, где все принципиально работает по-другому?
И, честно говоря, если кандидат на должность вашего ПМ не знает ответов на ваши вопросы, он плох не как ПМ в ИТ, а как ПМ в целом. Люди, осилившие книжку и домашний видео-курс по Agile — еще не ПМ…
И, честно говоря, если кандидат на должность вашего ПМ не знает ответов на ваши вопросы, он плох не как ПМ в ИТ, а как ПМ в целом. Люди, осилившие книжку и домашний видео-курс по Agile — еще не ПМ…
Надеялся, что будет статья «какие вопросы нужно задать PM, когда сидишь на собеседовании» ( чтоб убедиться, что перед тобой PM а не "деэффективный менеджер" )
А по сути — не уверен, что команда останется под управлением человека, который не знает и не хочет знать о налаженных бизнес-процессах в команде, а хочет всех рассадить как ему удобно ( потому что я так хочу), пойдёт расскажет в отделе кадров и бухгалтерии, что теперь ОН ТУТ ГЛАВНЫЙ ( чем угробит работу по сокращениям сроков приёма и проверки нового сотрудника для отдела с 2-3 месяцев до недели в госконторе) и организует работу по методологии DDD ( Deadline-driven development).
А по сути — не уверен, что команда останется под управлением человека, который не знает и не хочет знать о налаженных бизнес-процессах в команде, а хочет всех рассадить как ему удобно ( потому что я так хочу), пойдёт расскажет в отделе кадров и бухгалтерии, что теперь ОН ТУТ ГЛАВНЫЙ ( чем угробит работу по сокращениям сроков приёма и проверки нового сотрудника для отдела с 2-3 месяцев до недели в госконторе) и организует работу по методологии DDD ( Deadline-driven development).
Пффф… Мэнспрединг.
- Во-первых не понятно какой из PM-ов имеется ввиду. Project Manager, Product Manager, Program Manager? У каждого из них свои обязанности и свои задачи.
- Во-вторых если все-таки предположить, что Project Manager, то в рамках, например, того же SCRUM такой роли не существует.
Я не считаю подход с вопрос-ответом, способом отбора хороших кандидатов. Как на технические должности, так и на любые другие. Вопросы-ответы можно заучить и то, что человек ответит на собеседовании может никак быть не связанным с тем, как он будет себя вести в условиях реальной работы. Вопросы о том, что человек делал (Context, Action, Result) желательно перекрестно с коллегой, который(ая) расспросит слегка изменив акценты. При этом надо категорически воздерживаться от условного наклонение.
Если человек злоупотребляет спец. терминами — стоит проверить на знание и понимание оных. Если у человека есть опыт или навык, которого нет в нашей компании или наоборот есть, но требуется еще больше — стоит выяснить как он его получил и применил.
Именно Project Manager. Про SCRUM согласен. Даже хотел сделать сноску, что Scrum не трогать :))) Но Project то Leader есть по-любому ;) И часто так бывает, что он же и ScrumMaster. И не будет он «master-ить», если про «стройку» разрабам будет вещать.
Вопросы-ответы можно заучить, конечно. Но ведь вы при этом в глаза ему смотрите. Фиксируете реакцию. Заученную программу видно. При этом обязательно 6е чувство подскажет копнуть. Тут он и зароется
Вопросы-ответы можно заучить, конечно. Но ведь вы при этом в глаза ему смотрите. Фиксируете реакцию. Заученную программу видно. При этом обязательно 6е чувство подскажет копнуть. Тут он и зароется
UFO just landed and posted this here
Друзья, всем СПАСИБО! за полезные комментарии!
Sign up to leave a comment.
Как убедиться в компетенциях ПМа на ИТ-проект?