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

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

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

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

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

S>Прежде чем увольнять, надо разобраться в причинах. Если человек просто ничего не делал -- это одно, а если какие-либо
S>обстоятельства, то это другое. Плюс, надо смотреть на сколько сроки поплыли.

Хороший ПМ всегда сможет придумать обстоятельства непреодолимой силы, которые помешали сдать проект вовремя.

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

H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.

Зависит от того, кто будет поставлен на место уволенного ПМа. Если есть уверенность что новый ПМ справится лучше старого, то почему бы и нет.

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

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

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

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

S>Прежде чем увольнять, надо разобраться в причинах. Если человек просто ничего не делал -- это одно, а если какие-либо
S>обстоятельства, то это другое. Плюс, надо смотреть на сколько сроки поплыли.

Сроки плывут не сильно но уменьшают сроки выполнения задач для других команд, в частности тестирования.

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

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

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

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

H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.

Не сталкивался и не разумно.
Не, если ПМ просто балду пинал, то его конечно надо попросить,
но такие вещи видны еще до окончания проекта.

А в целом, на не совсем простых проектах не может один человек быть ответственным за прокол.
Реальность всегда сложнее и интереснее.
Ну а негативная мотивация — это почти самая худшая из мотиваций.
Хуже только подневольный труд.

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

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

H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.

B>Не сталкивался и не разумно.
B>Не, если ПМ просто балду пинал, то его конечно надо попросить,
B>но такие вещи видны еще до окончания проекта.

B>А в целом, на не совсем простых проектах не может один человек быть ответственным за прокол.
B>Реальность всегда сложнее и интереснее.
B>Ну а негативная мотивация — это почти самая худшая из мотиваций.
B>Хуже только подневольный труд.

За сроки отвечает именно ПМ с его строны нужна как минимум аргументация почему это происходит.
А какая кстати для ПМа может быть мотивация в случае срыва сроков?

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

P>За сроки отвечает именно ПМ с его строны нужна как минимум аргументация почему это происходит.

С этим согласен. ПМ отвечает за планирование, контроль
и своевременную коррекцию если что-то идет не туда.
Но это не означает, что он все сможет сделать.
Он "всего лишь" координирует и является таким же винтиком, со своей зоной ответственности,
как и другие участники проекта.

P>А какая кстати для ПМа может быть мотивация в случае срыва сроков?

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

Не уложиться в план на одном проекте — это еще пол беды.
Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом.

On 13.12.2012 19:26, hpux100 wrote:

> Сроки плывут не сильно но уменьшают сроки выполнения задач для других
> команд, в частности тестирования.
Ну так в чем проблема выяснить причины такого уплывания. Может кто-то
планирует слишком оптимистично?

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

B>Менее половины проектов укладываются в сроки и запланированный изначально бюджет.
Это сильно оптимистично... Думаю, что процентов 30...

B>Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом.
Обычно за процесс в целом отвечают уже другие люди, типа руководителя проектного офиса...

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

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

B>>Менее половины проектов укладываются в сроки и запланированный изначально бюджет.
N_C>Это сильно оптимистично... Думаю, что процентов 30...

Ну 30% тоже меньше 50%
Какова реальность фиг его знает.
Вот здесь говорят о 40%
Но в целом я скорей с тобой соглашусь.

B>>Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом.
N_C>Обычно за процесс в целом отвечают уже другие люди, типа руководителя проектного офиса...

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

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

V>On 13.12.2012 19:26, hpux100 wrote:

>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других
>> команд, в частности тестирования.
V>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то
V>планирует слишком оптимистично?

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

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

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

V>>On 13.12.2012 19:26, hpux100 wrote:

>>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других
>>> команд, в частности тестирования.
V>>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то
V>>планирует слишком оптимистично?

H>Причин несколько, в частности не учли влияние разработки новых компонент на систему в целом, в результате доведение системы до приемлемого качества заняло больше времени. Но сроки сильно сдвигаться не могут, об этом было сказано, тем не менее ПМ утвердил план работ по объему и срокам.

И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки?
Не понятная ситуация...

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

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

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

H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
E>Мне как то один ПМ в аутсорсе говорил одну вещь. Самый страшный провал в ПМстве — это не срыв сроков. К срыву сроков даже в несколько раз все привыкли, и считают это само собой разумеющимся. Ибо всегда будут изменения требований, потери на коммуникации и согласования, и на это вполне можно списать лишнее время. Самое страшное для ПМа, это сделать проект досрочно. Вот в этом случае ПМа нужно увольнять, ибо здесь он расписался в том, что не умеет оценивать время — здесь у него отмазок быть не может.
ИМХО ерунда... Каждый ПМ всегда закладывает резерв времени на непредвиденные или предвиденные ситуации. Выстрелят они — еще неизвестно, но даже если не выстрелили, ругать ПМа за резерв как-то странно. Всегда можно сказать заказчику, что в качестве бонуса ему сделаем еще несколько задач, или просто перекинем команду временно на обучение/другие задачи/отправим в отпуск...
Вот как раз срыв сроков, о которых ПМ не предупреждал заказчика — вот действительно провал ПМа. Ведь, по сути, срыв сроков на три месяца когда-то начинается сдвигом сроков на неделю. И утаивать эту информацию с тем, чтобы вывалить на заказчика сразу срыв в три месяца — вот самая большая ошибка ПМа...

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

H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
E>Мне как то один ПМ в аутсорсе говорил одну вещь. Самый страшный провал в ПМстве — это не срыв сроков. К срыву сроков даже в несколько раз все привыкли, и считают это само собой разумеющимся. Ибо всегда будут изменения требований, потери на коммуникации и согласования, и на это вполне можно списать лишнее время. Самое страшное для ПМа, это сделать проект досрочно. Вот в этом случае ПМа нужно увольнять, ибо здесь он расписался в том, что не умеет оценивать время — здесь у него отмазок быть не может.

А что, если затянул сроки — то умеет оценивать?
Я думаю, этот ваш знакомый ПМ просто лапшу на уши вешал.

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

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

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

V>>>On 13.12.2012 19:26, hpux100 wrote:

>>>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других
>>>> команд, в частности тестирования.
V>>>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то
V>>>планирует слишком оптимистично?

H>>Причин несколько, в частности не учли влияние разработки новых компонент на систему в целом, в результате доведение системы до приемлемого качества заняло больше времени. Но сроки сильно сдвигаться не могут, об этом было сказано, тем не менее ПМ утвердил план работ по объему и срокам.

B>И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки?
B>Не понятная ситуация...

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

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

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

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

B>>И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки?
B>>Не понятная ситуация...

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

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

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

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

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

Да по срокам это было известно.

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

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

B>>>И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки?
B>>>Не понятная ситуация...

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

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

Дело не столько в объеме, сколько в ложности задачи и ее влиянию на другие подсистемы. Реализация ряда фич требовала глубокого рефакторинга. Меньший объем новых фич скорее всего бы спас ситуацию.
Сначала все двигалось предсказуемо, поток проблем пошел после тестирования и появляния болшого количества регрессионных багов. А поскольку работы по доводке системы получилось сильно больше чем предполагалось, естественно возникли риски по срокам.

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

H>Дело не столько в объеме, сколько в ложности задачи и ее влиянию на другие подсистемы. Реализация ряда фич требовала глубокого рефакторинга. Меньший объем новых фич скорее всего бы спас ситуацию.
H>Сначала все двигалось предсказуемо, поток проблем пошел после тестирования и появляния болшого количества регрессионных багов. А поскольку работы по доводке системы получилось сильно больше чем предполагалось, естественно возникли риски по срокам.

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

У нас, кстати, ситуация в смысле сроков практически похожая.
Дата релиза известна заранее с точностью до дня и ее никак не сдвинуть.
Вся торговля идет как раз на тему, что же впихнуть в следующий релиз
и что делать, если видно что не успеваем...

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

H>Сначала все двигалось предсказуемо, поток проблем пошел после тестирования и появляния болшого количества регрессионных багов. А поскольку работы по доводке системы получилось сильно больше чем предполагалось, естественно возникли риски по срокам.
Так может разрабы (архитектор) не помогли ПМу, не указали на риски мырого программного продукта? Может ПМ (из своего предыдущего опыта) предполагал, что данный программный продукт более качественно сделан и он не потребует рефакторинга от этого количества фич. Может еще что-либо. Вы сами то поговорили с ним? Узнали, почему так произошло?
Вот почему понимание, что срыв сроков произойдет появилось в самом конце — при тестировании? Что, когда внеплановый рефакторинг проводили не было понятно, что сроки уехали? Или разрабы держали все при себе? Тогда почему тимлид не прокачал эту ситуацию? Почему он молчал? Не могло быть так, что этого ПМа банально подставила команда разработчиков, недовольных его назначением?

On 16.12.2012 19:11, hpux100 wrote:

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

On 16.12.2012 22:34, hpux100 wrote:

> Реализация ряда фич требовала глубокого рефакторинга.
> Меньший объем новых фич скорее всего бы спас ситуацию.
> Сначала все двигалось предсказуемо, поток проблем пошел после
> тестирования и появляния болшого количества регрессионных багов. А
> поскольку работы по доводке системы получилось сильно больше чем
> предполагалось, естественно возникли риски по срокам.
Вообще описание — хороший учебник многим начинающим начальникам.
Вероятнее всего (полностью ситуация ТС не раскрыл) были уже вековые
напластования старого кода и система как-то работала. Затем решили на
самом верху, что следует разгрести эти напластования и сделать все
хорошо. Нашли ПМа с горящими глазами, он пообещал все сделать (и сам в
это свято верил). А затем началась сложная работа по выдиранию золота из
вековых напластований. Отдел тестирования, как положено в подобных
задачах, подключился только тогда, когда выкатили уже рабочий билд
(уверен, что по прошедствии 2/3 всего времени). Ну и результат выше описан.
Да и окончание этой истории известно. Текущий ПМ объявляется "врагом
народа", берется следующий, который исправляет за годик все баги (с
минимальным добавлением фич) и объявляется "спасителем".

P.S. Это все фантазия и возможно у ТС было все не так.

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

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

H>>Сначала все двигалось предсказуемо, поток проблем пошел после тестирования и появляния болшого количества регрессионных багов. А поскольку работы по доводке системы получилось сильно больше чем предполагалось, естественно возникли риски по срокам.
N_C>Так может разрабы (архитектор) не помогли ПМу, не указали на риски мырого программного продукта? Может ПМ (из своего предыдущего опыта) предполагал, что данный программный продукт более качественно сделан и он не потребует рефакторинга от этого количества фич. Может еще что-либо. Вы сами то поговорили с ним? Узнали, почему так произошло?
N_C>Вот почему понимание, что срыв сроков произойдет появилось в самом конце — при тестировании? Что, когда внеплановый рефакторинг проводили не было понятно, что сроки уехали? Или разрабы держали все при себе? Тогда почему тимлид не прокачал эту ситуацию? Почему он молчал? Не могло быть так, что этого ПМа банально подставила команда разработчиков, недовольных его назначением?

Девелоперы проверили все выглядело нормально, все работало, были косяки местами но это посчитали мелочью.. Тестеры начали тестировать открыли большое количество багов. Прикинули объем, стало очевидно что многое исправить не удастся. Девелоперы идеально все проверить не могут.
При себе никто ничего не держал и никого не подставлял.

On 13.12.2012 19:28, hpux100 wrote:

> Да именно ПМ
И что?
1. ПМу согли настойчиво предложить согласиться со сроками.
2. ПМ мог искренне верить в то, что все получиться хорошо.
3. ПМ был уверен, что сроки — это сказки и сдачу проекта можно будет
двигать бесконечно (как обычно и происходит).
4. ПМ действительно больше валял дурака и был докой в местных интригах
(в это не верю, ибо в этом случае уже бы указал на "козла отпущения", а
сам бы был хорошим).

On 14.12.2012 1:16, bkat wrote:

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

Здравствуйте, Аноним, Вы писали:

А>Девелоперы проверили все выглядело нормально, все работало, были косяки местами но это посчитали мелочью.. Тестеры начали тестировать открыли большое количество багов. Прикинули объем, стало очевидно что многое исправить не удастся. Девелоперы идеально все проверить не могут.
КАК???? Как такое может быть? Девелоперы проверили — багов нет, а тестеры проверили — багов куча. Боле того, получается, что все, что написали девелоперы пускается в помойку. Это говорит о том, что либо девелоперы вообще не проверяли и их надо бить, либо программный продукт представляет собой редкостную дурнопахнущую кучу. В любом случае — если сейчас объявить виноватым ПМа — следующие ПМы будут вылетать точно также, т.к. команда увидит, что можно просто писать гуано, а отвечают не они, а один ПМ...

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

N_C>Здравствуйте, Аноним, Вы писали:

А>>Девелоперы проверили все выглядело нормально, все работало, были косяки местами но это посчитали мелочью.. Тестеры начали тестировать открыли большое количество багов. Прикинули объем, стало очевидно что многое исправить не удастся. Девелоперы идеально все проверить не могут.
N_C>КАК???? Как такое может быть? Девелоперы проверили — багов нет, а тестеры проверили — багов куча. Боле того, получается, что все, что написали девелоперы пускается в помойку. Это говорит о том, что либо девелоперы вообще не проверяли и их надо бить, либо программный продукт представляет собой редкостную дурнопахнущую кучу. В любом случае — если сейчас объявить виноватым ПМа — следующие ПМы будут вылетать точно также, т.к. команда увидит, что можно просто писать гуано, а отвечают не они, а один ПМ...

ПМ не факт что вылетит, но за сроки спросят с него. Коду лет 10,
да по большей части верно и проверять надо и код писать возможно лучше. Но кто это должен контролировать ПМ?

On 17.12.2012 16:49, hpux100 wrote:
> From: *hpux100* </Users/92486.aspx>

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

Слишком много неясного. Какой срок исполнения этого проекта, от момента
когда ПМ принял дела и сказал что согласен со сроками до планируемой
сдачи? Сколько разработчиков и тестировщиков участвовало? Был ли у
разработчиков тимлид? Не менялись ли требования?

--
WBR,
Serge.

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

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

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

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

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

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

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

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

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

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

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

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

H>On 17.12.2012 16:49, hpux100 wrote:
>> From: *hpux100* </Users/92486.aspx>

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

H>Слишком много неясного. Какой срок исполнения этого проекта, от момента
H>когда ПМ принял дела и сказал что согласен со сроками до планируемой
H>сдачи? Сколько разработчиков и тестировщиков участвовало? Был ли у
H>разработчиков тимлид? Не менялись ли требования?

H>--
H>WBR,
H>Serge.

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

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

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

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

А кстати, а ты кто?
Я имею ввиду твою роль? Ты девелопер, архитект, или вообще владелец компании?

On 18.12.2012 13:56, hpux100 wrote:

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

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

H>Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика.

Небольшой проект. И на сколько поехали сроки?

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

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

H>>Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика.

B>Небольшой проект. И на сколько поехали сроки?

2 недели

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

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

А ПМ-у дали реальную власть, чтобы "контролировать ситуацию полностью" и "быстро и адекватно реагировать"? Или же его только нагрузили ответственностью (назначили виноватым за все косяки), а соответствующие полномочия "случайно" так дать позабыли?

On 18.12.2012 14:05, hpux100 wrote:

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

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

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

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

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

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

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

B>А кстати, а ты кто?
B>Я имею ввиду твою роль? Ты девелопер, архитект, или вообще владелец компании?

Я ПМ другого проекта, который от этого зависит.

On 18.12.2012 14:22, hpux100 wrote:

> 2 недели
Круто. Такому ПМ надо премию давать и зарплату поввышать, пока не сбежал.

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

H>>>Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика.

B>>Небольшой проект. И на сколько поехали сроки?

H>2 недели

В смысле сроков не все так плохо на самом деле.
Проект короткий, девелоперов относительно много. Большой рефакторинг и прочие риски.
Короткие проекты не так просто планировать, а простанства для маневра почти нету.

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


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

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

On 18.12.2012 15:05, hpux100 wrote:

> Срок 2.5 месяца, 11 разработчиков, 5 тестеров, 2 аналитика. Тимлид есть,
> требования не менялись.

Если все эти 11 разработчиков реально что-то разрабатывали, да ещё в
связке с кодом 10-летней давности, то 2.5 месяца == полное отсутствие
манёвра и очень серьёзные риски не успеть в связи с этим. Единственное
что может и обязан был сделать ПМ в данном случае — довести понимание
этого до всех стейкхолдеров проекта.

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

А он технический вообще человек? Или просто умножил сказанное тимлидом
на к-т и подписался?

--
WBR,
Serge.

On 18.12.2012 14:44, Sharov wrote:

> Тоже как то резануло -- тут на одну коммуникацию времени будет уходит
> куча.
И не только коммуникацию. Старт проекта с таким количеством народа 1-2
месяца только займет. Даже при итерационном процессе, а не водопаде
первую версию только через 1-2 месяца можно выкатить.

> Странный проект, который нужно сделать за довольно
> небольшое время приличным количеством людей . Тут либо народу столько не
> нужно, либо сроки не адекватны...
Ну есть пару вариантов подобных проектов. Это обычно аутсорс и десяток
людей делают что-то почти одинаковое, но в больших количествах,
архитектура и т.п. уже давно сделаны, утверждены и пофиксены, нужно
написать пачку очень похожих модулей. Второй вариант тоже обычно в
аутсорсе, слепить что-то очень быстро и спихнуть заказчику, главное
получить подпись в акте приемки и забыть и забить.
В первом варианте нужна итерационная модель и тестеров нужно подключать
уже после первых 1-2 недель. Во втором, все пофиг, главное как-то
заставить работать и спихнуть заказчику.

> А что за проект если не секрет, какова предметная область?
Это у ТС надо спрашивать.

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

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


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

S>Тоже как то резануло -- тут на одну коммуникацию времени будет уходит куча. Странный проект, который нужно сделать за довольно
S>небольшое время приличным количеством людей . Тут либо народу столько не нужно, либо сроки не адекватны...
S>А что за проект если не секрет, какова предметная область?

Длительность это имеется ввиду итерация на релиз. Не весь проект. Объем большой как раз на 10-12 человек. До начала итерации аналитики пишут требования.
2.5 месяца это только разработка

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

H>2.5 месяца это только разработка

Первый раз слышу, чтобы под длительнстью проекта имели ввиду только разработку.

On 18.12.2012 14:58, hrensgory wrote:

> Если все эти 11 разработчиков реально что-то разрабатывали, да ещё в
> связке с кодом 10-летней давности, то 2.5 месяца == полное отсутствие
> манёвра и очень серьёзные риски не успеть в связи с этим.
Даже без кода 10-летней давности с такой толпой тут маневр практически
невозможен.
Предположим. Новый проект — все с большего понятно. Но, на одну
архитектуру и организацию разработки уйдет только 2-3 недели в лучшем
случае. После этого начнут подключаться разработчики и реализовывать
некую функциональность. При итерационном процессе, если проект простой
можно надеятся выкатить первую версию через 3 недели (чаще 1-1.5
месяца). После уже можно свести итерации к 2 неделям (чаще при такой
толпе бессмысленно). При подключении тестеров сразу же и хотя бы 5
итерациях получаем 15 недель. И это все в случае если все идет идеально.

> Единственное
> что может и обязан был сделать ПМ в данном случае — довести понимание
> этого до всех стейкхолдеров проекта.
И тут мы попадаем в неписанную часть процессов на этой конторе, ака
"крысиные бега" (в той или иной степени они присутсвуют в любом
коллективе). И здесь мы что-то подсказать TC не сможем.

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

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

H>>2.5 месяца это только разработка

B>Первый раз слышу, чтобы под длительнстью проекта имели ввиду только разработку.

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

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

V>On 18.12.2012 14:44, Sharov wrote:

>> Тоже как то резануло -- тут на одну коммуникацию времени будет уходит
>> куча.
V>И не только коммуникацию. Старт проекта с таким количеством народа 1-2
V>месяца только займет. Даже при итерационном процессе, а не водопаде
V>первую версию только через 1-2 месяца можно выкатить.

>> Странный проект, который нужно сделать за довольно
>> небольшое время приличным количеством людей . Тут либо народу столько не
>> нужно, либо сроки не адекватны...
V>Ну есть пару вариантов подобных проектов. Это обычно аутсорс и десяток
V>людей делают что-то почти одинаковое, но в больших количествах,
V>архитектура и т.п. уже давно сделаны, утверждены и пофиксены, нужно
V>написать пачку очень похожих модулей. Второй вариант тоже обычно в
V>аутсорсе, слепить что-то очень быстро и спихнуть заказчику, главное
V>получить подпись в акте приемки и забыть и забить.
V>В первом варианте нужна итерационная модель и тестеров нужно подключать
V>уже после первых 1-2 недель. Во втором, все пофиг, главное как-то
V>заставить работать и спихнуть заказчику.

>> А что за проект если не секрет, какова предметная область?
V>Это у ТС надо спрашивать.

Предметная область моделирование процессов физика, химия, это в общих чертах, детали не могу сообщать.

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

H>Предметная область моделирование процессов физика, химия, это в общих чертах, детали не могу сообщать.

Предметная область серьезная. Тут действительно нужны как люди разбирающиеся в вопросе, так и разработчики.
А еще желательнее два в одном. Благодарю за ответ.

On 18.12.2012 16:53, hpux100 wrote:

> Предметная область моделирование процессов физика, химия, это в общих
> чертах, детали не могу сообщать.
Ну тогда все начальство на проекте нужно шерстить, ибо не особо оно
компетентно. Ибо в подобных областях кучи подводных камней и обычно на
них натыкаешься в самый неподходящий момент.
Пример. Запрограммировали все правильно, по формулам, а оказалось, что
считает оно неприемлемо долго. Что делать? Время на решение этой
проблемы может оказаться сильно больше того, что разрабатывали саму модель.
А посему необходимо закладывать в план и риски, что нарветесь на
неожиданные подводные камни. Возможно и у вас напоролись по некоторым
фичам на такие камни.
Наказать ПМ за то, что он не пророк — это смешно и сослужите себе
"медвежью услугу".

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

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

H>на все одна итерация:
H>фаза разработки требований — 1.5 мес
H>разработка 2.5 мес
H>тестирование 1.5 мес
Хм... за полгода съехали _всего_ на две недели... Действительно, странное желание наказать ПМа...

H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.

Для начала неплохо бы определиться с целью. Чего вы хотите достигнуть? Вам требуется убрать неугодного человека и вы ищете повод для этого? Заказчик требует неустойку, но вы вместо выплат хотите выдать козла отпущения менеджера на растерзание? Или вам просто нужно некую публичную порку в стиле "вот что бывает с теми, кто ошибся в оценках длительности проекта"?

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

On 18.12.2012 16:32, Vzhyk wrote:

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

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

--
WBR,
Serge.

On 18.12.2012 17:53, hpux100 wrote:

> Предметная область моделирование процессов физика, химия, это в общих
> чертах, детали не могу сообщать.

Не на 21.12 сдача в production запланирована ?

--
WBR,
Serge.

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

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

Но тут надо подумать вот о чем: компания затратила деньги на проект, который дал этому ПМ-у опыт, пусть и негативный.
Вопрос теперь, где он этот опыт, оплаченный твоей конторой, будет применять — тут или у конкурентов?

On 19.12.2012 10:15, hrensgory wrote:

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

P.S. Причем проект в совсем не тривиальной области.

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

H>On 18.12.2012 16:32, Vzhyk wrote:

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

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

H>--
H>WBR,
H>Serge.

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

On 19.12.2012 10:17, hrensgory wrote:

> Не на 21.12 сдача в production запланирована ?
До чего ты не мне нравишься, по твоими постам, но тут похоже ты в точку
попал.

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

H>On 18.12.2012 17:53, hpux100 wrote:

>> Предметная область моделирование процессов физика, химия, это в общих
>> чертах, детали не могу сообщать.

H>Не на 21.12 сдача в production запланирована ?

H>--
H>WBR,
H>Serge.

нет чуть позже

On 19.12.2012 13:09, hpux100 wrote:

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

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

--
WBR,
Serge.

On 19.12.2012 14:01, hrensgory wrote:

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

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

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

Тут уже много раз отвечали, что нецелесообразно.
Но тут я пожалуй соглашусь с Vzhyk, что уволив его вы на самом деле сделаете ему одолжение.
Сама идея искать козла отпущения, а не разбираться в реальной проблеме,
говорит о весьма нездоровой обстановке у вас.

On 19.12.2012 14:52, bkat wrote:

> Но тут я пожалуй соглашусь с Vzhyk,

Ну за 20 лет наблюдения всего IT бизнеса на просторах CCCР можно уже
стать и телепатом. Сложность в том, что видишь негативные следствия, а
позитивные — это лотерея.

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

V>On 19.12.2012 14:01, hrensgory wrote:

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

Прибавление времени уменьшает объем. Это примерно одно и тоже.

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

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

H>>на все одна итерация:
H>>фаза разработки требований — 1.5 мес
H>>разработка 2.5 мес
H>>тестирование 1.5 мес
N_C>Хм... за полгода съехали _всего_ на две недели... Действительно, странное желание наказать ПМа...

Желания наказать нет, просто до этого сроки никогда не съезжали.
Были мысли его поменять поскольку получилось так что сейчас есть кандидаты успешно себя проявившие и готовые заниматься проектом

On 19.12.2012 16:16, hpux100 wrote:

> Прибавление времени уменьшает объем. Это примерно одно и тоже.
Если рассматривать абстрактно. В реальности все не так. В проектах с
фиксированной датой окончания нужно плясать от конца — это непросто.
По-простому, быть готовым после каждой итерации выкинуть некую
функциональность, есть есть вероятность ее не сделать.
Ну и итерации должны быть максимально быстрыми. Лучше, если они вообще
непрерывные, но это более абстрактное, нежели реализуемое. По-простому,
нет этапов (итераций), тестируется каждая реализованная функциональность
сразу же, как она реализована. Если кажется, что где-то что-то
неуспевается, оное выкидывается. Понятно необходимо разделить
функциональность на группы: обязательно реализовать, желательно
реализовать, "шоколад с майонезом".

P.S. Это самый дурацкий (тяжелый) вариант проекта.

P.P.S. Как совет ПМ не увольняйте и не наказываетя (себе же хуже
сделаете). Просто внимательно посмотрите на причины задержки и сделайте
конструктивные выводы — это предполагает конструктивную работу всех
начальников, а не поиск "козла отпущения" (виноватого).

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

V>On 19.12.2012 16:16, hpux100 wrote:

>> Прибавление времени уменьшает объем. Это примерно одно и тоже.
V>Если рассматривать абстрактно. В реальности все не так. В проектах с
V>фиксированной датой окончания нужно плясать от конца — это непросто.
V>По-простому, быть готовым после каждой итерации выкинуть некую
V>функциональность, есть есть вероятность ее не сделать.
V>Ну и итерации должны быть максимально быстрыми. Лучше, если они вообще
V>непрерывные, но это более абстрактное, нежели реализуемое. По-простому,
V>нет этапов (итераций), тестируется каждая реализованная функциональность
V>сразу же, как она реализована. Если кажется, что где-то что-то
V>неуспевается, оное выкидывается. Понятно необходимо разделить
V>функциональность на группы: обязательно реализовать, желательно
V>реализовать, "шоколад с майонезом".

V>P.S. Это самый дурацкий (тяжелый) вариант проекта.

V>P.P.S. Как совет ПМ не увольняйте и не наказываетя (себе же хуже
V>сделаете). Просто внимательно посмотрите на причины задержки и сделайте
V>конструктивные выводы — это предполагает конструктивную работу всех
V>начальников, а не поиск "козла отпущения" (виноватого).

спасибо за советы, это было рассмотрено как крайний вариант, поэтому вопрос и задавался на форуме

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


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

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

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

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

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

void managePeople(){
   if( project.isFixedTime && currentTime() > project.deadline && !project.isFinished ){
      manager.mail.send( "You're fired!" );
   }
}

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

В конце концов, даже эта пара строк кода обойдется компании дешевле, чем содержание руко-идиота.

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

G>В конце концов, даже эта пара строк кода обойдется компании дешевле, чем содержание руко-идиота.

Черт. Незаконченное сообщение случайно отправилось . Но вы поняли идею.

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

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

А с ним согласовывали эти сроки, или просто поставили перед фактом?

0>Если хочется избавиться от некомпетентного (неудобного и т.п. человека, то тоже можно).

Назвать некомпетентным РМ-а, у которого полугодовой проект съехал всего на 2 недели, мне было бы сложно.

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

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

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

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

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

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

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

Pzz>А с ним согласовывали эти сроки, или просто поставили перед фактом?

Согласовывали конечно

Здравствуйте, 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>этого самого дедлайна, а не прибавлять время на отдельные этапы.

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

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

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

На сколько больше чем простой раб (ой, извините, разработчик) -- в 2, в 3 раза?
может в 10?

Хотите накинуть ответственность за 10 простых юнитов -- ну так платите соответственно больше -- больше ответственность -- больше денег,
если пиэм по компенсации <= 2 простых раба -- так зачем ему вкалывать? -- он и будет работать как надзиратель 2-х рабов ))

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

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

Затронута очень интересная тема -- разделение бонусов между участниками регаты.
Так вот, как существует в других индустриях -- организующий юнит получает по крайней мере сумму 1/3 зарплаты каждого подчиненного юнита и несет всю ответсвенность за них. (имеется в виду не матричная схема, а просто тупо иерархическая, которая в большинстве, пока)
Почему в нашем ай-ти считается, что достаточно "на 200 баксов больше", чем у солдатов -- не ясно -- тогда ведь и спросить нельзя с такого офицера. Ответственности (за которую можно спросить) меньше. В чем фишка? (или анти-фишка?).

On 04.01.2013 4:49, SenorProgramador wrote:

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

On 04.01.2013 4:54, SenorProgramador wrote:

> V>То бишь ПМ — это пророк?
>
> Ну, типа, да, в идеале, пиэм -- челок со способностями к прогнозированю
> в рамках поставленной задачи ))
Только есть нюанс пророки не ошибаются, а в прогнозе любой может ошибиться.

On 04.01.2013 5:13, SenorProgramador wrote:

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

SP>Так вот, как существует в других индустриях -- организующий юнит получает по крайней мере сумму 1/3 зарплаты каждого подчиненного юнита и несет всю ответсвенность за них. (имеется в виду не матричная схема, а просто тупо иерархическая, которая в большинстве, пока)

Это, конечно же, фантазии начинающего менеджера.

SP>Почему в нашем ай-ти считается, что достаточно "на 200 баксов больше", чем у солдатов -- не ясно -- тогда ведь и спросить нельзя с такого офицера. Ответственности (за которую можно спросить) меньше. В чем фишка? (или анти-фишка?).

Про ответственность уже многократно перетиралось. Итог всегда один — ответственность всегда прямо пропорциональна и по сути равна количеству получаемых благ умноженным на сложность поиска аналогичного места.