Anforderungen richtig umsetzen (mit Kelly Suter von BI Worldwide)

Das Transkript lesen:

Wir testen aktuell, unsere Podcasts mit Hilfe eines Software-Programms zu transkribieren. Bitte entschuldigt etwaige Tippfehler, da der Bot nicht immer 100% korrekt ist.

Ben Aston:

Willkommen zum DPM-Podcast, in dem wir über die Theorie hinausgehen, um Expertenrat für das Projektmanagement von digitalen Projekten zu geben. Schön, dass Sie zuhören. Ich bin Ben Aston, Gründer des Digital Project Manager. Seien wir ehrlich, hat Ihr Kunde Ihnen jemals am Ende eines Projekts gesagt: „Hey, das war genau das, was wir wollten! Genau wie am Projektbeginn besprochen – und es ist einfach beeindruckend, wie ihr alles erfasst habt, ohne etwas zu vergessen.“

Ich vermute, das ist eher selten. Das liegt vermutlich daran, dass Ihre Anforderungen nicht richtig festgelegt wurden. Wie kann man Anforderungen so managen, dass kein Chaos entsteht, sondern dem Kunden und dem Entwickler die nötigen Informationen gegeben werden, um den Job zu erledigen? Genau darum geht es in der heutigen Folge: um Projektanforderungen.

Wie definieren wir Projekte und deren Funktionen für unsere Kunden so, dass alle wissen, was geliefert wird? Im Grunde sind Anforderungen für mich ein Kommunikationswerkzeug, aber es ist wirklich schwer, sie richtig zu machen. Definieren wir die Anforderungen zu locker, haben wir zwar mehr Flexibilität, bekommen aber vielleicht nicht das, was wir wollen. Definieren wir zu eng, fehlen vermutlich viele Details. Wie findet man das richtige Gleichgewicht?

Heute spreche ich mit Kelly Suter. Kelly ist technische Projektmanagerin bei BI Worldwide und eine unserer festen Deakin-Expertinnen bei The Digital Project Manager. Hallo Kelly.

Kelly Suter:

Hallo, danke für die Einladung, Ben.

Ben Aston:

Es ist großartig, Dich dabei zu haben. Ich glaube, das ist unser zweiter Podcast, oder?

Kelly Suter:

Ja, das ist richtig.

Ben Aston:

Wir haben schon vor längerer Zeit eine Folge aufgenommen. Für diejenigen, die Dich noch nicht kennen: Kannst Du uns einen kurzen Überblick geben? Wie bist Du ins Projektmanagement gekommen? Ich finde, Dein Weg ist ziemlich spannend – ähnlich wie bei vielen PMs. Kaum jemand träumt als Kind vom Projektmanagement. Erzähl uns doch mal, wie Du heute als Digital Project Manager arbeitest.

Kelly Suter:

Ich habe meine Karriere tatsächlich als Sportreporterin begonnen. Studiert habe ich Kommunikationswissenschaften mit Schwerpunkt PR und Medien. Als ich dann gemerkt habe, dass Zeitungen nicht mehr angesagt sind, habe ich mich in der PR umgesehen. Ich war etwa drei Jahre als Pressesprecherin für Sesame Street Live tätig. Dort konnte ich mich auf eine Marke spezialisieren. Eines Tages sprach mich dann jemand aus einem maßgeschneiderten E-Commerce-Unternehmen an, also einer Digitalagentur mit Full-Service-Ansatz, die sich ganz auf E-Commerce konzentriert.

Sie sagte: „Wir haben hier keine Projektmanagement-Abteilung. Möchtest Du Projektmanager werden?“ Ich fragte zurück: „Was ist das?“ Mein Vater hatte übrigens eine Grafikdesign-Agentur; daher war mir der Agenturalltag geläufig – stressig, immer viel los. Trotzdem dachte ich: Klingt spannend, ich schaue es mir an. Also wechselte ich dorthin. Das erste Buch, das ich je zu diesem Thema gelesen habe, war von Meghan McInerny: People, Pixels and Process. Ich weiß gar nicht, ob das die richtige Reihenfolge ist, aber ich habe es gelesen und versucht, das Gelernte auf die 12-köpfige Agentur zu übertragen.

Ben Aston:

Das kenne ich, ja.

Kelly Suter:

Genau. Ich …

Ben Aston:

People, Pixels … Ich glaube, es heißt People, Pixels and Process, ja.

Kelly Suter:

Stimmt. Ich habe versucht, so viel wie möglich für die Agentur zu übernehmen; damals waren wir 12 Leute. Wir haben Individual-„Brochureware“ und E-Commerce-Seiten erstellt. Vier Jahre später hatte ich ein siebenköpfiges PM-Team aufgebaut und die Prozesse weiterentwickelt. Mit Magento, Drupal, Cantego, WordPress usw. habe ich mich also wohlgefühlt und wollte mein technisches Wissen ausbauen. Dann bot sich die Chance einer PM-Position bei BI Worldwide, wo ich heute bin. Ich wollte zurück ins PM-Geschehen, an Projekten mitarbeiten und meine technischen Fertigkeiten schärfen. Das ist wirklich spannend und leider geht die Zeit wie im Flug vorbei. Aber ich liebe, was ich tue!

Ben Aston:

Mich interessiert: Was wäre eigentlich Dein Traumjob? Du hast ja viele verschiedene Stationen gehabt: Sportreporterin, Sesame Street, jetzt im Tech-Bereich als PM. Wie sieht der perfekte Job für Dich aus?

Kelly Suter:

Gute Frage. Was mir am meisten an meinen derzeitigen und vorherigen Aufgaben – z. B. bei Irish Titan – gefällt, ist es, Prozesse dort aufzubauen, wo noch keine vorhanden sind oder sie sich gerade erst entwickeln. Ich arbeite gern an Herausforderungen, bei denen Struktur erst geschaffen werden muss. Mein Traumjob wäre daher: Immer wieder in junge Unternehmen oder Start-ups kommen, Prozesse etablieren, sie mit dem Team testen, anpassen und so für Entlastung sorgen. Ich liebe Herausforderungen!

Ben Aston:

Klingt super. Mit welchen Herausforderungen beschäftigst Du Dich aktuell? Neben dem „Feuerwehr“-Job – wo siehst Du zurzeit die größten Hürden?

Kelly Suter:

Momentan ist es eine der größten Herausforderungen, das Team für Dokumentation zu begeistern – ohne es zu langweilen. Besonders wenn Kunde und Team motiviert sind, ist es schwer, alle für saubere Dokumentation zu gewinnen: „Wir müssen festhalten, was wir tun, und das als Vorlage speichern – auch wenn es aufwendig wirkt.“ Denn wenn jemand das Team verlässt oder neue Leute hinzukommen, soll der Prozess nicht verloren gehen. Ich habe Teams erlebt, die das Rad ständig neu erfinden, sowohl beim Produkt als auch bei der Doku – das ist ineffizient. Also: Dokumentation muss nicht mühsam sein, aber ausreichend, damit alles nachvollziehbar ist.

Ich arbeite gerade an Dingen, bei denen die letzte Doku aus 2014 stammt – das ist für den Kunden okay gewesen, aber sollte so nicht bleiben. Später beim Audit ist es schön, wenn alles ordentlich dokumentiert ist.

Ben Aston:

Also, Du organisierst Prozesse, Dokumentationen etc. Gibt es Werkzeuge, die Dir helfen? Wie gehst Du dabei vor?

Kelly Suter:

Für Doku nutze ich gern Google Suite – never change a running system! Wenn der Kunde keine Sicherheitsbedenken hat, einfach Google Docs nutzen. Zugriff kann gezielt vergeben werden. PDFs für finale Freigaben exportieren – perfekt! Für kreativen Austausch und Annotationen nutze ich InVision: Designer laden dort ihre Entwürfe hoch, der Kunde kann kommentieren. Nach der Freigabe lässt sich alles exportieren und in die Doku übernehmen. Falls InVision zu teuer ist: Sketch von Evernote ist eine kostenlose Alternative für einfache Annotationen. Ich halte es einfach: Designs importieren, kommentieren, dokumentieren, fertig.

Ben Aston:

Cool. Zum nächsten Thema: Du bist technischer PM, hast aber auch andere Rollen wie BA, SCRUM Master usw. Wie unterscheidet sich technisches Projektmanagement vom Digital Project Management? Und wie funktioniert das mit den verschiedenen Rollen?

Kelly Suter:

Gute Frage. Meine Rolle bei BIW ist tatsächlich ziemlich einzigartig: Ich mache technisches und klassisches Projektmanagement, etwa für Live-Events oder E-Learnings (ca. ein Viertel meiner Arbeit). Die übrige Zeit bin ich im technischen PM. Die Unterschiede zwischen DPM und TPM hängen davon ab, wie technisch das Projekt ist. Im DPM war ich für alles zuständig – Content, Wireframing, Design, Kreativ – und habe das Dev-Team eher „aus der Entfernung“ gemanagt. Jetzt im TPM bin ich viel näher an der Entwicklung, etwa im QA-Prozess, und schreibe selbst die technischen Anforderungen. Je enger dran, desto mehr Verantwortung. Im DPM habe ich Anforderungen gemanagt; jetzt schreibe ich sie auch selbst. Also: Ich bin mehr im „Maschinenraum“.

Ben Aston:

Für alle, denen „funktionale Anforderungen“ oder „Business Requirements“ nicht geläufig sind: Kannst Du erklären, wie Du an den Prozess herangehst?

Kelly Suter:

Zu Beginn eines Projekts muss man die Rollen klären, denn sie können sich je nach Kunde ändern. Beispiel: Ein komplexes Integrationsprojekt – ich kann bestimmte Anforderungen definieren (etwa: „Das Inventar soll live angezeigt und täglich aktualisiert werden“), aber auf Entwicklungsebene übergebe ich an die Entwickler. Es gibt einen Punkt, an dem ich sage: „Okay, bis hierhin kann ich Anforderungen schreiben – den Rest müsst Ihr als Dev übernehmen.“ Das ist ein Balanceakt und hängt auch davon ab, wie Kosten und Ressourcen verteilt werden. Wichtig ist: Die Verantwortlichkeiten müssen zu Beginn klar sein, alles andere wird durch offene Kommunikation gelöst.

Ben Aston:

Viele fragen sich jetzt: Was ist überhaupt ein Business Requirement Document (BRD) und was ein Functional Requirement Document (FRD)? Warum macht man das?

Kelly Suter:

Das BRD (Business Requirements-Dokumentation) ist wie ein Einführungskurs: Die wichtigsten Punkte auf hoher Ebene (z. B. „Wir brauchen Übersetzungen ins Spanische und Mandarin“, „10 Kurse bis April bereitstellen“, „6.000 User unterstützen“ etc.). BRD ist ein formales Abstimmungs-Checkpoint für alle Seiten, wo jeder unterschreibt: „Ja, wir wissen, worum es geht.“ Natürlich mit dem Vermerk, dass noch Details folgen und Prioritäten sich verschieben können, falls etwas später hinzukommt oder wegfällt.

Das FRD ist ein ganz eigener Meilenstein: Hier werden alle diese Punkte im Detail ausformuliert – etwa, WIE die Übersetzung erfolgen soll, durch Drittanbieter oder CMS? Im FRD wird deutlich mehr ausgearbeitet und es dient als Bauplan für die Realisierung. Nicht alles aus dem BRD findet hier Platz, manches wird für Phase 2 geparkt, anderes detailliert ausgearbeitet. Es ist eine Entwicklung: BRD als Gesamtüberblick, FRD als Bauanleitung.

Ben Aston:

Also, das BRD definiert den Projekterfolg aus Business-Sicht; das FRD geht ins Detail. Aber wie schafft man bei agilen Methoden den Spagat zwischen ausführlicher Doku und Flexibilität?

Kelly Suter:

Gute Frage. Wichtig ist, zu Beginn festzulegen, wie agil man vorgeht („Das ist unser Produkt, das entwickeln wir agil/iterativ …“). Beispiel: Wir bauen eine Software, die Lernfortschritte mit Punkten verknüpft, die dann im Marktplatz eingelöst werden können. Kunde will ein fixes Ziel und Termin, aber keine Zeit für vollständige Doku. In diesem Fall dokumentiere ich z. B. wöchentlich den aktuellen Stand, Aufgabenverteilung, offene Fragen, Logik etc. – so bleibt alles transparent. Durch regelmäßige Stand-ups, Präsentationen, Feedbackschleifen mit dem Kunden und enge Abstimmung im Team kann man agil vorgehen und trotzdem die notwendige Klarheit behalten.

Wichtig ist: Dokumentation läuft mit, Kundenfeedback fließt ein, und gemeinsam wird entschieden, was umgesetzt wird oder ggf. wegfällt.

Ben Aston:

Wenn man mit der Doku zu lange wartet, bremst man das Projekt aus. Anforderungen helfen, Klarheit zu schaffen und alle Beteiligten auf einer Linie zu halten, auch bei der Qualitätssicherung. Wie setzt Du das praktisch um, z. B. mit JIRA?

Kelly Suter:

Ich arbeite eng mit dem Team zusammen, frage viel nach („Wie habt Ihr das gemeint …?“), und wenn das FRD final ist, gehen wir damit ins Development. Mit JIRA baue ich für jede Story (z. B. Registrierung, Startseite, Produktseite etc.) eine Story an, mit Subtasks für jedes Feature. Die Entwickler schätzen dann selbst den Zeitaufwand, idealerweise die, die es auch bearbeiten. So ist jeder verantwortlich und auf dem aktuellen Stand der Anforderungen. QA-Aufgaben werden direkt in die Tickets eingebaut („Woran erkennt man, dass das Feature erfolgreich getestet wurde?“).

Ben Aston:

Ein großes Thema ist die Aufwandsschätzung besonders zu Projektbeginn, wenn noch keine Details definiert sind. Wie gehst Du hier vor?

Kelly Suter:

Ehrlich: Als PM habe ich selten die Vollmacht, Schätzungen abzugeben, sondern hole Input von Entwicklern. Ich schaue zuerst, was wir schon für ähnliche Kunden gemacht haben, z. B. eine Standard-E-Commerce-Implementierung mit Magento: ca. 6–8 Wochen, bestimmte Personalkonstellation. Das ist dann der Rahmen, an dem wir uns orientieren. Aber ich sage auch dem Vertrieb: „Wir wissen noch nicht alles – ohne Integrationen und Individualisierungen kostet es etwa so und so viel …“ Am besten hat man als PM eine Vergleichsliste parat („Hier sind drei vergleichbare Projekte, das war das günstigste, das das teuerste.“). Der Kunde muss verstehen: Die genaue Schätzung ist Teil des Discoverys und wird genauer, je mehr die Anforderungen ausgearbeitet sind.

Ben Aston:

Mit welchen Methoden unterstützt Du den Kunden dabei, zu priorisieren?

Kelly Suter:

Zwei Ansätze: Erstens lasse ich den Kunden eine Prioritätsskala für Umfang, Zeit und Budget erstellen. „Alle sind gleich wichtig“ zählt nicht – sie müssen entscheiden, was wichtiger ist. Zweitens: Die „Good-Better-Best“-Variante: Wenn neue Anforderungen oder Wünsche auftauchen, zeige ich Optionen mit verschiedenen Preisen und lasse den Kunden entscheiden, wo Kompromisse gemacht werden.

Ben Aston:

Bei technischen Projekten mit Fixpreis kann das schwierig sein. Wichtig ist, den Kunden in die Entscheidungsprozesse einzubinden – auch bei Schätzungen und Funktionen. Lass uns am Schluss noch einen Tipp: Wer bisher keine Requirements geschrieben hat und das einführen möchte – wie startet man?

Kelly Suter:

Mein Tipp: Wer neu ist, weiß vermutlich mehr, als er denkt, weil wir alle täglich digitale Produkte nutzen. Man muss nicht sofort ein ausgefeiltes Template aus dem Internet herunterladen – einfach Schritt für Schritt erklären, was gebaut wird („Homepage, Registrierungsformular“, etc.) und für jede Komponente fragen: Was soll das tun? Auf Desktop und Mobilgerät? Die Doku wie für die Oma schreiben und anschließend vom Entwickler gegenchecken lassen. Nur so wird das Team erfolgreich. Die Doku entwickelt sich weiter – Hauptsache ist, man beginnt.

Ben Aston:

Ich finde das sehr hilfreich. Es geht beim Requirements-Engineering darum, möglichst viele Fragen zu stellen und nichts als selbstverständlich anzunehmen. Am Ende ist das Dokument ein Kommunikationsmittel, das für alle Klarheit schafft und unterm Strich viel Zeit und Reibung erspart.

Kelly, vielen Dank, dass Du dabei warst.

Kelly Suter:

Vielen Dank für die Einladung.

Ben Aston:

Kelly ist übrigens auch Dozentin im Kurs »Mastering Digital Project Management«. Falls Sie PM-Training benötigen, informieren Sie sich unter dpmschool.com – der Kurs startet im Februar. Wenn Sie Kommentare oder Fragen zu Anforderungen haben, besuchen Sie unsere Ressourcen-Sektion oder treten Sie unserem Slack-Channel bei. Bis zum nächsten Mal und danke fürs Zuhören!