Future{hacks}: Süßes oder Software? Ein Plädoyer fürs Ausprobieren.

Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.

Ein Halloween-Spiel, ein bisschen KI und jede Menge Experimentierfreude. Warum Unternehmen öfter den Mut haben sollten, Ideen einfach mal auszuprobieren, bevor sie monatelang darüber diskutieren.

Was macht man, wenn man als UX/UI Designer ein paar Stunden Zeit, eine Halloween-Idee und Zugang zu Claude hat? Offenbar eine ziemlich aufwendige 3D-Halloween-Welt. Zumindest dann, wenn man Gregor heißt und bei uns arbeitet.

Eigentlich wollte unser Kollege nur ein bisschen mit Claude und Three.js experimentieren. Ein kleines Projekt, ein paar Ideen ausprobieren und schauen, was dabei herauskommt. Wer selbst schon einmal an etwas herumgebastelt hat, kennt das vermutlich. Man fängt mit einer Kleinigkeit an, entdeckt unterwegs neue Möglichkeiten und plötzlich ist der halbe Nachmittag vorbei.

Bei Gregor waren es rund sechs bis sieben Stunden, in denen ein ziemlich aufwendiges 3D-Halloween-Diorama entstanden ist. Besonders hängen geblieben ist mir aber sein Kommentar: „So viel Spaß hatte ich schon lang nicht mehr bei einem Projekt.“

Aus unserer Halloween-Spielerei ist schließlich auch das Kürbis-Slicer-Browserspiel ⁠Trick or Lean entstanden, an dem sich unser Developer Djordje ebenfalls kreativ austoben konnte. Wir konnten gar nicht so schnell schauen, da hat schon das halbe Büro Kürbisse durch die Gegend gesliced. Die einen haben fair gespielt. Die anderen haben ihre Hacking-Skills ausgepackt, um sich schon in der Testphase den Highscore zu holen (Berufsrisiko, wenn man in einer Softwarebude arbeitet). Keine Sorge, die Lücken waren noch vor dem Launch wieder dicht. Wer gerade fünf Minuten Zeit hat, darf es gerne selbst ausprobieren. Wobei ich für etwaige Produktivitätseinbußen keine Verantwortung übernehme.

Mich hat an der ganzen Geschichte vor allem beschäftigt, wie unkompliziert man mittlerweile solche Ideen umsetzen kann. Mit KI lassen sich heute auch Technologien ausprobieren, mit denen man bisher wenig Erfahrung hatte. Und plötzlich werden Dinge möglich, für die man früher deutlich mehr Zeit oder entsprechendes Budget gebraucht hätte.

Da stellt sich für mich schon die Frage, warum wir diese Möglichkeiten in Unternehmen eigentlich nicht viel öfter nutzen. Schließlich gibt es dort genügend Ideen, die seit Monaten irgendwo zwischen dem letzten Strategiemeeting und der nächsten Budgetplanung herumliegen.

Wir diskutieren gerne. Manchmal auch viel zu lange.

Ich bin seit über zehn Jahren im Tech-Vertrieb tätig und habe entsprechend viele Gespräche über Softwareprojekte geführt. Meistens beginnen diese recht ähnlich. Ein Unternehmen hat ein Problem, möchte einen Prozess verbessern oder überlegt, eine neue digitale Lösung einzuführen. Man spricht über Anforderungen, technische Möglichkeiten, Zeitpläne und natürlich über Geld.

Das ist auch richtig so. Schließlich kann nicht jeder Geschäftsführer für jede Idee ein paar Tausend Euro locker machen. Und wer schon einmal erlebt hat, wie aus einem vermeintlich kleinen Softwareprojekt ein ziemlich großes wird, weiß, warum man besser vorher ein paar Fragen stellt.

Trotzdem frage ich mich manchmal, ob wir es uns nicht unnötig kompliziert machen. Da werden Anforderungen über Wochen gesammelt, Konzepte ausgearbeitet und verschiedene Lösungsansätze diskutiert. Irgendwann hat man sich so lange mit einer möglichen Lösung beschäftigt, dass kaum noch jemand die ursprüngliche Idee hinterfragt. Ob die Mitarbeiter damit tatsächlich besser arbeiten können, bleibt dabei häufig offen.

Aus Kundengesprächen kenne ich das gut. In Softwareprojekten gibt es zwei Räume: den Problemraum, in dem geklärt wird, was eigentlich nicht funktioniert und warum, und den Lösungsraum, in dem es darum geht, wie man das behebt. Viele Unternehmen springen direkt in den Lösungsraum. Sie haben schon Screens, Features und Abläufe im Kopf, bevor die Probleme dahinter richtig erhoben sind. Und je länger man an dieser Vorstellung weiterdenkt, desto schwieriger wird der Weg zurück. Am Ende steht dann zu oft eine Software, die am eigentlichen Problem vorbeigeht. Ein kleiner Praxistest am Anfang würde viele dieser Fragen schneller klären als jede noch so gute Diskussion.

Nehmen wir einen mittelständischen Betrieb, der seinen Angebotsprozess vereinfachen möchte. Die Mitarbeiter übertragen Informationen aus Kundenanfragen händisch in verschiedene Systeme. Das kostet Zeit und sorgt regelmäßig für Fehler. Also wird über eine neue Software nachgedacht. Vielleicht braucht es eine umfangreiche Automatisierung, eine bessere Anbindung ans ERP oder überhaupt eine völlig neue Lösung.

Bevor man sich damit monatelang beschäftigt, könnte man allerdings auch eine einfache Eingabemaske entwickeln, ein paar realistische Testdaten hinterlegen und drei Mitarbeiter damit arbeiten lassen. Ohne vollständige Integration, ohne ausgefeilte Benutzerverwaltung und ohne große Designansprüche.

Möglicherweise stellt sich dabei heraus, dass die neue Oberfläche tatsächlich einiges erleichtert. Vielleicht merken die Mitarbeiter aber auch, dass ihr eigentliches Problem ganz woanders liegt. Beides wäre eine Erkenntnis, mit der man weiterarbeiten kann. Und im besten Fall hat man sich damit eine Menge Zeit, Diskussionen und möglicherweise auch Geld erspart.

KI macht das Ausprobieren wirtschaftlich interessanter

Natürlich ist Prototyping keine Erfindung der künstlichen Intelligenz. Entwickler haben schon immer kleine Anwendungen gebaut, um Ideen zu testen. Open Source, moderne Frameworks und fertige Komponenten haben das über die Jahre erheblich vereinfacht.

Mit generativer KI kommt allerdings eine weitere Möglichkeit dazu. Ein Entwickler kann sich heute bei der Erstellung von Oberflächen, einfachen Anwendungen oder Automatisierungen unterstützen lassen und dadurch schneller zu einem ersten Ergebnis kommen. Besonders spannend finde ich, was das Model Context Protocol (MCP) möglich macht. Damit lassen sich KI-Agenten mit anderen Tools und Systemen verbinden, und man kann sich plötzlich auch an Technologien wagen, die bisher nicht zum eigenen Fachgebiet gehört haben.

Eine erst am 9. Oktober veröffentlichte ⁠Studie von Moritz Mock und Barbara Russo hat verschiedene Formen der KI-gestützten Softwareentwicklung untersucht. Dabei zeigte sich, dass weitgehend automatisierte Entwicklungsabläufe schnell funktionierenden Code hervorbringen können. Allerdings erzeugten sie teilweise auch zusätzliche Komplexität und trafen technische Entscheidungen, die ursprünglich gar nicht verlangt waren. Die Untersuchung ist explorativ, zeigt aber recht anschaulich, welche Möglichkeiten und Grenzen diese neuen Werkzeuge mit sich bringen.

Für Unternehmen eröffnet sich dadurch eine interessante wirtschaftliche Überlegung. Wenn sich einfache Ideen mit überschaubarem Aufwand testen lassen, muss man nicht mehr jede mögliche Verbesserung von Anfang an wie ein großes IT-Projekt behandeln.

Gerade kleinere Unternehmen können sich schließlich nicht für jede Idee ein eigenes Entwicklungsteam leisten. Und selbst größere Betriebe müssen entscheiden, welche Projekte sie tatsächlich verfolgen wollen. Wenn aber bereits ein einfacher Prototyp zeigt, ob eine Lösung im Alltag sinnvoll wäre, kann man diese Entscheidung auf einer wesentlich besseren Grundlage treffen.

Dabei geht es auch um die Kosten, die entstehen, während man noch gar nichts entwickelt. Interne Abstimmungen, Workshops, Anforderungskataloge und wiederholte Entscheidungsrunden beschäftigen schließlich ebenfalls Mitarbeiter, deren Zeit nicht kostenlos ist. Wenn ein kleiner Prototyp dabei hilft, eine Idee frühzeitig zu bestätigen oder zu verwerfen, kann sich diese Investition durchaus rechnen.

Natürlich funktioniert das nicht bei jedem Vorhaben. Wer eine komplexe Systemlandschaft modernisieren oder sicherheitskritische Anwendungen entwickeln möchte, wird mit einem schnell zusammengebauten Prototyp allein nicht weit kommen. Für klar abgegrenzte Fragestellungen kann so ein erster Versuch allerdings erstaunlich aufschlussreich sein.

Man sollte allerdings wissen, wann Schluss ist

Eine gewisse Gefahr sehe ich bei der ganzen Experimentierfreude schon. Wenn die Umsetzung einfacher wird, steigt natürlich auch die Versuchung, jede halbwegs interessante Idee sofort auszuprobieren.

Und ich kenne unsere Entwickler:innen inzwischen gut genug, um zu wissen, dass aus einer kleinen Spielerei schnell ein ausgewachsenes Projekt werden kann. Gregors Halloween-Experiment ist dafür ein ziemlich sympathisches Beispiel.

Der Aufwand blieb überschaubar, und am Ende hat ein erfahrener Fullstack-Entwickler dafür gesorgt, dass das Ganze auch technisch sicher dasteht.

Bei internen Spaßprojekten, die das Marketing nur allzu gerne aufgreift, ist das völlig in Ordnung. Bei einem Kunden mit fixem Budget sieht die Sache anders aus. Nur weil die KI in wenigen Minuten eine zusätzliche Funktion programmiert, braucht sie deshalb noch lange niemand.

Dass man den Ergebnissen auch technisch nicht blind vertrauen sollte, zeigt eine weitere ⁠aktuelle Untersuchung im Fachjournal Science of Computer Programming. Über einen Zeitraum von 20 Monaten wurden verschiedene KI-Werkzeuge zur Erstellung von Softwaretests untersucht. Dabei schwankte die Qualität teilweise erheblich. Speziell angepasste Prompts und Konfigurationen erzielten bei den untersuchten Qualitätsmetriken um 20 bis 90 Prozent bessere Ergebnisse als generische Ansätze. Auch neuere Modellversionen waren nicht automatisch besser.

Für mich unterstreicht das, warum technisches Verständnis weiterhin wichtig bleibt. Einen ersten Prototyp kann man heute selbst ausprobieren. Sobald daraus allerdings eine Anwendung entstehen soll, auf die sich Mitarbeiter oder Kunden täglich verlassen müssen, kommen Themen wie Sicherheit, Datenschutz, Schnittstellen und langfristige Wartbarkeit ins Spiel.

Hier kann ein erfahrener Technologiepartner viel beitragen. Wobei ich von einem guten Partner auch erwarte, dass er mir sagt, was ich für den ersten Versuch noch gar nicht brauche. Wer für einen kleinen Prototyp bereits eine umfangreiche Enterprise-Architektur verkaufen möchte, hat die Aufgabenstellung vermutlich falsch verstanden.

Umgekehrt sollte man auch erkennen, wann ein Experiment seinen Zweck erfüllt hat und eine professionelle Umsetzung sinnvoll wird. Ein schnell entwickelter Prototyp kann eine hervorragende Grundlage für weitere Entscheidungen sein. Ihn anschließend ungeprüft in den produktiven Betrieb zu übernehmen, wäre allerdings keine besonders gute Idee.

Deshalb würde ich vor jedem Experiment drei Dinge klären: Welche konkrete Frage möchten wir beantworten? Wie viel Zeit und Geld dürfen wir dafür investieren? Und was machen wir anschließend mit dem Ergebnis?

Wenn sich nach dem vereinbarten Zeitrahmen keine brauchbare Erkenntnis abzeichnet, sollte man auch den Mut haben, das Experiment zu beenden. Sonst entwickeln wir künftig vielleicht sehr viel schneller Software, die am Ende niemand braucht. Und davon gibt es bereits genug.

Unser Future{hacks} Fazit

Vielleicht sollten wir uns wieder öfter etwas trauen.

Natürlich löst unser Halloween-Spiel kein großes Unternehmensproblem und vermutlich wird auch niemand dadurch seine Buchhaltung schneller erledigen. Es ist eine kleine Spielerei, die aus Experimentierfreude entstanden ist und bei der nebenbei neue Technologien ausprobiert wurden.

Genau diese Neugier würde ich mir allerdings auch öfter im Unternehmensalltag wünschen. Gerade jetzt, wo KI viele technische Einstiegshürden senkt und erste Versuche bei geeigneten Aufgaben mit vergleichsweise wenig Aufwand möglich macht.

Vielleicht gibt es auch bei euch eine Idee, über die seit Monaten diskutiert wird, ohne dass etwas passiert. Statt weiter im Lösungsraum zu planen, würde ich einen kleinen Zeit- und Budgetrahmen festlegen und die einfachste sinnvolle Version ausprobieren. Danach wisst ihr meistens mehr als nach jedem weiteren Meeting: ob es sich lohnt, die Idee mit einem erfahrenen Technologiepartner weiterzuentwickeln, oder ob ihr sie mit gutem Gewissen abhaken könnt.

Vielleicht sollten wir uns also weniger fragen, was ein Versuch kostet, und mehr, was es kostet, es gar nicht erst zu versuchen. Manchmal reicht ein kleiner Prototyp vollkommen aus, um zu sehen, ob mehr daraus werden kann.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.