Wie gehst du vor, wenn die Geschäftsanforderungen unklar oder mehrdeutig sind, bevor du mit dem Programmieren anfängst?

Question

Accepted Answer

Nach einer Vermutung zu programmieren ist die teuerste Art zu entdecken, dass du die Anforderung missverstanden hast. Wenn eine Anfrage vage ist, besteht meine Aufgabe darin, Mehrdeutigkeit in ein gemeinsames, schriftlich festgehaltenes Verständnis umzuwandeln, *bevor* ich Code schreibe, und das dann kostengünstig zu validieren. Mehrdeutigkeit ist kein Grund, Bedenken zu äußern; sie ist ein normaler Teil der Arbeit, um Klarheit zu schaffen.

## Wie ich Klarheit schaffe

- **Frag nach dem Warum, nicht nur dem Was.** Welches Ergebnis versuchen wir zu erreichen? Der Grund hinter einer Anfrage offenbart oft eine einfachere oder andere Lösung als die genannte.
- **Identifiziere den echten Nutzer und die Erfolgsmessung.** Wer spürt das Problem, und wie wissen wir, dass es gelöst ist? "Fertig" braucht eine Definition, auf die du zeigen kannst.
- **Paraphrasiere dein Verständnis zurück.** Es in deinen eigenen Worten auszudrücken bringt Unstimmigkeiten sofort ans Licht, viel billiger als sie in einer Demo zu entdecken.
- **Nutze Beispiele, Mockups und Akzeptanzkriterien.** Konkrete Artefakte zwingen vage Ideen, sich festzulegen. "Gegeben X, wenn Y, dann Z" verwandelt Meinungen in überprüfbare Aussagen.
- **Bringe Randfälle frühzeitig auf den Tisch.** Was ist mit leeren Zuständen, Fehlern, großen Eingabemengen, Berechtigungen? Jetzt zu fragen ist kostengünstig; in der Produktion zu entdecken ist es nicht.
- **Dokumentiere es und bestätige es.** Eine kurze schriftliche Zusammenfassung, der die Stakeholder zustimmen, wird zur gemeinsamen Quelle der Wahrheit und zum Maßstab deiner Umsetzung.

## Dann validiere im Kleinen

- Baue das **kleinste Slice**, das das Verständnis beweist – einen dünnen End-to-End-Pfad oder einen schnellen Prototyp – und hole Feedback ein, bevor du in die vollständige Umsetzung investierst. Echte Software vor einem Stakeholder klärt mehr als jedes Dokument.

## Warum es wichtig ist

Die meisten Projektfehlschläge lassen sich darauf zurückführen, dass das Falsche gebaut wurde, nicht auf schlechten Code. Ein Tech Lead, der zuverlässig Mehrdeutigkeit in klare, vereinbarte Anforderungen umwandelt, bewahrt das Team vor Überarbeitungen, schützt Schätzungen und verdient sich das Vertrauen des Unternehmens, indem er liefert, was tatsächlich gebraucht wird, statt nur das, was wörtlich gesagt wurde.