Anforderungen beurteilen
Dass ihr Menschen, rief ich aus, um von einer Sache zu reden, gleich sprechen müsst: das ist thöricht, das ist klug, dass ist gut, das ist bös! Und was will das alles heissen? Habt ihr deswegen die inneren Verhältnisse einer Handlung erforscht? wisst ihr mit Bestimmtheit die Ursachen zu entwickeln, warum sie geschah, warum sie geschehen musste? Hättet ihr das, ihr würdet nicht so eilfertig mit euren Urtheilen seyn.
Sich selbst täuschen
Goethe mahnt in „Die Leiden des jungen Werther“ nicht zu voreilig mit dem Bilden von Urteilen zu sein. Schnell hat man ein Wort gefunden um eine Sache zu beschreiben und fällt dann schnell selbst auf die Wertung dieses Wortes herein. Klug, gut oder bös. Aber warum geschah eine Handlung? Was war das Motiv und war es wirklich gut oder böse? Warum sieht man selbst eine Handlung als gut oder schlecht an?
Dies gilt in vielen Bereichen. Versucht man nicht auf sein erstes Urteil zu beharren, sondern hält inne und hinterfragt es, stellt man fest, dass nicht ein äußerer Faktor einen zu einem Urteil brachte, sondern eigene Wertungen, Erwartungen oder Bedürfnisse.
Was bedeutet dies für Entwickler?
Dieser Umstand zeigt sich auch in der Beurteilung eines Entwicklers einer Anforderung an eine Software. Vielleicht sind gerade Entwickler gewohnt in Mustern zu denken. Schnell bildet man sich das Urteil, dass eine Anforderung weniger wichtig ist als vom Kunden erläutert, weil man gewöhnt ist, dass meist die neuste Anforderung die wichtigste ist. Oder man geht mit einer Erwartungshaltung an die Lösung und versucht die Anforderung in ein bekannte Lösungsmuster zu pressen. Und als letztes hat man als Entwickler sicherlich das Bedürfnis die Lösung mit bekannten Technologien zu lösen, statt sich in eine Neue einzuarbeiten.
Was ist das Bedürfnis hinter einer Anforderung?
Es kann sich also lohnen das Bedürfnis des Kunden zu erfragen. Selbst wenn eine Anforderung simpel erscheint. Was bewegt den Kunden zu dem Wunsch? Was will er erreichen? Wie möchte er die Funktion benutzten? Was ist ihm dabei wichtig. Performance? Einfache Handhabung? Viele Konfigurationsmöglichkeiten? Anstatt die Anforderung direkt so umzusetzen wie man die Anforderungen des Kunden verstanden hat, kann man in einen Dialog mit dem Kunden treten. So hat man die Chance herauszufinden was der Kunde tatsächlich mit dem Feature bewirken will und es können sich ganz andere Lösungen ergeben. Vielleicht sind diese viel einfacher zu implementieren als man zunächst annimmt, weil viele Konfigurationsmöglichkeiten nicht gebraucht werden. Gegebenenfalls findet man Lösungswege, die einfacherer zu bedienen sind oder dem Kunden sogar noch mehr Nutzen bringen.
Fazit
Als Fazit sollte also gelten: Als ersten Schritt einer Story erst einmal das Bedürfnis hinter dieser zu erfragen um in einem Kommunikationsprozess ein besseres Verständnis der Anforderungen an die Software zu erlangen.
