Идея не новая ) Роберт Шекли «Билет на планету Транай». У президента с первого дня был неснимаемый ошейник со взрывчаткой. Граждане приходили в специальную комнату и могли нажать кнопку, выражающую поддержку или неподдержку того или иного решения президента. Когда таких «отрицательных» очков набиралось достаточно — ошейник взрывался

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

Это вполне стыкуется с «принципом единоначалия», что за успех или провал проекта несет ответственность один человек. Спрашивать за возникшие серьезные проблемы с команды — это как-то глупо, и не один заказчик не станет этого делать. Финансово-бюджетные вопросы, решение о наеме и перераспределении людей в командах также лягут на такого менеджера. Равно как и ответственность за анализ рисков по контракту.

По-поводу роли Product Owner. Он мог бы соответствовать роли ПМ, т.к. именно он знает приоритеты требований и что и в какой момент ДОЛЖНО появиться в продукте, а также КОГДА должна начаться опытная эксплуатация и обучение. Он может даже вести диаграмму Ганнта, где будет расписано какая фича и в какой итерации появится. Однако т.к. product owner может быть назначен со стороны заказчика, а не организации-исполнителя, а также не несет ответственность за другие активности — это не ПМ.

Scrum master — тоже не ПМ. Но его роль очень важна на этапе становления agile команды. В самом начале работы по agile команда не сможет просто так взять и самоорганизоваться. Ее «самоорганизует» scrum master до тех пор, пока не наступит «привыкание к agile» и команде не станет на ноги самостоятельно. После этого роль scrum master уходит на второй план и он уже не так нужен. Хотя, с кого тогда будет спрашивать delivery manager? ;-)

Очевидно, что при вышеуказанной организации работы delivery/account manager будет-таки следить за статусом работы КАЖДОЙ из команд и обращаться к scrum master или product owner соответствующих команд для решения возникающих проблем.

джуниор на то джуниор что ему надо учится всему, везде и всегда

полностью согласен. по-другому быстро двигаться вперед и вверх будет сложно.

Более того вы смотрите у кого там какая з.п. по статистике чтобы пристроится на как можно более теплое местечко, абсолютно не подумав над тем что много платят тем кто по настоящему крут в своем деле, независимо от того прошивает он микросхемы или пишет сервак на Java EE

А вот это как раз не запрещено и разумно, т.к. пока станешь из никого «по-настоящему крутым в своем деле», то остальные вокруг будут искать (и находить!) теплые местечки. Впрочем, все зависит от цели — быстро получить максимум знаний и навыков, за маленькую ЗП, чтобы потом резко «скакнуть» в цене. Либо предпочесть краткосрочную перспективу с неплохой ЗП, но медленным развитием и риском вылететь с работы, если будет общий кризис.

Да еще какие-то непонятные фразы про рутиную работу и неинтересные проекты у вас проскакивают

«Интересный проект» уже давно стало HR-клише :-) Плюсь для «начинателей» постоянная рутинная работа (например перманентный суппорт) противопоказана — скиснут и будут посредственно работать, даже если офигенные специалисты. Тут уже играет человеческий психотип.

Из минусов — высокий «порог входа». Надо много читать и пробовать. Зато нереально интересно!

Никогда не задумывался, что технический долг можно вот так вот трекать, так сказать «пАрами» задач. Мы все больше по-наколенному: ставим коменты «FIXME» в коде. Иногда с привязкой к номерам тикетов в трекере, но чаще без оных. Надо будет попробовать Ваш подход. Менеджменту ведь FIXME не продашь :-)

По-поводу отслеживания тех долга в большой команде — можно попробовать применить комбинированный подход. На макроуровне — тикеты, на микроуровне — FIXME комментарии в коде, полученные в результате код-ревью. Тикеты будут видны в трекере, а FIXME видны в среде разработки а также могут быть собраны в отчет на Continuous integration сервере (по-крайней мере Jenkins, он же Hudson имеет на борту плагин, который это делает).

Но в fucking open space, который неистребим, совершенно нереально выполнять работу, связанную с кодированием или написанием документации, без наушников и нормальной музыки.

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

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

К тому же ситуацию где «все друг другу друзья» редко встретишь в крупных компаниях, где обязательно есть «карьеристы-верхолазы» (это можешь быть и ты сам!). Так что полезно расширять кругозор и смотреть «где водятся драконы». А IT-не-IT — по-моему без разницы. Законы психологии для людей одного интеллектуального уровня одинаковы.

Если заказчик адекватен и команда хорошо мотивирована, то можно сообщить наиболее вероятную дату N и N+< запас на непредвиденные обстоятельства> и команде и заказчику. «Запас» обычно делается на основании предыдущего опыта выполнения сходных задач или вообще «от балды», если подобных задач еще не было.

Если же по каким-либо причинам заказчику трудно аргументировать наличие «запаса» ИЛИ у команды плохо с мотивацией — я за применение подхода, описанного SerG.

В любом случае мы имеем дело с риском опоздать на столько-то дней. Стрельнет он или не стрельнет — зависит от правильности исходных предположений, сложившейся в ходе проекта/итерации ситуации и положения звезд на небе. Если не стрельнул — все в шоколаде и выкатываем результат к дате N. Если стрельнул — ну что ж, все, кому надо, знали, что может случиться и все остается под контролем.

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

P.S. кто-то сказал: «В управлении проектами существует лишь один смертный грех — знать о надвигающейся катастрофе и никого не предупредить об этом».

P.S. Всегда забавляли диаграммы Ганнта, когда на одного человека в один период времени было навешено больше одной задачи (50% — тут, 50% — там). Полтора землекопа... В лучшем случае получается: 25% — тут, 25% — там. А в реале: ХЗ% — тут, ХЗ% — там, но всегда больше суммарного запланированного срока на обе задачи.