Empfindliche Softwareentwickler...

Liebe Forumsteilnehmer,
ich möchte in einer Firma ein QM-System einführen. Das klappt soweit ganz gut, der Geschäftsführer freut sich, dass er endlich mal sieht, was in seinem Betrieb überhaupt so alles läuft; die Mitarbeiter freuen sich, dass endlich Entscheidungen über bisher schwammige Sachverhalte getroffen werden. Sorgen bereiten mir nur die Herren Softwareentwickler. Die sind alle GENIAL, aber auch CHAOTISCH. Kaum Kommentare im Quellcode, nur magere Dokumentation, keine geregelten Testverfahren. Das Argument, was mir entgegenschlägt: "wenn uns der Kunde QM bezahlt, dann gerne, ansonsten keine Zeit".
Wie kriege ich meine Leute dazu, wenigstens einen Mindeststandard im Bereich Software-QM einzuhalten? Und wie sieht der Mindeststandard aus?

Liebe Herr Hummrich,
enscheidend für die Antwort: Sind Sie Führungskraft der Programmierer, verantworten also das Ergebnis, entscheiden dafür aber auch über Aufgaben dieser Personen, Förderung und Gehalt?
Oder sind Sie Qualitätsbeauftragter mit der Aufgabe, lediglich ein QM-System einzuführen, also ein Mittel, ein Werkzeug für Führungskräfte?
Im ersten Fall hätten Sie schon dies Soll-Verhalten Ihren Programmierern schon längst vorgelebt, wie es Ihnen wichtig ist, es gefordert, die Einsichtigen und Willigen gefördert, die Uneinsichtigen erst weniger streng, dann strenger angeschaut und den hartnäckigen Möchtegern-Rebell vielleicht abgemahnt.
Sie hätten den großartigen Vorteil der "heiligen Dreieinigkeit" gehabt aus Aufgabe, Kompetenz und Verantwortung. Seit uralten Zeiten ist eigentlich bekannt, daß diese Dreieinigkeit in sich stimmen muß für Erfolg.
Sie ist aber unscheinbar. Deshalb wird sie in der hemdsärmeligen Hektik des Alltags gern übersehen. Wer sie dann bricht, erzwingt Minderergebnisse.
Denn man kann eine Aufgabe nur dem geben, der auch die Kompetenzen hat, sie zu erfüllen, und den man für die Erfüllung verantwortlich macht.
Auch wenn ich mal wieder mit meinem C-Compiler herum spiele - Spezifikation, Editor, Compiler, Linker und ausführbares Programm gehören in dieselbe Hand.
Wem die Kompetenzen genommen wurden oder die Verantwortung, der muß scheitern - es sei denn, die Betroffenen sind ihm so wohl gesinnt, daß sie ihm gewähren, was er braucht.
Ihre Schilderung läßt einen doppelten Bruch dieser Dreieinigkeit erkennen:
1. Beim Leiter Softwareentwicklung. Er hat weiter die Ergebnisverantwortung für seine Abteilung. Ihm wurde aber Kompetenz (Befugnisse) genommen, also Einfluß auf die Art und Weise, wie das Ergebnis zustande kommt. Über diese Zwickmühle müßte er schon ziemlich sauer sein, aber vielleicht hat er die Wirkungsweise dieser Zwickmühle noch gar nicht erkannt.
2. Bei Ihnen. Ihr Geschäftsführer freut sich, wie Sie sich mühen, den Entwicklern qualitätsgerechtes Verhalten beizubringen, aber die dafür notwendigen Befugnisse hat er Ihnen nicht gegeben.
Mit diesen Verletzungen der Dreieinigkeit sind Ärger, Konflikte, Arbeitserschwernisse und Minderproduktivität dieser Personen und der Mißerfolg für Sie vorprogrammiert.
Aus eigener Kraft können Sie keinen Erfolg haben, nur mit dem Wohlwollen der Programmierer und des Leiters SW-Entwicklung. Das ist so unsicher wie ein angerissenes Bunjee-Seil.
Die Programmierer werden Sie als ihren Lieblingsgegner betrachten, Sie hassen, und alles, was Sie tun, hintertreiben. Ich an deren Stelle würde meine Spielchen mit Ihnen treiben, und ich, als der große Genius (als den ich mich jetzt mal erträume), der unkündbare Genius, ich würde Sie eins um andere Mal belämmert dastehen lassen. Sie verlangen von mir Mehraufwand? O.K. Ich bin artig, ich tue wie verlangt. Mein Chef fragt nach dem Grund der Terminüberschreitung? "Ja, Chef, der Herr Hummrich hat unseren Arbeitsaufwand pro Codezeile um 20\% gesteigert. Das war doch mit ihnen abgeklärt? Nein, doch nicht?" Und schon hetze ich meinen Chef auf Sie, auf daß er Ihnen die Hölle heiß mache, und wir Programmierer schauen uns an, wie Sie beide High Noon spielen. Ach, besser als jeder Fernsehkrimi!
Ihrem Geschäftsführer ist der Fehler unterlaufen, Brüche der Dreieinigkeit zuzulassen.
Spätestens, wenn sein Banker nach dem Grund der Verschlechterung der Kennzahlen fragt, könnte sich der Sündenbock-Suchblick auf Sie richten.
Wenn Sie diesen Bruch der Dreieinigkeit unauffällig selbst reparieren können, dann tun Sie es. Besser heute als morgen.
Es ist eine heikle Sache, ohne nähere Untersuchung kann ich nur den Ansatz zeigen:
1. Nehmen Sie die Aufgabe, die man Ihnen gegeben hat, mal nicht pragmatisch, sondern prinzipientreu-genau. Die lautet nämlich: "Einführung eines QM-Systems". "Einführung eines QM-Systems und Anwendung zum Erreichen von Zielen" aber wäre über das genannte Ziel hinaus geschossen.
2. Überlegen Sie sich ein praktisches Ziel Ihrer Aufgabe. Ein Ziel, das Sie aus eigener Kraft erreichen, mit dem Sie Erfolg haben können. Wie eben, Ihrem Geschäftsführer, dem SW-Entwicklungsleiter und anderen Führungskräften ein funktiionierendes QM-System in die Hand zu geben und diese zu informieren, wie sie es für ihre Ziele einsetzen.
Wenn dann der SW-Entwicklungsleiter die Qualitätsziele seines Geschäftsführer will, dann sollen die sich auch über die Auswirkungen auf die Ergebnisse unterhalten.

Sie aber haben mit der Übergabe des QM-Systems gute Arbeit geleistet. Wie die Führungskräfte Ihr Werkzeug dann nutzen, das ist deren Sache. Sicher werden Sie ihnen raten können.
Es mag noch mehr Ansätze geben.
Bis jetzt habe ich mich um das eigentliche Problem und dessen unauffällige Lösung gekümmert. Jetzt schaue ich mir das Ganze mal mit Abstand an und frage: "Wie konnte es zum Bruch der Dreieinigkeit kommen?" "Sind aus Unkenntnis vielleicht noch mehr Brüche aufgetreten, welche die Arbeit erschweren, die Kosten treiben und die Hitze in die Köpfe?" "Wie weit ist die Unternehmensqualität durch solche Fehler beeinträchtigt, die selbst zwar unscheinbar sind, sich in der Arbeit aber sehr hinderlich und teuer auswirken?"
Wenn Sie hier etwas für die Unternehmensqualität tun wollen, da habe ich Unterstützung für Sie - nämlich ein rationales Systemmodell der Unternehmenskultur, Qualitätskriterien für die Unternehmenskultur, wie man nicht nur solche Brüche der Dreieinigkeit erkennt, sondern noch andere Arbeitshindernisse, die von ähnlichen Defekten der Unternehmenskultur verursacht sind.
Ciao
Wolfgang Horn

Lieber Herr Hummrich!
Dem, was Herr Horn zu Ihrem aktuellen Dilemma geschrieben hat, läßt sich nicht viel hinzufügen. Aber einen schönen Gruß an Ihre Geschäftsleitung und Software-Entwickler von einem Software-Anwender:
Der Kunde ist natürlich nicht bereit, QM-Management zu bezahlen. Er ist überhaupt nicht bereit, irgendein Management zu bezahlen. Was er bezahlt, ist ein Produkt in guter Qualität. Und dafür ist eine Minimum an Management nun mal notwendig. Ich wäre weiß Gott bereit, für eine Software 10\% mehr zu bezahlen, wenn ich dann nicht mehr bei der Schulung vor den Augen der entsetzten Entwickler pro Stunde einen groben Bug finden müßte!
(Man muß es der Firma zu Gute halten: Die Schulung wurde nie berechnet!)
Vileicht hilft das ein bischen bei der Argumentation.
Schöne Grüße
Frank Hergt

Moin,
die üblichen QM-Systeme kommen aus dem Bereich der Fertigungstechnik, bei der man einfache Maßstäbe an Vorgabe und Ergebnis legen kann.
Mal angenommen, eine Firma beschäftigt Künstler, deren Gemälde auf einem Spotmarkt verkauft werden.. hier ist mit QM nicht viel zu holen. Es dürfte sich schon so mancher bei dem Versuch verschlissen haben, die 'kreative' Arbeit von Softwareentwicklern in QM-Bewertungsschemata zu pressen.
Auf Seite 1 des QS-Lehrbuchs steht eine andere Dreieinigkeit als die von W.Horn genannte: Termine - Kosten - Qualität. Hier fehlt mir die Einordnung.
In sensiblen Bereichen wie Medizin, Luft- und Raumfahrt etc. sind die Anforderungen so formuliert, daß auch ein QM möglich ist. Innovationen oder preiswerte Produkte sind hier aber nicht zu erwarten.
Im Consumer-Bereich ist es hingegen längst üblich, das Prüffeld auf den Kunden zu übertragen. Denn eben dieser fordert eine hochmoderne Applikation mit möglichst vielen Features. Qualität kostet Geld, das der Kunde zahlen muß, und Zeit, die bei den aktuellen Innovationszyklen zu veralteten Produkten führt.
Für einen Software- Entwicklungsauftrag muß hier also eine klare Positionierung vorhanden sein, über die sich Kunde(n) und Vertrieb einig sind. Erst dann ist ein QM überhaupt möglich.
Freundliche Grüße, Ulrich Horn

Hallo,
in meinem Fall geht es konkret um Software, die in der Messtechnik Einsatz findet, es sind also hohe Ansprüche an die Sicherheit gegeben. Zweifelsohne ist auch hier die Kreativität des Entwicklers gefordert. Und tatsächlich, da es häufig Einzellösungen sind, die programmiert werden müssen, ist es sicher unumgänglich den Kunden in das Testverfahren einzubinden.
Es gibt zum Thema Software-Entwicklung zahlreiche DIN-Normen. Es gibt auch einige Lehrbücher (z.B. "Lehrbuch der Software-Technik" von Balzert), die sich mit Software-QS beschäftigen. Doch all dies können nur Hinweise sein, die man im konkreten Fall angemessen berücksichtigen kann.
Ich habe mir (unterstützt durch die Anworten der Forumsteilnehmer) Gedanken gemacht, welche Maßnahmen geeignet sein könnten, z.B.:
- Klare Vereinbarung über den Umfang der Programmeigenschaften und den Testumfang treffen
- Programmierrichtlinien (Konventionen zur Variablenbenennung, Kommentare)
- Richtlinie oder Checkliste für die Programmdokumentation
- Testfälle auswählen, Test durchführen, Ergebnis dokumentieren.
Gehe ich damit etwa schon zu weit?
Beste Grüße
Holger Hummrich
: Moin,
: die üblichen QM-Systeme kommen aus dem Bereich der Fertigungstechnik, bei der man einfache Maßstäbe an Vorgabe und Ergebnis legen kann.
: Mal angenommen, eine Firma beschäftigt Künstler, deren Gemälde auf einem Spotmarkt verkauft werden.. hier ist mit QM nicht viel zu holen. Es dürfte sich schon so mancher bei dem Versuch verschlissen haben, die 'kreative' Arbeit von Softwareentwicklern in QM-Bewertungsschemata zu pressen.
: Auf Seite 1 des QS-Lehrbuchs steht eine andere Dreieinigkeit als die von W.Horn genannte: Termine - Kosten - Qualität. Hier fehlt mir die Einordnung.
: In sensiblen Bereichen wie Medizin, Luft- und Raumfahrt etc. sind die Anforderungen so formuliert, daß auch ein QM möglich ist. Innovationen oder preiswerte Produkte sind hier aber nicht zu erwarten.
: Im Consumer-Bereich ist es hingegen längst üblich, das Prüffeld auf den Kunden zu übertragen. Denn eben dieser fordert eine hochmoderne Applikation mit möglichst vielen Features. Qualität kostet Geld, das der Kunde zahlen muß, und Zeit, die bei den aktuellen Innovationszyklen zu veralteten Produkten führt.
: Für einen Software- Entwicklungsauftrag muß hier also eine klare Positionierung vorhanden sein, über die sich Kunde(n) und Vertrieb einig sind. Erst dann ist ein QM überhaupt möglich.
: Freundliche Grüße, Ulrich Horn

Herr Hummrich,
"gemeinsam Denken und Handeln" habe ich als Prozeß formuliert.
Geht man den nebulösen Bereich der "soft facts" mit rationalen Modellen und Prozessen an, verschwinden die Nebel und die Diskussionen werden konkreter, zielgerichteter, kürzer und erfolgreicher.
Den Prozeß schicke ich Ihnen gern zu - Email an mich, Prozeß kommt zurück.
Ciao
Wolfgang Horn