Software wird oft als Kosten- und nicht als Erfolgsfaktor gesehen. Stefan Priebsch erklärt, wie Unternehmen mit fachlich getriebener Entwicklung und kollaborativem Modellieren bessere Lösungen schaffen. Der Mensch steht dabei stets im Mittelpunkt.
Für Priebsch ist klar: Bei IT handelt es sich nicht um ein technisches Thema, sondern um ein Menschenthema. Wer Software entwickelt, arbeitet mit Entwicklern, Fachexperten und Anwendern zusammen. Ein Lehrer aus seiner Schulzeit hat ihn dabei geprägt: „Das Beste an einem Nobelpreisträger ist, dass er einem Fünfjährigen sein Fachgebiet erklären kann“, sagte dieser. Erst ohne Fachjargon und Bullshit-Bingo lasse sich Wissen wirklich vermitteln.
Gemeinsames Verständnis durch Rollenspiele
Der Domain-Driven-Design-Ansatz geht auf Eric Evans und dessen Buch aus dem Jahr 2003 zurück. Ziel ist eine fachlich getriebene Entwicklung: Erst die Domäne verstehen, dann technische Lösungen finden. Im Workshop setzt Priebsch auf kollaboratives Modellieren – etwa in Form von Event-Storming, Domain-Storytelling und Rollenspielen. Die Grundregel lautet: „Diskutiere nie etwas Unsichtbares.“
Besonders Rollenspiele hält er für wirkungsvoll. Die Teilnehmer schlüpfen dabei in Rollen wie Kellner, Koch oder Gast und spielen Prozesse durch. Dabei entdecken sie Fragestellungen, die in abstrakten Diagrammen nie auftauchen würden. Artefakte wie Teller werden durch beschriftete Zettel dargestellt – am Ende entsteht eine erste Dokumentation aus Rollen und Entitäten.
Fokus auf die Kerndomäne und kürzere Feedback-Loops richten
Priebsch warnt davor, sich in Sonderfällen zu verlieren. Entwickler neigten dazu, technische Details zu diskutieren, die wirtschaftlich kaum Relevanz besitzen. Wichtiger sei der Hauptpfad: Wo entsteht Wertschöpfung, wo kommen zufriedene Kunden her? Unternehmen sollten ihre Kerndomäne identifizieren – generische Bereiche wie die Buchhaltung gehören seiner Meinung nach ausgelagert.
KI sieht Priebsch als nützliches Werkzeug – fehlt beispielsweise ein Fachexperte im Workshop, lasse sich ein Sprachmodell in dessen Rolle versetzen. Eine Modellierungssitzung dauere ein bis zwei Stunden. Wer danach weiß, was nicht funktioniert, spare sich wochenlange Entwicklungsarbeit an der falschen Lösung.