Die neue Unhöflichkeit

Oder: Wie man Missverständnisse bei Anforderungen vermeiden muss.

Wir lernen von Kindesbeinen an, wie wir uns im Optimalfall in der Gesellschaft zu bewegen haben. Dazu zählen auch zahlreiche akzeptierte Kommunikationsmuster: Wie sprechen wir jemanden an, den wir nicht kennen, wie sprechen wir als Kind einen Erwachsenen an, wie verhalten wir uns kommunikativ im Berufsleben.

Zugegeben, insbesondere unter Freunden oder schlimmer noch, unter alten (männlichen) Buddies, sind die unterirdischsten Schimpfworte als guter Opener einer gesellschaftlich akzeptierten Begrüßung etabliert. Dabei sind Einleitung wie „na, alte Ratte“ noch in der Kategorie „Charmant“ einzustufen.

Ansonsten gilt aber unangetastet ein höfliches Raster: Sehr geehrte Frau…, sehr geehrter Herr …, guten Tag, bitte, danke, das wäre sehr nett, würden Sie freundlicher Weise, ich hätte sehr gern das und das, auf Wiedersehen, tschö mit ö, usw.

Es gibt einen Bereich, in dem man diese verinnerlichten und rückenmarksgesteuerten Floskeln sowie andere, gelernte Kommunikationsraster (bspw. publizistischer Natur), tunlichst unterlassen sollte: IT-Projekte. Genauer gesagt, in einem Teilbereich, dem Requirements-Engineering bzw. Anforderungsmanagement.

Holen wir einmal kurz aus:

Im Requirements-Engineering geht es darum, sämtliche Anforderungen einer (oft großen) Gruppe von Stakeholdern (Personen, die eine Anforderung an ein Produkt haben), zu analysieren und so zusammenzutragen, dass diese von spezialisierten Kräften (software-)technisch umgesetzt werden können.
Ein weit verbreitetes Problem sind dabei die nicht durchdachten und schwammig formulierten Anforderungen. Während ich mich zum Thema „nicht durchdachte und schwammige Anforderungen“ an anderer Stelle äußern werde, gehen wir in dieser Abhandlung fiktiv davon aus, dass die Anforderungen grundsätzlich inhaltlich und fachlich durchdacht sind. Bleibt also „nur noch“ die Formulierung der Anforderungen.

Dabei sind zwei Primäraspekte zu berücksichtigen:

1. Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

2. Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Ob und wie sich das mit Mustern der hippen Agil-Welt vereinbaren lässt oder ob sich das sogar beißt, dazu werde ich mich an anderer Stelle später separat auslassen.

Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

Das, was gewünscht ist, muss unmissverständlich von jedem lesenden Lebewesen auf diesem Planeten dasselbe und eindeutige Verständnis für das „was“ hervorrufen. Wir sprechen hier also von interpretationsspielraumfreien Texten.

Zugegeben: Das hinzubekommen, ist schwierig bis unmöglich. Es muss also eine bestmögliche Annäherung an „unmissverständlich“ und „interpretationsspielraumfrei“ geben.

Aber grundsätzlich gilt, wenn ein Entwickler etwas Emotionsloses und letztendlich auf Einsen und Nullen (also fließt Strom oder fließt keiner) basiertes Stück Logik in Form einer Software umsetzen muss, dann müssen die Anfroderungen verdammt noch mal eindeutig formuliert sein.

Wenn man seine Anforderungen nicht verständlich zusammentragen kann, passiert das, was keiner will aber zum Tagesgeschäft der meisten Firmen oder Projekte gehört:

„Ach, das haben wir uns aber ganz anders vorgestellt!“

Dieser Satz steht stellvertretend für:

  • vergebens aufgewandte Entwickler-Zeit
  • verbranntes Budget
  • vergeudete Zeit grundsätzlich
  • Frustaufbau
  • Strapazieren von zwischenmenschlichen Beziehungen

Typische Probleme bei der Aufnahme und Formulierung von Anforderungen sind:

  • Kommunikationsprobleme, Sprachbarrieren
  • widersprüchliche Sichten auf den Ist-Zustand
  • unklare Zielvorstellungen des „was“
  • hohe und nicht mehr greifbare Komplexität der zu lösenden Aufgaben
  • sich ständig ändernde Ziele u. Anforderungen
    • marktbedingt (Märkte sollen sich angeblich sehr schnell ändern können)
    • oder weil bereits mit unabgestimmten oder unklaren Anforderungen einfach mal losgelegt wurde
  • schlechte Qualität der Anforderungsbeschreibung
    • mehrdeutig, redundant, widersprüchlich, ungenau…
    • unnötige Produktmerkmale

Natürlich verstecken sich viele Firmen mittlerweile hinter der Agilität und behaupten, man müsse sich einfach viel mehr unterhalten.

Ja klar, wenn man nicht in der Lage ist, seine Anforderungen klar zu strukturieren und zu formulieren, kann man viel intensiver direkt mit den Entwicklern sprechen und Unklarheiten ggfls. durch viele Einzeltherapien aus dem Weg räumen. Aber dann muss man auch hinnehmen, dass man die wenig verfügbare und kostbare Entwicklerressourcen-Zeit zu einem Großteil verbrät anstatt sie entwickeln zu lassen.

Wir müssen darüber hinaus noch zwischen fachlichen und funktionalen Anforderungen unterscheiden und konzentrieren uns in diesem Fall auf ersteres.

Ein paar kleine Beispiele:

„Das Produkt soll das Wetter der nächsten 24 Stunden anzeigen!“

Hierbei ist bspw. unklar, ob das aktuelle Wetter der nächsten 24 Stunden angezeigt werden soll oder ob das für die nächsten 24 Stunden vorhergesagte Wetter angezeigt werden soll.

„Der Zustand der Patienten wird automatisch untersucht und aufgezeichnet!“

In diesem Fall könnte gemeint sein, dass sowohl automatisch aufgezeichnet als auch automatisch untersucht wird, oder dass nur automatisch untersucht wird und manuell aufgezeichnet.

„Wenn der Nutzer den Papierstreifen einsetzt, wird das Tamagotchi auf die Standard-Werte zurückgesetzt!“

Die Anforderung beschreibt ein technisches Gerät, bei welchem mit einem virtuellen Charakter gespielt werden kann. Sowohl der virtuelle Charakter als auch das Gerät selbst heißen „Tamagotchi“, so dass nicht eindeutig ist, ob das Gerät oder lediglich der Charakter auf die Standardwerte zurückgesetzt werden soll.

„Wenn der Nutzer den L-Button drückt, wird der Alarm ausgeschaltet!“

Unklar ist, ob ein ggfls. aktivierte Alarm ausgeschaltet wird oder die grundsätzliche Fähigkeit des Systems, Alarme auszulösen.

Oder zum Abschluss ein Klassiker

 „Schatz, wir haben kein Brot mehr, könntest du bitte zum Supermarkt gehen und eins holen? Und wenn sie Eier haben, bring 6 Stück mit.“

Was wird passieren? Er bringt 6 Stück Brot mit und keinerlei Eier. Und hat aus logischer Sicht alles richtig gemacht.

Das sind nur einige sehr einfache Beispiele. Die mögliche Menge der Unklarheiten und Fehlinterpretationen ist grenzenlos groß.

Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Kommen wir nun zur Unhöflichkeit und betrachten dazu folgendes Beispiel:

„Es wäre schön, wenn die Software hier eine Meldung ausgeben könnte, wenn mit nicht zu großem Aufwand machbar. Wenn zu viel Aufwand, dann könnte man das auch weglassen.“

Kling total nett. Netter Kollege. Mit dem will man auch gern mal ein Bier trinken oder was Leckereres. Das hilft nur im Projekt niemandem weiter. Hier haben wir eine Anforderung, die aus unklaren und sinnlosen Anforderungen besteht. Nehmen wir zuerst die Höflichkeitsmuster aus der Anforderung, dann bleibt:

„Die Software gibt hier eine Meldung aus, wenn Aufwand nicht zu groß, ansonsten könnte man das weglassen.“

Die Entscheidung, ob etwas umgesetzt wird oder nicht, ist im Normalfall nicht Bestandteil einer Anforderung sondern gehört in eine separate Bewertungs- und Priorisierungs-Skala.

Übrig bleibt:

„Die Software gibt hier eine Meldung aus.“

Durch das Weglassen von Floskeln sehen wir die folgenden Effekte:

  • Die Anforderung wird präziser
  • Es muss weniger geschrieben werden (weniger Zeit)
  • Es muss weniger Sinnloses interpretiert und rausgefiltert werden. Das spart noch mal Zeit und wir nähern uns einer Unmissverständlichkeit.

Und jetzt alles zusammen

Wenn wir jetzt noch die Erkenntnisse aus dem vorherigen Abschnitt einfließen lassen, haben wir nach Wegfiltern der sinnlosen Floskeln noch diverse Unklarheiten zu beseitigen bzw. verständlich zu machen:

  • Die Software → Welche Software genau?
  • hier → Wo ist hier „hier“? Wenn jemand in der anderen Seite des Raumes sitzt, wird das vielleicht als „da“ interpretiert? Das haben wir schon in der Sesamstraße gelernt: https://www.youtube.com/watch?v=Z-MRqTJMapY
  • hier → „hier“ ist in diesem Fall vielleicht nicht nur eine Frage nach dem „wo“ sondern auch nach dem „wann“?
  • eine Meldung → Was für eine Meldung? Was sagt die Meldung aus? Wie sieht sie optisch aus? Wie verhält sie sich?

Würden wir nun noch die Bedingungen für eine Bewertungs- und Priorisierungs-Skala hinterfragen und einfließen lassen, auch wenn wir sie eigentlich losgelöst von der eigentlichen Anforderung betrachten wollen, dann:

  • großer Aufwand → Ab wann ist ein Aufwand zu groß? Ist die Umsetzungsdauer gemeint oder der Ressourcen-Aufwand? Und wenn ja, wie viel davon?
  • Könnte → Wenn Aufwand zu groß, was dann? Was bedeutet könnte? Gar nichts machen oder eine einfachere Lösung umsetzen oder erst Rücksprache oder machen wir das vom Wetter abhängig?

Aus

„Die Software gibt hier eine Meldung aus.“

könnte man bspw. folgendes machen:

„Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund. Das Fenster schließt sich nach vier Sekunden selbständig oder das Fenster schließt sich sofort bei beliebigem Mausklick. Umsetzung nur, wenn Aufwand <= 2 Personentage und Umsetzungsdauer <= eine Woche.“

Bzw. gliedern wir die Entscheidung, ob etwas getan werden soll in unsere Bewertungs- und Priorisierungs-Skala aus und setzen das Ganze noch etwas mehr als Stichpunktliste, um die Umsetzung später deutlich besser abnehmen zu können (Akzeptanzkriterien, Testszenarien), dann:

  1. Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘.
  2. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund.
  3. Das Fenster schließt sich nach vier Sekunden selbständig.
  4. Das Fenster schließt auch bei beliebigem Mausklick.

Was haben wir alles gemacht?

  • Nicht hilfreiche Floskeln entfernt.
  • Unpräzise Anforderungen eindeutig gemacht
    • gestückelte, kleine Sätze
    • schwammige oder unklare Anforderungen wurden ausformuliert
  • Listen bringen Verständlichkeit, bessere Testbarkeit und bessere Abnahme-Möglichkeit
  • Nummerierungen (bzw. eindeutige und globale IDs) bringen Transparenz in Abhängigkeiten und Zusammenhänge.
    Man kann mit IDs eindeutig Anforderungen verknüpfen und auch viel transparenter drüber sprechen.

Wer muss das alles tun?

In etablierten Projektstrukturen gibt es eine Kompetenz-Ebene mit der Bezeichnung „Requirements-Engineering“ oder bei Abneigung gegen Anglizismen heißt es dann Anforderungsmanagement. Gibt es diese nicht, turnt meist eine übergreifend anayltisch und konzeptionell qualifizierte Projektmangement-Instanz durchs Projekt. Die machen das, was da oben steht. Teilweise in stunden-/tagelangen Workshops mit den Stakeholdern, indem alles hinterfragt und finalisiert ausformuliert wird.

Bei vielen mir bekannten Firmen ist das ein wenig anders. Es gibt nahezu keine gewerkeübergreifende Analyse- und Konzeptionskompetenz und auch keine für diese Tätigkeit abgestellte Personenmenge. Und das schon gar nicht auf Detailebene. Dazu kommt eine Vielzahl an Anforderungsstellern, die auf verschiedenste Zielsysteme schießen. Bei der Menge an Personen und Anforderungen können die Anforderungen nicht von einer Person aufgenommen, analysiert und konzeptionell finalisiert werden. Das ist von der schieren Menge her nicht machbar. So müssen Anforderungen bereits von den Stakeholdern oder eine spezialisierten Gruppe an Stakeholdern zumindest annähernd in der o.a. Qualität formuliert werden.

Das bedeutet?

Hört auf zu schwafeln und bitte, danke, hätte, könnte in Anforderungen prosaisch zu verpacken. Bringt es auf den Punkt. Sagt, was gefordert ist.