Arbeitsbereich Requirements: Schnittstelle zwischen Kunde und Entwickler
Im letzten Jahr haben wir Ihnen die Arbeitsbereiche „Service & Support“ und „Entwicklung“ vorgestellt. Heute möchten wir den Bereich Requirements näher beleuchten. Unsere Hauptverantwortliche Diana gibt Ihnen dazu einen umfassenden Einblick.
Requirements sind ein wichtiger Bestandteil unserer Projektarbeit. Als Schnittstelle zwischen unseren Kunden und unseren Entwicklern können wir dank der Requirements die Anforderungen genau definieren und so einen effizienteren Workflow schaffen, bevor wir mit den einzelnen Arbeitspaketen beginnen. Was das genau bedeutet, erklärt unsere Requirements-Ansprechpartnerin Diana im Interview.
Diana, wie würdest du deinen Arbeitsbereich beschreiben?
Kurz gesagt halte ich die Anforderungen und Wünsche der Kunden innerhalb eines Projektes schriftlich fest und bearbeite bzw. formuliere sie so, dass unsere Entwickler damit weiterarbeiten können. Dabei berücksichtige ich bereits verschiedene Konsequenzen und Möglichkeiten, die während der Programmierung auftreten können.
Das heißt, ich berücksichtige so viele Implikationen wie möglich. Das klappt natürlich nicht immer, manchmal kommen neue Aspekte hinzu, die wir vorher nicht berücksichtigen konnten. Ein Ziel ist es, spätere Rückfragen der Entwickler zu vermeiden.
Kannst du das etwas genauer definieren?
Ich möchte das einmal an einem ganz einfachen Beispiel erklären. Wir bekommen in einem Projekt die Anforderung, dass auf der Seite eines Onlineshops ein Button installiert werden soll, der z.B. auf eine Artikelseite verlinkt. Der Entwickler bekommt die Aufgabe und stellt sich wahrscheinlich ziemlich schnell die Fragen: Wie groß soll der Button sein? Was soll auf dem Button stehen? Welche Schriftfarbe? Welche Form? Er hat also direkt Rückfragen an den Kunden, weil die Aufgabenstellung zu allgemein gehalten ist.
Diese Fragen stelle ich mir schon bei der Erstellung der Requirements und bespreche sie mit dem Kunden ab, bevor unsere Entwickler mit der Arbeit beginnen. Im Idealfall hat der Entwickler am Ende keine Rückfragen mehr und kann direkt loslegen.
Wie kann man sich zum Beispiel den Projektablauf innerhalb der Requirements vorstellen?
Meistens bin ich bei den Kick-off-Gesprächen mit dem Kunden dabei und begleite das Projekt im weiteren Verlauf. Dies ist besonders wichtig, damit sich der Kunde ein Bild von mir machen kann, da ich im Laufe eines Projektes oft in sehr engen Kontakt mit dem Kunden stehe, um seine Anforderungen bestmöglich zu dokumentieren und eventuelle Fragen im Vorfeld zu klären. In diesen Gesprächen ergeben sich auch oft weitere Fragen, Wünsche und Ideen, die ich direkt für die Requirements dokumentieren kann.
Ich betrachte die gestellten Anforderungen sozusagen von allen Seiten und probiere auch schon im Vorfeld Möglichkeiten aus, die funktionieren könnten. Das Ziel am Ende der Requirements ist, dass der Entwickler alle Informationen hat, die er braucht und der Kunde am Ende das gewünschte Ergebnis bekommt - zum Beispiel einen neu aufgesetzten Onlineshop.
Manchmal nehme ich in dieser Phase auch an Reviews teil. Durch die Gespräche mit dem Kunden bekomme ich einen guten Einblick in seine Wünsche und Anforderungen und kann im Review gemeinsam mit dem Entwickler in diesem Schritt schauen, ob das Ergebnis auch den Wünschen des Kunden entspricht.
Kannst du uns das an einem Projektbeispiel erklären?
Anfang der Woche habe ich zum Beispiel die Requirements für ein Projekt fertiggestellt. In diesem Projekt unterstützen wir den Umstieg von Shopware 5 auf Shopware 6. Zu Beginn habe ich mir die gewünschten Anforderungen des Kunden angeschaut und mit den vorhandenen Möglichkeiten in Shopware 6 verglichen. Zum Beispiel benötigte der Kunde mehrere Versandarten für seinen Onlineshop.
Im nächsten Schritt habe ich in diesem Projekt dokumentiert, was eventuell schon mit Shopware 6 möglich ist und wo wir noch entwickeln müssen. Da die Versandarten und Kundenwünsche hier etwas komplexer waren, ist dies ein gutes Beispiel, bei dem ich mehr Rückfragen an den Kunden stellen musste.
Bei diesem Kunden sind wir jetzt so weit, dass ich ein Anforderungsdokument erstellt habe, in dem alle Anforderungen und Umsetzungsvorschläge meist in Form von User Stories festgehalten sind. Nach Freigabe durch den Kunden werden diese dann in entsprechende Projekt-Tickets umgewandelt und Schritt für Schritt abgearbeitet.
Das klingt spannend und abwechslungsreich. Hattest du in den letzten Jahren ein Lieblingsprojekt?
Ein Lieblingsprojekt habe ich eigentlich nicht. Vielmehr macht es mir Spaß, mich mit den verschiedenen Themen und Möglichkeiten auseinanderzusetzen und diese zum Teil auch auf ihre Umsetzbarkeit zu testen.
Letztes Jahr habe ich zum Beispiel an einem relativ großen Projekt gearbeitet, das ganz anders war als die üblichen Projekte, die ich sonst im Bereich Requirements betreue. Das war schon eine Herausforderung, aber auch sehr spannend, Einblicke in andere Bereiche ohne Onlineshop und auch mit anderen Funktionalitäten zu bekommen.
Gibt es etwas, was dir an diesem Arbeitsbereich besonders viel Spaß macht?
Wie ich bereits erwähnt habe, macht es mir Spaß, mich in neue Dinge einzuarbeiten. Letztendlich finde ich es aber immer sehr befriedigend, wenn wir die Projektarbeit abgeschlossen haben und der Kunde am Ende zufrieden ist. Dazu trägt natürlich auch jeder meiner Kollegen bei.