Entwickler oder Hellseher? Warum du Anforderungen nicht erraten solltest
„Das hatten wir doch alles besprochen!" Ein Satz, den ich im Projekt immer wieder höre – und innerlich seufze.
Denn ja, wir haben über die Anforderung gesprochen. Aber wir haben sie nicht wirklich verstanden.
Die Illusion der Klarheit
Im Meeting klang alles logisch: Ein Business Analyst beschreibt, was gebraucht wird, die Entwickler nicken, die Anforderungen werden als „spezifiziert" markiert. Und dann beginnt die Umsetzung – und plötzlich tauchen Fragen auf, die niemand gestellt hat.
Was passiert, wenn der Kunde zwei IBANs hat? Was, wenn das Konto zu dem Zeitpunkt schon geschlossen ist? Wie soll der Prozess mit fehlerhaften Daten umgehen? Und was bedeutet eigentlich „fehlerhaft"?
Die Fragen wirken banal. Aber sie entlarven eine harte Realität: Die Anforderung war nicht durchdacht – nur aufgeschrieben.
Wenn Entwicklung zur Anforderungsanalyse wird
Als Entwickler stolperst du mitten im Code über offene Punkte, die nie geklärt wurden. Und dann beginnt das große Nachfragen – manchmal zum dritten Mal, weil der letzte Stand nirgends dokumentiert wurde oder sich zwischenzeitlich wieder geändert hat.
In solchen Momenten wird die eigentliche Arbeit unterbrochen. Statt sauber zu entwickeln, führst du Recherchegespräche. Du wirst zum Dolmetscher zwischen Logik und Realität – oft ohne klare Ansprechpartner.
Mein Learning
Ein Satz, den ich mir immer wieder vor Augen führe:
Nur weil eine Anforderung besprochen wurde, ist sie noch lange nicht verstanden.
Gerade in komplexen Systemen reicht „ungefähr richtig" nicht. Man muss die Ausnahmefälle denken, die Systemgrenzen verstehen und den Mut haben, auch nach der dritten Rückfrage nochmal zu sagen: Das reicht nicht.
Beraten heißt auch: nachbohren dürfen
Als beratender Entwickler bist du nicht nur für sauberen Code zuständig. Du bist auch dafür da, Unklarheiten sichtbar zu machen. Und zwar so früh wie möglich.
Auch wenn das heißt, dass du die Rolle des „Unbequemen" einnimmst – der, der nochmal fragt, der nochmal bremst, der nicht einfach blind umsetzt.
Denn das ist echte Qualität: Nicht was du coden kannst, sondern was du vorher hinterfragt hast.