07.10.2024 / in Aus der Entwicklung
Da ich mehrere positive Rückmeldungen sowie einige Fragen zu meinem Vortrag erhalten habe, möchte ich die wichtigsten Punkte in diesem Blogbeitrag zusammenfassen.
Qualitätssicherung ist ein “fades” Thema, etwas, womit man sich nicht gerne beschäftigt. Neue Features und Verkaufszahlen sind viel interessanter.
Viel spannender wären daher Vorträge zu folgenden Themen:
Wie gewinne ich neue Kunden?
Wie senke ich die Entwicklungskosten um 30 %?
40 % schnellerer Entwicklungsprozess!
Das Interessante dabei ist, dass es einen unmittelbaren Zusammenhang mit der Qualitätssicherung gibt!
Um das zu verdeutlichen, sehen wir uns einmal den Entwicklungsprozess an.
Neukundengewinnung, Entwicklungskosten senken und ein schnellerer Entwicklungsprozess durch Qualitätssicherung.
In unserem Beispiel wollen wir ein kleineres neues Feature für unser Produkt entwickeln.
Es soll eine Anbindung an ein KI-Tool durchgeführt werden.
Im Prinzip ist es einfach, es geht nur um die Verwendung eines vorhandenen APIs für den Datenaustausch zwischen dem Dokumentenmanagement und dem KI-Tool.
Der/die Entwickler:in schätzt den Aufwand dafür auf 3 Tage -> damit starten wir die Planung. Es ist ein(e) erfahrener(e) Entwickler:in, also wird der Aufwand nicht wesentlich überschritten werden.
Soweit die Annahme!
Die Entwicklungsleitung weiß, dass die Auslastung einer Entwicklungsressource bei maximal 75% sein kann, der Rest geht für E-Mail, Meetings usw. drauf.
Somit ist die Dauer für die Durchführung der API-Anbindung nicht 3 Tage, sondern 4 Tage.
Nach 4 Tagen kommt die Funktion zur Modul-Prüfung in die Qualitätsabteilung.
Der/die QA-Tester:in muss verstehen, was die Funktion macht und wie sie angewendet wird => Aufwand1.
Dann muss getestet werden => Aufwand 2
Es tritt ein Fehler auf z.B. es ist nicht geregelt, was passiert, wenn die KI-Anbindung nicht erreichbar ist.
Der oder die Entwickler:in hat eine einfache technische Fehlermeldung vorgesehen, aber was signalisiert man dem Anwender?
Ein Time-out nach x Minuten mit dem Hinweis “Zeitüberschreitung”?
Das ist nicht gut, da braucht man etwas Besseres.
Beschreibung des Problems damit der/die Entwickler:in weiß was verbessert gehört => Aufwand 3
Die Projektleitung geht alle aufgetretenen Probleme durch und priorisiert sie => Aufwand 4.
Unser obiges Problem wird als wichtig erachtet und muss somit behoben werden.
Es wird wieder dem/der Entwickler:in zugeordnet und der Fehler wird behoben => Aufwand 5.
Der Gesamtaufwand für diesen Durchlauf ist sicherlich 1 Tag - die Dauer wird vermutlich länger sein, da Testen, Priorisieren und Fixen nicht unmittelbar hintereinander gemacht werden.
Wir rechnen einfacherweise mit 1 Tag Gesamtaufwand weiter.
Üblicherweise treten ca. 3-4 Probleme beim Testen pro Modul/Funktion auf die behoben werden müssen, also 3-4 Tage Zusatzaufwand.
In Summe wurden somit aus den 3 Tagen Aufwand, den der/die Entwickler:in geschätzt hat, 6-7 Tage.
Eine Überschreitung von >130%, ohne dass die ursprüngliche Aufwandsschätzung von 3 Tagen grundsätzlich falsch war.
Damit ist unser Entwicklungsprozess deutlich länger als gedacht!
Analog ist die Rechnung bezüglich der Entwicklungskosten.
Wenn wir die Kosten für den/die Entwickler:in mit 100 % annehmen, für eine/n QA-Mitarbeiter:in mit 80% und für die Projektleitung mit 120% sieht man sofort, dass die Entwicklungskosten > 30% höher sind.
Das Ganze ist noch sehr “günstig”, weil wir alle Probleme In-House, d.h. noch vor der Auslieferung zum Kunden abgefangen haben.
Wie hoch die Kosten sind, wenn das Problem erst beim Kunden auftritt, ist eine Hausaufgabe - aber sie sind so hoch, dass es klar wird, dass man die Qualitätssicherung nicht einfach als eine Teilaufgabe der IT/Entwicklungsabteilung betrachten kann.
Qualitätssicherung ist ein Thema für die Geschäftsführung
Tritt das Problem beim Kunden auf, ist auch das Neukundengeschäft gefährdet. Mundpropaganda spielt immer eine große Rolle (zumindest bei uns). Wenn ein potenzieller Neukunde bei einem Bestandskunden nachfragt, wie zufrieden er mit dem Produkt ist dann wäre eine Antwort in der Art “Ja, jetzt passt alles, aber die ersten 2 Monate hatten wir nur Probleme” ein Showstopper.
Die Auslagerung der Qualitätssicherung an den Kunden mag bei der App-Entwicklung oder bei einem reinen Cloud-Services noch ein möglicher und vom Kunden akzeptierter Weg sein, den man mit Marketingmaßnahmen kaschieren kann, aber wenn man so wie wir Produkte (egal ob Software oder Hardware) ausliefert, ist diese Methode fatal.
Um das zu verbessern, muss die Qualitätssicherung in den gesamten Entwicklungsprozess eingebunden werden.
Aber wie schaut eigentlich der gesamte Prozess von der Auftragsakquise bis zur Anwendung durch den Kunden aus?
Auftragsakquise
Schauen wir uns dazu einen vereinfachten Auftragsprozess an!
Wie läuft dieser ab?
1. Ein Kunde schickt ein Anforderungsdokument oder es gibt ein Ausschreibungsdokument, das mehr oder weniger genau die gewünschte Lösung beschreibt.
2. Der Vertrieb erstellt dazu das passende Angebot. Bei technischen Fragen hält er Rücksprache mit der Entwicklungsabteilung.
3. Das Angebot wird angenommen und es startet die Umsetzung.
Wie sieht jetzt die Auftragsbearbeitung aus?
(Wieder vereinfacht)
Auftragsbearbeitung
Die Kolleg:innen in der Professional Service Abteilung oder Entwicklungsabteilung sehen sich das Anforderungsdokument an, machen ein Design und starten mit der Entwicklung.
Wenn sie damit fertig sind, wird die Lösung getestet und dann beim Kunden termingerecht und zu den vereinbarten Kosten installiert.
Ab jetzt beginnt der Einsatz und das Produkt wird hoffentlich weiter gewartet.
Einschub: Qualitätssicherung im Unterschied zur Qualitätskontrolle
Ein kleiner Einschub mit einer Definition.
Die Qualitätssicherung beinhaltet alle notwendigen Maßnahmen und Methoden zur Sicherstellung der gewünschten Qualität.
Die Qualitätskontrolle wird häufig am Ende des Entwicklungsprozesses gemacht, um zu prüfen, ob die Software den Anforderungen entspricht.
Vereinfacht formuliert die Qualitätskontrolle, prüft mittels Statistik Antwortzeiten, Eingabemöglichkeiten, Dicke, Länge usw…
Um eine deutliche Verbesserung d. h. Senkung der Entwicklungskosten und schnellere Entwicklung zu erreichen, müssen wir den gesamten Prozess betrachten und nicht nur die Qualitätskontrolle am Ende.
Wie sieht jetzt der gesamte Prozess für einen Auftrag aus?
Wasserfall oder AGIL?
Sehen wir uns dazu noch einmal den ganzen Prozess der Auftragsbearbeitung an.
Der Übergang von einer “Stufe” zur nächsten also von der Implementierung zum Test usw. sieht aus und ist ein klassisches Wasserfallmodell.
Aber wir wollen “agil” arbeiten.
Durch den Auftrag sind aber schon das Budget und der Lieferzeitraum festgelegt. Das sind zwei wesentliche Projektkriterien!
Wo können wir überhaupt agil arbeiten?
Welche Möglichkeiten gibt es?
Welche Teile des Anforderungsdokuments setzt man in einem Sprint um, wofür macht man einen Prototyp?
Eigentlich nur in den “inneren” Stufen der Auftragsbearbeitung gibt es die Chance, agil zu arbeiten.
Wieder ein Einschub - das Teufelsquadrat nach Harry Sneed
Teufelsquadrat
Qualität, Quantität, Dauer und Kosten spannen ein Quadrat auf. Die Fläche des Quadrats steht für die Produktivität.
Die Produktivität ist fix, man kann nicht einfach die Produktivität des Teams steigern.
Wenn man jetzt an einer Ecke “zieht”, also eine Komponente verändert, verschieben sich die anderen Ecken automatisch.
Eine Erhöhung von Qualität oder die Verringerung der Entwicklungsdauer geht nur, wenn man die Quantität (Anzahl der Features) reduziert und/oder das Budget (z. B. mehr Personen beauftragt) erhöht.
Zwei Verbesserungsvorschläge - Tipps
1. Das Anforderungsdokument auch mit QS abstimmen.
Bei uns hat es sich bewährt, jemanden vom Dokumentationsteam zur Analyse/Bewertung des Anforderungsdokuments einzubinden.
Warum hat sich das bewährt?
Aufschreiben zwingt einen, sich genau damit zu befassen, man sieht Schwachstellen. Die Dokumentation muss am Ende die fertige Funktion im Detail beschreiben. Wenn es bereits zu Beginn der Entwicklung klar verständlich ist, kann man es auch umsetzen.
Alternativ ist es gut, jemanden aus dem Usability-Team zusätzlich zu integrieren. Gut und verständlich beschrieben ist wichtig, aber wenn es nicht sinnvoll anwendbar ist, hilft es am Ende auch nicht.
Auftraggeber mögen es meist nicht, wenn jemand von der Dokumentation integriert wird. Man muss es erklären. Der Auftraggeber meint, seine Anforderungsdokumentation wäre ja schon die Dokumentation.
Deshalb hat es sich bewährt, das Dokumentationsteammitglied als Requirements Engineer zu integrieren.
2. Den Product Owner stärken
Der Product Owner sollte nicht der Projektleiter sein. Ein Projektleiter achtet primär genau auf die zeitliche Abarbeitung der Aufgaben.
Der Schwerpunkt beim Product Owner ist die Anwendbarkeit des Produkts aus Sicht des späteren Anwenders. Das Produkt muss sinnvoll und so einfach wie möglich anwendbar sein. Es hilft nicht, wenn es rechtzeitig und im Kostenrahmen erstellt wurde und dann von niemanden verwendet wird.
Insbesondere neue Produkte und innovative Erweiterungen können sich nur durchsetzen, wenn sie einfach anwendbar und nützlich sind.
Ein Beispiel aus unserer Praxis für einen vollständig funktionierenden Dialog, der aber nicht sinnvoll anwendbar war.
Der folgende Dialog wurde getestet, jede Checkbox, jedes Feld funktionierte einwandfrei!
Die Anwender sind bezüglich der Usability verwirrt, was bedeutet es, wenn ein Feld leer ist oder wenn “[Leer]” im Feld steht?
Wo ist da der Unterschied?
Die Auflösung auf diese Frage:
Es gibt keinen Unterschied, es wurde das Feld zu unterschiedlichen Zeitpunkten von unterschiedlichen Entwickler:innen implementiert und jede/jeder hatte seine Präferenz für die Darstellung von “leer”.
Auf Wunsch von Spezialisten (Profi-Anwender) wurde auch eine Checkbox zur Einstellung der ETags-cache Kontrolle integriert. 99% der Anwender wissen nicht, was diese Checkbox bewirkt, wissen Sie es?
Auflösung: Der Server sendet an den Client (Browser) ein E-Tag für das spezielle Objekt (z.B: ein Bild), eine Markierung um das Element eindeutig zu identifizieren.
Will der Browser das Element mit dem E-Tag noch einmal verwenden (wieder anzeigen), fragt er beim Server nach, ob sich das Element geändert hat. Bei jeder Änderung des Elements wird vom Server ein neues E-Tag vergeben. Der Vorteil: Gibt es keine Veränderung, braucht nur das E-Tag transferiert und verglichen werden und nicht ein umfangreiches Bild oder ein Video. Das Datenvolumen ist kleiner und damit lädt die Seite schneller.
Jetzt betrachten wir das Feld “Caching”, es hat 3 spezielle und einen leeren Eintrag. Wer weiß, welcher Eintrag der Richtige ist.
Die Antwort ist, kommt darauf an!
Nur wissen das die Anwender?
Die Entwickler gehen oft davon aus, dass niemand auf einen Knopf drückt, den er nicht kennt. Das ist aber grundsätzlich falsch. Es wird einfach alles ausprobiert und dabei sind Einstellungen, die Auswirkungen auf andere Stellen oder zu einem späteren Zeitpunkt haben, fatal.
In obigem Beispiel bedeutet “Öffentlich”, die aktuelle Seite wird am Client, d. h. im Browser am Notebook der Anwender:in gespeichert und erst wieder aktualisiert, wenn die Cache-Lebenszeit abgelaufen ist.
Das passt gut für statische Elemente wie z. B. ein Firmenlogo. Es ist aber ganz fatal, wenn man, wichtige Seiten die häufig upgedatet werden mit dieser Cache-Einstellung versieht, weil man meint, die Information ist für die Öffentlichkeit bestimmt.
In unserem Beispiel wurde eine Seite für Alarmmeldungen mit der Cache-Einstellung “öffentlich” und der Cache-Lebenszeit “2 Tage” versehen und die Anwender:innen haben sich gewundert, warum die Seite nicht die neuesten, dringendsten und wichtigsten Meldungen anzeigt.
Der Browser hatte die Seite im Cache und fragte während der eingestellten Cache-Lebenszeit gar nicht mehr beim Server nach, ob es etwas Neues gibt.
Ein fataler Fehler! Die wichtigen Meldungen kamen nicht bis zu den Anwendern, ausgelöst durch eine kleine Einstellungsunstimmigkeit.
Nicht-funktionale Anforderungen sind, wie man sieht, oft entscheidend, aber schwer zu testen.
Der Product Owner muss immer genau im Blick haben, was er erlaubt, damit die AnwenderInnen das machen können, was sie wollen?
Ein weiterer Verbesserungsvorschlag:
“Das Beste, was Sie für die Qualitätssicherung tun können, ist, die eigenen Mitarbeiter zu AnwenderInnen zu machen.”
Wenn man das Produkt selber verwendet, versteht man die impliziten Anforderungen besser. Etwaige Unstimmigkeiten und Fragen, die sich während der Entwicklung ergeben, werden selbst logisch richtig gelöst.
Und wenn etwas nicht gut funktioniert, es den Anwender “nervt”, geht der/die Kollege:in direkt zum/zur Entwickler:in und der/die behebt es sofort. Noch besser ist es, wenn die Entwickler:innen bei der Anwendung selber bemerken, was unstimmig ist.
Qualitätsvision
Produktqualität oder Prozessqualität?
Wenn es mit der Qualität bzw. dem Projektablauf Probleme gibt, wird häufig ein Consultant zurate gezogen.
Ein Consultant macht dann zumeist einen Vorschlag, wie die Vorgehensweise verbessert werden muss.
Welches Modell zum Tragen kommt, d. h. das was er vorschlägt, hängt häufig vom aktuellen Trend ab. Six Sigma, Rational Unified Modell, XP-Programmring, Kanban, Scrum, um nur ein paar zu nennen.
Es stimmt, ein guter Prozess ist eine Voraussetzung für ein gutes Produkt, aber das reicht nicht.
Wirklich entscheidend ist die Produkt-/Qualitätsvision.
Wofür ist das Produkt gedacht, welches Problem soll es beheben, welche Innovation ermöglichen?
Das best funktionierende Produkt wird nicht verwendet, wenn es nicht gebraucht wird.
Also gehört zur Qualitätsvision der Anwendungszweck. Der muss passen, alles andere folgt danach.
Was bedeutet Qualität für uns?
Ganz klar, wie vermutlich bei jedem Hersteller steht die Kundenzufriedenheit an erster Stelle!
Der Kunde ist zufrieden, wenn man genau das liefert, was er haben möchte.
Vereinfacht formuliert “Wir spielen, was sie hören wollen”!
So einfach ist es aber nicht, es gibt entscheidende Sachzwänge, Rahmenbedingungen und vorausschauende Entwicklungen, die man unbedingt berücksichtigen muss und die noch höher als die Kundenwünsche zu werten sind.
Welche Sachzwänge sind das?
Kosten - Die Anwender wünschen sich etwas, aber es ist klar, dass das Budget nicht für die Umsetzung aller Wünsche reicht
Termine - Oft gibt es im Unternehmen globale Termine, die Updates oder die Installation von neuen Lösungen verhindert. Das können definierte frozen Zones, Ausrollen von neuer Hardware oder generell die Verfügbarkeit von IT-Unterstützung sein.
Diese beiden Sachzwänge muss man immer berücksichtigen.
Tödliche Kundenwünsche - Ja, die gibt es auch!
Das sind Anforderungen, die einem als Hersteller auf Dauer das “Genick brechen”!
Kundenwunsch 1: Änderungen sind nicht erwünscht
Warum ist dieser Kundenwunsch tödlich?
Die aktuelle Lösung wird als veraltet angesehen und durch ein anderes Produkt ersetzt.
Man muss mit der Zeit gehen. Neuerungen, bedingt durch technische Veränderungen oder neue Trends, müssen von Zeit zu Zeit in das Produkt einfließen.
Kundenwunsch 2: Änderung ja aber mit Flexibilität
Aber nach 3-5 Jahren hat man so viele zusätzliche Schalter und Optionen eingebaut, die sich zum Teil widersprechen, dass man nicht mehr zielführend testen kann und bei Meldungen von Problemen gar nicht weiß, welche Einstellung beim Kunden gerade aktiv ist
Frankenstein lässt grüßen. Das Stückwerk ist dann einfach nicht mehr wartbar.
Zusammenfassung
Was braucht man für eine funktionierende Qualitätssicherung?
Und wichtig, um diese Punkte zu berücksichtigen, braucht es MUT der Entscheider. Es ist oft sehr verlockend, eine Entscheidung auf den Kunden abzuwälzen. Der Kunde erzeugt Autos, Schuhe, Kabel, Bankprodukte oder verkauft Dienstleistungen. Bei allen seinen Produkten und Dienstleistungen hat er die richtige Produktvision, aber bei dem Produkt, was wir ihm liefern, müssen wir die bessere Produktvision haben, es ist ja unser Kernthema.
Vielen Dank, wenn Sie bis hier her gelesen haben.
Ich hoffe, es waren ein paar interessante Denkanstöße dabei oder Punkte bei denen sie mir komplett widersprechen.
In beiden Fällen freue ich mich über eine Nachricht: peter.luttenberger@hyperwave.com