Должен ли архитектор программного обеспечения подчиняться менеджеру проекта? [закрыто]

Я считаю, что это ложная дихотомия по следующим причинам:

• Менеджер проекта не должен пытаться навязать свое мнение об архитектуре программного обеспечения, это не его работа. Их работа состоит в том, чтобы управлять процессом доставки «продукта» в соответствии с требованиями. Они делают это, координируя/используя экспертов в предметной области (например, архитекторов) в команде проекта для обеспечения необходимых элементов. Если PM придерживается (и пытается внедрить) мнения об архитектуре программного обеспечения, тогда роли и обязанности размыты, и именно это размытие создает проблему. Роли и обязанности всех членов команды проекта, включая PM, должны быть четко определены в документе об инициации проекта и однозначно понятны всем.
• Архитектура программного обеспечения (предположительно) будет помогать на этапах проектирования программного проекта и, следовательно, отвечает за создание элементов конечного результата. В этом отношении их результаты становятся частью результатов проекта и, соответственно, находятся под контролем Менеджера проекта. Таким образом, для целей проекта они являются частью команды проекта, условно управляемой менеджером проекта, но это не означает, что менеджер проекта может или должен переопределить их — это не должно быть так, как работает управление проектом (см. выше)

Подводя итог, по моему мнению и в идеальном мире, архитектор «отчитывается» перед проектным менеджером (или, точнее, вносит свой вклад в проект, которым управляет проектный менеджер), но проектный проект не превосходит их вклад. Я уверен, что в реальном мире есть много вариантов такого расположения со всеми возможными оттенками вдоль континуума, но проблема здесь исключительно в том, что роли и обязанности не определены четко и не соблюдаются всеми.

Хотя я в принципе согласен с другими ответами, я редко сталкиваюсь с такой чистой и истинной формой дисциплины управления проектами, которая практикуется в реальном корпоративном мире.

Важно посмотреть, где существуют невысказанные мотивы, которые могут исказить предполагаемые мотивы Менеджера проекта. Да, в принципе руководитель проекта несет ответственность за реализацию проекта в рамках бюджета и в срок. Важно помнить, что, поскольку PM является арбитром стоимости и времени, они представляют только 2 из 3 основных принципов общего объема работ.

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

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

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

Концепция та же. Они существуют как важные участники проекта, а не как участники команды разработчиков.

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

Эти роли предназначены для повседневных общих управленческих обязанностей (посещаемость, обзоры производительности, рабочие задания). Что касается обязанностей по проекту, Архитектор должен будет отчитываться о прогрессе, проблемах и планировании PM. Если предложенный дизайн по какой-то причине не соответствует потребностям бизнеса, например, его реализация займет много времени, это вызов PM. Как правило, если архитектор и менеджер по проектам не могут найти приемлемое решение, они переходят на более высокие уровни управления для принятия окончательных решений.

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

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

Предполагая, что вы имеете в виду отчеты в значении «работы для» (очевидно, что архитектор должен сообщать о ходе работы менеджеру проекта, если это необходимо), простой ответ таков:

Менеджер по доставке не должен управлять членами группы доставки, существует конфликт интересов

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

Наделение одной стороны высшими полномочиями создаст неприступную ситуацию (было такое), когда проект сильно скомпрометирован, чтобы уложиться в сроки и/или в бюджет. Поочередно с PM на буксире к архитектуре вы в конечном итоге столкнетесь с ситуацией Duke-Nuke'em Forever, когда ничего не поставляется, так как его нужно дорабатывать/рефакторить.

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