Drei Wochen ehrliche Diagnose ersparen drei Monate Bauen am falschen Ziel. Hier steht, wie wir verstehen, was bei dir wirklich los ist - bevor die erste Zeile Code geschrieben wird.
Die meisten Software-Projekte scheitern nicht beim Bauen. Sie scheitern viel früher - bei der Frage, was eigentlich gebaut werden soll.
Wer mit dem falschen Verständnis vom Problem startet, baut die falsche Lösung - egal wie gut die handwerkliche Umsetzung ist. Genau deshalb beginnt unsere Arbeit nicht mit einem Lastenheft, nicht mit Mockups, nicht mit Sprint-Plänen. Sie beginnt mit Fragen, die du vermutlich noch nie so gestellt bekommen hast - und mit Antworten, die du oft selbst überraschen werden.
Wir fragen
Vision, Schmerzpunkte, Alltag, Grenzen - in der richtigen Reihenfolge.
Du zeigst
Screenshots, Listen, Beispiele - das, was Worte nicht zeigen.
Wir entwerfen
Drei abgestufte Wege mit Preis, Umfang, Zeit. Du entscheidest.
Wenn ein Kunde mit der Bitte kommt "Wir wollen ein CRM", ist das keine Problembeschreibung. Es ist eine Lösungs-Hypothese. Die echte Frage liegt darunter: Wo gehen Kundenkontakte heute verloren? Welche Nachfrage wurde nie beantwortet? Wer wusste was nicht? Wir nehmen Wünsche ernst, aber wir nehmen sie nicht wörtlich.
Lastenhefte sind nicht falsch - sie sind nur das Ergebnis der falschen ersten Frage. Wer "Was soll es können?" fragt, bekommt Funktionen aufgelistet. Wer "Was läuft heute schief?" fragt, bekommt Probleme beschrieben. Aus Funktionen bauen wir Software, die niemand braucht. Aus Problemen bauen wir Software, die jemand vermisst, wenn sie weg ist. Das ist nicht das gleiche.
Der klassische Aufsatz dazu ist "Marketing Myopia" von Theodore Levitt (Harvard Business Review, 1960). Levitts These: Eisenbahn-Gesellschaften sind nicht untergegangen, weil der Bedarf an Transport gesunken wäre - sondern weil sie glaubten, im Eisenbahn-Geschäft zu sein statt im Transport-Geschäft. Sie haben das Produkt mit dem Problem verwechselt.
Clayton Christensen hat das in "Jobs to be Done" zugespitzt: Niemand kauft einen Bohrer, weil er einen Bohrer will - er will ein Loch. Software-Projekte verirren sich aus genau dem gleichen Grund: Der Kunde beschreibt den Bohrer, den er sich vorstellt. Die Aufgabe des Beraters ist, das Loch zu finden, das er eigentlich braucht.
Du kopierst seit Jahren Kundendaten aus dem Postfach in eine Excel-Liste, von dort ins Buchhaltungsprogramm, von dort in dein E-Mail-Tool zurück. Im Interview erwähnst du das nicht - es ist normal. Routine wird unsichtbar, je länger sie dauert. Sie ist da wie die Tapete im Wohnzimmer: man merkt sie erst, wenn jemand fragt.
Genau deshalb stellen wir nicht nur Fragen, sondern auch Gegenfragen. Wenn du sagst, "ein Auftrag dauert bei uns etwa eine Stunde", fragen wir nach, was in dieser Stunde konkret passiert. Wenn du sagst, "wir haben ein Tool dafür", fragen wir, wie oft das Tool wirklich genutzt wird und wer was außerhalb davon nochmal notiert. So tauchen die Schritte auf, die in keinem Handbuch stehen - aber jeden Tag Zeit kosten.
Der psychologische Befund ist alt und gut gesichert. Nisbett & Wilson haben 1977 in einem viel zitierten Aufsatz ("Telling More Than We Can Know", Psychological Review) gezeigt: Menschen wissen oft nicht, warum sie etwas tun - und wenn sie es erklären, erfinden sie plausible Gründe, die mit dem tatsächlichen Verhalten wenig zu tun haben. Das gilt für Konsumentscheidungen genauso wie für Arbeitsroutinen.
Der Soziologe Donald Schön beschrieb dasselbe Phänomen als "tacit knowledge": Wissen, das wir im Tun haben, aber im Reden nicht abrufen können. Erfahrene Praktiker können oft erklären, was sie tun, aber nicht, warum es funktioniert. Wer Software für diese Praxis baut, muss das implizite Wissen mit aufdecken - nicht nur das explizite.
Features-Wünsche sind Spekulationen. Status quo ist Wirklichkeit. Wer zuerst nach Funktionen fragt, lädt den Kunden ein, sich Lösungen auszudenken, die er gar nicht beurteilen kann. Wer zuerst nach dem Alltag fragt, kommt mit konkretem Material zurück - echten Engpässen, echten Entscheidungen, echten Fehlern. Aus diesem Material lassen sich Lösungen ableiten. Aus erfundenen Features nicht.
Unsere besten Fragen klingen deshalb fast banal: Beschreib mir einen typischen Dienstag. Wer schickt dir morgens den ersten Auftrag, in welcher Form? Was tust du als nächstes? Wann das letzte Mal etwas verloren gegangen ist - wie kam das? Welche Aktion tippst du in einer Woche mehr als zehn Mal? Diese Fragen klingen nach kleinen Beobachtungen. Aber aus zwanzig davon entsteht ein präzises Bild dessen, was wirklich gebaut werden muss.
Im Toyota-Produktionssystem heißt das "Gemba" - der "wirkliche Ort". Taiichi Ohno, einer der Architekten des Systems, machte daraus eine Regel: Geh hin, wo die Arbeit passiert. Schau zu. Frag dort, nicht im Konferenzraum. Wer den realen Arbeitsplatz nicht kennt, kann ihn auch nicht verbessern - unabhängig davon, wie gut die Theorie ist.
Akademisch sauber aufgearbeitet wurde das von Wil van der Aalst (TU Eindhoven) unter dem Begriff Process Mining: die Wissenschaft, gelebte Prozesse aus realen Daten zu rekonstruieren - nicht die im Handbuch beschriebenen. Studien zeigen regelmäßig Abweichungen von 30 bis 60 Prozent zwischen der erwarteten und der tatsächlichen Prozesslandschaft. Wer auf die erwartete Variante baut, baut für eine Welt, die nicht existiert.
Was Menschen über ihre Arbeit sagen, weicht fast immer von dem ab, was sie tatsächlich tun. Nicht aus Unehrlichkeit - sondern weil Erinnerung glättet, was im Alltag holprig ist. Deshalb bitten wir dich nicht nur, Fragen zu beantworten. Wir bitten dich, Belege hochzuladen: einen Screenshot deines wichtigsten Tools. Ein Foto von dem Zettel auf deinem Schreibtisch. Eine Excel-Datei, in die ihr wirklich tippt. Ein Beispiel eines Angebots, das du letzte Woche geschrieben hast.
Diese Artefakte lügen nicht. Sie zeigen das Datum, das niemand ausspricht. Die Spalte, die im Interview nicht erwähnt wurde. Die handschriftliche Notiz am Rand, die verrät, wo der digitale Prozess endet und das echte Leben anfängt. Eine Stunde Material-Sammlung ist oft mehr wert als drei Stunden Telefonat - weil wir damit das sehen, was du gar nicht mehr siehst.
In der Ökonomie ist die Unterscheidung als "Stated vs. Revealed Preferences" bekannt - eingeführt von Paul Samuelson 1938 (Economica). Was Menschen sagen, sie würden bevorzugen, und was sie tatsächlich tun, sind zwei verschiedene Datensätze. Die Marktforschung der letzten 80 Jahre hat den Befund unzählige Male bestätigt: Verhalten ist verlässlicher als Selbstauskunft.
In der UX-Forschung ist die Maxime daraus geworden: "Watch what they do, not what they say." Jakob Nielsen, einer der Pioniere des Feldes, formulierte es so: "Self-reported claims are unreliable, as are user speculations about future behavior." Unsere Konsequenz: Wir verlangen nicht nur Worte. Wir verlangen die Dinge, mit denen du heute arbeitest.
Wenn wir zu früh nach dem Budget fragen, schneidet die Antwort den Lösungsraum vor dem ersten Gedanken ab. Wer sagt "Wir haben 8.000 Euro", baut die nächsten zwei Stunden Pläne für 8.000 Euro - egal ob das Problem in Wirklichkeit größer oder kleiner ist. Wir drehen die Reihenfolge um: erst die Vision, dann der Schmerz, dann die Lösung - und ganz zum Schluss die Frage, was du dafür einsetzen willst.
Das ist nicht weltfremd. Wir wissen, dass Budgets endlich sind. Aber das Budget bestimmt die Reihenfolge der Umsetzung, nicht den Wert des Problems. Wer mit Budget anfängt, verliert die Hierarchie. Wer mit Wert anfängt und am Ende das Budget einordnet, bekommt eine ehrliche Liste: das hier ist die Wirkung, hier ist der Preis, und so passen sie zueinander.
Tversky & Kahneman haben 1974 in ihrem Science-Aufsatz "Judgment under Uncertainty" den Anchoring-Effekt beschrieben: Die erste Zahl, die in einer Diskussion fällt, verzerrt alle weiteren Bewertungen - auch wenn sie offensichtlich irrelevant ist. In Verhandlungs- und Vertriebs-Settings wurde der Effekt hundertfach repliziert. Wer zuerst über Geld redet, hat die Diskussion über Wert bereits verloren.
Im Vertrieb ist die korrigierte Reihenfolge bei Neil Rackham im Klassiker "SPIN Selling" (1988) beschrieben: erst Situation, dann Problem, dann Implikation - was kostet dich das Problem heute? - und erst zum Schluss die Lösung mit Preis. Studien zu B2B-Verkaufsabschlüssen zeigen: Diese Reihenfolge führt zu signifikant höheren Auftragswerten und gleichzeitig zu zufriedeneren Kunden. Wir nutzen die Logik nicht im Verkauf - aber in der Diagnose. Das Ziel ist das gleiche: zuerst verstehen, dann einordnen.
Wir geben dir keine eine Empfehlung. Wir geben dir drei. Klein - das, was den schmerzhaftesten Punkt zuerst löst, in Wochen statt Monaten umsetzbar. Mittel - der Kern dessen, was wir in einem Quartal stemmen können, mit klarer Wirkung im Alltag. Groß - was die Vision aus dem ersten Gespräch wirklich erreicht, mit allem, was dazugehört.
Jeder Weg kommt mit Scope, Preis und Zeitrahmen. Wir markieren, welchen wir aus unserer Erfahrung empfehlen würden - aber die Wahl liegt bei dir. Das ist keine Bequemlichkeit. Es ist die ehrlichste Form von Beratung: Wir können dir sagen, was wir an deiner Stelle täten. Aber wir sind nicht an deiner Stelle - du kennst Druck, Politik, Stimmung in deinem Haus besser als wir. Drei Wege geben dir die Hebel, die richtige Entscheidung selbst zu treffen.
Die psychologische Grundlage ist der Asymmetric Dominance Effect (Huber, Payne, Puto, 1982): Wenn Menschen vor zwei Optionen stehen, fällt die Entscheidung schwer. Sobald eine dritte Option dazukommt, die das Feld strukturiert, wählen sie deutlich entschlossener - und sind zufriedener mit der Wahl. Drei Optionen sind die kognitiv günstigste Anzahl: eine ist diktatorisch, zwei erzwingen Schwarz-Weiß-Denken, vier überfordern.
Verwandt ist die Choice-Architecture-Forschung von Cass Sunstein und Richard Thaler ("Nudge", 2008): Wer Entscheidungen strukturiert vorlegt, hilft, ohne zu bevormunden. Drei abgestufte Wege sind genau das. Sie nehmen dir die Wahl nicht ab. Sie machen sie machbar.
Sorgfalt im Verstehen, Mut zum Schnitt. Wer das eine ohne das andere macht, kommt nicht weit.
Diese sechs Schritte sind nicht Berater-Choreographie. Sie sind das einzige Vorgehen, das wir kennen, das vor dem Bau ehrlich klärt, ob überhaupt das Richtige gebaut werden soll. Drei Wochen Diagnose sind nicht der Beweis von Gründlichkeit - sie sind der Preis dafür, die nächsten drei Monate nicht zu verschwenden. Und am Ende stehen nicht Folien, nicht Workshops, nicht Zertifikate - sondern drei konkrete Wege, zwischen denen du entscheiden kannst. Das ist alles, was du an dieser Stelle wirklich brauchst.
Mehr darüber, wie wir nach der Problemanalyse weiter vorgehen, steht unter Erst die Werkzeuge, dann die KI. Welche Hürden bei der Einführung in Betrieben am häufigsten auftreten, findest du unter Die größten Hürden liegen selten in der Technik. Eine ehrliche Einordnung der KI-Risiken steht unter Was KI nicht kann, auch wenn es so wirkt. Den Qualitätsmaßstab für gute Software haben wir unter Wann ist Software wirklich gut zusammengefasst.