Fehlschläge - Link-Tipp

Fehlschläge bei IT- und Software-Projekten sollen schon vorgekommen sein - auch ohne teuren Flughafen drumherum... Nun lernt man z. B. bei Scrum aus eigenen Fehlern immer am Besten, jedoch lernt man aus den Fehlern anderer deutlich billiger: P. Mertens von der Universität Erlangen-Nürnberg untersucht in dem Artikel "Fehlschläge bei IT-Großprojekten der Öffentlichen Verwaltung – ein Beitrag zur Misserfolgsforschung in der Wirtschaftsinformatik" Fehlschläge und resultierende Erfahrungen bei öffentlichen Projekten (der Artikel ist - glaube ich - in ähnlicher Form im "Informatik Spektrum" der Gesellschaft für Informatik erschienen).
Beim Lesen besser nicht drüber nachdenken, was das an Steuergeldern gekostet hat!

Anforderungen formulieren - Best practices

Eigentlich ist es nicht schwierig, die grundlegenden syntaktischen und grammatikalischen Bedingungen anzuwenden:

Formulierungen im Aktiv
Auch wenn es nicht nach superkorrektem Formaldeutsch klingt:

• Richtig: „Der Benutzer markiert die freizugebenden Einträge und bestätigt die Freigabe“ 
• Behördendeutsch: „Durch die Markierung und anschließende Bestätigung initiiert der Benutzer die Freigabe“

Ungenauigkeiten vermeiden
Vermeiden von Abschwächungen und ungenauen Quantifizierungen, zur Abschreckung:

• „Das neue System muss alles können, was das alte System auch konnte“
• „Das System verschickt die Reports in der Regel täglich“
• „Grundsätzlich zeigt das System dem Benutzer nur aussagekräftige Fehlermeldungen“

Einfache, klare Sätze

• Richtig: „Das System zeigt... Der Benutzer gibt ein...“
• Falsch: "Nachdem das System die Liste anzeigt, gibt der Benutzer einen Suchbegriff zur Verfeinerung ein" 

Hier empfiehlt sich der Translator-Test: wenn es so einfach ist, dass man es z.B. mit Google Translate vom Deutschen ins Englische übersetzen kann, ohne dass es zu peinlich wird, dann ist es einfach genug! Abgesehen davon, dass Sie vielleicht nicht jedem Übersetzungsdienst sagen möchten, womit Sie sich gerade beschäftigen...


Priorität und Verbindlichkeit

Pro Anforderung festlegen:

• Richtig: Soll, Muss, Kann
• Falsch: „Das System sollte das jeweils aktuelle Datum auf jede Seite des Reports ausgeben“ - die Klassifizierung kann sich schneller ändern, als Sie die Grammatik anpassen können!

Soweit – so einfach. Im Prinzip.

In der Praxis muss man meist Fachleuten mit tiefem Fachwissen solche einfachen Regeln immer und immer wieder nahebringen, oft verwechseln gerade ungeübte Anwender epische Romantexte mit nützlichem Informationsgehalt.
Und: interessante Nebensatzkonstruktionen sollte man Herrn Kafka und Kollegen überlassen.

Anforderungen – oder: Wie man als strahlender Held den neunköpfigen gordischen Knoten reitet...

Projekterfolg steht und fällt mit Anforderungen – das ist bekannt. Aber ist das wirklich so schwierig? Eigentlich liest man doch dauernd über Requirements Engineering, zum Beispiel

• Requirements Engineering von Klaus Pohl
• Das berühmte Volere Template
• Artikel, Paper und Vorträge von Chris Rupp von der Sophist Group 

Best Practices zur Formulierung von Anforderungen finden Sie hier.

Ein paar Anforderungen zu sammeln, ist eigentlich einfach: viele Unternehmen verwenden Excel, einige hingegen spezielle Software wie Doors oder andere. Auch Ticketsysteme wie Jira werden gerne als Anforderungsverwaltung eingesetzt.

Und die Verwaltung?

Mit welchem Tool verwalten Sie als Projektleiter die wachsende Liste? Word? Excel? Wiki-Systeme wie Confluence? Ticket-Systeme wie Jira? Viele Unternehmen nutzen Excel – ist sowieso vorhanden, mittlerweile mengentauglich und jeder kennt es. Und der ein oder andere kann sogar Makros programmieren – ganz ohne IT-Abteilung!

Schnell geht mit der wachsenden Anforderungsflut die Übersicht verloren, aber halt, in Excel nutzen Sie doch einfach Auto-Filter, Pivot-Tabellen und Gruppierungen! Jetzt müssen Sie noch kurz das Feedback der Stakeholder einholen, also Datei versenden und hoffen, dass die alle nur ins vorgesehene Feld schreiben.

Dummerweise geht das mehrfach so, weil eine Antwort mitunter weitere Fragen hervorruft. Und Stakeholder gibt es mehr, als Sie dachten. Die fangen an, Antworten und Kommentare mit individuellen Farben zu markieren, weil man so einfacher auf einen Blick den Zusammenhang sieht. Oft trifft man zudem auf die Kombination aus Excel zum Filtern und Sortieren und Word zur textuellen Beschreibung.

Haben Sie das schon mal erlebt? Nach meiner Beobachtung erstellen vor allem Techniker und Ingenieure mit Vorliebe Funktionslisten: Benutzerregistrierung, Anmeldevorgang, Suchfunktion, Neuanlage von Geschäftsobjekten Typ A, Neuanlage von Geschäftsobjekten Typ B, ...

Hilft das den Stakeholdern, wenn sie die Anforderungen prüfen und freigeben sollen? Ich erinnere mich an ein Projekt, in dem die Stakeholder sich nach einigen Runden außer Stande sahen, die Beschreibungen jeweils zu prüfen und freizugeben. Wie beherrschen Sie die Komplexität? Noch mehr Makros und Filter?

Hier hilft Ihnen nur Struktur: vom Groben zum Detail, auf jeder Ebene Übersicht schaffen!
Welche Strukturierung passt zu Ihrer Anwendungsdomäne? Eine generelle Antwort ist schwierig: "Embedded Software" im Anlagenbau unterscheidet sich deutlich von Online Transactional Processing (OLTP), also Verwaltungssoftware, in Unternehmen.
Meine Domäne sind OLTP-Systeme, bei denen immer – und wirklich immer – folgende Struktur schnell Nutzen schafft:

Strukturen

Geschäftsprozesse

Womit erwirtschaftet das Unternehmen Gewinn? Oft sind durch Betriebsorganisation oder ähnliche Stakeholder Prozesse schon dokumentiert. Zudem kann man schnell in wertschöpfende Kernprozesse und unterstützende Prozesse unterscheiden. Meist erhält man eine Folge von Prozessbereichen, die auch zeitlich darstellbar sind. Beispiele:

• Produktentwicklung in einem Versicherungsunternehmen: stellt oft den ersten Schritt im Lebenszyklus eines Produktes dar, inklusive Ideenfindung, Berechnungen, Dokumentation, etc.
• Marketing des entwickelten Produktes ist der nächste Schritt: das Unternehmen bewirbt das Produkt 
• Vertrieb fokussiert sich auf die Ansprache einzelner Kunden: denen muss man natürlich den Produktpreis individuell benennen können
• Abschluss folgt dem Vertrieb, in der Versicherungsdomäne ein sehr wichtiger Prozessbereich mit vielen einzelnen Prozessen

Use Cases – Anwendungsfälle

Wer macht was mit dem System? Hier beschreiben Sie die Prozessanteile, die mit dem zu entwickelnden System umgesetzt werden. Dabei führen „Akteure“ die Schritte des Use Cases aus. Ein Use Case stellt einen abgeschlossenen Bearbeitungsschritt dar – und kann auch von einem externen Systeme als Akteur ausgeführt werden (Beispiel unten).

User Stories: hier wird’s agil... 

Man kann einen Use Case meist gut zerlegen in kleinere Teile (Login, Suchen, Ergebnisse sortieren). Das hilft bei agilen, kurzen Sprints: das Team kann die Story auch wirklich in der Zeit umsetzen, der gesamte Use Case kann in mehreren Sprints entstehen (Beispiel unten).

Nichtfunktionale Anforderungen

Gerne vergessen und immer ein Kostenfaktor: wie schnell soll eigentlich das System jeweils reagieren? Und wie viele Datensätze verarbeiten Sie denn so? Es macht ja doch einen Unterschied, ob man das System für 10.000 oder 10 Millionen Datensätze pro Stunde entwirft.

Beispiele 

Use Cases – ganz grob

• Akteur Sachbearbeiter
• Antrag erfassen: Unbearbeiteten Antrag wählen, gescannten Papierantrag anzeigen,  automatisch erfasste Daten sichtprüfen, fehlende und falsche Daten nachtragen, Antrag prüfen und freigeben.
• Akteur Zeitsteuerung
• Antragsprüfung einmal pro Tag starten: freigegebene Anträge für die Prüfung finden, jeden Antrag maschinell prüfen, Ablehnung oder Bestätigung veranlassen.
• Akteur externes System, hier Data Warehouse (DWH)
• Daten neuer Anträge exportieren an das DWH: pro Sparte Daten selektieren und verdichten, Ergebnisse exportieren, erfolgreichen Lauf vermerken.

User Stories (Beispiel Antrag erfassen)

• Als Sachbearbeiter wähle ich einen gescannten und automatisch erkannten, aber noch nicht bearbeiteten Antrag aus, um ihn zu bearbeiten und dadurch einen Vertragsabschluss vorzubereiten.
• Als Sachbearbeiter lasse ich mir den gescannten Papiereintrag anzeigen, um die automatisch erkannten Einträge zu prüfen und gegebenenfalls zu korrigieren.
• Als Sachbearbeiter vergleiche ich automatisch erkannte Feldinhalte mit dem Scan-Bild und korrigiere Fehler.
• Als Sachbearbeiter starte ich die automatische Prüfung und gebe den Antrag frei, wenn keine Probleme erkannt wurden, um den Vertragsabschluss zu ermöglichen.
• Als Sachbearbeiter starte ich die automatische Prüfung und setze den Antrag auf Wiedervorlage bei Problemen. Hiermit werden fehlerhafte Anträge nachbearbeitet.

Das wirkt auf den Leser nüchtern und langweilig? Mag sein, die Einfachheit der User Stories erlaubt aber eine Bearbeitung z.B. in einem Sprint und vermeidet Mehrdeutigkeiten. Denken Sie daran: was Sie nicht reinschreiben, wird spätestens dann vom Entwickler interpretiert.

Die oben gezeigte Struktur hilft bei der Verwaltung von Anforderungen, sowohl in traditionellen als auch in agilen Projekten! Probieren Sie es aus – und finden Sie Ihre eigene, perfekte Struktur!

Viele große Projekte versuchen zudem, sehr feine Anforderungen zu verwalten, um Nachvollziehbarkeit zu erreichen. Dies ist jedoch eine ganz andere, längliche Geschichte... 

Link-Tipp. Dunkle Seite von Scrum

Die zahllosen Scrum-Seiten zeigen ja immer, wie alles toll und reibungslos funktioniert, worauf man achten muss usw.

Wie Rolf Dobelli in seinem Bestseller "Die Kunst des klaren Denkens" zeigt, sollte man sich eher für die Misserfolge vieler Probanden als für die Erfolge einiger weniger Probanden interessieren.

Daher unbedingt lesen: die dunkle Seite von Scrum