Ich bin Projektmanager bei NIX United. Mein Team arbeitet an einem IT-Produkt, an dem mehr als 150 Personen beteiligt sind. An diesem Produkt arbeiten zahlreiche Teams, darunter ein Team von 30 IT-Experten von NIX United. Weitere Teams kommen aus Indien, Japan und China.
Wir haben alle das gleiche Veröffentlichungsdatum und den gleichen Rückstand. Daher ist es wichtig, eng mit allen verteilten Kundenteams zusammenzuarbeiten, um Fehler zu vermeiden.
Ich möchte meine Erfahrungen teilen und die Herausforderungen beschreiben, die wir hatten, als wir ein altes Legacy-System auf eine neue Plattform migrierten, und wie wir die Tools und Mechanismen sorgfältig verfeinerten, um den Kundenerwartungen in unvorhersehbaren Situationen gerecht zu werden.
Dieser Artikel wird für Projektmanager, Geschäftsanalysten, technische Analysten und andere Fachleute in einer PM-Rolle nützlich sein.
Warum arbeiten wir angesichts der Unsicherheit?
Zu Beginn des Projekts verfügten wir über ein teilweise zusammengestelltes Team aus Front-, Back- und Client-Entwicklern, Geschäftsanalysten und Qualitätssicherungskräften sowie eine grobe Schätzung, wie viele weitere Fachkräfte benötigt werden könnten.
Es gab jedoch keinen geplanten Arbeitsumfang, keine genaue Schätzung oder keine Startstrategie. Darüber hinaus wurden Schlüsselpersonen des Projekts (Product Owner, technischer Projektmanager und Supervisor) befördert und in andere Projekte innerhalb des Unternehmens versetzt. Erschwerend kam hinzu, dass der Kunde ohne Rücksprache mit uns einen unrealistischen Zeitplan festgelegt hatte.
„“ – werden die Leute sagen. Aber für uns ist das Glas immer halbvoll. Wir arbeiten seit langem mit diesem Kunden zusammen und haben ein vertrauensvolles und respektvolles Verhältnis aufgebaut.
Daher halten wir es für unvernünftig, einen schädlichen Präzedenzfall zu schaffen und die Zusammenarbeit anschließend zu beenden. Darüber hinaus glaubten wir, dass wir die Situation kurzfristig lösen würden.
Wir begannen damit, dass wir uns weigerten, die Frist des Kunden einzuhalten. Stattdessen konzentrierten wir uns auf die T-Shirt-Größe der Aufgaben und erhielten eine überarbeitete Frist, die nur um fünf Monate von den ursprünglichen Terminerwartungen des Kunden abwich.
Darüber hinaus koordinieren wir aktiv den Entwurf und untersuchen die Anforderungen, um etwaige Engpässe und Abhängigkeiten zu anderen Teams zu erkennen. Wir versuchen, alle Risiken im Frühstadium zu minimieren.
All dies geschah in Zusammenarbeit mit dem Entwicklungsteam, um einen intensiven Dialog mit dem Kunden zu führen.
Wie wir auf eine Lösung hinarbeiten
Zunächst informierten wir den Kunden über das Risiko einer Terminüberschreitung sowie über die Möglichkeit unerwarteter Abhängigkeiten von den Teams anderer Kunden, die uns zu diesem Zeitpunkt nicht bewusst waren.
So bereiten wir den Kunden sofort auf mögliche Änderungen vor. Anschließend stellten wir einen neuen Product Owner ein, der die Anforderungen fortlaufend strukturieren und dokumentieren sollte. Unser Hauptziel war es, den Umfang so schnell wie möglich zu gestalten und zu bewerten.
Unsere Maßnahmen machten für den neuen PO Sinn und er wurde Teil des Prozesses. Wir haben unsere Ergebnisse immer noch in Artefakten in einem internen System erfasst, um mit einer gemeinsamen Wissensdatenbank zu arbeiten. Wir beziehen auch andere Teams mit ein, mit denen wir Abhängigkeiten haben, um darüber zu sprechen.
Wir haben auf Situationen hingewiesen, die uns aufhielten und uns daran hinderten, bei Kundengesprächen schneller voranzukommen, ohne den Fokus auf den täglichen Fortschritt zu verlieren. Zum Beispiel das Design des Kunden. Denn ohne Design können wir die Schnittstelle nicht vollständig erstellen.
Nachdem wir die Vorbereitungen abgeschlossen hatten, erstellten wir einen neuen Zeitplan, der alle genannten Risiken berücksichtigte. Der Kunde war nicht enttäuscht, als er den neuen Zeitplan erhielt, da er über jeden Schritt informiert war. Tatsächlich hatte ich es erwartet!
Der Kunde war an dem Prozess beteiligt und in diesem Moment ging es ihm nur darum, die neuen Anpassungen mit der Geschäftsleitung abzustimmen. Gemeinsam mit dem Kunden kamen wir zu dem Schluss, dass unser Team andere Möglichkeiten für die Stakeholder in Betracht ziehen musste.
Es war von entscheidender Bedeutung, von den Projektbeschränkungen Abstand zu nehmen und nach Möglichkeiten zu suchen, den Umfang zu reduzieren, das Team zu erweitern und potenzielle Kundenverluste vorherzusagen. Wir haben drei Optionen entwickelt, jede mit ihren eigenen Kosten und Auswirkungen. Der Kunde nutzte unsere Präsentation als Ausgangspunkt und ließ die Überarbeitungen von der Geschäftsleitung genehmigen.
Die Planungsphase der Datenmigration stellte für uns jedoch eine andere Herausforderung dar. Es reichte nicht aus, alle Funktionen des alten Systems vollständig in das neue zu integrieren.
Daher mussten wir festlegen, welche Organisationen wann auf das neue System migrieren würden. Und damit niemand außen vor bleibt, werden wesentliche Kennzahlen identifiziert und Änderungen können rückgängig gemacht werden, wenn etwas schief geht.
Aufgrund der bevorstehenden Winterferien und Weihnachtspläne mussten wir unsere Datenmigrationsstrategie umstrukturieren und den Start verschieben, da es wichtig war, uns an die Fähigkeiten und den Zeitplan des Kunden anzupassen.
Welche Schlussfolgerungen ziehen wir aus diesem Fall?
Nachdem ich mich mit dem Kunden im oben genannten Szenario befasst habe, möchte ich einige Dinge als Schlussfolgerungen aus diesem Fall ansprechen.
Sag immer die Wahrheit und nichts als die Wahrheit.
Führen Sie so schnell wie möglich eine Prüfung der Probleme durch, da nur so eine neue, funktionierende Lösung gefunden werden kann. Dies erreichen Sie als ein Team mit Ihrem Kunden, das beide an einem erfolgreichen Ergebnis interessiert ist.
Es wäre in unserer Situation ein Misserfolg gewesen, wenn wir uns entschieden hätten, zu schweigen. Erwarten Sie nicht, Glaubwürdigkeit beim Kunden zu erlangen, indem Sie unangemessenen oder gefährlichen Bedingungen zustimmen.
Stakeholder auf Kundenseite müssen synchron sein
Vereinbarungen neu verhandeln. Wenn viele Schlüsselpersonen Entscheidungen treffen, kommunizieren sie möglicherweise nicht miteinander. Es liegt in Ihrer Verantwortung, alle auf den neuesten Stand zu bringen.
Sie liegen völlig falsch, wenn Sie glauben, dass alle Teammitglieder auf Kundenseite mutige Menschen sind, die jeden Tag miteinander streiten. Jeder lebt in seiner eigenen Welt und hat keine Zeit für „zusätzliche“ Aufgaben.
Tauchen Sie ein in das Projekt
Sie werden nicht viel erreichen, wenn Sie sich nicht in das Projekt vertiefen. Leider wird weder die Belastung nach Entwicklungsrichtung geplant, die Fristen nicht richtig berechnet, der entscheidende Weg nicht angezeigt, noch werden die richtigen Statistiken erhoben und nachfolgende Aktivitäten geplant.
Tauchen Sie so weit wie möglich ein. Schreiben Sie sich nicht ab, weil Sie der Entwickler-Community nichts zu bieten haben. Scheuen Sie sich andererseits nicht davor, Fragen zu stellen, aus Angst, sich lächerlich zu machen.
Manchmal hebt der Projektmanager Nuancen hervor, die sonst niemand im Team berücksichtigt hat. Und das alles, weil Sie eine andere Sicht auf das Problem haben als das Entwicklungsteam.
Berücksichtigen Sie die Abhängigkeit Ihrer Agenda von anderen Teams
Es ist von entscheidender Bedeutung, die Kommunikation aller Teams in Einklang zu bringen und ihre Aktivitäten an ihren eigenen Regeln und Praktiken auszurichten. Egal wie unangenehm es auch erscheinen mag, zögern Sie nicht, das Problem direkt anzugehen.
Während einer unserer Hauptversammlungen mit einem Team, dem wir unterstellt waren, erfuhren wir beispielsweise, dass sie nicht die Absicht hatten, die von uns gesuchte Funktionalität in ihre Version aufzunehmen.
Wir stellten fest, dass die von uns erwartete 100-prozentige Reichweite bei weitem nicht der Fall war, als wir ausdrücklich fragten, was sie abdecken könnten. Dieses Team teilte uns auch mit, dass es die von uns erwartete Entwicklungsversion nicht innerhalb einer bestimmten Frist liefern würde.
Bewerten Sie die Risiken
Es ist schwierig, bei der Arbeit sein volles Potenzial auszuschöpfen. Daher werden sowohl die Schätzung als auch die Dauer mit einem bestimmten Risikoverhältnis festgelegt. Dadurch entsteht ein Puffer, der uns Handlungsspielraum gibt.
Behalten Sie in diesem Szenario jedoch den Prozentsatz der Bereichsvariation im Auge. Es ist ein schlechter Empfang, wenn es anfängt, sich schnell auszudehnen. Das bedeutet, dass Sie nicht alle Risiken berücksichtigt und eine falsche Schätzung erstellt haben.
Infolgedessen müssen Sie möglicherweise ein neues Szenario erstellen, die Anzahl der Spieler erhöhen, die Frist verschieben oder den Umfang reduzieren.
Dashboards können sehr nützlich sein
Machen Sie nichts von Hand, seien Sie faul. Atlassian hat bereits alles für Sie bedacht. Das Wichtigste ist, zu wissen, was Sie verfolgen möchten und welche Kennzahlen Ihnen Antworten liefern können.
Meiner Meinung nach ist es besser, mehr Panels als weniger zu haben. Sie werden feststellen, welche Panels Sie nicht benötigen, wenn Sie sie verwenden.
Führen Sie Vorbereitungstreffen ein
Es reicht nicht aus, die Aufgaben für den nächsten Sprint vorzubereiten. Beenden Sie den gesamten Versionsbereich. Und je früher Sie beginnen, desto besser. Indem Sie anstehende Aufgaben hinauszögern und aufschieben, werden Sie alle verborgenen Überraschungen nicht früher entdecken.
Planen Sie die Veröffentlichung, nicht den nächsten Sprint
Dies ist eine natürliche Konsequenz des vorherigen Ratschlags. Sie sollten das gesamte Bild sehen, nicht nur einen Teil davon. Es wird nicht einfach sein, objektiv zu beurteilen, inwieweit Ihr Team die Erwartungen der Kunden erfüllen kann.
Wenn Sie keine klare Vorstellung davon haben, was geschieht, ist es schwierig, Fristen anzugeben. Der Versionsbericht mit Veröffentlichungsdatum ist ein nützliches Tool in Jira und Sie sollten es ausprobieren. Ich bin sicher, Sie werden überrascht sein, wenn Sie die Veröffentlichungstermine aus einer pessimistischeren Sicht auf die Situation sehen.
Legen Sie nicht alles auf Ihr eigenes Team
Es kann sinnvoller sein, einige Funktionen mit anderen verteilten Teams zu teilen. Wenn sie die Aktivität schon einmal durchgeführt haben, verfügen sie möglicherweise über mehr Erfahrung.
Dadurch können sie diese Aufgaben möglicherweise schneller erledigen als Ihr Team, das mehr Zeit damit verbringen muss, sich in einen neuen Codebereich zu vertiefen. Berücksichtigen Sie die Gesamtgewinne, anstatt einzelne Lücken zu korrigieren.
Nehmen Sie auch die Meinung anderer Teams ein.
Experten aus anderen Teams können aufzeigen, was Ihrem Team fehlt, was Ihnen eine neue Perspektive verschafft und viel Zeit für das gesamte Projekt spart.
Verfolgen Sie Projektkennzahlen.
Sie müssen sich der Leistung Ihres Teams bewusst sein. Verfolgen Sie bei jedem Sprint definitive Abweichungen vom Plan. Wenn Sie sich verspäten, müssen Sie berechnen, wie viel Arbeit auf Sie zukommt, wie schnell Sie die Arbeit nachholen müssen und wer dafür aufkommt.
Sprint-Berichte in Jira bieten Tracking-Geschwindigkeit am Ende jedes Sprints. Ich empfehle außerdem die Verwendung des Sprint Health-Gadgets und des Rich Filter by Status.
Jede Vereinbarung muss schriftlich dokumentiert werden.
Der Kunde wird Zahlen besser verstehen können als jede andere Sprache. Und jedes Gespräch sollte mit einer Zusammenfassung des Anrufs enden: einer kurzen Notiz, in der beschrieben wird, worüber Sie gesprochen haben, was Sie gelernt haben, was Ihnen in den Sinn gekommen ist und wer für die nächsten Schritte verantwortlich ist.
Geschieht dies nicht, hört jeder Mensch nur das, was er will, und erinnert sich auf unbedeutendere Weise. Als Projektmanager besteht Ihre Aufgabe darin, die Wahrscheinlichkeit des Eintretens solcher Verluste zu verringern. Seien Sie also nicht faul; Machen Sie sich Notizen zu allem, was gesagt wurde.
Noch besser: Zeichnen Sie Anrufe mit Zustimmung aller Gesprächsteilnehmer auf. Auf diese Weise können Sie sich die Kassette immer wieder anhören, wenn Sie einmal verloren gehen oder etwas vergessen.
Ich übe das Aufzeichnen von Anrufzusammenfassungen, aber das ist nicht immer einfach, daher ist es am besten, in komplexen Sitzungen, die eine hohe Konzentration erfordern, kein Multitasking zu betreiben.
Führen Sie Aufzeichnungen über Änderungen am Umfang.
Natürlich ist es immer besser, wenn es automatisiert ist. Verwenden Sie Jira-Benachrichtigungen und Dashboards. Wenn Sie das Verfahren nicht selbst konfigurieren können, können Sie die Hilfe des Kunden oder erfahrenerer Mitarbeiter in Anspruch nehmen.
Seien Sie bei allem, was Sie tun, jederzeit und überall offen und ehrlich.
Halten Sie den Kunden regelmäßig über Ihre Fortschritte auf dem Laufenden. Mit laut gesprochenen Worten und per E-Mail/Nachrichten gesendeten Textnachrichten.
Bedenken Sie außerdem, dass jede Information, selbst die grundlegendste, falsch interpretiert werden kann. Erklären Sie daher unbedingt auch die grundlegendsten Details, da der Haken für die Öffentlichkeit verborgen bleiben könnte.
Ich bin gespannt, wie unsere Reise in der aktuellen Version endet, aber das wird eine andere Geschichte sein.
