Надеюсь, вы не считаете, что предсказуемость может быть обеспечена только по Scrum ))) Есть и другие методологии, даже более эффективные на предмет предсказуемости.
Просто молиться на аджайл, скрам (как это у нас любят) — бессмысленно.
аджайл вообще малоэффективен по поводу оценок
PMBOK (например) описывает методики оценки (parametric, three-point-estimate, .... etc), поэтому можно не изобретать велосипед.
Есть такая штука — ROM, ее используют в начале проекта для получения «грубой» оценки. Т.е. тот же ПМ может это сделать. Но когда мы говорим о точных оценках, после уточнения требований, оценивают (что логично) разработчики. ПМ может дополнительно закладывать свои оценки на проджект менеджмент — риски, коммуникации, планирование. QA — на качество. .... etc. Т.е. каждый оценивает СВОИ задачи в проекте.
Быть абсолютным профессионалом в оценках не получится — тут и технологии разные, и проекты разные. Если у компании один продукт — например, Magento, и движок используется для интернет магазинов, то здесь проще. То есть если вы набили руку в оценках в веб-технологиях, это не означает, что сможете оценить embedded-проект.Для этого и придуманы инструменты, помогающие снизить риск недо-, пере-оценки.
Человеку свойственно ошибаться, и девелоперу тоже. Статистический анализ — это круто, но главное, чтоб оценивал тот, кто будет выполнять задачу. Если, например, разработчик перекладывает свои задачи оценки на ПМа, то, наверное, он что-то неверно понимает. А Макконнелла всем полезно читать (и не только о программировании).
«Самоорганизующиеся команды» — научная фантастика в IT (конек скрам-проповедников). Но мечтать никто не запрещает... А вообще очень напоминает анархию.
интересный пост
но считают себя знатоками млин
Не люблю корпоративы, но приходится ходить, потому что айчары внимательно следят за этим — они же эти мероприятия организовывают, потому болезненно реагируют на игнор. Вроде как не обязаловка, но и не пойти нельзя. Конкурсы дурацкие ненавижу. Но всем ведь не угодишь...
зачем? наверное, затем, что для успешных проектов, приносящих прибыль, одних только программистов недостаточно — сам по себе код ничего не стоит
переживать надо другим айтишникам, и то — не всегда
Иногда так поступают, чтобы специально погрузить кандидата в состояние стресса (у нас не умеют проводить такие собеседования, но многие пытаются). Но при нынешнем дефиците разработчиков, сейчас на такое вряд ли кто решится. Это либо очень уверенная в себе компания, либо иди.отизм/бардак... Во второе верится больше.
Но в данном случае это скорее актуально для разработчиков, работающих в Magento, чем для всех.
Вариант 3. Кому-то очень не хочется читать негативные комменты о себе. Поэтому хотят знать «врагов» в лицо )
Еще в
Но время изменилось, ведь успех проекта сегодня обеспечивают далеко не только разработчики, на первое место в профессии ПМа выходят коммуникации и customer service (особенно в аутсорсе), — что чаще гораздо важнее technical skills.
Не знаю, причем здесь Гарвард (HBS ? :)), но я имел ввиду другое:IMHO тестировщики, программисты, ...(прочие айтишники)... могут быть Пмами, но необязательно должны быть именно они.
Основы программирования и баз данных, понимание ключевых технологий (совершенно необязательно знать их досконально) — может, это утрировано, но больше не надо, плюс желание и возможность самостоятельно повышать свой уровень знаний технологий и пр. Раз в несколько месяцев появляются новые технологии, ПМ всегда будет отставать от них, и отстанет навсегда, т.к. в менеджменте своей «техники» достаточно.
По поводу тех.лидов, если команда небольшая, то тех. лида вообще может не быть. Есть, например, архитектор на стороне клиента. ПМ все равно не сможет заменить этих спецов. Вопрос в том, занимается ли ПМ, собственно, своей работой или делает ее за других (причем, вместо основных функций), повышая при этом риски в проекте? Или для вас идеальный ПМ, видимо, это «ПМ-аналитик-архитектор-девелопер-тестер-...», т.е. шизофреник? ))
О каких правилах речь? Кто их придумал, утвердил? Лично вы? :)Мне кажется, вы склонны считать исключением все, что отличается от вашего опыта )) Так можно вообще любой пример считать исключением ))
Не знаю, где в моих комментах вы нашли TW )), но я имел ввиду людей, которые могут приходить вообще не из IT сферы. ИМХО они даже лучше справляются с работой ПМа, чем «отягощенные бэкграундом», т.к. вносят свежий взгляд на решение обыденных проблем (конечно, еще есть компании, в которых считается, что основные задачи Пма — это ревью кода, архитектура, паттерны, тестирование и пр. — тут либо фундамент конторы шатается, и экономят на всем, либо неправильно называется должность). У них нет «запасного аэродрома» («а вдруг не справлюсь, то вернусь к работе девелопера/тестировщика/....») - т.е. рисков в карьере больше, поэтому и более ответственно относятся к своей работе. Т.е. думать как менеджер они начинают гораздо быстрее :)) И менторинг здесь будет только помогать. И я только за, чтоб такие люди приходили в IT.
По собственным наблюдениям, у некоторых разработчиков на новой должности ПМ адаптационный период может занимать от нескольких месяцев до года (у тестировщиков, аналитиков — быстрее), в течение этого периода к ним приходит озарение, — что, менеджменту, оказывается (!), тоже нужно учиться, и что их задачи теперь находятся совершенно в другой плоскости, а их заслуги в дотнете уже никому неинтересны.
Насчет имен, — их много. К примеру, недавно на DOU было интервью с Лилией Вершининой. Лично с ней незнаком, к сожалению.
Успешная карьера может складываться совершенно по-разному.
Вы не поверите, но есть много ПМов в IT, которые не были ни программистами, ни тестировщиками, ни аналитиками. И от этого они не хуже менеджеры. Возможно, потому, что они занимаются работой ПМа, а не всем, чем придется, как сегодня модно.
Учителя сейчас все, в основном, предпенсионного возраста. Если бы было легко уйти и устроиться на другую работу — все бы уже это сделали. А молодежь в школах не задерживается.
даже «старый» RUP в этом плане интереснее, потому что вначале определено, что должно быть в итоге. в скраме пытаются угодить всем, изобрести абсолютно гибкий звездолет, в итоге — получается мопед, а клиенту нужен был автомобиль. главное — ездит...