In einem Gespräch vor einigen Wochen wurde ich mal wieder auf ein Thema gestoßen, welches für viele Projektmisserfolge verantwortlich ist. Insbesondere in Kreisen von Projektumsetzern (Engineers, Developer, etc.) scheint es nur eine Dimension der Qualität zu geben. Es wird großer Wert auf sauberes Coding und die Einhaltung von Dokumentation gelegt.
Über unterschiedliche Ansätze wie Reviews, Test Driven Development, FAT, SAT, Unit und Integration Tests und andere wird versucht die Qualität der entwickelten Lösung sicherzustellen.
Falsches Auto
Stellen wir uns mal vor ich plane eine Durchquerung der Sahara und bestelle mir dafür ein Fahrzeug. Nach langer Wartezeit erhalte ich dann endlich das für mich individuell gefertigte Fahrzeug. Wie geplant wird mir das Auto auf den Hof geliefert und da steht es nun – Rot glänzend, ein brandneuer 911 GTS3… .
Sicherlich ein fantastisches Fahrzeug, welches perfekt funktioniert und alle Qualitätstests erfolgreich bestanden hat. Nur leider ist das Fahrzeug überhaupt nicht für den geplanten Einsatzzweck geeignet!
Genau dasselbe passiert in vielen Projekten. Es wird kontinuierliche und konsequent an den Anforderungen des Kunden/ des Anwenders vorbei entwickelt. Entwickler sitzen zusammen und machen einen Plan, überlegen sich die tollsten Features und Funktionen. Diese sind zwar cool, leider braucht sie aber keiner… Schade!
Um ehrlich zu sein, war auch ich vor Jahren schon einmal in dieser Situation. Nach langen Gesprächen mit Stakeholdern hatten wir eine Lösung für eine regulatorische Abteilung entwickelt. Das Management war begeistert und schließlich kam der große Tag, an dem die Lösung dem Team präsentiert wurde.
Nach dem Ende der Präsentation durch den Abteilungsleiter war es unangenehm ruhig im Raum, bis schließlich eine Dame aufstand und sagte: So arbeiten wir schon seit drei Jahren nicht mehr!
Sie können mir glauben, die Stimmung im Raum wurde danach nicht angenehmer.
Seit diesem Tag versuche ich immer auch die zweite Dimension der Projektqualität zu berücksichtigen. Dabei geht es um das Verständnis der Anforderung: Was benötigt der Anwender, um seine Arbeit tun zu können? Was ist sein Schmerz, was sein Problem?
Fazit – Sprich mit dem Nutzer
Ich habe daraus gelernt in jedem Projekt direkt mit den Anwendern zu sprechen. Verlassen Sie sich nicht auf Aussagen von Vorgesetzten, Projektmanagern, etc. Gehen Sie direkt zu den Leuten und fragen Sie nach! Sprechen Sie mit Ihnen und holen Sie da Ihr Feedback ein.
Welche Erfahrungen haben Sie mit „False Requirements“ gemacht? Gerne per Mail an mich oder hier in den Kommentaren.
Mit chaotischen Grüßen
Christof Layher
