Безусловно спорная. Более того, через год у меня вполне могут изменится условия и задачи, и я вернусь к старому доброму институту проектного офиса.
Про второй пункт хочется ответить: стало больше ролей, но вы же знаете, что в гибких методологиях один из негласных принципов: two pizzas team. Роли — ролями, а размер команд лучше держать до 10 челоек. А не как в одном крупном изместном банке, где на переписывание софта для call-center собирали отдел в 50 человек.

Вы верно уловили суть.

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

Что тут говорить, если самые классические банки начинают создавать свои «лаборатории» или «гаражи», отказываясь в них от иерархических функциональных структур.

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

Согласен, но это тема на отдельную дискуссию. Про то, как за последние 5-7 лет в IT начали меняться требования к руководителям людей. Это очень интересный процесс. И у меня сейчас на работе очень наглядная ситуация с двуми группы специалистов: с хорошим управлением людьми и без него. Разница видна невооруженным глазом.

Согласен с очень базовой вещью: если работу нужно сделать, кто-то ее должен сделать. Ее можно перекладывать между ролями, но исчезнуть она не может, если только не сменятся условия (изменение методологии, автоматизация, отсутствие требований и т.д.).
Но вот что интересно: разработчики растут. Тут уже был комментарий про то, что зрелость IT специалистов на рынке подросла. Сейчас есть возможность собрать команды, в которых уровень ответственности и осознанности TL и старших разработчиков будет таким, при котором им в рамках гибкой методологии не нужен будет PM.

Вот тут я не соглашусь. Если команде, когда что-то пошло не так, нужен менеджер, это незрелая команда. Вот у меня в командах разработки на 7-10 человек есть TL и три старших специалиста (BE, FE, QA). И они потому TL и старшие, что умеют решать сложные вопросы и не давать спринтам идти не так. Они очень опытные, умные, мотивированные, интересные, веселые и позитивные ребята. Им точно не нужен PM. Ему просто нечего будет делать днями напролет.

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

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

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

Не соглашусь только с жесткой связкой: зрелость компании и необходимость PM-а. Подумайте, Spotify или Valve — зрелые компании. Но работают без PM-ов. Я думаю, это больше вопрос требований к продукту и процессу, чем зрелость компании.

В статья я рассуждал о диаграмме Гантта. Ее главная сила с моей, сугубо личной, точки зрения состоит в управлении зависимостями. А в современной разрботке зависимостям фактически объявлена война.
В гибких методологиях план работ существует в другом виде. Чаще всего я встречал его как сочетание roadmap-а фич на горизнте плюс-минус года, набора квартальных целей и целей и составов спринтов.

Согласен полностью. Лучшие из Product Owner-ов полным ходом осваивают SQL для работы с первоисточниками данных на репликах и временами что-то пишут в команде. И развитие программистов в менеджменте востребовано и происходит все активнее. Оба процесса очень правильные.

Я тут привел личное мнение про состав кросс-функциональных команд. Что, кстати, было до недавних пор одним из главных расхождений во мнении с руководителем разработки на моей прошлой работе. Я не сторонник классического Scrum и очень ценю именно глубокую профессиональную экспертизу.

В случае с DevOps, QA и PM действительно так происходит. Не везде. И это, пока что, не стало трендом. Но примеры есть. В 2015ом крупная европейская eComm компания с штатом в 250+ разработчиков одномоментно расформировала отделы системных администраторов и «обрадовала» команды разработки, что они теперь сами за прод отвечают. Шок, это очень мягкое определение того, что там было. Но ничего, справились. Работают.

Я бы дальше пошел. Сейчас пора на полном серьезе задуматься, а что мы будем делать в эпоху автоматизации работы. Вот на Medium была интересная заметка: «The Coders Programming Themselves Out of a Job». Там обсуждали, в частности, разумно ли говорить работодателю, что ты автоматизировал свою работу. Часть тех, кто на это отважился, были уволены с аргументацией, что не за что тебе теперь платить зарплату.

Это я к тому, что история с распределением работы PM-а внутри команды еще не самое сложная. Сложнее, когда работу забирает автоматизация.

На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.

Я прошу прощения, если ввел в заблуждение своим отступлением в сторону в тексте. Я считаю, что кроссфункциональная команда — это группа профильных специалистов, решающих общую задачу. Они не должны быть fullstack разработчиками. Наоборот, чем более профессиональны FE, BE и QA, тем сильнее команда и быстрее делается работа. Про fullstack я вспомнил просто как пример того, что все идеи ходят по кругу.

Это выглядит странно. Под кросс-функуиональными командами я имел в виду команды, где каждый специалист профессионал в своей области, но все вместе делают один продукт. И сравнивал с классическим подходом, когда есть отдел Java с руководителем, отдел FE с руководителем. И у QA есть свой руководитель. И все эти руководители распределяют задачи между сотрудинками каждый по своей системе. Это не архаика, вот прямо сейчас, в 2019ом у моего друга, который в роли PO работает, такая структура пытается проекты делать.

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

Тут я могу сказать, что без оптимизаций выдачи в профиле истории операций, мы получили заметную деградацию. Но после нескольких быстрых доработок окончательная производительность просела относительно Oracle примерно на 10-15%. Сейчас смотрим что можно сделать в плане следующей волны оптимизации, которая должна дать прирост порядка 30%. При этом, за счет отказа от переноса старых таблиц, дефрагментации и сжатия BLOB, мы в PostrgreSQL получили экономию дискового пространства порядка 40% относительно Oracle.

Зарплату, конечно, не урезали. В этом нет смысла, наши DBA активно участвуют в миграции и осваивают PSQL. А вот про плюшки можно долго говорить. Их много. Во-первых, это банальная экономия. Oracle очень дорогой и в стоимости лицензий, и в поддержке. Тарифицируется в долларах, скидки дает в единицах процентов. Во-вторых, для нас крайне актуально легкость в поднятии новых баз с учетом микро-сервисной модели, обилия тестовых стендов и необходимости, порой, иметь локальную БД на разработческом ноутбуке. Тут с PSQL все сильно проще. В-третьих, за счет лицензии open source и сообщества к PSQL достаточно быстро делают необходимый в администрировании и эксплуатации инструментарий. И он так же бесплатный.

С пятью миллионами все просто — для значимых проектов у нас есть практика оценочно проверять их стоимость. Это не расходы на покупку софта или услуги подрядчиков, это пересчет времени наших специалистов в деньги. Мы раз в полгода-год берем все прямые расходы (зарплата, премии, налоги) и косвенные (аренда, связь, общие расходы) и расчитываем стоимость человеко-дня по ключевым ролям. Не стремимся к точности до копейки, достаточно грубой оценки. Зато благодая этому можно для любого проекта очень быстро прикинуть его планируемую и фактическую стоимость для компании. Очень помагает осознавать масштаб инициатив или сравнивать с аналогичной стоимостью на рынке у аутсорсеров / интеграторов.