Eine Verwaltungssoftware in Phasen entwickeln: entscheiden, was in die erste Version kommt

Die Frage „Was kommt in die erste Version“ bekommt fast immer dieselbe falsche Antwort: ein bisschen von allem. Ein Stück Stammdaten, ein Stück Bestellungen, ein Stück Lager. Das ist die Wahl, die am vorsichtigsten erscheint und die man nicht nutzen kann: Kein Prozess kommt bis zum Ende, und das System bleibt etwas, das man zusätzlich zu dem ausfüllen muss, was man ohnehin schon tut.

Das Kriterium ist das Gegenteil: Die erste Version deckt einen vollständigen Prozess ab, von Anfang bis Ende, auch wenn er eng begrenzt ist. Besser wenig und vollständig als viel und unterbrochen.

Ein vollständiger Prozess, mit einem sichtbaren Ergebnis

„Vollständig“ hat eine genaue Bedeutung: Wer das System nutzt, muss für diesen Teil der Arbeit die frühere Methode aufgeben können. Wird nach der Dateneingabe im System weiterhin auch die gewohnte Tabelle ausgefüllt, ist die erste Version nicht fertig: Das ist doppelte Arbeit, und sie wird aufgegeben, sobald das Unternehmen eine schwierige Woche hat.

Das Ergebnis muss für jemanden sichtbar sein: ein Dokument, das ausgegeben wird, eine Liste, die es vorher nicht gab, ein Anruf, der nicht mehr nötig ist. Das dient zwei Dingen gleichzeitig: Es liefert einen konkreten Grund, das System zu nutzen, und einen Beweis, dass das Projekt vorankommt.

Das Unverzichtbare von den Verbesserungen trennen

Die Anfragen kommen alle gleichzeitig und alle dringend. Es braucht Fragen, die trennen, und es sind immer dieselben vier.

• Bleibt der Prozess ohne diese Funktion stehen? Kann jemand dasselbe vorläufig auf andere Weise erledigen, ist sie nicht unverzichtbar.
• Wer nutzt sie, und wie oft? Funktionen, die zweimal im Jahr gebraucht werden, können lange manuell bleiben, und oft bleiben sie für immer manuell, ohne dass sich jemand beschwert.
• Was passiert wirklich, wenn sie fehlt? „Wir verlieren Zeit“ und „wir können nicht fakturieren“ sind nicht dieselbe Antwort.
• Ist es eine Funktion oder eine Gewohnheit? Es kommt vor, dass ein Schritt nachgebildet werden soll, der nur existierte, weil das alte Werkzeug nichts anderes konnte.

Vorsicht bei kurzen Anfragen, die eine ganze Welt mit sich bringen: Ein zusätzlicher Status auf einem Dokument kann Berechtigungen, Benachrichtigungen, einen Verlauf und eine Regel erfordern, wer ihn ändern darf. Der Aufwand bemisst sich nicht an der Länge des Satzes, der ihn beschreibt.

Die Abhängigkeiten, die man nicht aufschieben kann

Die Einführung in Modulen funktioniert nur, wenn bestimmte Entscheidungen sofort getroffen werden, auch wenn sie Teile betreffen, die erst viel später kommen. Es sind wenige, und sie später zu ändern kostet so viel wie ein Neubau.

• Die gemeinsamen Daten: wie ein Kunde, ein Artikel, ein Auftrag identifiziert wird. Erfindet die erste Version eine eigene Nummerierung, muss die zweite später zwei Archive abgleichen.
• Wer was sieht: Die Berechtigungen werden von Anfang an geplant, auch wenn das System anfangs nur von drei Personen genutzt wird. Sie später hinzuzufügen bedeutet, jeden Bildschirm zu überarbeiten.
• Woher die Daten kommen, die nicht hier entstehen: Liegen die Bestände woanders, wird jetzt entschieden, wer über eine Menge bestimmt, auch wenn die Anbindung erst später kommt.
• Wie der Verlauf erfasst wird: Muss man wissen, wer was geändert hat, muss das von Anfang an vorgesehen werden, denn im Nachhinein lässt es sich nicht rekonstruieren.

Beispiel: erste Version für Aufträge

Ein Unternehmen, das Anlagen installiert, möchte eine Verwaltungssoftware für Aufträge. Die Wunschliste enthält rund zwanzig Funktionen. Die erste Version nimmt vier davon, kommt aber bis zum Ende.

Die ausgeschlossenen Funktionen sind nicht gestrichen: Sie bleiben aufgelistet, mit dem Grund daneben und der Bedingung, unter der sie wieder aufgenommen werden. Das ist der Unterschied zwischen Aufschieben und Vergessen, und es erlaubt auch, denen zu antworten, die sie verlangt hatten.

Abnahmekriterien: wie man sagt, dass es fertig ist

„Es funktioniert“ ist kein Kriterium. Ein Kriterium ist ein Satz, den jeder überprüfen kann, geschrieben bevor die Entwicklung beginnt.

1. Den realen Fall beschreiben, nicht die Funktion: „Der Baustellenleiter eröffnet den Auftrag aus einem angenommenen Angebot, teilt das Team zu und füllt den Bericht vom Telefon aus, auf der Baustelle“.
2. Sagen, wer es prüft: die Person, die diese Arbeit täglich macht, nicht die, die das Projekt in Auftrag gegeben hat.
3. Die schwierigen Fälle einbeziehen: der stornierte Auftrag, der ohne Netzverbindung ausgefüllte Bericht, der Einsatz, dessen Termin sich verschiebt.
4. Festlegen, mit welchen Daten getestet wird: echte und aktuelle Daten, denn erfundene sind immer ordentlicher als die Wirklichkeit.

Die Anfragen, die währenddessen eintreffen

Sie werden kommen, und das ist ein gutes Zeichen: Es bedeutet, dass jemand das System nutzt. Das Problem ist nicht, sie zu erhalten, sondern sie schnell einzuordnen.

• Fehler: Das Vorhandene tut nicht das, was vereinbart wurde. Wird sofort korrigiert.
• Versäumnis: wird für den Prozess gebraucht, und niemand hatte es erwähnt. Es wird geprüft, ob es aufgenommen wird, und der Liefertermin verschiebt sich entsprechend.
• Verbesserung: macht die Arbeit angenehmer. Kommt auf die Liste, nicht in die laufende Version.
• Kurswechsel: Das Unternehmen hat seine Arbeitsweise geändert. Muss gesondert besprochen werden, denn es ist keine Anfrage, sondern ein anderes Projekt.

Ohne diese Unterscheidung wird jede Anfrage dringend, und die erste Version erscheint nie. Das ist die häufigste Art, wie solche Projekte ins Stocken geraten: nicht wegen eines technischen Hindernisses, sondern durch Anhäufung.

Was dieser Leitfaden nicht abdeckt

Hier geht es um Umfang und Reihenfolge: was in die erste Version kommt, was aufgeschoben wird und in welcher Reihenfolge. Die Tests, die vor dem täglichen Verlassen auf ein System durchzuführen sind, sind ein eigenes Kapitel. Und betrifft die zu bewertende Funktion den Einsatz eines automatischen Assistenten, gelten andere Beurteilungskriterien, weil das Ergebnis nicht auf dieselbe Weise vorhersehbar ist.