Здравствуйте, SkyDance, Вы писали:

H>>Желания наказать нет, просто до этого сроки никогда не съезжали.

SD>Буду Станиславским.
SD>НЕ ВЕРЮ.

H>>Были мысли его поменять поскольку получилось так что сейчас есть кандидаты успешно себя проявившие и готовые заниматься проектом

SD>Ага, стало быть, цель — продвинуть кого-то конкретного в РМ'ы. Цель вполне разумная и понятная. Я так понимаю, проблемы только в сложности обоснования такого хода. Есть ли возможность выполнить этот же манёвр, но без радикальных действий вроде увольнения? Например, открыть новый проект или подпроект. Двенадцать человек — немало, их уже можно на две команды поменьше разделить.

Да, с точки зрения увольнения это кардинальная мера. На текущий момент понятно что это делать нежелательно, в частности исходя из ответов на форуме.
Но 2 ПМа на 12 человек это многовато. Там есть Тимлиды для небольших групп, не более 4 человек в группе.

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, hpux100, Вы писали:


H>>Желания наказать нет, просто до этого сроки никогда не съезжали.

B>А раньше такие рефакторинги тоже делали?
B>А вообще не верю, что сроки никогда не съезжали.
B>Может в последнее время, по все по накатанной шло.
B>Но пока дошли до такого состояния наверняка были проколы.

B>Ну а то, что другие ПМы не будут больше косячить — это понятно.
B>Неблагодарная работа уже сделана. Снимать сливки может и другой

Раньше так кардинально не переделывали. Именно в текущий релиз возникла такая необходимость.
Другие ПМы возможно тоже будут косячить. Но обязанность ПМа учесть все риски по возможности и выработать стратегию как снизить их влияние в случае возникновения.
В этом в частности ценность ПМа, за это он и зарплату получает больше чем разработчик. От работы ПМа зависит вся функциональность запланированная на релиз, от разработчика да и Тимлмда только часть. От архитектора тоже часть а именно техническая составляющая, если архитектура дорабатывается. Аналитики выполняют свою часть работы. ПМ должен учесть все входы, выходы, зависимости проанализировать, учесть риски и сказать насколько это возможно выпустить в релизе.

Здравствуйте, hpux100, Вы писали:

H>В этом в частности ценность ПМа, за это он и зарплату получает больше чем разработчик. От работы ПМа зависит вся функциональность запланированная на релиз, от разработчика да и Тимлмда только часть. От архитектора тоже часть а именно техническая составляющая, если архитектура дорабатывается. Аналитики выполняют свою часть работы. ПМ должен учесть все входы, выходы, зависимости проанализировать, учесть риски и сказать насколько это возможно выпустить в релизе.

Понятно... мы кажется ходим по кругу.
ПМ, который типа бога, способного все учесть и предусмотреть — это иллюзия.
Спускайтесь на землю лучше...

Здравствуйте, hpux100, Вы писали:

H>В этом в частности ценность ПМа, за это он и зарплату получает больше чем разработчик.
ПМ редко получает з/п больше, чем опытный разработчик (если это конечно не ПМ олимпийской стройки)...

On 20.12.2012 10:55, bkat wrote:

> ПМ, который типа бога, способного все учесть и предусмотреть — это иллюзия.
> Спускайтесь на землю лучше...
Да тут уже озвучена причина всей это возьни. Нужно продвинуть нужного
человека в ПМ, а тут случай как раз подвернулся. ТС же собирает
аргументы здесь для проведения этой операции.

On 19.12.2012 17:16, hpux100 wrote:

>>> Коллега, это неправильный запас, ибо давно известно что "работа занимает
>>> всё отведённое на неё время". В проектах с несдвигаемым внешним
>>> дедлайном надо назначать срок ОКОНЧАТЕЛЬНОЙ СДАЧИ проекта за X недель до
>>> этого самого дедлайна, а не прибавлять время на отдельные этапы.
> V>Наедешься, что он тебя слышит и понимает?
>
> Прибавление времени уменьшает объем. Это примерно одно и тоже.

Как убедительно показывает ситуация, ставшая темой этого топика, иногда
этого "примерно" достаточно чтобы заставить всех здорово понервничать.

На самом деле это совсем не одно и то же — иметь 2 недели запаса при
сдаче проекта или иметь увеличенную на 2 недели фазу разработки (когда в
вашем случае тестировщики ещё ничего не трогали).

--
WBR,
Serge.

H>Да, с точки зрения увольнения это кардинальная мера. На текущий момент понятно что это делать нежелательно, в частности исходя из ответов на форуме.
H>Но 2 ПМа на 12 человек это многовато. Там есть Тимлиды для небольших групп, не более 4 человек в группе.

Тогда надо разбираться с тем, почему упомянутые кандидаты хотят стать PM'ами. Возможно, они всего лишь требуют повышения оплаты труда, полагая, что РМ получает больше. С такой особенностью я в России сталкивался неоднократно, даже опытные ключевые разработчики получали меньше РМ. Что и вынуждало их превращаться из хорошего разработчика в плохого РМ.

В подобном случае можно попробовать переговоры о повышении оплаты. Если человеку хочется больше ответственности — об увеличении влияния человека на проект (например, допустить его до участия в создании требований, переговорах с заказчиком), при этом бонусы к зарплате рассчитывать по успешному окончанию проекта.

В целом же ситуация классическая: компания не растёт, а люди в ней расти таки желают. Однозначных рекомендаций в таком варианте быть не может. Вероятно, стоит порекомендовать "кадидатам в РМ" попробовать пособеседоваться в каких-нибудь еще компаниях, и если они вправду что-то понимают в управлении, думаю, им будут рады. А если нет — то ваша ситуация, простите, банальные корпоративные интрижки.

Здравствуйте, SkyDance, Вы писали:

H>>Да, с точки зрения увольнения это кардинальная мера. На текущий момент понятно что это делать нежелательно, в частности исходя из ответов на форуме.
H>>Но 2 ПМа на 12 человек это многовато. Там есть Тимлиды для небольших групп, не более 4 человек в группе.

SD>Тогда надо разбираться с тем, почему упомянутые кандидаты хотят стать PM'ами. Возможно, они всего лишь требуют повышения оплаты труда, полагая, что РМ получает больше. С такой особенностью я в России сталкивался неоднократно, даже опытные ключевые разработчики получали меньше РМ. Что и вынуждало их превращаться из хорошего разработчика в плохого РМ.

SD>В подобном случае можно попробовать переговоры о повышении оплаты. Если человеку хочется больше ответственности — об увеличении влияния человека на проект (например, допустить его до участия в создании требований, переговорах с заказчиком), при этом бонусы к зарплате рассчитывать по успешному окончанию проекта.

SD>В целом же ситуация классическая: компания не растёт, а люди в ней расти таки желают. Однозначных рекомендаций в таком варианте быть не может. Вероятно, стоит порекомендовать "кадидатам в РМ" попробовать пособеседоваться в каких-нибудь еще компаниях, и если они вправду что-то понимают в управлении, думаю, им будут рады. А если нет — то ваша ситуация, простите, банальные корпоративные интрижки.

Там есть ПМы но на других проектах. Тимлиды не стремятся стать ПМами. На 12 человек 1 ПМа более чем достаточно.
Непонятно почему ключевой разарботчик должен получать больше ПМа. Если все под контролем любой ключевой разработчик меняется также быстро как и ПМ. От ПМа завист работа всего проекта, от разркаботчика каким бы ключевым он небыл только часть. Если проект может встать от того что например уе ключевой разработчик это говорит о том что процессы поставлены плохо.

Здравствуйте, hpux100, Вы писали:

H>Другие ПМы возможно тоже будут косячить. Но обязанность ПМа учесть все риски.

Учесть все риски невозможно. Учесть можно только некоторые самые очевидные.

Здравствуйте, hpux100, Вы писали:

H>Интересно мнение, поскольку в этом форуме большинство связны с управлением и координацией проектов.
H>При жестоко регламентированных сроках релиза, стоит ли увольнять Менеджера Проекта, если проект не сдан в срок.
H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.

Конечно, нужно увольнять. Можно посмотреть на футбольные клубы — там тренеры курсируют между клубами в случайном порядке и иногда даже возвращаются в тот же клуб.

Здравствуйте, hpux100, Вы писали:

H>Риски он не учел, по критичным изменениям в системе и как они повлияют на качество. Сроки сдвинуть нельзя, объем можно скоректировать. Бюджет можно было увеличить. Неизменны только сроки.

Интересно, как это безнаказанно (без увеличения сроков) можно увеличить бюджет?
Увеличивается бюджет (пересчитывается) -- соответсвенно увеличатся и сроки -- неужели вы считаете, что если юниту платить в 2 раза больше -- так он будет в 2 раза больше работать?
А привлечь дополнительного юнита -- всегда дополнительные издержки.
Найти подходящего человека и влить его в команду -- так это может занять от месяцев до полугода и больше. Как же, даже теоретически, вы собирались решить проблему недостатка необходимой "рабочей силы"?
А привлечение дополнительных юнитов -- это не совсем задача проджект менеджера -- это хьюман ресорсес.
Если хар не срабатывает -- так чего валить на пиэма?

Здравствуйте, Vzhyk, Вы писали:

V>On 16.12.2012 19:11, hpux100 wrote:

>> H>>Причин несколько, в частности не учли влияние разработки новых
>> компонент на систему в целом, в результате доведение системы до
>> приемлемого качества заняло больше времени. Но сроки сильно сдвигаться
>> не могут, об этом было сказано, тем не менее ПМ утвердил план работ по
>> объему и срокам.
>>
>> Риски он не учел, по критичным изменениям в системе и как они повлияют
>> на качество. Сроки сдвинуть нельзя, объем можно скоректировать. Бюджет
>> можно было увеличить. Неизменны только сроки.
V>Думаю, что лучше предложить ПМу уволиться. Уверен, он найдет себе
V>получше контору. Здесь же описаный типичный поиск "козла отпущения".

Я еще раз акцентирую внимание на том, что при увеличении бюджета увеличивается и время на разработку -- хотя бы из-за стоимости (по времени, не только по деньгам) привлечения новых юнитов и введения их в курс дела.
пиэму -- вот тебе 10 человек в начале проекта -- это одна задача, а вот тебе еще 20 человек в середине проекта -- это совсем другая задача,
а вот тебе еще 50 человек в конце проекта, чтобы удовлетворить все возрастающие требования -- это задача третья и почти не решаемая,
это надо быть супер-джедай-пиэмом чтобы такую задачу разрулить в сроки изначально фиксированные.
Корректировать объем ближе к концу проекта -- это заведомо эпик фэйл.
Свидетельство того, что не был проведен нужный ресерч на начале, что тоже стоит много времени и денег, а заказЧеги, они хотят всего и сразу, как правило,
а в реальности все и сразу не работает. Классическая проблема непонимания цели и методов ее достижения детектед.
Я согласен с вами -- по поводу стандартной "русской" проблемы -- "кто виноват". Думать надо было раньше -- на старте. Никто не виноват.
"Пошла Машенька в лес по грибы да по ягоды. Вернулась ни с чем. Потому что надо ставить перед собой конкретные цели."

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Здравствуйте, hpux100, Вы писали:

H>>да по большей части верно и проверять надо и код писать возможно лучше.
N_C>Я-бы сказал, что неоттестированный разработчиками код выдавать на тест нельзя. А судя по сообщению: "огромное количество ошибок при тестировании" говорит скорее о том, что разрабы вывалили плохо написанный код на тестировщиков. Мне, конечно, легко говорить — я то не знаю всех нюансов, но по внешним признакам я бы сказал так.

H>>Но кто это должен контролировать ПМ?
N_C>Это зависит от принятой в вашей организации схемы работы. На мой взгляд ПМ не должен контролировать качество кода. Это дело синиора, тим-лида, архитектора и пр... Другой разговор, что ПМ должен принять все действия для того, чтобы повысить качество кода — здесь соглашусь однозначно.

А как насчет текникал пиэм?
Через кого пиэм должен знать реального положение вещей по поводу качества кода?
Кого спросить и как проконтролировать?
Нужна система. Сколько у пиэма тим-лидов, архитекторов, сеньйоров, и как пиэм может проконтролить, что они его не вводят в заблуждение насчет качества и сроков будущего продукта -- вот в чем заключается системный подход с точки зрения пиэма.
С точки зрения оунера системный подход заключается в том, как контролить того же пиэма -- то есть как видеть в процессе -- идет ли общее дело вверх или наоборот скатывается в пропасть, ибо оунер рискует больше всех вместе взятых юнитов.

Здравствуйте, hpux100, Вы писали:

H>ПМ, я считаю, должен отвечать за любую активность на проекте. Он может не разбираться в деталях но контролировать ситуацию должен полностью.
H>Если какие то проблемы или риски он должен быстро и адекватно реагировать. На то он и ПМ, на проекте он ключевой человек.

На проЕкте -- да, ключевой человек,
но не на проДукте. Глядя со стороны (это просто мое мнение, не сочтите за единственно верное) -- вы не можете контроллировать (оценивать действия и их последствия) вашего пиэма.
Может, вам надо еще грамотного продакт менеджера, который отвечал бы за продукт?

Деньги и прочие бонусы получают не за успешный проЕкт, а за успешный проДукт. feel the difference//

Здравствуйте, hpux100, Вы писали:

H>Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика. Тимлид есть, требования не менялись. Требования не имеют права меняться после того как началась фаза разработки, там классическая водопадная модель применяется. Заканчивается разработка начинается регрессионое тестирование. Обеъем и сложность обсуждалась с ПМ, тимлидом и заказчиком. ПМ объем подтвердил.

У меня такой естественный вопрос:

2.5 месяца -- это что?

препродакшн, продакшн, пост-продакшн,

или -- все вкупе вместе взятое?

если нет -- какие сроки были на пре-продакшн?

"заканчивается разработка" -- это что заканчивается -- бета, что ли.

Какие этапы (майлстоуны) у вашего проекта?

через сколько этапов надо пройти, чтобы добраться до рилиза (читать -- версии, которую можно продать и заработать достаточное количество денег)?

так вот на вот эти все вопросы пиэм не отвечает -- пиэм отвечает за продакшн.

Здается мне, в роли пиэма вы видели эдакого убер-универсального солдата (или он вас в этом убедил, что зря), может и не так -- не вижу пока полной картины, но симптомы, вроде бы знакомые ))

Здравствуйте, Vzhyk, Вы писали:

V>On 18.12.2012 13:56, hpux100 wrote:

V>реализовал — такого человека или понижать или увольнять. Если он...

Понижать человека -- нельзя -- только или повышать или оставлять работать дальше или увольнять.
Понижать -- это увольнять, не будет мотивации у "пониженного" человека.

Здравствуйте, Vzhyk, Вы писали:

V>On 18.12.2012 14:05, hpux100 wrote:

>> Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика.
V>Вот здесь в первом числе уже большой баг, при описанном выше количестве
V>народа.
V>За 2.5 месяца проектик максимум на 2 человека более ни менее сделать
V>можно. Если же в проекте 11 прогеров 5 тестеров и 2 ОП да еще при вашей
V>модели разработки на 8-12 в лучшем случае рассчитывать можете, вне
V>зависимости от сложности проекта.

Согласен, как то странно и слишком самоуверенно -- а если команда не сработается -- надо уже сработанная слаженная команда, имеющая представление о том, что им предстоит сделать -- а это тоже время -- период вхождения в курс дела.

>> Заканчивается разработка начинается регрессионое
>> тестирование.
V>Вот здесь второй баг.

>> Обеъем и сложность обсуждалась с ПМ, тимлидом и
>> заказчиком. ПМ объем подтвердил.
V>То бишь ПМ — это пророк?

Ну, типа, да, в идеале, пиэм -- челок со способностями к прогнозированю в рамках поставленной задачи ))
Если требования изменялись в процессе -- это другое -- на это никаких пророков не напасешься ))

Здравствуйте, hpux100, Вы писали:

H>проект в данном случае это прикручивание новых фич к продукту которому около 12 лет.
H>на все одна итерация:
H>фаза разработки требований — 1.5 мес
H>разработка 2.5 мес
H>тестирование 1.5 мес

то есть:

пре-продакшн -- 1.5

альфа, бета-100 -- 2.5

от беты-100 до рилиза -- 1.5

мое мнение -- на часть альфа, бета -- кор разработка -- слишком мало времени относительно других фаз, да и просто -- слишком мало времени -- юнитам надо еще сработаться -- перейти в боевое состояние.

Здравствуйте, hpux100, Вы писали:

H>Запас есть, трудоемкость задач умножается на коэффициент 1.5. Т. е. времени дается реально больше. Про
H>ПМа вопрос открытый, на форуме просто задавался вопрос насколько это целесообразно.

Ага, а надо на 3.14, а потом еще на два ))

Здравствуйте, hrensgory, Вы писали:

H>On 19.12.2012 13:09, hpux100 wrote:

H>Коллега, это неправильный запас, ибо давно известно что "работа занимает
H>всё отведённое на неё время". В проектах с несдвигаемым внешним
H>дедлайном надо назначать срок ОКОНЧАТЕЛЬНОЙ СДАЧИ проекта за X недель до
H>этого самого дедлайна, а не прибавлять время на отдельные этапы.

этот "мнимый дедлайн" ред лайн называется ))