Projektmanagement mehrerer Produktlinien, vernetzter Projekte 75 Entwickler, 7-8 Produktmanager in einem agilen Manager

Wir sind eine mittelgroße Produktorganisation mit 700 Mitarbeitern, davon etwa 100 im technischen Bereich, 75 Entwickler (einschließlich Leads und Arch), 15–18 QA-Leute, 7–8 technische Produktmanager.

Wir haben ungefähr 70 Einzelposten in einer sogenannten Projekt-Bucket-Liste, aber wenn ich sie wirklich kategorisieren müsste, wären es 10-15 Hauptprojekte mit mehreren Unterprojekten unter jedem Bucket.

Wir haben mobile Apps, Websites, administrative Websites, Backend-Komponenten und miteinander verknüpfte B2B- und B2C-Plattformen mit mehreren Unterkomponenten in verschiedenen Sprachen von Java, .Net, .Net Core, go, php usw., wobei einige Projekte Abhängigkeiten von externen Drittanbietern aufweisen Von Banken über staatliche Einrichtungen bis hin zu Telekommunikationsunternehmen usw.

Die Herausforderung, vor der ich stehe, ist, wie ich diese Leute dazu bringe, vorhersehbare, effiziente und relativ fehlerfreie Projekte zu liefern.

Ich bin nicht mehr auf der technischen Seite, aber aufgrund meines Hintergrunds als Entwickler und Architekt stand ich vor langer Zeit vor der Herausforderung, dies zu bewältigen und die derzeitige chaotische und völlig unvorhersehbare Überschreitung und die extrem aufgeblähten Zeitpläne dazu zu bringen, Dinge schnell, agil und vorhersehbar zu liefern und Qualität.

Wir haben begonnen, Confluence zu verwenden, wo wir unsere vollständigen BRD/PRDs (User Stories und Details) schreiben, und Jira, wo sie weiter in Epics, User Stories, Issues, Tasks und Subtasks unterteilt sind.

Diese Leute folgen kaum einem Prozess, wie bringt man alle auf dieselbe Seite und wie bringt man Produktmanager dazu, die Entwickler und die QA dazu zu bringen, qualitativ hochwertige Ergebnisse zu liefern?

Zum Hintergrund: Wir haben 2-3 Hauptprodukte, aber mehr Produktmanager, weil es einfach zu viel Arbeit an jedem Produkt gibt und wir daher ein Team brauchen, um ein bestimmtes Produkt zu verwalten.

Etwas Hilfe / Anleitung / Zauberformel wäre sehr dankbar :)

Für welchen Ansatz Sie sich auch entscheiden, stellen Sie sicher, dass Sie (oder ein sehr engagierter, sehr leidenschaftlicher Projektsponsor) die Befugnis haben, die Änderung tatsächlich durchzusetzen und Mitarbeiter einzustellen/zu entlassen. Eine so große Veränderung wird nicht in einem vernünftigen Zeitrahmen durch „Führen durch Einflussnahme“ erreicht. Versuchen Sie auf jeden Fall, mit allen beteiligten Parteien einen Konsens und guten Willen aufzubauen, aber die Änderung muss Biss haben oder Sie werden zum Scheitern verurteilt.
„Diese Leute folgen kaum einem Prozess, wie bringt man alle auf dieselbe Seite und wie bringt man Produktmanager dazu, die Entwickler und die QA dazu zu bringen, qualitativ hochwertige Ergebnisse zu liefern?“ Dies wird als Führung bezeichnet und ist das, was von Ihren Führungskräften und der C-Suite erwartet wird. Obwohl es Dinge gibt, die Sie beeinflussen können, liegt die Definition und Durchsetzung von Prozessen auf Unternehmensebene nicht wirklich in der Verantwortung des einzelnen Projektmanagers.
Klingt nach vollwertigem Programmmanagement. Sehen Sie sich die Arbeit von Johanna Rothman an, zB amazon.com/Agile-Lean-Program-Management-Collaboration/dp/…

Antworten (2)

Ich würde auch hinzufügen, dass Sie bei einer Änderung der Größenordnung, die Sie in Betracht ziehen, klein denken sollten, mit einem Produkt und einem Entwicklungsteam beginnen, versuchen sollten, sie zum Laufen zu bringen, und dann weitere Produkte und Teams hinzufügen sollten, wenn sich der Umzug einbürgert .

Erwägen Sie auch, einen Agile Coach zu beauftragen, der Ihnen hilft, da dies kein kleines Unterfangen ist. Stellen Sie sicher, dass das Unterfangen von Führungskräften gesponsert wird, da Entwicklerteams ziemlich widerspenstig sein können, ihre Arbeitsweise zu ändern, und sie oft nicht sehen, dass es irgendein Problem mit dem Status quo gibt.

Schließlich geben Sie nicht auf, es gibt viele Hürden, die es zu überwinden gilt, agile Techniken in einer bestehenden Entwicklungsorganisation zu etablieren, aber wenn es Chaos in Ordnung verwandelt, wird es viele Vorteile haben.

Viel Glück!

Skalierte Scrum-Frameworks sollten gut funktionieren. Sie können Nexus, LeSS oder SAFe ausprobieren. Nexus ist mein Favorit.

Im Allgemeinen ist es eine schlechte Idee, ein schlechtes Agile/Scrum-Team zu skalieren. Außerdem können Sie meiner Meinung nach ohne die ordnungsgemäße Verwendung von Continuous-Integration-Pipelines kaum effektiv sein.