Was eine Plattform braucht, bevor Code entsteht

Es hilft, weil jede Frage, die früh beantwortet wird, später nicht mehr mitten in der Arbeit von einem Entwickler beantwortet werden muss. Steht aufgeschrieben, wie eine Rechnung storniert wird oder wer die Akte eines Kunden sieht, wird die Plattform gleich beim ersten Mal so gebaut, wie Ihr Unternehmen es meint.

Der Unterschied zeigt sich deutlich beim Neubau alter Systeme. Der Code ist meist richtig. Was fehlt, ist eine schriftliche Beschreibung, was er tun sollte. Gibt es diese Beschreibung, ist jede Diskussion über einen „Fehler“ einfach: Wir lesen nach, was dort steht, und wissen sofort, was gilt.

Die Antworten aufzuschreiben dauert ein bis zwei Wochen. Das kostet aber viel weniger als eine Regel, die im vierten Monat auffällt, wenn Bildschirme und Daten schon auf einer falschen Annahme beruhen. Deshalb beginnt unser Vorgehen mit einer Anforderungsphase. Sie genehmigen sie, bevor Struktur, Gestaltung oder Bau starten.

Es sind sechs Punkte, und keiner braucht Fachsprache. Die Tabelle zeigt jeden Punkt, die Frage, die er beantwortet, und ein kurzes Beispiel für eine brauchbare Antwort, klar genug, um darauf zu bauen. Eine Antwort, die in wenige einfache Sätze passt, zeigt, dass alle das Thema verstanden haben.

Die letzte Zeile ist die wichtigste. Eine Anforderung hat Wert, wenn man sie prüfen kann. Deshalb schreiben wir jeden allgemeinen Wunsch gemeinsam mit Ihnen um, bis er eine klare Prüfung ist.

Sie werden in einer festen Folge von fünf Schritten zur Vorgabe. Jeder Schritt endet in einem Text, den Sie lesen und genehmigen können. Der Bau beginnt, nachdem Sie den fünften Schritt genehmigt haben. Was dann noch offen ist, wird als offen festgehalten, damit Sie es entscheiden und nicht der, der baut.

1. Wir sprechen mit denen, die sie nutzen werden. Wir hören den Inhaber des Unternehmens, aber auch jeden, der sie täglich benutzt. Dieser kennt die Ausnahmen.

2. Wir schreiben die Regeln in einfachen Sätzen. Eine Regel pro Satz. „Eine Erstattung über einem Grenzwert braucht eine Freigabe“ ist eine klare Regel, die man prüfen kann.

3. Wir legen die Rollen fest und was jede sieht. Eine einfache Tabelle mit Rollen und Aktionen deckt die meisten Fehler bei den Rechten auf, bevor sie auftreten.

4. Wir halten Grenzen und offene Fragen fest. Rechtliche, technische und betriebliche Grenzen stehen auf einer Seite. Jede Frage, die auf eine Antwort wartet, bekommt einen Verantwortlichen und ein Datum.

5. Wir vereinbaren die Abnahmeprüfungen. Jede Regel bekommt mindestens eine Prüfung. Sie lesen die Liste und genehmigen sie.

Das Ergebnis ist ein schriftlicher Umfang, der Ihr Unternehmen genau beschreibt. Auch unsere eigenen Werkzeuge für den Bau arbeiten danach. Deshalb zahlt sich die Sorgfalt in dieser Phase im ganzen weiteren Projekt aus.

Es heißt, dass wir die Technik wählen, nachdem wir wissen, was Sie brauchen. Die Anforderungen legen fest, was die Plattform können muss, wie viele sie nutzen werden und mit welchen Systemen sie sich verbinden muss. Danach wählen wir die Werkzeuge, die dazu passen. Wir erklären schriftlich, warum wir sie gewählt haben, damit Sie die Begründung immer zur Hand haben.

Ein kleines internes Werkzeug für zehn Kolleginnen und Kollegen und eine Plattform für Tausende Kunden aus vielen Organisationen sind verschiedene Projekte, auch wenn die Bildschirme ähnlich aussehen. Das erste braucht eine einfache Einrichtung, die sich leicht übergeben lässt. Das zweite braucht getrennte Daten für jeden Kunden, sorgfältige Zugriffsregeln und Überwachung. Wissen wir von Anfang an, welches von beiden Sie brauchen, hat das System genau die Größe, die Ihre Arbeit verlangt.

Auf der Seite zu SaaS-Plattformen und Business-Anwendungen lesen Sie, was ein solches Projekt umfasst. Die Anforderungsphase ist der klarste Weg, gemeinsam die richtige Lösung für Ihren Fall zu finden.

Besondere Aufmerksamkeit verdienen Anforderungen, die auf keinem Bildschirm zu sehen sind: Sicherheit, Barrierefreiheit, Fehlerbehandlung, Übergabe. Meist fragt niemand danach, aber sie machen im Alltag einen großen Unterschied. Wir gehen sie von Anfang an eine nach der anderen durch, denn dann sind sie leicht aufzuschreiben, während sie in einem fertigen Produkt teurer nachgerüstet werden.

• Sicherheit. Wer sich anmelden darf, wie Passwörter geschützt werden, was nach vielen fehlgeschlagenen Versuchen passiert. Der OWASP Application Security Verification Standard ist ein offener Standard mit technischen Sicherheitsanforderungen. Wir nutzen ihn als Checkliste, um zu sehen, welche davon Ihre Plattform betreffen.

• Barrierefreiheit. Soll die Plattform auch Menschen mit Behinderung dienen, wird das jetzt festgehalten. Die WCAG des W3C sind der internationale Bezugspunkt, mit den Stufen A, AA und AAA. So wird das Ziel als prüfbare Anforderung geschrieben.

• Fehlerbehandlung. Der Zahlungsanbieter antwortet nicht, eine Datei ist zu groß, der Nutzer schließt das Fenster mittendrin. Für jeden Fall vereinbaren wir, was genau passiert.

• Übergabe. Wie Konten, Code und Daten an dem Tag übergeben werden, an dem das Projekt abgeschlossen ist.

• Wachsende Nutzung. Dafür braucht es keine Prognose, nur eine Frage: Was muss weiter funktionieren, wenn zehnmal so viele Nutzer kommen?

Es wird mehr geprüft, als man erwartet. Ein schriftlicher Umfang wird auf Widersprüche gelesen. Eine Rollentabelle wird mit echten Szenarien durchgespielt. Die Abnahmeprüfungen werden zu automatischen Tests, noch bevor es die Funktion gibt, die sie prüfen. Das ist die Logik von „erst der Test“: Die Prüfung ist die Vorgabe selbst, in einer Form, die sich ausführen lässt.

Denselben Ansatz verfolgen wir in unserer eigenen Arbeit. Die Fallstudie zu Planner zeigt, wie aus einer schriftlichen Vorgabe eine Anwendung wird, mit Prüfungen in jedem Schritt und in einem echten Browser. Sie zeigt auch, was möglich wird, wenn die Texte so genau sind, dass ein Werkzeug ihnen folgen kann.

Haben Sie schon Notizen, eine Tabelle oder ein altes System, bringen Sie sie mit. Sie sind wertvolles Material für die Vorgabe, auch wenn sie nicht geordnet sind. Sie können mit einer Projektanfrage beginnen und uns sagen, was Sie schon wissen und was wir gemeinsam klären sollen.

Sie entscheiden über Zweck, Regeln, Daten und Prioritäten, denn das sind Geschäftsentscheidungen. Wir schlagen Lösungen vor, erklären das Für und Wider und halten jede Entscheidung fest. Den technischen Weg bestimmen wir, nachdem die Anforderungen genehmigt sind, und erklären ihn in einfacher Sprache.

So bleiben die Verantwortlichkeiten klar. Muss eine Regel später geändert werden, gibt es eine schriftliche Aufzeichnung, wer sie festgelegt hat und warum. Die Korrektur wird ein einfaches, ruhiges Gespräch. Muss eine technische Wahl geändert werden, zeigt dieselbe Aufzeichnung, welche Anforderung sie erfüllt.