Anforderungen siehe Screenshot

Heute hatte ich Gelegenheit, zwei völlig unterschiedliche Herangehensweisen an die Erstellung von Anforderungen zu erleben.

Worum es gehen soll, zeigt die folgende Grafik:
Was man auf dem Foto sieht, ist der Vergleich zweier  Features. Während das linke Feature auf neun(!) DIN A4 Seiten Platz findet, werden es auf der rechten Seiten nicht einmal zwei Seiten. Nun könnte man annehmen, dass das linke Feature komplexer sei. Ist es aber nicht. Nicht acht Seiten Beschreibung komplexer.

Es handelt sich um Anforderungen in zwei sich unterscheidenden Systeme, die aber inhaltlich über ähnliche Komplexität verfügen.

Der wesentliche Unterschied ist offensichtlich.

Klick für Großversion

Links: Ausführliche Beschreibung der umzusetzenden Anforderungen. Es werden verschiedene Zustände, Designvorgaben und gewünschte Abläufe und Funktionalitäten beschrieben.

Rechts: ‘Wir brauchen das Feature XY, Funktion und Maße sind dem Screenshot zu entnehmen.’.

Die Anforderungsbeschreibung links stammt aus einem Produktbacklog eines agilen Software-Projektes, rechts ist eine Weiterentwicklungs-Anforderung für ein bestehendes Produkt. Das wirklich Erstaunliche daran ist, dass beide Anforderungsbeschreibungen aus ein und dem selben Unternehmen stammen. Hier fehlt es offenbar an Wissen über Konzeption und Anforderungserhebung (“requirements engineering“). Aus meiner Sicht bedarf es einer akzeptierten, unternehmensweit gültigen Projektkultur. Dem Mitarbeiter waren seine mit der Rolle verbundenen Aufgaben nicht transparent. Fehlende Zuständigkeiten und Entscheidungsmöglichkeit aber führen zu Unsicherheit und Zeitverzug. Die Zeit, die mit der fehlenden Anforderungsanalyse gespart wurde, wird meiner Erfahrung nach von dadurch verursachten Fehlern, Problemen und zusätzlicher Klärungsrunden mehr als aufgebraucht.

Es geht mir nicht darum, jetzt immer ausufernde Prosa zu schreiben Und machmal reichen sicher auch zwei Seiten aus. Trotzdem: Schon einfache Hilfsmittel wie User Stories (“Als User möchte ich …”) oder Mindmaps können helfen, das Verständnis davon zu transportieren, was der Auftraggeber denn eigentlich haben möchte. Es muss nicht immer eine Wissenschaft daraus gemacht werden. Auch narrative Methoden (Story-Telling, also Geschichtenerzählen) können hier helfen. Und zwar als Zuhörer und als Erzähler. Es kann nicht schaden, denjenigen Menschen zuzuhören, für die man dieses Feature, dieses Produkt usw. entwirft. Sich von Ihnen aus ihrem Arbeitsalltag berichten zu lassen. Es ist erstaunlich, wie viel man dadurch erfährt. Am Ende sind es diese Menschen, die das Produkt einsetzen. Genauso wichtig ist es aber auch, dafür zu sorgen, dass der Entwickler in die Lage versetzt wird, zu verstehen, was umgesetzt werden soll.

Fest steht, dass jeder Mensch  seinen eigenen Erfahrungshorizont, seine eigene Vorbildung mit sich herumträgt. Was nicht beschrieben ist, lädt zu Interpretation ein. Und ein Entwickler füllt Informationslücken evtl. mit anderen Annahmen aus, als es sich der Auftraggeber gedacht hat. Es ist beinahe sicher, dass – wenn sich der Entwickler seinerseits nicht die fehlenden, nicht oder nur unzureichend beschriebenen Informationen holt – etwas vollständig anderes herauskommt, als gewünscht war. Besonders erfrischend ist diese  Situation dann dadurch, dass bei einer solchen Kultur das Drama erst am Ende sichtbar wird – wenn es entweder zu spät ist, oder nur mit viel Geld und Aufwand zu beheben.

Übrigens: Die Anforderung links wurde nach etwa 8h live genommen. Entwickler und IT hatten quasi keine Fragen hinsichtlich der gewünschten Funktionalität. Während der Umsetzung ergab sich eine Rückfrage, die der Product Owner aber kompetent und schnell beantworten konnte. Die Variante rechts wird inkl. Rückfragen und Klärung von Zuständigkeiten wohl noch  einige Zeit in Anspruch nehmen…