Im nächsten Abschnitt geht es nun um Prozessqualität,
das ist hier bei uns die dritte Frage.
Ihr heißt die Frage, worin besteht der Zusammenhang zwischen Prozess und Produktqualität?
Für die Produktqualität und die Qualitätsmerkmale hatten wir diese Norm ISO 29,
25, 10 beziehungsweise 25.000 und für die Prozessqualität,
ich gehe noch mal zurück zu dieser Folie,
da haben wir nicht so eine schöne Norm.
Es gibt etwas in der ISO 9.000, aber so richtig
viel haben wir nicht. Ich möchte erst Zunächst aber in
die Frage einsteigen, warum brauchen wir denn Prozessqualität?
Was hat Prozessqualität denn mit Produktqualität zu tun? Es ist
ganz klar, wir wollen Nutzerzufriedenheit erreichen. Also irgendwie,
ich mache mal so, was wir erreichen wollen,
ist ein zufriedener Nutzer.
Und das wollen wir erreichen durch Produktqualität
Und was wir auch, was dazu auch gehört,
wir hatten diese Qualität in der Benutzung.
Ich nehme mal hier den englischen Begriff, Quality in use.
Der war auch noch in der Norm drin.
Beides soll dazu beitragen, dass der Nutzer zufrieden ist,
dass der Nutzer seine Ziele erreichen kann.
Wie können wir das erreichen? Natürlich durch gute Arbeit.
Und diese gute Arbeit können wir unterstützen,
indem wir einen guten Prozess haben.
Und deswegen spielt der Prozessqualität hier
eine wichtige Rolle,
Qualität. Also die Prozessqualität schafft Voraussetzungen. Für die Produktqualität.
Wir können es allerdings nicht umdrehen. Wir können nicht sagen,
ja, wir machen eine gute Prozessqualität und dann wird der Nutzer schon zufrieden sein.
Ein kleines Beispiel möchte ich bringen aus dem Restaurant.
Sie sind zufrieden, wenn das Essen schmeckt,
wenn der Service gut ist, dann fühlen sie sich wohl
Dass wenn nur der Prozess in der Küche funktioniert,
zum Beispiel das, was die Lebensmittelkontrolle,
die Hygieneinspektionen sich anschaut, werden die Nahrungsmittel alle entsprechend gelagert,
die Kühlkette nicht unterbrochen, ist es sauber und aufgeräumt,
sind da keinen Unfall gefahren in der Küche,
keine Brand gefahren in der Küche.
Das alles ist wichtig, ist eine Voraussetzung dafür,
dass sie ein verdauliches Essen bekommen, von dem sie nicht krank werden.
Ja, und so. Aber das ist nicht die einzige Voraussetzung.
Das bedeutet nämlich noch nicht, dass das Essen auch schmeckt.
Ja, also deswegen ist diese Prozessqualität wichtig,
schafft Voraussetzungen für die Produktqualität, aber ist nicht das Einzige,
was dazu führt, dass der Benutzer die Nutzerqualität zufrieden ist.
Er nutzt Zufriedenheit erreicht wird, so wollte ich sagen. Ja,
und diese Voraussetzungen schaffen, dass es die grundsätzliche Annahme,
die Prozessqualität und deswegen wollen wir auch für die Prozessqualität bestimmte Merkmale erreichen.
Auf der nächsten Folie habe ich hier ein paar Dinge zusammengestellt,
die stammen allerdings nicht aus einer Norm.
Es ist immer zu empfehlen, einen Norm zu verwenden,
wenn man sie denn benutzen kann. Was ich hier aufgeschrieben
habe, ist aus meiner ganz persönlichen Erfahrung als Projektleiter.
Ich habe einige Jahre größere Projekte geleitet. Und da,
wenn man selbst sich um Qualität bemüht, um Qualität kümmert,
kann man auch eine ganze Menge zusammentragen, was sind wichtige Merkmale.
Allerdings sind die eben nicht,
haben nicht diesen Grad der Abstimmung und gerade der begrifflichen Sauberkeit erreicht,
den so eine Norm eigentlich erfordert.
Mir ist allerdings keine Norm bekannt, die das genau beschreibt.
Es gibt für Prozesse, die ISO 9000 oder die 9000 bis 9004 Normenfamilie,
schreibt, wie Prozesse zu beschreiben sind, wie ein Qualitätsmanagementsystem aufzustellen ist.
Aber das passt nicht so richtig für Softwareentwicklung und es passt nicht so richtig für unsere Ziele,
nämlich die wir auf der vorgehenden Folie hatten, Produktqualität zu erreichen.
Also, dass sie als Vorrede, ich möchte die Dinge ihnen kurz vorstellen.
Ich fange mal an mit etwas, was sie sehr gut nachvollziehen können.
Und zwar mit Produktivität, wir ein bisschen aus der Mitte heraus.
Ergebnis zu Aufwand, man könnte hier auch noch sagen,
Effizienz, wäre auch noch ein vergleichbares Wort.
Also Verhältnis auf einen nutzen, das soll gut sein,
weil wir ja Softwareentwicklung in einem wirtschaftlichen Umfeld machen.
Wir müssen damit Geld verdienen, wir wollen selber unsere Miete bezahlen können,
aber auch wir wollen die Existenz einer Firma sichern,
da muss man auch mal in die Zukunft investieren,
auch mal neue Technologien erfragen, wo man Erfahrungen bringt,
wo man nicht gleich Geld mit verdient.
Also man muss auch ein bisschen was zurücklegen können.
Und dazu muss natürlich das Ergebnis dem Aufwand gegenüber angemessen sein.
Das ist ein Merkmal eines Entwicklungsprozesses und auch eine Voraussetzung,
dass wir koordiniert für gut arbeiten können
Dann die nächsten beiden Punkte, die hier drüber stehen, Terminplanung und Budgetplanung.
Sie werden sich denken, was hat denn das damit zu tun,
dass die Software am Ende gut ist?
Ja, wenn wir für den Kunden, für die Kundenzufriedenheit,
ist Termineinhaltung ganz direkt wichtig. Ich gehe mal noch ein Bild zurück. Ja,
also hier wäre es tatsächlich so, die Termineinhaltung,
die ist ganz direkt wichtig für die Kundenzufriedenheit,
der Termin ist ja nicht nur, dass er zu dem Zeitpunkt etwas bekommt,
sondern die Organisation des Anwenders hat sich häufig darauf eingestellt.
Also nehmen wir mal an,
sie liefern Software für eine Bank und diese Bank hat zu dem Zeitpunkt,
wo sie diese Funktionen benutzen soll, möchte sie entsprechend die Kunden informiert haben.
Das heißt, die Kunden haben alle Informationsmaterialien bekommen. Die Mitarbeiter haben Schulungen bekommen,
sie internen Abläufe sind umgestellt und dann wäre es aber blöd,
wenn wir dann sagen, ja,
wir sind leider am Tag einen Monat zu spät damit.
Ja, also deswegen Termineinhaltung ist ganz wichtig und für die
Planung muss die Abschätzung genau sein.
Also deswegen habe ich das Güte der Abschätzung genannt.
Wenn wir vorher eine Erschätzung machen, im März,
ja, wir werden am 30.09. fertig sein,
dann soll das bitte nicht erst am 30.10. sein,
sondern wir wollen möglichst genau das machen.
Gleichzeitig, wenn wir ungenau sehen. Wir können natürlich sagen,
okay, wir machen Reserve ein oder zwei Monate.
Ja, dann dauert es aber zu lange.
Also eigentlich wollen wir möglichst gut schätzen können. Das Gleiche
trifft auf das Budget zu. Wir wollen mit dem Budget auskommen,
wenn das nicht wäre, wird die Produktivitätszahl nicht erreichen,
aber vor allen Dingen sonst müssten wir unbezahlte Arbeit leisten,
wenn das Geld nicht reicht, wenn wir das Budget überschreiten.
Gerade wir haben heutzutage viele Festpreisprojekte, wo vorher klar ist,
dieses Produkt kostet diese Summe X und da müssen wir da auch reichen.
Nun können wir ja auch hier sagen, okay,
wenn wir gut schätzen können, ist das hervorragend,
wenn wir schlecht schätzen können,
nehmen wir einfach
was Reserve
Ja, aber wenn wir ein Software-System anbieten, sagen,
ja, wir machen,
dass wir 175.000 und jemand anders kann genauer schätzen und er weiß,
okay, ich brauche 110, ich mache ein bisschen Reserve,
125, ich mache ein Angebot für 125.000 Euro und wir haben 175 angeboten,
werden wir es nicht bekommen, den Auftrag.
Deswegen ist die Güte der Abschätzung hier auch ein wichtiges Kriterium. Nun werden Sie sich fragen,
ja, was hat denn das mit Prozessqualität zu tun,
das ist die Qualifikation des Projektleiters, das ist die Organisation,
die Reife der Organisation der Firma,
macht man Aufwandsschätzungen und Terminschätzungen so reproduzierbar,
dass man beim nächsten Mal oder nach den realen Zahlen das verbessern,
überarbeiten kann, sodass man beim nächsten Mal eine bessere Schätzung machen kann.
So, diese beiden Punkte soweit abgesprochen als nächstes möchte ich hier etwas zu Aufgabenkoordination sagen.
Es ist immer so, bei größeren Projekten jedenfalls,
dass viele Mitarbeiter arbeiten haben, die aufeinander aufbauen.
Das heißt, wenn der eine mit etwas fertig ist,
ist das das Input für den Nächsten und wenn das
sein Output ist, wieder das Input für den Nächsten
Wenn die Planung dafür gut funktioniert, also eine gute Aufgabenkoordination ist,
dann haben wir einen geringen Anteil von Zeiten,
wo jemand warten muss, weil er das noch nicht machen kann.
Natürlich, wenn die Leute nicht da sitzen,
Däumchen drehen, sie werden irgendwas anderes machen,
aber diese Zeit war eigentlich, ist eigentlich nicht nützlich.
Wir haben ja irgendwie in Form von Leerlauf.
Das ist das eine, wenn wir Leerlaufzeiten haben,
wäre es schlecht, aber es gibt noch was anderes Schlechtes,
wenn ein Mitarbeiter zu viele Aufgaben hat.
Es gibt typischerweise Rollen in einem Projekt,
der Projektleiter und der Architekt gehören dazu,
aber auch Leute, die einfach viele Qualifikationen haben,
die sind für ganz viele Sachen verantwortlich
Und wenn man für mehrere Sachen verantwortlich ist,
dann braucht man zwischendurch eine Zeit zum Umschalten.
Das kostet Aufwand. Man sagt auch, geistige Umrüstzeit,
ja, ich schreibe das mal mit dir dran.
Umrüsten, dieser Begriff kommt aus dem Maschinenbau, ja,
wenn Sie sich vorstellen, Sie machen dafür ein Auto,
haben Sie eine große Presse, die macht aus Blech, Kurtflügel.
Und dann machen Sie erst den Kurtflügel für rechts und dann
machen Sie den Kurtflügel für links,
müssen Sie zwischendurch die Maschine kurze Zeit anhalten, um das umzubauen.
Und genauso brauchen wir das auch, wenn wir gerade die
Bucking gemacht haben und müssen dann hinterher eine Aufwandsschätzung, eine Projektplanung machen.
Dann müssen wir zwischendurch uns das eine ablegen und dann in das Neue erstmal reindenken.
Und dann haben wir auch eine ungenutzte Zeit.
Und wenn wir das zu viel hin und her machen,
zu viel Sachen parallel, dann sinkt insgesamt und zur Produktivität
unsere Produktiv nutzbarer Zeit.
Das heißt, wir wollen versuchen, dass wir nicht so
viele Paralleltätigkeiten haben.
Ich schreibe mal hier in das obere Loch
Wartezeiten dazu
Ja, das sind auch Zeiten, die irgendwie nicht produktiv sind.
Die nächsten Punkte, den ich nennen möchte,
ist hier, geht es hier um Organisation, Kommunikation.
Regelungsgrad, damit es gemeint, haben wir viele Vorschriften oder
wenige Vorschriften
Das möchte ich kurz auf einem separaten,
in einem separaten Bild mal darstellen, das haben wir die nächste Folie,
habe ich dafür mal vorbereitet und zwar zwei Koordinaten,
einerseits der Regelungsgrad, das heißt die Menge der Regelungen.
Damit sind Vorgaben gemeint und die Produktivität. Wenn wir mal annehmen,
wir haben ganz wenig Vorgaben, ganz wenig Regeln,
dann bedeutet das, wir haben mehr oder weniger chaotisches Arbeiten,
jeder arbeitet so, wie er es gerade kann.
Es ist nicht viel abgestimmt und da passiert es so,
dass die Produktivität nicht so besonders hoch ist. Es kann sein,
wir führen dann ein paar ordnende Regeln ein und sagen,
ja, das und das wird so abgestimmt, das wird so abgestimmt.
Wir legen einfach ein paar Abstimmungen fest und dann steigt die Produktivität,
weil wir mehr oder weniger Lehrlauf haben, weniger Überarbeitungsbedarf,
wenn ja Misskommunikation, ja, das steigt immer weiter und ist,
wenn wir dann immer noch mehr einführen, mehr einführen,
werden wir aber merken,
vielleicht gibt es ja hier noch so einen Wert,
wenn wir noch mehr einführen würdest dazu führen,
wir haben mehr Produkte
Kolle auszufüllen, mehr Besprechungen, mehr Sachen zu lesen.
Und dann sinkt die Produktivität wieder. Und wenn wir noch mehr Regelungen haben,
kommen wir vor lauter Papier schon gar nicht mehr hin.
Und wenn es, dann entsteht, dann haben wir vielleicht noch eine geringere.
Hier vorne wäre es, könnte ich mir,
könnte man das so sagen, zu chaotisch.
Und hierhin würde man sagen zu bürokratisch. Und wenn man
diese Punkte miteinander verbindet, entsteht so eine Art Parabel.
Und das wäre Für eine bestimmte, das wäre die optimale Menge von Regelungen.
Und was das Optimum ist, ich habe hier keine Werte dran geschrieben.
Es gibt nicht den Wert 1, 10, 20,
sondern das hängt davon ab von den Projektbedingungen.
Wir brauchen mehr Regelungen bei hohem Risiko
Bei einem großen Projekt mit vielen Mitarbeitern.
Vielen Beteiligten. Oder bei hoher Komplexität der Aufgabenstellung
Also wenn wir ein Flugzeug bauen,
ist das mehr Komplex, wir haben mehr Spezialisten dabei,
müssen wir mehr Regelungen, mehr Abstimmungen haben.
Also das meine ich hier mit dem Regelungsgrad.
Wir gehen mal zurück und machen hier weiter. Da bei
der Gelegenheit kann ich auch gleich was zu dem Reifegrad sagen.
Es gibt ein Reifegrad-Modell, da werden wir hier nicht drauf eingehen.
Ich bin nicht ganz sicher, ob Guido Kritzer darauf eingeht.
Hier können wir das, ich nenne das mal,
das heißt Capability-Mediurity-Model, Zum Beispiel CMI, Carpability,
Mattheory, Mattheory T. Model, das I steht für Integration.
Es geht darum, wie ist eine Organisation, eine Softwareentwicklungsorganisation organisiert. Ja,
also gibt es, welche Regelungen gibt es für Konfigurationsmanagement,
welche Regelungen gibt es für Metriken, welche Mehrregelungen gibt es für Aufwandsschätzungen oder so etwas.
Das ist zum Beispiel eine reife Organisation,
hat dort mehr Regelungen beziehungsweise die Möglichkeit sogar,
das anzupassen
So, das war also hier zum Reifegrad eingeschoben,
weil das mit dem Regelungsgrad gut zusammenpasst. Informationswege,
Länge hat damit zu tun, dass wir häufig in großen Organisationen,
also zum Beispiel in großen Projekten, Subteams einführen.
Kleine Gruppen, die Teile von größeren Gruppen sind und dann
die Kommunikation nicht mehr von jedem zu jedem läuft, sondern in bestimmten Corti-Kanälen.
Ich male das mal hier oben rechts in die Ecke,
wie so eine Hierarchie aussehen könnte. Ja, also das sieht so aus,
dass wir hier einen Projektleiter haben, der hat,
da gibt es vier Bereiche und in jedem Bereich gibt es nochmal drei Gruppen.
Und hier male ich das mal auch hin, noch die drei Gruppen.
Und wenn wir jetzt eine Kommunikationsbedürfnis haben, zum Beispiel,
es gibt ein Problem zwischen dem hier und dem hier. Und es ist so in einer Organisationsstruktur,
die Kommunikation nur entlang dieser Beziehungen erlaubt,
weil die anderen irgendwie nicht miteinander sprechen oder nicht miteinander sprechen sollen,
dann könnte die, würde die Kommunikation,
halt hier fehlt noch ein Strich, den ballen wir noch,
das soll der hier drunter hängen, dann würde die Kommunikation so laufen,
dass wir hier lang gehen,
hier lang und dann würde es hier lang gehen und hier lang gehen.
Ja, so, und jetzt haben wir,
haben wir hier also einmal Kommunikation, nochmal Kommunikation, nochmal Kommunikation,
nochmal Kommunikation, viermal weiter. Sie kennen alle das Spiel,
stille Post, wenn ich etwas immer weiter sage,
geht Information verloren, ganz abgesehen davon,
dass die Chefs auf der oberen Ebene häufig von den Details keine Ahnung haben,
es wäre also gut diesen Informationsweg nicht so lang zu machen.
Das ist hier gemeint, dass es ein Nachteil,
wenn wir so eine geordnete Kommunikation in solchen Strukturen haben,
ist der Informationsweg möglicherweise lang. Wenn wir das nicht hätten,
und jeder würde hier mit jedem sprechen,
also ich spreche von dem Projekt zwischen 40 und 100 Mitarbeitern,
dann würden wir das nicht hinkriegen, wenn dort jeder mit jedem spricht,
da haben wir tausende Kommunikationsbeziehungen und da geht zu viel verloren,
dann wäre der Kommunikationsaufwand zu hoch.
Also wir müssen zwischen diesen beiden hier Informationsweglänge mit
eben sehr guter Organisation und die Kommunikationsaufwand abwägen
Spezialisierungsgrad ist etwas mit Arbeitsteilung, also nicht Arbeitsteilung unter viele,
wie es hier ist, so eine Arbeitsteilung nach Sorten.
Es gibt also den Datenbank-Administrator und den Fachmann für Persistenz und
den Fachmann für das Framework XY. Und je mehr wir
solche Fachleute haben, desto mehr Spezialwissen haben wir einerseits verfügbar.
Und wenn wir zu wenig davon haben, muss jeder alles machen können.
Und dann fehlt uns das. Wenn wir allerdings
zu viele Spezialisten haben, jetzt auch den Nachteil,
dass diese Spezialisten dann das Nadelöhr sein könnten,
wenn wir gerade viel davon brauchen.
Also hier gibt es
auch ein Optimum
So, sie merken,
wir reden die ganze Zeit nicht über wirkliche Softwareentwicklung,
sondern wir reden ja über die Organisation von Projekten,
also damit über den Entwicklungsprozess.
Und ich habe auch gar nicht davon gesprochen,
ob wir jetzt agil arbeiten oder in einem Wasserfallmodell.
Das hat auch nochmal unterschiedliche Punkte. Als letzten größeren Punkt
hier etwas zum Erfahrungsmanagement, wir wollen gern Erfahrungen behalten.
Sie wissen, Erfahrungen sammelt man durch Misserfolge,
aber eigentlich möchte man nicht so viele Misserfolge.
Eigentlich möchte man die Erfahrung ohne Misserfolge vorher
Erfahrungen, also gut übertragen, zum Beispiel bei der Einarbeitung
übertragen von Erfahrungen an neue Mitarbeiter, wie gut funktioniert das?
Ein Projekt hat dann immer gleich eine Checkliste und was muss ein neuer Mitarbeiter können?
Und dieser Mitarbeiter merkt dann, das und das fehlt das,
erkennt sich gleich, der nächste Mitarbeiter kriegt mit dieser Ergänzung.
Das Nächste, was das führt also direkt zu mehr Produktivität,
schnellerer Einarbeitung bedeutet auch schneller produktiv wirken,
das wirkt direkt hier auf die, wo war die Produktivität,
hier genau hier links Ergebnis und Aufwand.
Ja, also da wirkt das
ganz direkt
Der nächste Punkt, Fehlervermeidung,
das ist tatsächlich der größte Beitrag zu Produktivität,
weil wir, und das mache ich hier mal gleich,
schreibe ich das mal hiermit dran, größter Beitrag zu Produktivität.
Weil der, wenn wir etwas dreimal machen,
weil es jedes Mal noch nicht funktioniert hat,
das ist dann etwas, was wir Rework,
heißt das Neue Neudeutsch,
was wirklich
richtig viel Aufwand kostet
Ja, und natürlich hier als letzter Punkt,
das ist auch noch etwas mit Erfahrung zu tun,
Optimierungsgeschwindigkeit gelingt es uns, aus Erfahrungen zu lernen und unsere Organisationen zu verbessern.
Die letzten beiden Punkte habe ich nur hier so mit aufgeführt,
die sind ganz wichtig, aber ich habe sie nicht weiter aufgegliedert, Kundenzufriedenheit und Mitarbeiterzufriedenheit.
Wenn die Kunden nicht zufrieden sind, wandern sie ab.
Es ist viel aufwendiger, einen neuen Kunden zu gewinnen,
als einen Kunden zu halten. Deswegen sollte man versuchen,
die Kunden zu halten. Und bei Mitarbeitern ist es sogar noch schlimmer,
wenn gute Mitarbeiter unsere Firma verlassen, gehen meistens andere gute Mitarbeiter auch noch.
Und wenn sie wenn der Erfahrungsschatz weg ist,
dann ist keiner mehr da, der die Arbeit gut machen kann.
So viel zu Prozessqualität. Ich gehe nochmal eine Folie zurück,
um nochmal zu erklären, eigentlich schafft diese Prozessqualität die Voraussetzung dafür,
dass wir Produktqualität zur Zufriedenheit des Nutzers erreichen können.
Und das waren jetzt einzelne Beispiele. Diese Beispiele gebe ich
Ihnen hier mit als Ansatzpunkt für eigene Arbeit.
Vielleicht arbeitet der eine oder andere von Ihnen mal ein verantwortlicher Position,
als Gruppenleiter, gar als Projektleiter,
dann könnten Sie vielleicht davon dafür nützen haben,
ich werde diese Sachen so nicht in dieser Form abfragen,
vielleicht außer solcher deines allgemeinen Sachen wie Produktivität oder so.
Aber die anderen Sachen sind hier ein bisschen zu speziell.
Soweit damit sind wir am Ende dieses Abschnittes.
Weiter geht's beim nächsten mit Fehlervorpflanzung.
Vielen Dank