Soll der Softwarearchitekt dem Projektleiter unterstellt sein? [geschlossen]

Ich glaube, dass dies aus folgenden Gründen eine falsche Dichotomie ist:

• Der Projektmanager sollte nicht versuchen, seine Meinung zur Softwarearchitektur durchzusetzen, das ist nicht seine Aufgabe. Ihre Aufgabe ist es, den Prozess der Lieferung eines "Produkts" gemäß den Anforderungen zu verwalten. Sie tun dies, indem sie Fachexperten (z. B. Architekten) innerhalb des Projektteams koordinieren/einsetzen, um die erforderlichen Elemente bereitzustellen. Wenn der PM Meinungen zur Softwarearchitektur vertritt (und versucht, diese umzusetzen), werden die Rollen und Verantwortlichkeiten verwischt, und diese Verwischung verursacht das Problem. Die Rollen und Verantwortlichkeiten aller Projektteammitglieder, einschließlich des PM, sollten im Projektinitiierungsdokument klar definiert und von allen eindeutig verstanden werden.
• Die Softwarearchitektur unterstützt (vermutlich) die Designphasen eines Softwareprojekts und ist daher für die Erstellung von Elementen des Liefergegenstands verantwortlich. Insofern werden ihre Ergebnisse Teil der Projektergebnisse und unterliegen dementsprechend der Aufsicht des Projektmanagers. Für die Zwecke des Projekts sind sie also Teil des Projektteams, das fiktiv vom Projektmanager geleitet wird, aber das bedeutet nicht, dass der Projektmanager sie außer Kraft setzen kann oder sollte – so sollte Projektmanagement nicht funktionieren (siehe oben).

Zusammenfassend lässt sich sagen, dass der Architekt meiner Meinung nach und in einer idealen Welt dem PM „berichtet“ (oder genauer gesagt sein Fachwissen in das Projekt einbringt, das der PM verwaltet), aber der PM übertrumpft seinen Beitrag nicht. Ich bin sicher, dass es viele Varianten dieser Anordnung in der realen Welt gibt, mit allen möglichen Schattierungen entlang des Kontinuums, aber das Problem hier liegt ausschließlich darin, dass Rollen und Verantwortlichkeiten nicht klar definiert und von allen eingehalten werden.

Während ich anderen Antworten grundsätzlich zustimme, erlebe ich selten eine so reine und wahre Form der Projektmanagement-Disziplin, die in der realen Unternehmenswelt praktiziert wird.

Es ist wichtig zu prüfen, wo unausgesprochene Motivationen existieren, um die beabsichtigten Motivationen des Projektmanagers zu korrumpieren. Ja, grundsätzlich ist der Projektmanager dafür verantwortlich, das Projekt budget- und termingerecht abzuliefern. Es ist wichtig, sich daran zu erinnern, dass der PM, da er der Schiedsrichter von Kosten und Zeit ist, nur 2 der 3 Grundprinzipien des gesamten Arbeitsumfangs repräsentiert.

In den meisten Organisationen sind Projektmanager nicht von Natur aus und natürlich nicht motiviert, der Qualität angemessenen Respekt und Aufmerksamkeit zu schenken, was zu der unersättlichen Versuchung für einen PM in einem schwierigen Projekt führt, Qualität zu opfern oder Entwicklungsentscheidungen zu beeinflussen, die Zeit und Kosten begünstigen die Kosten der Qualität.

Dies ist der Hauptgrund, warum die technische Architektur, die auf der hohen Ebene des Designs arbeitet und sich auf Qualitätsattribute konzentriert , so entscheidend wichtig ist, dass sie nicht an die Berichtsstruktur des Projekts im Allgemeinen gebunden sind. Wenn die Organisation den technischen Architekten und die Qualitätsattribute in der Software schätzt, werden sie nicht an Projektbeschränkungen gebunden und dienen stattdessen als Gleichgewichtsprüfung dagegen. Wenn Sie sich die Rolle eines technischen Architekten in einer agilen Organisation vorstellen würden, würden sie eng mit dem Product Owner zusammenarbeiten, um die Softwareanforderungen zu definieren und Erwartungen an ein hochwertiges Design zu setzen.

Würden Sie auch argumentieren, dass der Projektmanager den Product Owner bei der Definition von Softwareanforderungen und -umfang zur Rede stellen sollte? Natürlich nicht, das wäre lächerlich.

Das Konzept ist das gleiche. Sie existieren als wichtiger Stakeholder im Projekt und nicht als beitragendes Mitglied des Entwicklungsteams.

Der Architekt sollte der Person unterstellt sein, die für die Leitung des Entwicklungsteams verantwortlich ist, typischerweise ein Entwicklungsleiter, aber in kleineren Betrieben könnte es ein allgemeiner IT-Manager sein. Der PM sollte dem Business Manager unterstellt sein, jedoch wird der PM häufig der IT-Abteilung zugeordnet. In diesem Fall sollte der PM der für das IT-Geschäft verantwortlichen Person unterstellt sein, die in kleineren Unternehmen dieselbe Person sein könnte, die die Entwicklung leitet.

Diese Rollen sind für die täglichen allgemeinen Managementaufgaben (Anwesenheit, Leistungsbeurteilungen, Arbeitsaufträge) vorgesehen. Für Projektverantwortungen muss der Architekt dem PM Fortschritt, Probleme und Planung melden. Wenn das vorgeschlagene Design aus irgendeinem Grund nicht den Geschäftsanforderungen entspricht, weil die Implementierung zu lange dauert, ist dies der Anruf des PM. Wenn der Architekt und der PM im Allgemeinen keine akzeptable Lösung finden, wird dies an die höheren Managementebenen eskaliert, um endgültige Entscheidungen zu treffen.

Oftmals bedeuten diese Entscheidungen, von Best Practices oder Standards abzuweichen, die eingeführt wurden, um geschäftliche Anforderungen zu erfüllen. Es ist die Aufgabe des Architekten, herauszufinden, wie die neuen Anforderungen außerhalb der Praxis erfüllt werden können, und einen Plan zu erstellen, wie diese Probleme behoben werden können, sobald die Zeitkrise vorbei ist. Kämpfen Sie nicht weiter in einer Schlacht, die bereits verloren ist, es sei denn, es treten neue ernsthafte Bedenken auf.

tl;dr; Es ist die Aufgabe des Architekten zu versuchen, dem Projektmanager das gewünschte Design innerhalb der von ihm angeforderten Parameter bereitzustellen.

Angenommen, Sie meinen Berichte im Sinne von "arbeitet für" (offensichtlich sollte ein Architekt den Fortschritt gegebenenfalls einem PM melden), lautet die einfache Antwort:

Kein Mitglied des Lieferteams sollte von einem PM verwaltet werden, es besteht ein Interessenkonflikt

Die Aufgabe des PM besteht darin, sicherzustellen, dass das Projekt pünktlich und zu minimalen Kosten geliefert wird. Das Lieferteam (insbesondere Architekten wie im Beispiel) ist dafür verantwortlich, ein zweckmäßiges Design und eine zweckdienliche Implementierung zu liefern, und dies könnte durchaus nicht in den Plan des PM passen, und ein Projekt erfordert Kompromisse auf beiden Seiten, um es zu liefern.

Einer Seite die ultimative Autorität zu geben, wird eine unangreifbare Situation schaffen (da gewesen), in der das Projekt stark kompromittiert wird, um Zeit und/oder Budget einzuhalten. Alternativ mit PM im Schlepptau zur Architektur endet man in einer Duke-Nuke'em Forever-Situation, in der nichts ausgeliefert wird, da es verfeinert/überarbeitet werden muss.

Sie brauchen die technische Bereitstellung und das Projektmanagement auf entgegengesetzten Seiten, um sich gegenseitig herauszufordern, auf diese Weise liegt ein gutes Projekt (auch wenn es sich zu diesem Zeitpunkt vielleicht nicht so anfühlt).