Комментарии 77
НЛО прилетело и опубликовало эту надпись здесь
С этим-то проблем, как правило, нет, т.к. у человека, как минимум, хватает смелости/наглости считать, что из него выйдет хороший пм. Особенно это касается девочек-выпускниц it-факультетов. Для себя я решил, что пм женщины пусть работают с кем угодно, но только не со мной +)
Я с вами не согласен! Первый пункт самый важный — многие если не все IT проекты страдают от недостатка времени на их выполнение. А уже время на выполнение зависит от кучу других параметров, перечисленных ниже.
НЛО прилетело и опубликовало эту надпись здесь
В очередной раз открываю подобные статьи с целью увидеть что-то новое и в очередной раз понимаю что убил очередные 5 минут моего времени!
вы не должны убивать время на чтение подобных материалов, если все давно уже поняли и качественно применяете на практике.
А если вы все это уже читали, а на практике не получается, и теперь считаете что только убиваете на это лишние 5 минут, бросьте вообще идею стать хорошим манагером проектов
А если вы все это уже читали, а на практике не получается, и теперь считаете что только убиваете на это лишние 5 минут, бросьте вообще идею стать хорошим манагером проектов
НЛО прилетело и опубликовало эту надпись здесь
Серебряная пуля пролетела мимо? :)
Мне кажется в России у менеджеров проектов распространенных ошибок много больше, чем описал автор. =)
Ошибки это хорошо, а пути их решения или как их избежать?
Вот вопрос: в софтверных компаниях пээмы, как правило, вырастают из разработчиков. кодер -> программер -> тимлид -> пээм. Понятно бывают исключения, но в пределах статистической погрешности.
Внимание вопрос: почему такие умные замечательные разработчики, которые становятся такими безграмотными пээмами?
Я понимаю почему «хороший разработчик»!=«хороший пээм» с точки зрения менеджерских качеств. Но в данном топике меня задело — «чаще читают разработчики». Пээмы же не с другой планеты приходят.
Внимание вопрос: почему такие умные замечательные разработчики, которые становятся такими безграмотными пээмами?
Я понимаю почему «хороший разработчик»!=«хороший пээм» с точки зрения менеджерских качеств. Но в данном топике меня задело — «чаще читают разработчики». Пээмы же не с другой планеты приходят.
>почему такие умные замечательные разработчики, которые становятся такими безграмотными пээмами?
Потому что для того, чтобы быть грамотным ПМом, недостаточно быть умным и замечательным разработчиком, нужно иметь те самые пресловутые «менеджерские качества». Причём не вместо девелоперских скиллов, а в дополнение к ним — это ключевой момент.
>Пээмы же не с другой планеты приходят.
К сожалению, иногда именно оттуда. Мне как-то на полном серьёзе пришлось объяснять своему ПМу (менеджеру проекта в софтверной компании, курировавшему разработку коммуникационного приложения) разницу между личным сообщением в соц.сети и обычным е-мейлом.
Потому что для того, чтобы быть грамотным ПМом, недостаточно быть умным и замечательным разработчиком, нужно иметь те самые пресловутые «менеджерские качества». Причём не вместо девелоперских скиллов, а в дополнение к ним — это ключевой момент.
>Пээмы же не с другой планеты приходят.
К сожалению, иногда именно оттуда. Мне как-то на полном серьёзе пришлось объяснять своему ПМу (менеджеру проекта в софтверной компании, курировавшему разработку коммуникационного приложения) разницу между личным сообщением в соц.сети и обычным е-мейлом.
Потому что работа ПМ имеет намного больше неопределенностей чем работа разработчика. Не всем удается сохранить ясность мысли при кажущихся противоречиях. Плюс сильно больше параметров надо отслеживать. И нельзя попробовать-окомпелировать-исправить, ошибки вылазят сильно позже. Ну и так далее…
Потому что каждый поднимается до уровня своей некомпетентности, согласно Мерфи.
Чтобы быть хорошим девелопером, нужно быть хорошим девелопером. Чтобы быть эффективным PM, нужно быть жесточайшим управленцем/упёртым фашистом/человеком без частички души etc.
Чтобы быть хорошим девелопером, нужно быть хорошим девелопером. Чтобы быть эффективным PM, нужно быть жесточайшим управленцем/упёртым фашистом/человеком без частички души etc.
нет, не получится из такого биоробота хорошего пээма
тем более, опять же статистика за меня, человек знающий предметную область с самого низа — гораздо более эффективен на руководящем посту, чем человек из другой отрасли пусть и эмбиэй
исключения конечно же бывают
тем более, опять же статистика за меня, человек знающий предметную область с самого низа — гораздо более эффективен на руководящем посту, чем человек из другой отрасли пусть и эмбиэй
исключения конечно же бывают
Тут опять же палка о двух концах.
Либо мы из хорошего «низовщика» получаем неплохого PM, но c очень большой вероятностью его нельзя будет перекинуть на другие отрасли, либо мы берём управленца, который не досконально знает «низовые» технологии, но зато может быть универсальным.
В случае конкретного/остальных проектов эффективность первого оцениваем на 4+/2, в случае второго на 3+/3+. Что лучше?
Либо мы из хорошего «низовщика» получаем неплохого PM, но c очень большой вероятностью его нельзя будет перекинуть на другие отрасли, либо мы берём управленца, который не досконально знает «низовые» технологии, но зато может быть универсальным.
В случае конкретного/остальных проектов эффективность первого оцениваем на 4+/2, в случае второго на 3+/3+. Что лучше?
доскональное знаний технологий отрасли, тем более в ИТ, пээм теряет чуть позже чем сразу после вступления в должность: но он всё равно знает тонкости бизнес-процессов, которые управленец со стороны знать не может в принципе
как правило, сильные пээмы, о которых слагают легенды и создавшие проекты высокого класса, являются как раз «выращенными»
как правило, сильные пээмы, о которых слагают легенды и создавшие проекты высокого класса, являются как раз «выращенными»
это в вас говорит неудачный опыт общения с ПМами или самокритичность? :)
Неудачный опыт с «выросшими» PM.
Сейчас я в роли GM рулю вот такими вот PM, и понимаю, что дешевле и эффективнее набрать «чикагских мальчиков».
Сейчас я в роли GM рулю вот такими вот PM, и понимаю, что дешевле и эффективнее набрать «чикагских мальчиков».
Формально говоря, это принцип Питера, который гласит, что «В иерархической системе любой работник поднимается до уровня своей некомпетентности».
Кстати, эту книжку иммет смысл прочитать всем, кто работает, либо планирует работать в крупной организации. Душевных метатаний станет меньше на порядок. www.lib.ru/DPEOPLE/PITER/piter.txt
Кстати, эту книжку иммет смысл прочитать всем, кто работает, либо планирует работать в крупной организации. Душевных метатаний станет меньше на порядок. www.lib.ru/DPEOPLE/PITER/piter.txt
в ссылках к оригиналу нашел статью "Забудь о разработки с помощью надежды" того же автора. Улыбнуло не только HDD=Hope Driven Development, а первый абзац — «пойдёте ли вы на войну без шлема? будете ли вести машину не пристегнувшись?» — дальше читать не стал: буржуйские правила у нас еще долго работать не будут
эх… опять своим путем идти придется
эх… опять своим путем идти придется
Не сложно получить на хабре много плюсов рассказав в очередной раз какие идиоты бывают менеджеры и как важно слушать программистов и обеспечивать их всем необходимым.
Об этом пишется намного больше чем об обратной проблеме — когда проекты срываются программистами — или из за их низкой квалификации, или из за стремления рисковать, играться с новыми технологиями…
Или такого не бывает?
Об этом пишется намного больше чем об обратной проблеме — когда проекты срываются программистами — или из за их низкой квалификации, или из за стремления рисковать, играться с новыми технологиями…
Или такого не бывает?
обе эти проблемы решаются пмами, на то они и существуют.
Как попали люди с недостаточной квалификацией в команду? «Стремление рисковать» само по себе вреда ходу проекта не наносит, кто эти рискованные решения подтверждает? Кто дал играться с новыми технологиями в ущерб проекту? И последний вопрос — менеджер в такой команде это, выходит, тот кто подходит со спины три раза в день и спрашивает «Когда будет готово?» Так его легко можно заменить мартышкой с диктофоном.
Получается, что на программистах никакой ответственности?
да, программист в этой конструкции всего лишь инструмент
сложный инструмент, дорогой, но не более
сложный инструмент, дорогой, но не более
По моему как правило это не так. Чаще всего в команде есть программисты с опытом у которых очень большой, если не определяющий вес во многих вопросах:
1. выбор технологий
2. дизайн и архитектура
3. Иногда и методология разработки.
Порой таких официально называют архитекторами, порой нет, но суть та же — множество решений, а значит и ответственности, — на них.
1. выбор технологий
2. дизайн и архитектура
3. Иногда и методология разработки.
Порой таких официально называют архитекторами, порой нет, но суть та же — множество решений, а значит и ответственности, — на них.
так не кто же не говорит, что всё делится на черное и белое
люди такого класса и подчиняться должны пээмам (или кому-то ещё) классом не ниже
управление персоналом — довольно увлекательная и сложная вещь
люди такого класса и подчиняться должны пээмам (или кому-то ещё) классом не ниже
управление персоналом — довольно увлекательная и сложная вещь
Ну в общем да. У нас сейчас так и происходит.
Кстати — PM- может быть
Product Manager — отвечает за требования
Program Manager — отвечает за «логистику»
Project Manager — которого Вы скорее всего имеете ввиду
Кстати — PM- может быть
Product Manager — отвечает за требования
Program Manager — отвечает за «логистику»
Project Manager — которого Вы скорее всего имеете ввиду
в контексте топика обсуждаются именно проджект манагеры, так можно и ПМС к разговору приплести :)
Product Manager — отвечает за продукт (маркетинг, бизнес-требования)
Program Manager — отвечает за программу (группу проектов) для реализации определенной бизнес цели\стратегии
Project Manager — отвечает за проект
Program Manager — отвечает за программу (группу проектов) для реализации определенной бизнес цели\стратегии
Project Manager — отвечает за проект
Архитектор — участник команды, который может защитить своё решение и доказать необходимость реализации идеи
ПМ — участник команды, который может собрать несколько решений в кучу и принять один правильный вариант с точки зрения денег/времени/качества (порядок может меняться, но всегда какой-то из параметров стоит на первом месте)
Много других ролей делают…
И теперь программист:
* Разработчик — участник команды, инженер, способный копать от забора и до обеда, но с умом. По пути он будет копать и вглубь и вширь и найдёт параллельные решения этой задачи и своих прошлых.
* Кодер — участник команды, способный копать от забора и до забора, пока не упрётся во что-нибудь. Ведь и не факт, что в правильную сторону копать будет…
ПМ — участник команды, который может собрать несколько решений в кучу и принять один правильный вариант с точки зрения денег/времени/качества (порядок может меняться, но всегда какой-то из параметров стоит на первом месте)
Много других ролей делают…
И теперь программист:
* Разработчик — участник команды, инженер, способный копать от забора и до обеда, но с умом. По пути он будет копать и вглубь и вширь и найдёт параллельные решения этой задачи и своих прошлых.
* Кодер — участник команды, способный копать от забора и до забора, пока не упрётся во что-нибудь. Ведь и не факт, что в правильную сторону копать будет…
А если менеджера не спросили перед внедрением рискованного решения? Или того хуже сделали вопреки явному запрету?
Кстати, обычно, менеджер по три раза в день спрашивает «когда будет готово», только если сроки, озвученные программистом, уже пропущены пару раз ;-)
Кстати, обычно, менеджер по три раза в день спрашивает «когда будет готово», только если сроки, озвученные программистом, уже пропущены пару раз ;-)
Как вы думаете, как долго после «сделали вопреки» люди могут работать в команде? Под «не спросили» вы, случайно, не имеете ли ввиду «менеджер не в курсе чем занимается команда»?
НЛО прилетело и опубликовало эту надпись здесь
Хороший список.
По первому пункту. Мне кажется, что тут, как бы банально это не звучало, качество в данном вопросе важнее количества. Причем, хорошие сотрудники тянут команду назад сильнее, чем её двигают вперёд плохие.
К примеру, я считаю, что 5 крутых девелоперов будут работать качественнее, быстрее и эффективнее, чем те же 5 крутых + 5 плохих. Потому что
1. Плохим надо будет помогать.
2. За плохими надо будет доделывать.
3. После плохих придется переделывать.
И делать все это придется в урон своим задачам.
По первому пункту. Мне кажется, что тут, как бы банально это не звучало, качество в данном вопросе важнее количества. Причем, хорошие сотрудники тянут команду назад сильнее, чем её двигают вперёд плохие.
К примеру, я считаю, что 5 крутых девелоперов будут работать качественнее, быстрее и эффективнее, чем те же 5 крутых + 5 плохих. Потому что
1. Плохим надо будет помогать.
2. За плохими надо будет доделывать.
3. После плохих придется переделывать.
И делать все это придется в урон своим задачам.
А эти пункты взяты из вашего реального опыта в управлении проектами?
Пункт 4 «все требования к продукту вместе с техническими спецификациями и графиком работ» ДОЛЖНЫ «быть определены и зафиксированы еще в самом начале проекта» на этапе планирования
Вот например мой список который является прямым отрицанием на список обязанностей менеджера:
1. Неумение ставить цели
2. Неспособность к организаторской работе
3. Отсутствие действий, направленных на мотивирование сотрудников
4. Отсутствие системы измерения показателей эффективности
5. Отсутствие действий, направленных на развитие сотрудников
Пункт 4 «все требования к продукту вместе с техническими спецификациями и графиком работ» ДОЛЖНЫ «быть определены и зафиксированы еще в самом начале проекта» на этапе планирования
Вот например мой список который является прямым отрицанием на список обязанностей менеджера:
1. Неумение ставить цели
2. Неспособность к организаторской работе
3. Отсутствие действий, направленных на мотивирование сотрудников
4. Отсутствие системы измерения показателей эффективности
5. Отсутствие действий, направленных на развитие сотрудников
Вообще, это перевод. Но все эти пункты напоминают мне мои и чужие ошибки, да. По той части 4го пункта на которой вы заострили внимание я могу и согласиться — да, должны, без какой-либо фиксации требований работать нельзя. Но жизнь — штука сложная, требования плывут. По разным причинам — по неопытности тех кто эти требования составляет, по причине того что под действием внешних факторов меняются потребности заказчика и т.п. Дыма без огня не бывает. Agile методологии — ответ на изменяющиеся требования.
никакие методологии тут не помогут — оценка impact -> согласование -> новый план
Категоричненько.
в смысле? аргументируйте пожалуйста
Если пересмотр текущих целей проекта осуществляется на регулярной основе (как раз таки «гибкие» методологии), оценка ущерба и согласование изменений бюджетов и сроков не требуются. Вы же рассматриваете только вариант фиксированных требований, сроков и бюджетов.
«пересмотр текущих целей проекта осуществляется на регулярной основе» — это значит что проекта вообще нет, и необходимо создать новый проект с одной целью — «определить цели на будущий проект»
Я и говорю «категоричненько».
Ваше «категоричненько» подходит как неуместный ответ на любое выражение собственной мысли собеседником.
Например, вы старались переводили никому ненужную статью, а я вам одним словам — Категоричненько!
Наверно вы сами ожидали такого ответа на ваш пост, раз лепите его где попало…
Например, вы старались переводили никому ненужную статью, а я вам одним словам — Категоричненько!
Наверно вы сами ожидали такого ответа на ваш пост, раз лепите его где попало…
Ну а что я вам должен ответить, если вы уперлись и не готовы воспринимать какие-либо альтернативные точки зрения? Гибкие методологии успешно используются многими компаниями по всему миру, включая google, phillips, nortel, yahoo, siemens medical solutions, paypal… я могу продолжать вечно. И все эти люди не согласны с вашим «значит что проекта вообще нет», с успешными результатами их труда вы сталкиваетесь каждый день. Смысл спорить? Вы действительно слишком категоричны.
Вы работали во всех этих компаниях?
Любая методология основана не на каком то магическом знании\опыте а на просто логике.
«Если вы не знаете куда идете (цель), то любое место назначение является результатом вашего движения».
Вы: " Скажите я уже пришел?"
Я: «А куда вышли?»
Вы: «Я не знаю куда я шел»
Я: «Вы пришли» или «Вы не пришли» (в зависимости от моего настроения)
То что я написал про создание нового проекта когда непонятна цель проекта — это из PMBOK.
Любая методология основана не на каком то магическом знании\опыте а на просто логике.
«Если вы не знаете куда идете (цель), то любое место назначение является результатом вашего движения».
Вы: " Скажите я уже пришел?"
Я: «А куда вышли?»
Вы: «Я не знаю куда я шел»
Я: «Вы пришли» или «Вы не пришли» (в зависимости от моего настроения)
То что я написал про создание нового проекта когда непонятна цель проекта — это из PMBOK.
Я не работал во всех этих компаниях — это информация, полученная из открытых источников. Какое имеет отношение к вопросу работал я в них или нет? Если уж на то пошло, я работал в таких проектах, и да, были проекты которые заканчивались и успехом и провалом. Пересмотр текущих целей — не есть отсутствие целей, заметьте. И прекратите носиться как с писаной торбой со своим PMBOK.
Очень коротко… но реально все по делу. Все верно. По пункту 2 в работе с клиентом сейчас вообще не оговариваю четких сроков!
Вот например работаю с Германией… никогда не говори что сделаешь за 1 неделю и точка! не поверят, уйдут. Скажи примерно неделю — растяни на 2… итог тебя полюбят(но эту у германии такая особенность)
Вот например работаю с Германией… никогда не говори что сделаешь за 1 неделю и точка! не поверят, уйдут. Скажи примерно неделю — растяни на 2… итог тебя полюбят(но эту у германии такая особенность)
Вы читали PM code of ethics?
Поставьте себя на место заказчик и посмотрите что получится…
Например вам надо отремонтировать квартиру, а бригада вам на ваш законный вопрос «когда по плану закончите с работой?», отвечает — «мы сейчас вообще не оговариваем четких сроков», " Скажем примерно неделю — а растянем на 2"…
Правда здорово!!! :)
Поставьте себя на место заказчик и посмотрите что получится…
Например вам надо отремонтировать квартиру, а бригада вам на ваш законный вопрос «когда по плану закончите с работой?», отвечает — «мы сейчас вообще не оговариваем четких сроков», " Скажем примерно неделю — а растянем на 2"…
Правда здорово!!! :)
НЛО прилетело и опубликовало эту надпись здесь
Да это не более чем catch-phrases, главное — содержание. Эта статья достаточно банальна, но просто каждый пункт мне напоминает одну или несколько ситуаций из моей жизни, потому и решил перевести. Может быть прочтя еще раз одно и то же, кто-то не допустит тех же глупых ошибок.
Ох, иногда проще/результативнее именно не говорить, а книжку или статью подкинуть. Умный человек сам себя узнает и поймет, а с бестолковым и разговор не поможет, только отношения испортятся. Зарубежные классики хорошо помогают — Друкер, например.
+1 Я за личное общение
А если ещё и взаимопонимание достигнуто, то можно и с пивом
А если ещё и взаимопонимание достигнуто, то можно и с пивом
Так, вот не понятно, что в статье. В 4-м пункте написано «4. Контроль вместо делегирования», далее идёт текст самого пункта в котором говорится о том, что делегирование это хорошо, так о чём хотел сказать нам автор о том, что Контролировать вместо Делегирования или что? Этот момент вообще не понял.
Делегирование решений, в свою очередь, делает разработчиков лучше и, обычно, является краеугольным камнем отличного продукта.
Делегирование решений, в свою очередь, делает разработчиков лучше и, обычно, является краеугольным камнем отличного продукта.
Я бы еще добавил: незнание предметной области на уровне разработчика. Столько раз приходилось сталкиваться с тем, что менеджер реально не представляет способов решения задачи и не может прогнозировать время, требуемое на задачу, что в конце концов прекратил работать с менеджерами.
Имхо: лучший менеджер — это человек из среды программистов, который нашел в себе нотку управленца.
Как говорил один преподаватель в институте, а по совместительству — владелец фирмы экономических прогнозов: «Экономистов на работу не беру. Беру математиков, а потом учу их экономике. Это дешевле и эффективнее».
Имхо: лучший менеджер — это человек из среды программистов, который нашел в себе нотку управленца.
Как говорил один преподаватель в институте, а по совместительству — владелец фирмы экономических прогнозов: «Экономистов на работу не беру. Беру математиков, а потом учу их экономике. Это дешевле и эффективнее».
Я бы сказал — не делегировать полномочия, а считаться с идеями разработчика!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 самых распространенных ошибок менеджеров