No-Code- und Low-Code-Tools machen es leicht, einfach loszubauen. Genau so entstehen im Fachbereich oft kleine Apps oder Automationen – schnell, nützlich, ohne grosses Projekt. Der Frust beginnt, wenn daraus stillschweigend etwas Dauerhaftes wird und die IT-Entwicklung plötzlich Fragen stellt, die wie Bremsen wirken. Dieser Beitrag zeigt, wie wir als Citizen Developer unsere Lösungen so bauen, dass sie später leichter an die „richtige IT“ anschliessen können.
Warum die IT-Entwicklung anders fragt als wir
Wenn wir eine Lösung bauen, denken wir zuerst an den Nutzen: „Spart das Zeit?“, „Wird der Prozess einfacher?“, „Kommen die Kolleginnen und Kollegen damit klar?“ Das ist richtig – dafür sind wir nah genug am Problem. Und genau diese Nähe ist der Grund, warum Citizen Development so viel Tempo bringt.
Die IT-Entwicklung hat aber eine zusätzliche Brille auf. Sie fragt nicht, ob es heute hilft, sondern ob es auch morgen noch hält. Diese Fragen wirken manchmal kleinlich, sind aber meistens ein Zeichen von Verantwortung. Drei Gedanken stecken fast immer dahinter: Was passiert am Montagmorgen, wenn es nicht läuft? Wer sieht welche Daten – und was wäre der Schaden, wenn etwas nach aussen gelangt? Und wie ändern wir das in drei Monaten, ohne dass alles auseinanderfällt?
Im CAS Software Development with AI and NoCode ist uns das besonders aufgefallen: Sobald eine Lösung nicht nur „nice to have“ ist, sondern im Alltag gebraucht wird, kippt die Wahrnehmung. Wir nennen es vielleicht immer noch „das kleine Tool“, aber die Umgebung behandelt es wie ein System. Und Systeme haben Eigenheiten: Sie fallen aus, sie werden erweitert, sie werden zum Standard – und plötzlich sind Menschen abhängig davon.
Unser Hebel als Citizen Developer: Anschlussfähigkeit nebenbei mitdenken
Wir müssen nicht plötzlich wie professionelle Entwicklerinnen und Entwickler arbeiten. Aber wir können unsere Ergebnisse so gestalten, dass die Übergabe oder gemeinsame Weiterentwicklung später nicht bei null beginnt.
Der erste Schritt ist, dass wir unser Versprechen explizit machen. Ist das gerade Ideensuche, um schnell zu lernen? Dann sagen wir das so – und begrenzen bewusst Nutzerkreis, Daten und Erwartungen. Ist es ein Machbarkeitsnachweis, der zeigen soll „das geht grundsätzlich“? Dann halten wir fest, welche Annahmen gelten. Und sobald wir merken „das könnte bleiben“, behandeln wir es als wachsendes Produkt – nicht perfekt, aber bewusst anschlussfähig.
Ein einfaches Beispiel: Eine kleine Automatisierung, die eine Liste aktualisiert, ist im Ideensuche-Modus harmlos. Sobald sie aber Freigaben steuert oder Termine auslöst, entstehen Erwartungen. Dann wird plötzlich wichtig, ob sie bei einem Fehler still stehen bleibt oder jemanden benachrichtigt. Genau hier können wir viel Frust verhindern, wenn wir früh entscheiden, in welchem Modus wir sind.
Anschlussfähig wird es für die IT vor allem dann, wenn drei Dinge nicht erraten werden müssen. Erstens: Zuständigkeit. Wer ist fachlich verantwortlich, wenn Fragen kommen oder Prioritäten geändert werden? Zweitens: Daten und Zugriffe. Welche Art von Daten verwenden wir, und wer darf sie sehen oder bearbeiten? Drittens: Betrieb im Kleinen. Was ist das erwartete Verhalten bei Fehlern – und wer wird informiert, wenn etwas schiefläuft? Das sind keine grossen Konzepte, sondern eine Art „Beipackzettel“, der Missverständnisse verhindert.
Ein weiterer, oft unterschätzter Punkt ist Nachvollziehbarkeit von Änderungen. Dafür brauchen wir nicht zwingend ein komplexes Werkzeug. Es reicht häufig, wenn wir Änderungen bewusst machen: „Was haben wir angepasst – und warum?“ Wenn die IT später übernehmen oder mitarbeiten soll, ist diese Spur Gold wert.
Und zuletzt: Wir warten nicht bis zur grossen Übergabe. Sobald absehbar ist, dass eine Lösung wachsen könnte, suchen wir früh ein kurzes Gespräch mit der IT-Entwicklung. Nicht als Abnahme, sondern als Übersetzung: Wir erklären Nutzen und Prozess, die IT spiegelt Betrieb und Risiken. Zehn Minuten früher investiert sparen oft Wochen später.
Zum Mitnehmen:
Zum Lernen darf es easy sein. Für den Alltag muss es stabil sein. Und wenn wir es dauerhaft nutzen wollen, muss es zu unserer IT passen.
