Beiträge gettagt mit Requirements

Vor kurzem hat mir Frank von einem Team erzählt, in dem man auf Fragen nur mit drei Antworten reagieren darf: „Ja.”, „Nein.” und „Ich weiß nicht.”. Sätze wie „Das sollte so funktionieren.” oder „Wenn alles glatt geht, müsste das klappen.” sind in diesem Team verboten.

Das wollte ich mal zum Anlass nehmen, eine Liste von Wörtern und Redewendungen aufzustellen, die ich (zumindest im Berufsleben) nicht mehr hören möchte, besonders wenn es um Aufwand, Lösungen oder Termine geht.

„sollten”, „müssten”, etc.

Der Konjunktiv ist der Feind einer jeden Projektplanung. Meistens verrät er einem nicht, unter welchen Bedingungen ein Arbeitspaket rechtzeitig fertig wird, oder unter welchen Bedingungen der Code wie erwartet funktioniert. Wenn Sie den Konjunktiv im Berufsleben hören, dann nehmen Sie so schnell wie möglich Reißaus.

„sollen”

„Sollen” ist der kleine Bruder von „sollten” aber fast genau so schlimm. Was machen Sie, wenn Sie in einem Anforderungsdokument einen Satz wie „Die Antwortzeit des Service soll unter 200 Millisekunden liegen.” vorfinden? Ist das eine freundliche Bitte oder eine zwingende Anforderung? Was passiert, wenn diese Anforderung nicht erfüllt wird? Beim Einsatz des Verbs „sollen” bewegen Sie sich in einer Grauzone.

„einfach”, „nur”, etc.

In der Software-Entwicklung gilt nicht „Weil einfach einfach einfach ist.”. Zwei Situationen sind fast nie identisch, das heißt, wenn heute etwas funktioniert hat, haben Sie keine Gewißheit, dass es morgen genau so funktioniert. Die Vokabeln „einfach” oder „nur” werden meistens eingesetzt, um einen Sachverhalt zu verharmlosen oder die Komplexität zu verstecken. Wenn Sie diese Wörter hören, dann schauen Sie besser genau so hin. Aber vielleicht sehe ich das einfach nur zu eng.

„prinzipiell”, „eigentlich”, „normalerweise”

Ist der aktuelle Fall der Normalfall, oder wird jetzt gerade gegen das Prinzip verstoßen? Ich möchte nicht wissen, wann ein Arbeitspaket unter anderen Umständen eigentlich fertig wird, sondern wann genau in diesem konkreten Fall mit der Fertigstellung des Arbeitspaketes zu rechnen ist. Vor Jahren habe ich mit einem guten Freund gearbeitet, dessen Shop-Projekt monatelang „normalerweise nächste Woche fertig werden sollte”.

Was ist daran schlecht?

Warum möchte ich diese Wörter nicht hören? Sie machen es mir schwer, zu reagieren. Wenn das Projekt normalerweise pünktlich fertig gestellt werden sollte, dann sagt mir das das selbe, als würde das Projekt wahrscheinlich nicht rechtzeitig fertig und damit bin ich wieder genau so schlau wie vorher.

Ein „Wir hatten Probleme mit den Unit-Tests und werden nicht zum geplanten Termin fertig. Es dauert eine Woche länger.” zeigt mir klar, woran ich bin und ermöglicht mir (und dem Team) Maßnahmen zu ergreifen. Es geht hier um Verbindlichkeit, die nötig ist, um entsprechend reagieren zu können. Ob dies bedeutet, einfach Funktionalitäten außen vor zu lassen, um den Termin zu halten, oder stattdessen den Termin zu verschieben, hängt vom Projekt ab.

Aber warum hört man diese Wörter trotzdem so oft, wenn es darum geht, einen Termin zu bestätigen oder frühzeitig abzusagen? Meistens möchte man damit schlechte Nachrichten vermeiden und hofft, den Termin doch noch irgendwie zu halten. Damit wird die schlechte Nachricht in den meisten Fällen jedoch nur verschleppt, wenn der Termin nicht doch noch, wie durch ein Wunder, gehalten werden kann.

Wie kann man es verhindern?

Erschießen Sie nicht den Überbringer der schlechten Nachricht und schaffen Sie eine Kultur, in der man eigene Fehler zugeben und schlechte Nachrichten überbringen kann, ohne mit Sanktionen rechnen zu müssen. Belohnen Sie Verbindlichkeit und signalisieren Sie so, dass es Ihnen lieber ist, früh die schmerzhafte Wahrheit zu erfahren, anstatt sich lange in trügerischer Sicherheit zu wiegen.

Probieren Sie einfach, dann sollte das eigentlich auch in Ihrem Team funktionieren.