Welche Metriken beschreiben die Qualität von Software Dienstleistern am besten? - Cape Of Good Code

Die qualifizierte Auswahl von Softwareentwicklungsdienstleistern ist von hoher strategischer Bedeutung. Anhand eines modifizierten PDCA Zyklus (Plan-Do-Check-Act nach Deming) gehen wir darauf ein, was der Einkauf als einzelne Phasen der kontinuierlichen Lieferantenanalyse (Specify-Qualify-Monitor-Revise) tun kann und tun sollte.

Wie im ersten Blog (Warum braucht der Einkauf von Individualsoftware neue Kriterien bei der Lieferantenqualifikation?) für den Einkauf von nach Vorgabe gefertigter Software dargelegt, ist die Lieferantenqualifizierung von Softwaredienstleistern komplex. Es geht für den Einkauf bei der Lieferantenwahl darum, die relative Sicherheit zu haben, dass dieser die benötigten Software Entwicklungen für die eigene Digitalisierungsroadmap  am besten entwickeln und betreuen kann. Bei Software heißt das, dass die Codebasis für viele Jahre und im Launch-Rhythmus der eigenen Produkt-Upgrades mit normalem Aufwand an die neuen Anforderungen angepasst werden kann.

Es ist klar, dass letztlich viele Fachabteilungen in einer Lieferantenbeziehung mit einem Software-Dienstleister beteiligt sind. Wir haben unsere Betrachtung in dieser Blogserie aber auf den Einkauf gelegt, um zu zeigen, wie wichtig Spezialkenntnisse rund um die Technologie von Software auch im Einkauf sind. Nur so können Risiken für das Unternehmen im gesamten Software Lifecycle minimiert werden.

Die Festlegung, welche Eigenschaften und Parameter bei Software die bestimmenden und beschreibenden Größen für die Qualität und Skalierbarkeit der Software und des Software-Engineerings sind, ist nicht trivial.

Wir bei Cape of Good Code nutzen dabei einen modifizierten PDCA Zyklus (Plan-Do-Check-Act Methodik nach Deming), der sich in der Qualitätssicherung in vielen Industrien seit Jahrzehnten bewährt hat. In unserem Fall sind es die für die Entwicklung von Software adaptierten Phasen: Specify-Qualify-Monitor-Revise.

Bild 1: Zyklus der Cape of Good Code Lieferantenanalyse von Software-Dienstleistern in enger Zusammenarbeit mit der Entwicklung, QS und dem Einkauf

Cape of Good Code hat für jede Phase dieses bei jeder Iteration wiederkehrenden Zykluses einen Katalog von Fragestellungen entwickelt, die von jedem (potentiellen) Entwicklungspartner beantwortet werden müssen. Die vergleichende Auswertung bestimmt dann, welcher Anbieter aus technologischer Sicht (!) der richtige Lieferant wäre. Natürlich gibt es in jeder dieser Phasen, eine Vielzahl weiterer Fragen und Kriterien aus den Fachabteilungen (Bsp. Bonität, Preis, Lieferzeit), die für sich genommen auch jeweils ein No-Go bedeuten können.

Unser Analysezyklus sollte mit jeder neuen Softwarelieferung (Iteration) zum Einsatz kommen, wobei die Fragen zur Qualify-Phase sich im weiteren Lifecycle auf die Prüfung der Qualifikation des Projektteams beschränken können. In einer jahrelangen Zusammenarbeit zu einem unter Innovationsdruck stehendem Produkt wie Software ist es elementar, in dieser Zeit auch die relevanten Fähigkeiten des Lieferanten immer wieder zu vermessen.

Der Fokus der Cape of Good Code Lieferantenanalyse ist die Technologie und das Software-Engineering. Für die einzelnen Phasen der kontinuierlichen Lieferantenanalyse sind im Folgenden beispielhaft einige Themen gelistet:

Specify: Festlegung der Anforderung an die Software durch den Auftraggeber

• Nach welchen Testkriterien sollen die Ergebnisse eines Updates abgenommen werden?
• Nach welchen KPIs soll die Qualität der Softwarelieferungen und das Software-Engineering bewertet werden?
• Welchem Detaillierungsgrad können und sollen die eigenen Spezifikationen entsprechen? Müssen diese hinreichend fix sein oder sind gewisse Freiheitsgrade erlaubt, die erst zum Ausführungszeitpunkt ausgestaltet werden können?
• Für welche software-abhängigen Eigenschaften der eigenen Entwicklung werden die meisten Änderungen während der Entwicklungszeit erwartet?
• Was ist der früheste und was der späteste Zeitpunkt zur Beauftragung der Softwareentwicklung (Eindeutigkeit der Specs vs. Dauer der Entwicklung)?

Qualify: Tool- und Interview-basierte Qualifizierung/Auswahl von Lieferanten 

• Werden die richtigen Software Tools eingesetzt, um die Qualität der Entwicklungsergebnisse messen  zu können?
• Wie hoch ist die übliche Entwicklungseffizienz des Anbieters?
• Ist der Projektplan sinnvoll synchronisiert mit dem eigenen Projektplan?
• Wie hoch ist die Auslastung und der Skill Level der benötigten Entwickler?
• Wie werden die Off- oder Nearshore Entwicklerteams eingebunden?
• Ist der Lieferant bei Kapazitätsspitzen in der Lage weitere qualifizierte Entwickler einzubinden?
• Welches Feedback kann man von vorherigen Kunden des Lieferanten einholen?

Monitor: Toolbasierte Prüfung der Lieferungen nach jedem Update

• Wie hoch sind die Technischen Schulden der Software hinsichtlich Architektur- und Code-Qualität?
• Wie aufwändig ist es neue Features der Software zu entwickeln?
• Ist das Knowhow für diese Software weiterhin sinnvoll im Projektteam verteilt (d.h. bestehen einseitige Abhängigkeiten) und wie nützlich ist die Dokumentation?
• Wie effektiv werden Tests zur frühen Fehlerfindung eingesetzt?
• Welche Technischen Schulden müssen priorisiert und mit welchem prognostizierten Aufwand reduziert werden?

Revise: Strukturierte Behebung der Probleme

• Wie ist eine Verbesserungsroadmap mit KPIs zur Software und dem Software-Engineering aufzustellen?
• Wie werden Budgets und Verantwortlichkeiten bestimmt, um den Entwicklungsaufwand für Wartung und Technische Schulden auf den Standard von ca. 20% zu bringen?
• An welchen relevanten Stellen sollen Dokumentation und Tests der Software nachgezogen werden?
• Wie muss man die Wissenverteilung im Projekt optimieren, junge Entwickler strukturiert einarbeiten bzw. Senior-Entwickler effizienter einsetzen?
• Welche einseitigen Abhängigkeiten von Entwicklern und Lieferanten müssen eventuell abgebaut werden?

Im Folgenden seien zusammenfassend einige empfehlenswerte KPIs aufgeführt, die sich unserer Erfahrung nach als relevant herausgestellt haben: