Warum wir vor jedem Projekt zu viele Fragen stellen

Irgendwann in den ersten Gesprächen kommt der Moment, in dem unser Gegenüber leise die Geduld verliert. Wir haben nach Abläufen gefragt, nach Zuständigkeiten, nach Ausnahmen. Wir haben Fragen gestellt, deren Sinn sich nicht sofort erschließt. Und dann kommt sie, die Frage hinter allen Fragen: Wann wird gebaut?

Die Irritation ist verständlich. Wer ein Projekt beauftragt, will Bewegung sehen. Trotzdem bleiben wir dabei. Denn was wie ein Umweg aussieht, ist der schnellste Weg, den wir kennen.

Die teuersten Fehler passieren vor der ersten Zeile Code

Software scheitert selten am Code. Sie scheitert an Abläufen, die falsch verstanden wurden. Ein Missverständnis, das sich im Gespräch beiläufig ausräumen ließe, steckt später im Fundament des Programms. Dann hilft kein Nachbessern an der Oberfläche mehr. Jede Frage vorher ist billiger als jede Korrektur danach.

Deshalb fragen wir. Ausführlich, hartnäckig, manchmal zum dritten Mal dasselbe in anderen Worten.

Was wir wirklich wissen wollen

Vier Fragen kehren in fast jedem Projekt wieder.

Wie läuft es heute wirklich? Nicht, wie es laut Handbuch laufen sollte. Der Unterschied zwischen beidem ist oft der Kern des Problems.

Wo wird dieselbe Information mehrfach angefasst? Eine Bestellung, die mehrfach abgetippt wird, ist kein Ärgernis, sondern ein Befund.

Was ist der Sonderfall, der einmal im Monat alles aufhält? Der Normalfall ist schnell beschrieben. Projekte entscheiden sich am Ausnahmefall.

Und die wichtigste: Was soll bewusst so bleiben, wie es ist? Nicht alles, was alt ist, ist schlecht. Manches ist über Jahre gereift und funktioniert genau deshalb.

Ein Ablauf, der niemanden stört, ist kein Projekt wert.

Wir automatisieren nicht um der Automatisierung willen. Wenn ein Prozess trägt, lassen wir ihn in Ruhe.

Am Ende steht eine Arbeitsliste, keine Wunschliste

Das Ergebnis der vielen Fragen ist unspektakulär und genau deshalb wertvoll: eine Arbeitsliste aus dem echten Betrieb. Sie enthält, was tatsächlich stört, was tatsächlich Zeit kostet, was tatsächlich Fehler produziert. Ein Lastenheft sammelt Wünsche. Eine Arbeitsliste benennt Arbeit.

Mit dieser Liste beginnt das Bauen. Und es beginnt an der richtigen Stelle.

Dahinter steht eine einfache Haltung: Unsere Software steht nicht im Schaufenster, sie steht im Betrieb. Sie muss laufen, wenn es darauf ankommt, Jahr für Jahr. Dafür müssen wir Ihren Betrieb verstehen, bevor wir ihn in Software gießen. Also stellen wir Fragen. Zu viele, heißt es am Anfang. Am Ende heißt es: die richtigen.