In der Oktoberausgabe 2010 von brandeins erläutert die Sozialwissenschaftlerin Bettina Warzecha wie Qualitätsmanagement sehr oft als das Sammeln und Bewerten von Zahlen verstanden wird. Diese noch aus dem Industriezeitalter stammenden Bestrebungen, alles quantitativ erfassen zu wollen, hat viel Nutzen bei repetitiven Arbeiten oder in der Massenproduktion gebracht. Sollen wissensintensive Dienstleistungen oder durch Wissensarbeit entstandene Produkte quantitativ bewertet werden, sieht das allerdings völlig anders aus. Hierzu Bettina Warzecha: „Dennoch kann Qualitätsmanagement in einem bestimmten Rahmen nützlich sein, etwa bei der industriellen Produktion standardisierter Produkte. Absurd wird es, wenn man diese aus der Ingenieurswissenschaft stammende Methode – wie leider mittlerweile üblich – auf Wissensarbeit überträgt.“
Für durch Wissensarbeit erzielte Resultate wie z.B: eine Softwareanwendung ist zunächst einmal die qualitative Beurteilung der Brauchbarkeit wichtig. Nur wenn diese gegeben ist, und das ist nicht immer selbstverständlich, kann man sich über quantitative Messgrössen unterhalten, vorher nicht.
der wissensarbeiter
der wissensarbeiter 
Ist es nicht beobachtbar, dass die Methodik im Softwareengineering in dieselbe Richtung geht wie dies der Fordismus oder gar der Taylorismus im Industriezeitalter für die Manufaktur bedeutet hatten?
So sind etwa Patterns standardisierte Lösungen von gängigen Problemen und Scrum zerstückelt grosse Aufgaben in kleine Task, die autonom abgearbeitet werden können. Würde bei Scrum Planung und Ausführung getrennt, dann geht das schon in Richtung isolierter Fliessbandjobs für Wissensarbeiter, die zu einer Entfremdung der Arbeitswelt von Software Ingenieuren führen kann.
Dazu kommt, dass, wie ich das verstehe, Scrum dem Entwicklungsteam kein RE zugesteht, was ein weiterer Schritt in Richtung einer ausdifferenzierten Arbeitsteilung geht.
Vor diesem Hintergrund ist ein quantitatives Qualitätsmanagement durchaus verständlich. Dazu kommt, dass ich etwa ein Projektmanager aus dem Business mit Zahlen über Code Coverage, PMD, Check Style, JDepend oder was auch immer einfacher überzeuigen kann als wenn ich einfach hinstehe und qualitativ sage: „Das ist gute Software“
Hallo Marc
Ich sehe eher eine Zweiteilung der Softwarewelt. Industrialisierung mit hoher Arbeitsteilung und Standardsierung und – ich nenne das – Professionalisierung mit sinnvoller Arbeitsteilung und optimal auf die Problemstellung angepasstem Vorgehen.
Bei Scrum ist die Idee, dass der Product Owner das RE macht oder ein dedizierter Requirements Engineer, siehe http://2010.reconf.de/fileadmin/PDF_Dateien/REConf_2010/Vortraege/Ersatzvortra_Monique_Jakobi.pdf
Ich bin aber der Überzeugng, Scrum funktioniert nur richtig gut, wenn das Team ins Requirements Engineering eingebunden ist und mit den Anwendern immer wieder Kontakt hat um z.B. Abläufe im Detail auszuarbeiten und per Prototyping Vorschläge zu machen.
Gruss,
der wissensarbeiter