Der Planner: von der Spezifikation zur App

Der Planner ist unser eigenes Werkzeug, das ausführliche Vorgaben ohne Aufsicht in eine Anwendung verwandelt. Bei jeder Funktion entsteht zuerst der Test, das Ergebnis wird im Browser mit dem Entwurf verglichen, und eine Qualitätsschranke entscheidet, was weitergeht.

Eigenes Produkt

Branche	Interne Werkzeuge und Plattformen
Herausforderung	Unklare Struktur
Entscheidungsumfeld	Produktbewertung
Komplexität	Hoch
Leistung	Plattform

Wenn Sie wissen wollen, mit welcher Kontrolle aus einer schriftlichen Vorgabe eine Anwendung entstehen kann: Die Fallstudie zeigt, wie der Planner von der ersten Zeile bis zur Übergabe arbeitet und wo die letzte Entscheidung immer bleibt, bei Ihnen. Der Planner ist unser eigenes Werkzeug, deshalb nennen wir seinen echten Namen.

Element	Einzelheit
Art	Eigenes Produkt, mit Namen genannt
Eingabe	Schriftliche Vorgaben und das Material des Kunden
Zwei Arten von Projekten	Website (Next.js mit unserem eigenen CMS) und SaaS-Plattform (Laravel API und Next.js)
Regel je Funktion	Erst der Test, dann der Code
Leistungen, die er stützt	Unternehmenswebsites, SaaS-Plattformen und Business-Anwendungen

Der Planner Wie sah die Ausgangslage aus?

Wir bauen Websites und Plattformen für Organisationen, die ein planbares Ergebnis wollen. In jedem Projekt wiederholen sich dieselben Grundschritte: Aufbau, Funktionen, Tests, Prüfung des Aussehens, Korrekturen. Wenn man sie aus dem Gedächtnis erledigt, ändern sie sich von Projekt zu Projekt ein wenig. Ein festes Werkzeug sorgt dafür, dass jeder Schritt immer auf dieselbe Weise geschieht.

Darum haben wir unsere Methode in ein Werkzeug verwandelt. Der Planner nimmt Vorgaben und geht jedes Mal denselben Weg. Er ist keine Vorlage, die gleiche Websites ausstößt. Er ist ein Ablauf, der jeden Schritt zu Ende bringt.

Er arbeitet bei zwei Arten von Projekten: einer Website in Next.js mit unserem eigenen CMS als Backend und einer SaaS-Plattform mit Laravel API und Next.js.

Der Planner Was sollte der Planner lösen?

Die wichtigste Anforderung war Beständigkeit bei wachsendem Umfang. Die Vorgaben sind ein langes Dokument. Irgendwo zwischen Seite 3 und Seite 40 kann eine Anforderung etwas anders umgesetzt, vergessen werden oder etwas anderes beeinflussen. Ein Mensch bemerkt einen Teil davon, ein müder Mensch weniger.

Es gab eine zweite Anforderung. Eine automatische Arbeit ohne Beobachtung kann stundenlang vom Ziel abkommen. Ein Werkzeug ohne Aufsicht braucht einen Aufseher und feste Grenzen, damit Selbstständigkeit immer von Kontrolle begleitet wird.

Der Planner Welche Rahmenbedingungen haben ihn geprägt?

Vier Bedingungen ergaben sich aus unserer Arbeitsweise. Der Inhaber des Projekts entscheidet, was nur er entscheiden kann. Das Werkzeug bringt seine Arbeit zu Ende, ohne endlose Schleifen. Die Grenzen stehen im Code. Angaben des Kunden werden nie erfunden. Es folgen die Einzelheiten.

Die Grenzen stehen im Code: höchstens 5 Sessions je Aufgabe, 3 Reparaturen der Qualitätsschranke, 3 Versuche je Prüfrunde. Ist eine Grenze erreicht, bleibt das Thema für den Inhaber liegen, während die Ausführung mit dem Rest weitermacht.

Die letzte Bedingung betrifft den Inhalt. Preise, Freigaben oder Tatsachen liefert der Kunde. Was nur der Inhaber geben kann, wird in einer Liste für ihn gesammelt, und der Text wird so geschrieben, dass er auch ohne diese Angaben vollständig lesbar ist.

Der Planner Was macht den automatischen Bau zuverlässig?

Der automatische Bau wird zuverlässig, wenn er drei Punkte abdeckt. Jeder Erfolg wird durch Code belegt, der wirklich gelaufen ist. Jede Korrektur wird von einer neuen Prüfung aller übrigen Teile begleitet, damit nichts anderes kaputtgeht. Jeder Versuch hat eine Grenze, damit das Werkzeug nicht immer wieder dasselbe repariert.

Dazu kommt ein vierter Punkt: Die Seite im Browser muss dem vereinbarten Entwurf ähneln. Der Vergleich geschieht bei jeder Funktion, nicht erst am Ende. So wird eine Abweichung sofort korrigiert, bevor sie sich auf vielen Seiten wiederholt.
Jeder dieser Punkte wurde zu einer Regel des Planners. Die nächsten Abschnitte zeigen, wie.

Der Planner Wie gehen wir vor?

Der Planner folgt einem festen Weg, vom Entwurf bis zu den Berichten. Jede Funktion durchläuft dieselben Schritte: fehlschlagender Test, Code, Qualitätsschranke, Prüfung im Browser, unabhängige Zweitprüfung. Die nummerierte Liste zeigt die Reihenfolge, von den Vorgaben bis zu den abschließenden Qualitäts- und Sicherheitsprüfungen.

Entwurf: Die Vorgaben werden zu einer Liste von Funktionen mit Abnahmekriterien und Seiten.
Inhalt: Jede Seite und jeder Artikel wird geschrieben, bevor gebaut wird.
Für jede Funktion: zuerst die Analyse der Auswirkungen, dann ein fehlschlagender Test, dann der Code, der ihn bestehen lässt, am Ende das Aufräumen.
Qualitätsschranke: lint, typecheck, Tests, build und e2e-Tests müssen bestehen, mit Belegen.
Prüfung im Browser: Das Ergebnis wird geöffnet und mit dem Entwurf verglichen.
Unabhängige Zweitprüfung der Funktion und Commit.
Der Inhaber sieht den Build und gibt ihn frei, bevor die Prüfungen beginnen. Von da an ist das Design gesperrt: Änderungen am Aussehen werden zu Vorschlägen an den Inhaber.
Prüfungen: Die Agents für Qualität und Sicherheit laufen auf einem festen Weg. Wir beschreiben sie in der Fallstudie Agents für Qualität und Sicherheit.

Zwei Ebenen beaufsichtigen die Arbeit. Ein Hook innerhalb der Session lässt sie nicht ohne Belege enden. Ein Aufseher außerhalb der Session startet sie neu, wartet, wenn die Nutzungsgrenzen erschöpft sind, und hält Phasen und Grenzen ein. Bei einem echten Hindernis übergibt er es an einen Entscheider, der festlegt, wie die Arbeit weitergeht.

Der Planner Welche Entscheidungen waren wichtig?

Es gibt sechs wichtige Entscheidungen: erst der Test, Beleg statt Behauptung, fester Weg mit festen Runden, Freigabe durch den Inhaber vor den Prüfungen, Tests auf einer Kopie der Datenbank, CMS nur zum Lesen. Jede beantwortet einen der Punkte aus dem vorigen Abschnitt.

Erst der Test

Für jede Funktion wird zuerst der fehlschlagende Test geschrieben. So ist „fertig“ von Anfang an klar definiert.

Beleg, nicht Behauptung

Die Schranke führt echte Befehle aus und behält das Ergebnis. Eine Funktion gilt nur dann als fertig, wenn die Prüfungen es belegen.

Fester Weg, feste Runden

Jeder Prüf-Agent läuft einmal, in fester Reihenfolge und mit einer bestimmten Zahl von Runden. Die zweite Runde läuft nur, wenn die erste etwas korrigiert hat. Ein Agent läuft nur innerhalb seiner eigenen Reihenfolge erneut, nicht weil jemand anderes Code geändert hat. So kommt der Ablauf immer zum Ende.

Der Inhaber gibt vor den Prüfungen frei

An diesem Punkt wird das Design gesperrt. Die Prüfungen konzentrieren sich auf Richtigkeit, nicht auf Geschmack.

Tests auf einer Kopie der Datenbank

Die Tests laufen auf einer Kopie, nie auf der Inhaltsdatenbank. Das Werkzeug hält an, wenn beide Datenbanken dieselbe sind, damit der echte Inhalt frei von Testdaten bleibt.

Das CMS ist auf der Website nur zum Lesen da

Was im CMS gefunden wird, wird festgehalten und in dessen eigenem Repository korrigiert, nicht durch eine Notlösung in einer einzelnen Website.

Der Planner Was ist das Ergebnis?

Das Ergebnis ist Beständigkeit. Jedes Projekt folgt demselben Weg, und jeder Schritt hinterlässt Belege, sodass nichts von der Aufmerksamkeit Einzelner abhängt.

Der Kunde erhält einen Build, in dem jede Funktion einen Test hat und jede Seite im Browser geprüft wurde. Er erhält außerdem eine Datei mit allem, was geprüft wurde, und eine kurze Liste der Entscheidungen, die bei ihm lagen. So beruht die Website auf einem prüfbaren Weg, nicht auf dem Gedächtnis von jemandem, und bleibt über Jahre zuverlässig.

Der Planner übernimmt die wiederkehrenden Teile der Arbeit, damit sich das menschliche Urteil auf die Fragen richtet, die es brauchen. Wie ein Projekt von der Anfrage bis zur Lieferung vorankommt, lesen Sie in unserem Ablauf, oder starten Sie ein Projekt.

Der Planner: von der Spezifikation zur App Häufige Fragen

Braucht der Planner menschliches Eingreifen?

Ja, bei den Entscheidungen, die dem Inhaber gehören. Dazwischen arbeitet der Planner ohne Aufsicht. Der Inhaber gibt den Build vor den Prüfungen frei und entscheidet, was nur er entscheiden kann. Der Planner sammelt diese Themen in einer Liste und macht mit dem Rest weiter.

Was bedeutet „erst der Test“ für den Kunden?

Es bedeutet, dass jede Funktion eine automatische Prüfung hat, die vor der Funktion selbst geschrieben wurde. Wenn eine Änderung die Funktion später beeinträchtigt, bemerkt die Prüfung es sofort. So finden wir die Probleme, bevor Sie ihnen begegnen.

Mit welchen Technologien arbeitet der Planner?

Er arbeitet bei zwei Arten von Projekten: Websites in Next.js mit unserem eigenen CMS und SaaS-Plattformen mit Laravel API und Next.js. Bei anderen Technologien besprechen wir es mit Ihnen, bevor das Projekt beginnt.

Nächster Schritt: Der Planner: von der Spezifikation zur App

Starten Sie Ihr Projekt

Senden Sie eine Projektanfrage oder prüfen Sie Ihre aktuelle Website kostenlos. Jede Nachricht lesen wir selbst.

Projekt starten Website prüfen