Здравствуйте, 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 аналитика.

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