Six Sigma für Software - welche Bestandteile gibt es

Wie im letzten Blog-Eintrag beschrieben, bietet Six Sigma für Software ein Toolset, mit dem verschiedene Prozesse der Softwareentwicklung unterstützt werden können. Folgende Toolsets sind dies:

• Kundenorientierung
• Prozessorientierung
• Steuerung mit Metriken

Welche Bestandteile beinhaltet das Toolset für die Kundenorientierung:

• Das Kano–Modell zur Bestimmung der Mindestanforderungen an die Software
• Die Ermittlung der kritischen Kundenanforderungen mittels Critical to Quality (CTQ)
• Die Methode Voice of the Customer (VoC) zur Ermittlung der Prioritäten aus Kundensicht
• Quality Function Deployment (QFD)
• Methoden für das Benchmarking (Vergleich mit Konkurrenten)
• FMEA (Fehler Möglichkeits- und Einfluss- Analyse) ist eine Methode zur Vermeidung von Problemen, in dem Lösungen für solche Probleme schon vorab bedacht werden

Diese Tools von Six Sigma konzentrieren sich auf das Qualitätsmanagement in den frühen Phasen der Softwareentwicklung.



Das zweite Toolset unterstützt die Prozessoriertierung:

• Prozessbeschreibungen (Flussdiagramme), wobei fraglich ist, ob diese benötigt werden, wenn umfangreiche Modellierung stattfindet
• SIPOC (Prozessanalyse: Supplier – Input – Prozess – Output – Customer) Auch hier ist die Frage, ob dieses Tool benötigt wird, wenn intensive Modellierung stattfindet. Es ist jedoch eine interessante Methode zur Betrachtung von Prozessen
• DMAIC ist der klassische Verbesserungsprozess im Six Sigma (Define-Measure-Analyse-Improve-Control)

Das dritte Toolset dient der Steuerung durch Metriken:

• Six Steps to Completion (Projektmanagement - Methode) Eine interessante Vorgehensweise, bei der "fertig" erst dann wirklich "fertig" ist, wenn alle Aktivitäten abgeschlossen sind (und nicht der "Code für den Tester über den Zaun geworfen wird")
• Function Point (Aufwandsmessungen zur Schätzung der Projektdauer)
• Fehlerstatistiken (Steuerung über offene Punkte, ToDo's)
• Histogramme
• Paretodiagramme
• Weitere statistische Methoden

Alle Tools (oder Methoden) bieten interessante Ansätze, die in die Entwicklungsprozesse integrierbar sind. Hat man jedoch ein Entwicklungsvorgehen (z. B. nach CMMI) auf einem hohen Level im Unternehmen implementiert, bringt der Einsatz dieser Methoden nicht zwingend weitere Verbesserungen. Es lohnt sich jedoch, die Methoden einmal anzusehen.

Wenn beim Kunden ein Softwarefehler auftritt

Fehlerfreie Software ist ja eine Utopie. Trotz intensivster Qualitätssicherung ist eine Software-Auslieferung ohne leichtere oder sogar schwere Fehler ist nicht möglich. Nicht jeder Fehler in der Software muss beim Kunden auch auftreten. Ist dies jedoch der Fall, zeigt sich im Umgang mit dem Problem, was einem die Kunden wert sind. Ein sehr auffälliges, und aus meiner Sicht auch positives Beispiel, habe ich heute bei twitter.com entdeckt. 
Der Anbieter my6sense hatte einen Fehler in seiner Applikation. Erwarten würde man, dass der Fehler bereinigt wird und anschließend die Kunden, wenn dies möglich ist, direkt darüber informiert werden. Das Unternehmen hat sich jedoch entschlossen, sehr aktiv auf die Kunden zu zugehen, und das Problem über twitter kommuniziert.

A very positive and impressive way of customer support

Diese sehr offene Art führt dazu, dass viel mehr User, als die von dem Problem betroffenen, das Problem mitbekommen. Trotzdem hatte sich der Anbieter dafür entschieden. Einige Zeit später hatte der Anbieter das Problem behoben und auch in diesem Fall wieder alle twitter-follower informiert. 

the problem is solved

Der offene Umgang mit dem eigenen Fehler und die Kommunikation sorgen dafür, dass der Kunde trotz des Fehlers weiterhin Vertrauen in seinen Anbieter hat (solange der Fehler nicht zum Regelfall wird) und damit auch als Kunde langfristig erhalten bleibt.
Ich finde, dass dies ein Beispiel sehr guter Betreuungs-Qualität ist. Thanks to my6sense.