Unlängst hatte ich eine interessante Diskussion mit einem Nachbarn, der im Bereich Softwareentwicklung für einen größeren Softwareanbieter arbeitet. Er bestätigte meinen Eindruck, dass die Softwarequalität1 drastisch nachgelassen hat.
Doch woran liegt das? Ich habe da so ein paar Verdachtsmomente.
Spezifikationen
Schaut man sich die Spezifikationen neuer Produkte an, die also die Umsetzung von geplanten Funktionen in die Technik beschreiben, stellt man schnell fest, hier gibt es immer öfter teils gravierende Lücken, die m.E. auf verschiedenen Ursachen basieren.
Funktionsbeschreibungen
Die Beschreibung der Zielfunktionen, die das Produkt umsetzen soll, enthält oft schon nicht alle relevanten Informationen. Zwar werden die Anwendungen für den Nutzer halbwegs2 gut beschrieben, aber bereits bei den Betriebszuständen und den Übergängen zwischen diesen3, sind nach meiner Beobachtung bereits viele Unklarheiten enthalten.
Stellt sich also die Frage nach der Ursache. Stellt sich also die Frage nach der Ursache. Hier gibt es m.E. mehrere Möglichkeiten.
Organisation
Zumindest in der Automotive Welt gab es in den letzten Jahren den Trend, die Funktion von der dahinterstehenden Technik abzutrennen und getrennt zu betrachten. Die Funktion des „Function Owners“ wurde geschaffen.
Die Logik dahinter ist relativ einfach. Immer mehr Funktionen werden fast ausschließlich durch Software umgesetzt, die sich modellbasiert auch noch verhältnismäßig einfach und schnell umsetzen lässt. Der entstehende Code muss dann „nur noch“ in bestehende Steuergeräten zugewiesen4 werden und schon ist eine Funktion implementiert.
Ganz so einfach ist es dann aber doch nicht. Je mehr Funktionen5 auf die gleichen Ressourcen zugreifen, umso schwieriger wird es, das Verhalten des Gesamtsystems zum Schluss vorauszuplanen oder zu verstehen.
Notwendig wäre also eine intensive Abstimmung aller Function Owner, um Überschneidungen von Funktionen oder gar gegeneinander wirkende Software zu erkennen und zu verhindern. Die hierfür notwendige Abstraktion ist aber alles andere als trivial und setzt neben langjähriger Erfahrung auch eine immense Vorstellungskraft für diese Querschnittsfunktion voraus.
Ich bin mir nicht sicher, ob mich mein Eindruck täuscht, gefühlt werden die Function Owner aber auch immer jünger, sodass ein tiefgreifendes Verständnis für die zugrundeliegende Technik und parallel installierten Funktionen nicht einmal vorausgesetzt werden kann.
Trennung Spezifikation von der Umsetzung
Wenn man sich primär mit der Zielfunktionalität beschäftigt und nur noch wenig oder keinen Bezug mehr zur technischen Umsetzung hat, ergeben sich weitere Probleme. So werden die technischen Möglichkeiten der verwendeten Komponenten gern unter- oder überschätzt.
Die Modellierung der Funktion erfolgt nur noch am Computer, ohne die Auswirkungen6 von Parametern der Algorithmen auf den Nutzer zu verstehen. Der Computer sagt auch nicht, welche Parametergrenzen oder Regelgüte für den Nutzer spürbar ist oder zum Wohlbefinden im Fahrzeug beiträgt.
Ebenso schwierig wird es einzuschätzen, wie sehr die Mikroprozessoren in den Steuergeräten an Auslastungsgrenzen kommen oder vom Optimum ihrer Leistungsfähigkeit entfernt sind.
Werden Funktionen als Softwarekomponenten noch selbst entwickelt und dem Technikzulieferer quasi als App7 zur Implementierung bereitgestellt, ist ein Verbesserungsprozess der Modellqualität kaum noch möglich.
Trennung Nutzfunktion von Systemfunktionen
Nicht zu vernachlässigen ist die Trennung der Nutzfunktion für den Endkunden von Systemfunktionen, also den Funktionen, die für den Betrieb der Technik notwendig sind. Hierzu zählen u.a. die Kommunikation zwischen den Steuergeräten8, Warnkonzepte oder die Fahrzeugdiagnose9.
Zwar werden hier durch die Organisationen Querschnittsfachstellen bereitgestellt, die aber dann wiederum nicht tief in der jeweiligen Funktionalität stecken und eher allgemeine Fragen beantworten können.
Wie man sieht, stellt bereits die Organisation einen nicht zu unterschätzenden Risikofaktor dar.
Schnittstellen
Eine Folge der beschriebenen Trennung von Nutzfunktion, Technik und Systemfunktionen ist der Bedarf an definierten Schnittstellen.
Prozessbeschreibungen
Natürlich kann man durch Prozessbeschreibungen hier für eine Linderung sorgen, knirschen wird es immer im Getriebe, wenn thematisch voneinander entfernte Entwickler versuchen müssen, sich zu synchronisieren.
Da helfen auch die Prozessbeschreibungen nur bedingt, da man ja alle denkbaren Abweichungen von Standards berücksichtigen müsste.
Auch ist die Prozessqualität von Erfahrungen abhängig, die derjenige gemacht hat, der die Abläufe definiert. Im Besten Falle handelt es sich hierbei um jemanden, der aus dem Umfeld des beschriebenen Prozesses kommt, also ein Softwareentwickler für Softwareprozesse, Hardwareentwickler für Hardwarebelange usw.
Machen wir uns nichts vor, jemanden aus dem Technikumfeld der auch noch Affinität zu Prozessen hat, dürfte nicht so einfach zu finden sein, gehen hier doch technische und formale Interessen relativ stark auseinander.
Prozessanwendung
Mögen Prozesse noch so gut beschrieben sein, wie mit ihnen umgegangen wird, steht auf einem ganz anderen Blatt. Selbst wenn der Prozessspezifizierer aufgeschrieben hat, wie er oder sie den Prozess verstanden und gemeint hat10, muss das, was der Ausführende daraus gelesen und für sich interpretiert hat, mit der eigentlichen Intension kaum noch etwas zutun haben.
Wird man als Anwender dann noch mit einer Flut an Prozessen überflutet, reduziert man sich ganz schnell wieder „auf den logischen Menschenverstand“ und sein „Bauchgefühl“. Das mag zwar per se nicht schlecht sein, ist aber wieder einmal stark von der Erfahrung des Prozessanwenders abhängig.
Änderungen
Niemand kann zu 100% vorhersagen, wie eine Funktionalität aussehen soll, Änderungen sind also an der Tagesordnung, und was noch viel wichtiger ist, das Kommunizieren der Selbigen.
Natürlich gibt es Prozessbeschreibungen, wie mit Änderungen umzugehen ist. Aber, nachdem Änderungen ihren Einfluss auf Abläufe, Terminpläne, Kosten oder auch technische Konsequenzen hat, muss natürlich jede Änderung getrackt werden, Gremien durchlaufen und auf alle Eventualitäten abgeklopft werden.
Es mag nicht überraschen, dass genau diese Vorgehensweisen nicht nur zeitlich eine Belastung für die Projekte darstellt.
Ich selbst war in nicht wenigen Change Management Diskussionen involviert, in denen ich mir über den (monetären) Nutzen der Meetings Gedanken gemacht habe.
Setzt man nämlich Änderungsumfänge von wenigen Minuten ins Verhältnis zu den Abstimmaufwänden von Stunden oder gar Tagen für mehrere hochbezahlte Personen ins Verhältnis, ergibt sich schnell ein Ungleichgewicht. Zusätzlich muss man auch das menschliche Verhalten berücksichtigen, kleine Probleme gern aufzubauschen, um z.B. Zeitdefizite an anderer Stelle zu kompensieren oder die eigene Bedeutung zu überhöhen. Ich muss also mal wieder meine heißgeliebten „Opportunitätskosten“ bedienen.
Noch intensiver wird der Änderungsprozess, wenn es nicht nur verschiedenen Organisationseinheiten eines Untermehmens betroffen sind, sondern Zulieferer oder deren Sublieferanten. Ein jeder will noch etwas Profit aus der Situation schlagen und sich für überzogene Preisverhandlungen revanchieren.
„Make or Buy“ ist also eine Entscheidung, dessen Ergebnis nur schwer voraussagbar ist.
Zeitplanung
Eigentlich haben wir hier ein typisches Organisationsproblem, die Zeitplanung. Mit steigender Hierarchieebene werden Planungen immer „optimistischer“ und Zeitdefizite immer häufiger verschwiegen. Man will schließlich den Chefs gefallen und seine Zielerreichung11 garantieren.
Die Entwicklungszeiträume werden immer kürzer, obwohl die Komplexität und somit der Entwicklungs- und Testaufwand der Systeme steigt. Wie will man da auch noch vernünftig planen, zumal man weiß, dass sich jeder Planer gewissen Reserven einbaut, ohne aber das Pareto-Prinzip oder Murphys Law zu berücksichtigen.
Ausgetragen werden die entstehenden Reiberein letztlich auf den Rücken der Ausführenden.
Ausführung
Überlässt man die Ausführung für die Umsetzung einer Funktionalität Dritten, hat man kaum noch Einfluss auf das eigentliche Doing, zumindest nicht ohne Gesetze12 zu verletzen.
Druck in Preisverhandlungen führt in der Regel dazu, dass Optimierungen der Umsetzungskosten im Wesentlichen in Personalkosten gesehen werden. Das Einstellen von Rookies ist also durchaus gängige Praxis. Alternativ bietet sich natürlich auch noch das Outsourcing in Niedriglohngebiete an, wobei aber gerne die Schnittstellenverluste ignoriert werden.
„Single Point of Contact“
Eine Methode zur Verringerung von „Störungen oder Unterbrechungen der Entwickler“ durch den Kunden und Vermeidung von Verdachtsmomenten auf Arbeitnehmerüberlassung13 ist die Installation von „Single Points of Contacts“. Es wird also jemand engagiert, der hochkommunikativ zwischen Spezifizierern und Umsetzern Informationen transferiert und gern nebenbei noch die Funktion eines Projektleiters erfüllen soll. Genial, oder?
Ist eigentlich jemandem schon aufgefallen, welche Interessensgebiete jemand haben muss, um bestimmte Berufe zu ergreifen? Da gibt es den MINT14-Anhänger, den Wirtschaftler oder auch den Geisteswissenschaftler. Diese persönlichen Ausrichtungen treten i.d.R. separat auf und nur selten in Personalunion.
Natürlich gibt es den Wirtschaftsingenieur oder auch den hochkommunikativen Ingenieur der nicht dem typischen Bild eines Nerds entspricht. Man kann aber nicht davon ausgehen, dass Mehrfachinteressen vorliegen und Programmierer sich gern mit Projektmanagement beschäftigen, Hardware-Entwickler mit Prozessen usw.
Was ist also die Konsequenz? Der „Single Point of Contact“ mutiert zum Flaschenhals15 entweder auf technischer Seite oder als Projektmanager. Ups.
Spezifikationslücken, Wissenslücken
Gerade für Dritte ist die Umsetzung von Funktionen nur dann möglich, wenn präzise Beschreibungen – sprich Spezifikationen – vorliegen. Und schon haben wir einen Teufelskreis. Ungenaues Spezifizieren führt zur Verlangsamung in der Umsetzung, Änderungsmanagement und somit Zeitverzug.
Kreativität durch Erfahrung
Dass man Kosten auch durch Erfahrung optimieren kann, scheint oft nicht bewusst zu sein. Technische Kreativität und Schnelligkeit in der Abarbeitung von Aufgaben ist nun mal ein positiver Nebeneffekt, wenn man auch auf erfahrene Kollegen setzt. Das Argument, alte Hunde lernen keine neuen Tricks ist natürlich auch nicht ganz von der Hand zu weisen, ein heterogenes Team in Können und Erfahrung wäre also ein guter Kompromiss.
Qualität
Qualität ist – wem ist es wirklich klar – den Erwartungen des Kunden gerecht zu werden. Und schon wird es kniffelig. Was sind tatsächlich die Erwartungen des Kunden? Saubere Umsetzung der Technik? Komplette Dokumentation? Einhaltung aller Schnittstellen?
Die Qualitätserwartung des Kunden sollte also geklärt sein, damit im Nachhinein keine Diskussionen aufkommen.
Quintessenz
Dass die Erwartungshaltungen der Nutzer von Funktionen immer öfter nicht vollumfänglich getroffen werden – sprich „schlechte Qualität“ – ist also eine logische Konsequenz aus verschiedenen Entwicklungen in der Organisationsstruktur von Unternehmen. Die Vergabe von Entwicklungen an Dritte führt – opportunitätskostenbereinigt – nur selten wirklich zu Einsparungen.
Zu berücksichtigende Opportunitätskosten wären u.a.:
- Mehraufwand Spezifikationsgüte für externe Vergabe
- organisatorischer Mehraufwand für
- Change Management
- Suppliermanagement
- zusätzliche Kontrollgremien
- Abstimmaufwände
- zusätzliche Entwicklungszeiten durch organisatorische Reibungen
- Einarbeitungsaufwände für Wechsel von Zulieferern
- IT-Schnittstellen
Falls es jetzt so rüberkommt, dass ich gegen Ingenieursdienstleistungen bin, dem ist mitnichten so. Es sollte nur differenziert und mit klarem Verständnis über Vor- und Nachteile geschehen.
Für die allgemeine Abarbeitung von Entwicklungen dürfte das Zünglein an der Waage eher zugunsten interner Tätigkeiten ausfallen. Für Querschnittsaufgaben, die zusätzlich einen hohen Mehrwert durch spezifische Erfahrungen generieren, sind externe Vergaben eher ein Gewinn.