Arbeitsweise

Erst entscheiden, dann bauen.

Vor der ersten Zeile Code steht fest, was entstehen soll und woran wir messen, dass es fertig ist. Dann wird gebaut – mit Tests, die vor der Funktion entstehen, und einer Prüfung, die nicht von dem kommt, der gebaut hat. In Betrieb geht nichts ohne meine Freigabe. So arbeite ich in jedem Projekt, ob mit oder ohne KI.

Aufgaben

Was ich übernehme.

Sechs Dinge, die in jedem Projekt bei mir liegen – vom ersten Gespräch mit den Leuten, die den Ablauf täglich machen, bis zur Übergabe eines Systems, das ohne mich weiterläuft. Was davon im Einzelfall gebraucht wird, entscheidet das Vorhaben.

Verstehen, wie heute gearbeitet wird

Ich sitze mit den Leuten zusammen, die den Ablauf täglich machen – nicht nur mit denen, die ihn beauftragen. Daraus entsteht eine Beschreibung, die beide Seiten wiedererkennen.

Aufschreiben, was die Lösung können muss

Anforderungen, Datenmodell, Schnittstellen, Abnahmekriterien. So genau, dass sich hinterher prüfen lässt, ob es erfüllt ist – und so verständlich, dass der Fachbereich es lesen kann.

Entscheiden, wie gebaut wird

Welche Technik zu den vorhandenen Systemen passt, wo Daten liegen, wer was sehen darf, wie das Ganze betrieben wird. Jede Entscheidung wird begründet und aufgeschrieben.

Bauen, testen, anbinden

Anwendungen, Schnittstellen, Datenumzüge, Auswertungen – mit automatischen Tests, die vor der Funktion entstehen. Wo es sinnvoll ist, mit KI-Unterstützung; die Verantwortung bleibt bei mir.

Projekt und Beteiligte führen

Fachbereich, IT, Hersteller und Dienstleister an einen Tisch bringen, Entscheidungen herbeiführen und festhalten, Risiken benennen, Termine und Budget im Blick behalten.

Übergeben, so dass es ohne mich läuft

Dokumentation, Tests, Einweisung und ein Aufbau, den ein anderer Entwickler versteht. Am Ende hängt nichts mehr an mir – weder das Wissen noch der Betrieb.

Ablauf

So läuft ein Arbeitspaket.

Sechs Schritte, immer in dieser Reihenfolge – auch wenn es schnell gehen soll. Gerade dann: Der Schritt, den man unter Druck auslässt, ist meistens der, der später am teuersten wird.

01
Aufgabe schneiden
Aus der Spezifikation wird ein abgegrenztes Arbeitspaket mit klarem Ziel und klarer Grenze.
02
Auftrag schreiben
Das Paket wird so beschrieben, dass Umfang, Randbedingungen und Abnahmekriterien eindeutig sind.
03
Tests zuerst
Die automatischen Prüfungen entstehen, bevor die Funktion gebaut wird.
04
Umsetzen
Die technische Umsetzung erfolgt gegen den Auftrag – nicht gegen eine Vermutung.
05
Gegenprüfen
Ein getrennter Prüfschritt vergleicht das Ergebnis mit der Spezifikation. Alle Tests müssen grün sein.
06
Meine Freigabe
Erst wenn ich das Ergebnis fachlich und technisch geprüft habe, gilt das Arbeitspaket als fertig.

Grundsätze

Woran ich mich halte.

Fünf Regeln, die in jedem Projekt gelten, ob mit oder ohne KI. Im Vertrag stehen sie nicht – aber sie entscheiden darüber, ob Du am Ende etwas in der Hand hast, das Du verstehst und weiterbetreiben kannst.

Erst wird entschieden, dann wird gebaut

Vor der ersten Zeile Code steht, was die Software können muss und woran wir messen, dass sie fertig ist. Das klingt langsamer und ist es nicht: Was vorher geklärt ist, muss hinterher nicht dreimal umgebaut werden.

Die Prüfung kommt vor der Umsetzung

Zu jedem Arbeitspaket entstehen zuerst die automatischen Tests, die belegen, dass es funktioniert. Erst danach wird umgesetzt. Nichts wird zusammengeführt, solange ein Test fehlschlägt.

Niemand gibt die eigene Arbeit frei

Was gebaut wurde, wird in einem getrennten Schritt gegen die Spezifikation geprüft – egal, ob es von mir, einem Kollegen oder einem Modell stammt. Die letzte Entscheidung, fachlich wie wirtschaftlich, treffe ich.

Die Technik folgt dem Problem

Zuerst wird verstanden, woran es im Alltag hakt. Welche Technik das löst, entscheidet sich danach – und oft ist es nicht die neueste, sondern die, die zu den vorhandenen Systemen passt.

Was ich baue, kannst Du weiterbetreiben

Dokumentation, Tests und ein nachvollziehbarer Aufbau gehören dazu. Das System bleibt auch dann betreibbar und erweiterbar, wenn ich nicht mehr im Projekt bin.

Auf Wunsch

Mit KI, wenn Du es willst.

Ob Modelle bei der Umsetzung mitarbeiten, entscheidest Du – im Angebot steht es ausdrücklich drin. Wenn ja, ändert sich am Ablauf nichts, nur am Tempo: Ein Modell setzt beschriebene Aufträge um, ein zweites liest gegen, und die Freigabe bleibt bei mir. Ohne KI läuft derselbe Ablauf, mit denselben Prüfungen.

Paul GrasztatVerantwortung und Freigabe

Klärt die Anforderungen, beschreibt Abläufe, trifft die Architekturentscheidungen, schreibt die Arbeitsaufträge und legt fest, woran fertig gemessen wird.

Finale fachliche und technische Freigabe.

Prüfendes Modell„Gegenleser“ – vergleicht Ergebnisse mit der Spezifikation

Prüft jedes Arbeitspaket gegen Auftrag und Abnahmekriterien, ohne selbst am Code zu arbeiten. Findet Abweichungen, bevor ich sie sehe.

Keine Freigabe.

Umsetzendes Modell„Bauhelfer“ – setzt einen beschriebenen Auftrag um

Übernimmt die technische Umsetzung nach dem Arbeitsauftrag: Code, Tests, Dokumentation. Arbeitet nur an dem, was beschrieben ist, und legt das Ergebnis zur Prüfung vor.

Gibt das eigene Ergebnis nicht frei.

Was das für Dein Vorhaben bedeutet – an Zeit, an Kosten, an dem, was Du am Ende in der Hand hast? Beschreib es mir in drei Sätzen, ich sage Dir, wie ich es angehen würde.

Vorhaben einschätzen lassen