Первый жесткий сценарий. Цена и время проекта утверждены и не пересматриваются (в разумных пределах).
Это идет в разрез с мотивацией команды разработчиков – обычно вешают ярлык “лень и не профессионализм”.
В таком сценарии менеджер проекта не может себе позволить быть либералом, он будет крайне напрягать команду для достижения своей мотивации.
Если команду формируют под проект то вероятнее всего будет проблема и обсуждаемая методология не поможет.
Если команда слажена и возможности всех учтены изначально – SCRUM удовлетворит мотивацию нижнего звена но не удовлетворит амбиции PM – он лишний.
Идельная среда для SCRUM – это STARTUP!
В этом случае все увлечены конечным продуктом с коммунистическим лозунгом – от каждого по способностям – каждому по потребностям.
Если предположить сценарий продажи конечного продукта какому нибудь гиганту IT – то любые расходы времени и средств даже оправданы, так как любая фитча только добавит очередной плюс умноженный на 100.
SCRUM подобные методологии уж больно демократичные в системе виников и шпунтиков, когда разработку сопоставляют с постройкой автомобиля, где 80% это дело техники, а 20% подготовка проекта.
В IT индустрии все наоборот – ценится знание и опыт, что доказывает высокие зарплаты.
SCRUM ближе к человеку, RUP к бизнесу.

По сути СКРАМа:
- как эта схема организации труда решает вопросы архитектуры? У кого эта роль? Кто должен ее планировать и следить за ее выдерживанием? Кто должен продумывать архитетурные требования к реализации. Это очень важно, а в презентациях по СКРАМу я этого не нашел. Теперь варианты:
а) эта роль у ProductOwnera. Сомневаюсь, что заказчику есть дело, где строки, в харкоде или в ресурсах.
б) эта роль у Scram Mastera. По теории вроде нет. У нас SM даже не работал в команде.
в) команда “самонаводящаяся”. Т.е. сама все продумает и придержится.Опять сомневаюсь. Возможно я не с теми людьми за свои 30 лет сталкиваюсь:), но суть большинства ничего не делать, ни за что не отвечать и обязательно получать при этом многА денеХ. Ну на кой им продумывать, брать на себя ответственность, потом окажется, что ошибся, окажется, то как хочешь писать нельзя)))…У нас так было: один предлагает в лоб, чтоб меньше париться, другой наоборот, чтоб два дня потерять, но потом за пол-часа долететь, остальные невнятно пытаются примкнуть к одному из. Прошу учесть психологию, хватит уже нескольких “друзей”, чтобы лобировать любые [ленивые] решения! При равности голосов разрулить некому. Даже если на митинге к чему-то пришли, туча моментов возникает по ходу работы: как этот функционал реализовывать, куда этот в проекте расположить и т.д.. Пытаемся решить командой по ходу работ: три разных мнения, форсировать некому, каждый делает по своему. Все время нужно следить: то неправильно понял, то забыл и т.д. Про кодревью в курсе, это не одно и то же, вот таких два “забыл/непонял” друг друга отревьювят будь здоров.
в) есть выделенный архитектор в команде. Это многое меняет. По сути при разговоре с заказчиком команда тогда не нужна.Она ему будет только мешать. В любом случае если он есть, то будет существенно влиять на декомпозицию фичей, требования и сроки выполнения.

У меня было такое чувство при всем этом, как-будто собрали плотника, штукатурщика, маляра, каменьщика и т.д. и дали задание без подробного плана строить дом. И на вопрос почему “поколодник не вровень со стеной”, и почему “куда-то исчезают маляры и штукатуры” (http://newradio.by.ru/new_page_5.htm) ответить некому, т.е.есть – всей команде. А всех не уволят, так что и фиг с ним.

> 1. выращивание узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
Задача нахождения баланса между общими и специальными навыками у работников не специфична для разработки ПО. Но, согласитесь, в целом мир движется к большей специализации.

> 2. это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не командна, со всеми вытекающими;
как раз задача PM сделать так, чтобы была команда, так ведь. И такое мышление — не самамя сложная проблема для решения.

>3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
какая связь между микроменеджментом и всей картиной?

>3. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
это зависит от конкретной ситуации. Кто-то хочет работать с интересными людьми, еще какие-то соображения бывают. Также может быть и отсутствие заинтересованности к привлечению новых людей в скрам-команде.

>4. когда в итоге новых людей подключают, у PM-а работы только прибавляется;
Закон Брукса?

>5. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции
какими имеено?

>вместо этого они могли бы заниматься:
>а) развитием продутка;
это функция менеджера продукта, а не менеджера проекта
>б) формированием команды и устранением пряпятствий на её пути;
как раз этим PM и должен заниматься. Что ему мешает?
>в) высокоуправленческой функцией на уровне предприятия.
а этим должен заниматься управленец соответствующего уровня. Для маленьких компаний, эта фнкция может оказаться совмещенной с функцией PM, но в общем случае, зачем?

>теперь о проблемах по задачам и прогрессу проекта:
1. так как члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично;
2. что такое частично сделанная работа (фича) – это вливания инвестиций, которые не вернулись;
3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии “мы на половине проекта” или “50% фич сделаны наполовину”;
4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков – всех заинтересованных сторон.
выход? да, частые релизы. Как это противоречит варианту, когда командой управляет PM?

>это неуправляемый проект. титаник.
если плохие руководители, то да. Но, это общемировая проблема. Качество менеджмента определяет всё. Скрам — серебряная пуля?

>есть ещё проблемы, которые могут вытекать из классической модели управления. но даже, если их удается контролировать, такой подход не дает возможность людям (командам) раскрыть весь свой потенциал. а команды – это ценнейший фонд компаний, которые занимаются интеллектуальными разработками.
почему не дает. А почему в футболе есть тренер, который направляет команду? Ведь там тоже это ценнейший фонд?

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

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

Я видел команды, которые говорили “у нас не работает Скрам”. Но на деле скрамом там не пахло. Мне понадобилось 3 года, чтоб понять как работает Скрам и почему он такой какой он есть. В течение этих трех лет я делал многое неправильно.

Учусь до сих пор, но успех таких команд и проектов как iDOM доказывает мне, что я на правильном пути.

Желаю Александру, его проекту и команде успехов. Буду рад уделить его проекту пару часов личного времени.

Удач!

Классика руководства проектом конечно работает, если руководитель обладает умениями, навыками и талантами. Дело лишь в том, что такой подход может вести к следующим проблемам управления:

1. выращивание узкоспециализированных специалистов (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
2. это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не командна, со всеми вытекающими;
3. у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
3. подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
4. когда в итоге новых людей подключают, у PM-а работы только прибавляется;
5. в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции

вместо этого они могли бы заниматься:
а) развитием продутка;
б) формированием команды и устранением пряпятствий на её пути;
в) высокоуправленческой функцией на уровне предприятия.
и т.д.

теперь о проблемах по задачам и прогрессу проекта:
1. так как члены рабочей группы работают над своими задача (частями функционала), размеры задач и темпы работы людей разняться, то какая-то часть фич оказывается сделана частично;
2. что такое частично сделанная работа (фича) – это вливания инвестиций, которые не вернулись;
3. эти фичи нельзя потестировать и, если их много, то проект оказывается в состоянии “мы на половине проекта” или “50% фич сделаны наполовину”;
4. это непрозрачно и рискованно для инвесторов, заказчиков, подрядчиков – всех заинтересованных сторон.

это неуправляемый проект. титаник.

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

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

приходите на PM-labs на наш доклад по этой теме