Von der Idee zur Wirkung: Annahmen sichtbar machen

Worum es geht

Beim Kita-Verbund Sonnenstrahl läuft es seit Jahren gleich: Beim Abholen bekommen die Eltern einen Zettel, auf dem steht, was ihr Kind gegessen hat, wie lange es geschlafen hat und wann es gewickelt wurde. Die Zettel gehen verloren, sind manchmal kaum lesbar, und um 17 Uhr, wenn zehn Eltern gleichzeitig vor der Tür stehen, schreiben die Betreuenden hastig nach. Die Geschäftsleitung hat deshalb eine Idee freigegeben: eine digitale Tagesinfo.

Die naheliegende Reaktion wäre: App planen, drei Monate entwickeln, ausrollen. Genau so scheitern aber viele ICT-Vorhaben. Nicht weil die Technik versagt, sondern weil die Lösung im Alltag niemand nutzt. Das merkt man erst, wenn das Budget verbraucht ist.

In diesem Modul lernst du den anderen Weg: Du prüfst eine Idee in kleinen, günstigen Schritten, bevor viel Geld fliesst. In dieser ersten Lektion lernst du, warum gute Ideen scheitern, wie der Kreislauf «Bauen, Messen, Lernen» funktioniert und wie du die Annahmen hinter einer Idee sichtbar machst und ordnest.

Warum gute Ideen trotzdem scheitern

Stell dir eine Schreinerei mit zwölf Mitarbeitenden vor. Der Chef lässt für CHF 25'000 eine App zur Zeiterfassung auf der Baustelle entwickeln. Sie ist schön, schnell und fehlerfrei. Drei Monate später schreiben trotzdem alle ihre Stunden wieder auf Papier. Warum? Mit Arbeitshandschuhen lässt sich das Handy kaum bedienen, auf vielen Baustellen gibt es keinen Empfang, und die Schreiner hatten nie ein Problem mit den Papierrapporten. Das Problem hatte nur das Büro.

Die Entwickler haben nichts falsch programmiert. Sie haben auf Annahmen gebaut, die nie jemand überprüft hat. Solche Annahmen lassen sich vier Risikoarten zuordnen:

Informatikerinnen und Informatiker konzentrieren sich instinktiv auf die Machbarkeit. Die gefährlichsten Annahmen liegen aber meist bei Wunsch und Bedienbarkeit, also beim Verhalten von Menschen.

Der Kreislauf Bauen, Messen, Lernen

Statt alles auf einmal zu planen und zu bauen, arbeitest du in Schleifen. Der Ansatz stammt aus der Lean-Startup-Bewegung (Eric Ries) und heisst Build-Measure-Learn:

1. Bauen: Du baust nur so viel, wie nötig ist, um eine bestimmte Frage zu beantworten. Das kann eine Papierskizze sein, ein klickbarer Prototyp oder eine erste nutzbare Version.
2. Messen: Echte Nutzerinnen und Nutzer verwenden das Gebaute, und du beobachtest oder misst, was passiert.
3. Lernen: Du vergleichst das Ergebnis mit deiner Erwartung und entscheidest, wie es weitergeht.

Der Trick dabei: Geplant wird der Kreislauf rückwärts. Zuerst fragst du: Was wollen wir lernen? Dann: Was müssen wir dafür messen? Und erst zuletzt: Was ist das Kleinste, das wir dafür bauen müssen? Wer mit dem Bauen beginnt, baut fast immer zu viel.

Eine Analogie: Wer ein Restaurant eröffnen will, mietet nicht sofort ein Lokal für zehn Jahre. Klüger ist ein Foodtruck an ein paar Wochenenden. Dort zeigt sich schnell, welche Gerichte laufen und ob überhaupt jemand kommt.

So ist dieser Kurs aufgebaut:

Annahmen sammeln und ordnen

Annahme oder Fakt?

Ein Fakt ist belegt: «Die Eltern erhalten heute beim Abholen einen Zettel.» Eine Annahme ist noch nicht belegt: «Die Eltern würden eine Mail täglich lesen.» Das klingt plausibel, aber niemand hat es geprüft. Auch eine Aussage der Chefin ist kein Fakt, solange sie auf ihrem Gefühl beruht. Die wichtigste Prüffrage lautet: «Woher wissen wir das?»

So findest du Annahmen

Geh den Ablauf aus Sicht jeder beteiligten Person durch (Betreuende, Eltern, Kitaleitungen, Geschäftsleitung, IT) und frag bei jedem Schritt: Was muss stimmen, damit das klappt? Schreib jede Antwort als Satz «Wir glauben, dass …». Zehn bis zwanzig Annahmen sind normal. Wer nur drei findet, hat zu wenig gesucht.

Die Assumption Map

Danach ordnest du die Annahmen auf einer Assumption Map (Annahmen-Landkarte) mit zwei Achsen:

• Wichtigkeit: Fällt die Idee in sich zusammen, wenn die Annahme falsch ist?
• Unsicherheit: Wie wenig wissen wir? Gibt es Belege, Erfahrungen, Daten?

Daraus entstehen vier Felder:

In Miro oder auf einem Whiteboard klebst du die Annahmen als Post-its in dieses Raster. Für eine nachvollziehbare Reihenfolge kannst du beide Achsen zusätzlich mit 1 bis 5 bewerten und als Faustregel Risiko = Wichtigkeit × Unsicherheit rechnen. Das ist keine exakte Wissenschaft, sondern ein Hilfsmittel für die Diskussion im Team.

Schritt für Schritt: Alessias Assumption Map

Schritt 1: Die Idee in einem Satz. Alessia schreibt: «Betreuende erfassen Essen, Schlaf und Wickeln auf einem Tablet, und die Eltern erhalten am Nachmittag automatisch eine Zusammenfassung per Mail.»

Schritt 2: Den Ablauf skizzieren. Betreuende erfassen im Tagesverlauf, das System sammelt die Einträge, am Nachmittag geht eine Mail an die Eltern, die Eltern lesen sie vor oder nach dem Abholen.

Schritt 3: Annahmen sammeln. Mit zwei Betreuerinnen und der Kitaleiterin von Wettingen sammelt Alessia in 30 Minuten zwölf Annahmen. Acht davon siehst du hier:

Schritt 4: Gemeinsam bewerten. Alessia bewertet nicht allein, denn die Betreuerinnen wissen besser als sie, wie hektisch der Alltag ist. Ein Beispiel aus der Diskussion: Annahme 1 ist wichtig, aber die Kitaleiterin erzählt, dass Eltern beim Abholen fast immer nach Essen und Schlaf fragen. Es gibt also Belege, deshalb ist die Unsicherheit nur 2.

Schritt 5: Sortieren. Nach Risiko absteigend: Nr. 2 (25), Nr. 4 (16), Nr. 7 (15), dann Nr. 8 und Nr. 6 mit je 12. Bei Gleichstand nimmt Alessia zuerst die Annahme mit der grösseren Unsicherheit (Nr. 8), denn dort ist der Lerngewinn am grössten.

Schritt 6: Plausibilität prüfen. Passt das Ergebnis zum Bauchgefühl des Teams? Die Kitaleiterin nickt: «Wenn meine Leute keine Zeit haben, ist der Rest egal.» Nr. 7 (Datenschutz) ist zwar riskant, lässt sich aber ohne Nutzertest klären: Alessia klärt mit der Geschäftsleitung und der für den Datenschutz verantwortlichen Person, was erlaubt ist. Nicht jede riskante Annahme braucht ein Experiment.

Schritt 7: Ergebnis festhalten. Diese zwei Annahmen wird Alessia mit Nutzerinnen und Nutzern testen:

• Nr. 2: Betreuende haben im Alltag Zeit für Einträge.
• Nr. 4: Eltern lesen die Tagesinfo am selben Tag.

In der nächsten Lektion macht sie daraus testbare Hypothesen mit klaren Erfolgskriterien. Die Sortierung aus Schritt 5 lässt sich übrigens leicht automatisieren. Im folgenden Code-Labor schreibst du die Funktion dafür selbst:

Typische Fehler

• Nur technische Annahmen sammeln. «Die Schnittstelle ist schnell genug» ist bequem zu prüfen, aber selten das grösste Risiko. Korrektur: Zu jeder der vier Risikoarten mindestens zwei Annahmen notieren.
• Fakten und Annahmen vermischen. «Alle Eltern haben eine Mailadresse» klingt nach Tatsache. Ob die Adressen aktuell sind und gelesen werden, ist eine Annahme. Korrektur: Bei jeder Aussage fragen «Woher wissen wir das?».
• Die Map allein am Schreibtisch erstellen. Korrektur: Mindestens zwei Personen aus der Zielgruppe einbeziehen, denn sie kennen den Alltag besser.
• Wichtigkeit und Unsicherheit verwechseln. Eine sehr wichtige, aber gut belegte Annahme ist nicht zuerst dran. Korrektur: Beide Achsen getrennt bewerten.
• Die Map nur einmal erstellen. Korrektur: Nach jedem Experiment aktualisieren. Bestätigte Annahmen wandern in die Spalte «sicher».

Zusammenfassung

• Viele ICT-Vorhaben scheitern nicht an der Technik, sondern an ungeprüften Annahmen über das Verhalten von Menschen.
• Annahmen lassen sich vier Risikoarten zuordnen: Wunsch und Nutzen, Bedienbarkeit, Machbarkeit, Wirtschaftlichkeit.
• Im Kreislauf Bauen, Messen, Lernen prüfst du eine Idee in kleinen Schritten. Geplant wird er rückwärts: Was wollen wir lernen, was messen, was bauen?
• Die Assumption Map ordnet Annahmen nach Wichtigkeit und Unsicherheit. Wichtig und unsicher wird zuerst getestet.
• Als Hilfsmittel kannst du Risiko = Wichtigkeit × Unsicherheit berechnen. Die Diskussion mit den Betroffenen ist aber wichtiger als die Zahl.
• Nicht jede riskante Annahme braucht einen Nutzertest. Rechtliche oder technische Fragen klärst du oft schneller durch eine Abklärung.