Aufteilung der PM-Verantwortung zwischen technischem Leiter und nicht-technischem PM in einem agilen Projekt?

Erstens könnten Sie verschiedene Methoden/Frameworks verwenden, um Projekte durchzuführen. Scrum wäre hier nicht unbedingt die Lösung, da Ihr Hauptanliegen in der Verantwortungsgrenze zwischen diesen beiden unterschiedlichen und erforderlichen Rollen liegt. Sowie die richtige Ebene der Kommunikation einzurichten.

Ich habe dem Ton Ihrer Frage etwas entnommen, das bereits ein Problem hervorzuheben scheint. In deiner Frage sagst du:

Ein nicht technischer PM kann bestimmte Abhängigkeiten nicht identifizieren, weil er keine Ahnung hat, dass sie existieren. Daher meine Frage.

In diesem Sinne würde ich dringend empfehlen, dass Sie damit beginnen, das Attribut „nicht technisch“ von der Rolle zu entfernen. Das ist nicht das eigentliche Problem. Die Rolle des PM besteht nicht darin, die technischen Abhängigkeiten selbst zu erarbeiten, sondern sie mit der Unterstützung und dem Fachwissen des beteiligten Teams zu verwalten. Wenn Sie der technische Leiter sind, sind Sie dafür da. Sie haben die besten detaillierten Informationen über die technischen Aspekte des Projekts und verstehen die Abhängigkeiten besser.

Um auf die Aufgabentrennung zurückzukommen, könnten Sie sich auf Projektmanagement- und Bereitstellungs-Frameworks wie DSDM Atern beziehen . Wenn Sie sich das unten stehende Diagramm DSDM Atern Rollen und Verantwortlichkeiten ansehen, können Sie erkennen, dass die Rollen Projektmanager (blau) und Technischer Koordinator (grün) zusammenarbeiten, um einen geschäftlichen Nutzen zu erzielen (zusammen mit Business Sponsor und Visionary).

Einige der Verantwortlichkeiten des Projektmanagers in diesem Modell wären:

• Kommunikation mit der Geschäftsleitung und den Projektleitungsbehörden (Unternehmenssponsor, Projektausschuss, Lenkungsausschuss usw.) mit der Häufigkeit und Formalität, die sie für notwendig erachten
• Projektplanung und Terminierung auf hoher Ebene, aber keine detaillierte Aufgabenplanung
• Überwachung des Fortschritts anhand der Baseline-Projektpläne
• Management von Risiken und allen Problemen, sobald sie auftreten, Eskalation an leitende
  geschäftliche oder technische Rollen nach Bedarf
• Verwalten der Gesamtkonfiguration des Projekts Motivieren der Teams, ihre Ziele zu erreichen
• Verwaltung der geschäftlichen Beteiligung innerhalb der Lösungsentwicklungsteams
• Bereitstellung von Spezialistenrollen nach Bedarf Behandlung von Problemen, die von den Lösungsentwicklungsteams eskaliert wurden
• Coaching der Solution Development Teams beim Umgang mit schwierigen Situationen

Während für den Technischen Koordinator :

• Abstimmung und Kontrolle der technischen Architektur
• Bestimmung der technischen Umgebungen
• Beratung und Koordination der technischen Aktivitäten jedes Teams
• Identifizieren und Besitzen von architektonischen und anderen technisch basierten Risiken, gegebenenfalls Eskalation an den Projektmanager
• Sicherstellen, dass die nicht-funktionalen Anforderungen erreichbar sind und anschließend erfüllt werden
• Gewährleistung der Einhaltung angemessener Standards der technischen Best Practice
• Kontrolle der technischen Konfiguration der Lösung
• Verwaltung der technischen Aspekte des Übergangs der Lösung in den Live-Einsatz
• Beheben technischer Differenzen zwischen technischen Teammitgliedern

Die Kombination der beiden Rollen ist wirklich mächtig und führt in der Regel zum Projekterfolg.

Jetzt müssen wir das Kommunikationsproblem angehen.

Ich sage den Leuten immer, sie müssen aufhören, darauf zu warten, dass etwas passiert, und später mit dem Finger zeigen, wenn die Dinge nicht so gelaufen sind, wie sie es erwartet haben. Dieses Verhalten hilft niemandem.

Wenn sich der Projektmanager in Ihrem Team nicht gemeldet hat, um mit Ihnen zu erarbeiten, wie regelmäßig Sie sich treffen sollten oder welche Tools zum Berichten erforderlich sind, fühlen Sie sich mehr als befähigt, dieses Gespräch selbst zu beginnen.

Sie haben erwähnt, dass Sie Jira bereits verwenden, also könnten Sie beide vielleicht ein paar Stunden zusammensitzen, um herauszufinden, wie Sie die Funktionalität am besten nutzen können, um technische Abhängigkeiten zu erfassen - Vorgänge aus verschiedenen Projekten mit einer Projektliste "Abhängigkeiten" zu verknüpfen - Status zu melden, und mitteilen, ob es bereits ein Team gibt, das sich mit dem Problem befasst usw.

Ich habe Jira persönlich mit GreenHopper für ähnliche Berichte verwendet und es hat sehr gut funktioniert.

Ich verstehe, dass die Situation ist:

1. Sie sind technischer Leiter (TL),
2. Sie berichten an einen PM, der keine oder fast keine Domänenkenntnisse, technische Kenntnisse hat.
3. Der PM versteht dich nicht.

"Ein nicht-technischer PM kann bestimmte Abhängigkeiten nicht identifizieren, weil er keine Ahnung hat, dass sie existieren.": Muss er nicht. Ich denke, es ist Ihre Hauptaufgabe, die Probleme so zu erklären, dass er sie versteht.

Wenn ich Sie wäre, würde ich in der Sprache sprechen, die der PM verstehen und mit mir übereinstimmen kann.

Sprechen Sie direkt mit dem PM und definieren Sie eine klare RACI-Matrix , das ist eine gute Idee.

Der Hauptpunkt für die RACI-Matrix könnte hier sein: 1. Der technische Leiter verwaltet und meldet technische Probleme, warnt vor möglichen nicht-technischen Problemen, die er wahrnehmen kann. 2. Der PM verwaltet alle nicht-technischen Aspekte des Projekts, wie z. B.: HR , Anforderungen, Risiken, Kommunikation, Budget...

Sie können nach googeln

• „Technischer Leiter“ „Projektmanager“ RACI

um zu sehen, wie sich ein TL und ein PM unterscheiden.

Um ehrlich zu sein, wenn Ihr Projekt einen nicht-technischen Projektmanager hat, der sich nicht sehr gut mit der Geschäftslogik oder den funktionalen Aspekten des Projekts auskennt und auch an anderen Projekten beteiligt ist, sollte seine Beteiligung am Projekt nicht größer sein als die von Managementaufgaben – was eine nettere Art zu sagen ist – „Ihrem Team den Mist aus dem Weg zu räumen und Sie und das Entwicklungsteam sich auf die eigentliche Arbeit konzentrieren zu lassen“.

Er konnte:

1. Nehmen Sie an endlosen Geschäftsmeetings teil und informieren Sie das Entwicklungsteam und Sie in 5 Minuten über die relevanten Dinge, damit sich das Team (und Sie) auf echte Entwicklungsarbeit konzentrieren können.
2. Helfen Sie bei der Pflege von Stundenzetteln und Projektplänen und aktualisieren Sie diese akribisch, damit der Rest des Teams keine TPS-Berichte einreichen muss . :)
3. Führen Sie alle anderen nicht-technischen Dokumentationen durch, an denen niemand im Team interessiert ist.
4. Treffen Sie sich informell mit Ihnen und dem Team und helfen Sie dem Team, das zu bekommen, was es für seine Arbeit benötigt (Server, Lizenzen, Hardware, Pizza, Kaffee usw.).
5. Werben Sie für das Team und die Arbeit, die das Team leistet, für den Rest des Unternehmens. Positive Schwingungen und Wahrnehmungen über das Projekt und das Team tragen wesentlich zum Erfolg des Projekts bei. Geschichtenerzähler sind genauso wichtig wie Erbauer .

Bei Managern, die nicht technisch versiert sind oder eine nicht-technische Rolle spielen, wissen die besten, wie man dem Team aus dem Weg geht, Probleme aus dem Weg räumt, Empathie zeigt, eine positive Stimmung und Wahrnehmung für das Projekt schafft und das Team, besorgen Sie dem Team, was es braucht, um seine Arbeit zu erledigen (Server, Lizenzen usw.) und ermöglichen Sie den Entwicklungsteams, die eigentliche Arbeit mit ungeteiltem Fokus zu erledigen.

Wie Steve Yegge in seinem legendären, aber kontroversen Beitrag beschreibt, kann jeder andere Versuch von nicht-technischen Managern, Programmierer zu verwalten, gefährlich sein .

Wenn Sie nicht auf den obigen Link geklickt haben: http://steve-yegge.blogspot.in/2006/05/not-managing-software-developers.html ist ein Muss.