Ich wurde gebeten, die Produktion meines Teams zu beschleunigen: Agile, A/B-Tests, Workflow und Prozesse

Ich habe eine schwierige Situation bei der Arbeit, zu der ich gerne Ihren Rat einholen möchte.

Ich bin derzeit Webentwicklungsmanager und beaufsichtige ein neu vervollständigtes Team, das aus einem Entwickler, einem Digitaldesigner und einem UX-Designer besteht. Ich habe mich mit dem Team zusammengesetzt, um unsere Projektzeitpläne zu ermitteln und ein SLA für ein Standard-Landing-Page-Projekt zu erstellen. Das Team hat darum gebeten, dass wir unseren aktuellen Prozess verlangsamen, um die Arbeit nach besten Kräften zu erledigen.

Wir haben den Prozess abgebildet, der die folgenden Phasen und Arbeitsstunden umfasst:

- Discovery [8]
- Definition phase (wireframing & determining technical solutions) [24]
- A/B of the wireframes [16]
- Design [16]
- Development [32]
- Pre Launch Testing & Revision [24]
- The launch [12]
- Post Mortem [4]

Ich habe diesen Prozess zu meinem VP hochgeladen und sie mochten es nicht.

"Es ist gut zu wissen, was sie wollen, aber das ist nicht die Realität" - paraphrasiert.

Und ich stimme zu, es ist selten eine perfekte Welt, und das verstehen wir alle. Manchmal kommen Projekte mit beschleunigten Zeitplänen in die Pipeline, und das ist in Ordnung. Ich habe es ihnen gesagt:

Ich wusste nicht, wie ich erreichen konnte, was sie wollten, ohne Fehler zu machen. Aber ich bin bereit, es herauszufinden.

Ich möchte vermeiden, Fehler zu machen und unterdurchschnittliche Arbeit zu leisten, und Systeme für A/B-Tests implementieren, für die ich eingestellt wurde. Ich habe zum Ausdruck gebracht, dass wir ein Muster der Einstellung von Personal zeigen, um unsere hohe Arbeitsbelastung zu bewältigen, aber dann exponentiell dazu beitragen, sobald wir neue Mitglieder an Bord haben. Worauf sie erwähnten, dass sie eine Weile gewartet haben, um diese Projekte fertigzustellen. Obwohl es in diesem speziellen Fall nicht wahr ist, machte es Sinn (lesen Sie den Kontext unten), da ich in den letzten Monaten mit einigen Projekten im Rückstand war.

KONTEXT - Wir stehen kurz vor dem 1-jährigen Jubiläum der Neugestaltung unserer Hauptwebsite (Großprojekt 40 Seiten, mehrere Funktionen). Als alleiniger Entwickler hatte ich ursprünglich 30 Tage Zeit und wir verlängerten nach 2 verpassten Fristen auf etwa 90 Tage. Obwohl die Abkürzungen, die ich gemacht habe, genehmigt wurden, habe ich unter dem ständigen Druck, diese komprimierten Zeitlinien zu erreichen, viele Ecken gekürzt. Die Website war langsam und konnte nicht indexiert werden, also haben wir viel Zeit damit verbracht, uns davon zu erholen, und wir haben auch eine Menge technischer Schulden auf uns genommen, die weitere 6 Monate für die Problemumgehung und Bereinigung gedauert haben.

Sie schlugen vor, einen agilen Ansatz zu wählen (mit dem ich als Anfänger vertraut bin, aber in der Praxis nicht angewendet habe). Ich antwortete mit:

„In einem agilen Prozess sind Sprints Zeitblöcke, und diese 2 Wochen scheinen de facto die minimale Sprintlänge zu sein, sodass das aktuelle Projekt, das wir ausarbeiten, 2 Sprints/4 Wochen benötigen würde.“

MEHR KONTEXT - Sie wollten, dass das Projekt in 2-3 Wochen abgeschlossen ist. Die anderen gleichzeitig laufenden Projekte nicht mitgezählt.

Das schien sie im Moment zu beruhigen, aber heute Morgen erhielt ich diese Nachricht:

„Ich dachte mehr an unser Freitagsgespräch. Wenn ich sage, dass man sich auf Agile einlassen muss, habe ich nicht die agilen Prozesse vorangetrieben (obwohl an Sprints, Backlogs, Stand-ups usw. nichts auszusetzen ist, falls hilfreich), sondern mehr an die Denkweise. Lassen Sie uns Elemente veröffentlichen und A/B-Test von dort. Lassen Sie uns zusammenarbeiten, Design und UX-Denken von Anfang an nutzen, anstatt auf alle Anforderungen oder Inhalte zu warten, bevor Sie beginnen. Lassen Sie uns von der Annahme, dass eine Seite fertig ist, wenn sie gestartet wird, dazu übergehen, die Idee der kontinuierlichen Verbesserung wirklich einzubauen ( und die Daten betrachten, um zu sehen, worüber wir iterieren sollten)"

Auf den ersten Blick scheint es:

  1. Mit anderen Worten: "Lass es uns aus der Tür holen und es später reparieren."
  2. Sie wollen auch die agilen Ergebnisse ohne den agilen Prozess.

Obwohl ich die Notwendigkeit verstehe, mich vom Perfektionismus fernzuhalten, waren wir in der jüngeren Geschichte bei weitem nicht in der Nähe, und ich wurde für diese Probleme zur Rechenschaft gezogen. An diesem Punkt bin ich mir nicht 100% sicher, von hier aus zu gehen. Ich habe einen zweiten Prozess verspottet, der die Zeitlinien verkürzt.

- Discovery [8]
- Definition phase (wireframing & determining technical solutions) [10]
- A/B of the wireframes [4]
- Design [12]
- Development [20]
- Pre Launch Testing & Revision [6]
- The launch [4]
- Post Launch Testing & Revision [6]
- Post Mortem [2]

Ein Teil von mir möchte zu meinem Team gehen und einfach sagen: „Hier ist, was wir haben, wie können wir es zum Laufen bringen?“ Auch wenn ich meinen Chef respektiere, möchte ich auch nicht den Status quo verewigen, der mein Team ausbrennt, wie ich es in den letzten Monaten getan habe.

Wo soll ich von hier aus gehen?

"Wohin soll ich von hier aus gehen?" droht als zu breit geschlossen zu werden. Mir ist unklar, was Sie aus dieser Frage herausholen wollen.
Danke für die Antwort. Nachdem ich Ihre Antwort gelesen habe, scheint es klar, dass ich untersuchen sollte, welche Teile des Projekts unabhängig erreichbar sind.

Antworten (1)

Sie haben hier zwei getrennte Probleme.

  1. Sie sind nicht auf derselben Seite wie Ihr VP, wenn es darum geht, was „agil“ bedeutet.
  2. Sie denken, dass es Sache des VP ist, zu entscheiden, ob ein Zeitplan realistisch ist oder nicht.

Ich werde diese in umgekehrter Reihenfolge angehen.

Realistische vs. akzeptable Schätzungen

Erstens kann nur das Team, das die Arbeit durchführt, entscheiden, ob eine Schätzung realistisch ist . Die einzige Person, die entscheiden kann, ob ein Kostenvoranschlag akzeptabel ist , ist der Kunde oder der Vertreter des Kunden (in diesem Fall der VP). Verwechseln Sie die beiden nicht.

Wenn eine akzeptable Schätzung unrealistisch ist, ändern Sie die Schätzung, damit sie realistisch ist. Wenn eine realistische Schätzung nicht akzeptabel ist, fügen Sie Ressourcen hinzu, reduzieren Sie den Umfang oder lehnen Sie das Projekt ab.

Was ist agil?

Als Scrum Master mit ~5,5 Jahren stimme ich dem Zitat, das Sie vom VP gemacht haben, zu 100 % zu. Du sagst:

Sie wollen auch die agilen Ergebnisse ohne den agilen Prozess

Wobei ich es so formulieren würde:

Sie wollen agile Ergebnisse und kümmern sich nicht besonders darum, ob sie durch den Scrum-Prozess erreicht werden oder nicht

Agilität ist dies und dies . Das ist es. Es ist eine Philosophie und eine Denkweise.

Ob Sie 16 Stunden im Design oder 12 Stunden im Design verbringen, hat absolut nichts damit zu tun, ob Sie agil sind oder nicht . Wissen Sie, was agil wäre? Etwas mehr davon:

„Hey Team. Der VP will [großes Ding], das meiner Meinung nach in [50 separate Dinge, jede unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar] unterteilt werden kann. Was glauben Sie, wie viel wir erledigen können? zwei Wochen?"

"Uh, vielleicht 5 von ihnen?"

"Okay, dann vielleicht diese 5?"

"Nein, das ist ein bisschen lückenhaft, ich glaube nicht, dass wir das zuverlässig machen können."

"Okay, wie wäre es stattdessen mit diesen 5?"

"Ja vielleicht."

"Okay, dann versuchen wir es."

Dann 2 Wochen später,

„Hey VP, wir haben es geschafft, diese 4 Dinge fertigzustellen. Sollen wir jetzt live gehen oder nicht?“

"Nein, noch nicht. Wir müssen [das Ding] zuerst erledigen."

"Hey Team, wie lange würde es dauern, [das Ding] zu machen?"

"Ungefähr 10 Minuten."

„Hey VP, wir können [das Ding] in 10 Minuten erledigen, sollen wir dann Live gehen?“

"Sicher. Dieses Projekt hat aber immer noch höchste Priorität, also arbeite weiter daran."

„Hey Team. Lasst uns live gehen. Was können wir von den verbleibenden Aufgaben in 2 Wochen erledigen?“