Zengarten durch ein Tempeltor gesehen

Paradoxe der Produktentwicklung

Lesezeit 6 min

Ein Paradox ist eine oft überspitzte, absurde und scheinbar widersprüchliche Aussage. Diese widersprüchliche Aussage kann jedoch zu neuen Einsichten führen. Ich glaube, dass wir in der embedded Produktentwicklung ein paar interessante Paradoxe berücksichtigen sollten.

Ist das Offensichtliche immer das Richtige?

Es gibt diese Ideen in der Produktentwicklung, v.a. in der Softwareentwicklung, welche sich bei genauer Betrachtung in ihr Gegenteil verkehren:

Wie diese Widersprüche in praktischen Fällen auftreten, und wie sie sich auflösen lassen, lesen Sie hier:

Paradox 1: Wenn Sie schneller entwickeln wollen, nehmen Sie sich mehr Zeit

...mehr Zeit für die Spezifikation und die Findung der passenden technischen Lösung (der "Architektur").

Eine kurze Geschichte

welche das illustriert. "Hilfe, die Norm tritt Ende Jahr in Kraft... Und keine unserer 12 Steuerungen erfüllt die neuen Anforderungen." Wir haben dann insgesamt vier (4) Monate in die Spezifikation investiert, zuerst zwei Monate bis wir eine optimale technische Lösung und noch vier Steuerungsvarianten hatten. Dann noch je einen Monat mit dem Produkt-Management, um je eine Steuerungsvariante zu kippen.

In dieser Zeit entstanden sehr klare und ausführliche Spezifikationen und eine klare Architektur, welche den Konsens mit Produktmanagement, Mechanik und Produktion dokumentierte. Die verbliebenen zwei Varianten konnten wir dann innert sechs (6) Monaten fristgerecht per Ende Jahr zur Produktionsreife bringen. Und übrigens: die Steuerungen werden auch heute, nach dreizehn Jahren, noch ohne wesentliche Änderungen produziert.

Was passiert, wenn man schnell startet?

Wenn man mit einer Produktentwicklung basierend auf unklaren Anforderungen startet, dann hat das in der embedded Entwicklung den Nachteil, dass in der Auswahl des Prozessors, des Betriebssystems, der Schnittstellen etc. von den Entwicklern Annahmen getroffen werden müssen. Wenn diese sich dann im Laufe der Klarstellung der Anforderungen als falsch erweisen, z.B. der Prozessor zu schwach ist, dann ergibt sich ein grosser Aufwand für ein Redesign oder für die Entwicklung um technischen "Fehlentscheide" herum. 

Und was ist mit agil?

Die agilen Prozesse und Arbeitsweisen des Erzeugens von Spezifikationen während des Projektes lösen meist nicht die Probleme und können die Risiken erhöhen.

Fazit

Die schnelle und reibungslose Entwicklung muss mit einer frühzeitigen Klärung der Anforderungen erkauft werden.

Paradox 2: Wenn Sie billiger entwickeln wollen, nehmen Sie den höheren Stundensatz

...wie auch Ihre qualitativ hochstehenden Produkte nicht die billigsten sind, sind qualitativ hochstehende Ingenieure nicht die billigsten.

Eine kurze Geschichte

Ein Kunde hat die Software für eine graphische Bedienoberfläche als Near-Shoring Auftrag iterativ/ "agil" vergeben. Die Software hatte ausser dem visuellen Design exakt die gleiche Funktionen wie die Oberfläche, die wir für eine andere Plattform zum Fixpreis entwickelten. Diese Near-Shoring Entwicklung wurde zuerst massiv günstiger abgeschätzt.

Zwei Jahre nach Produktionsstart meinte der CTO des Kunden: "Eine grafische Bediensoftware kostet überall gleichviel". Die Kosten für beide Entwicklungen waren nach allen Änderungen im Near-Shoring Projekt gleich gross. Und nicht einmal nur gleich: unsere Entwicklung umfasste zusätzlich die gesamte Elektronik und Ablaufsteuerung, die graphische Oberfläche machte nur 60% der "gleich grossen" Entwicklungskosten aus.

Was passiert, wenn man nur auf den Stundensatz schaut?

Für eine erste Iteration wird ein einfacher Fall abgeschätzt, aus Unwissen oder um niedrigen Aufwand auszuweisen, damit man mit der Entwicklung starten kann. Dann werden die unreifen Anforderungen an unerfahrene Entwickler vergeben, die nach bestem Wissen und Gewissen die Anforderungen erfüllen. Die Nachfolgenden iterativen Änderungen und Beseitigung von Missverständnissen fressen den gesamten Kostenvorteil wieder auf.

Fazit

Die Einsparungen, die sich über die Entwicklung und die gesamte Produktlebensdauer aus der Erfahrung der Ingenieure, aus klaren, gelebten Prozessen und aus kontinuierlichen Schulungen ergeben, müssen mit einem erhöhten Stundensatz erkauft werden.

Paradox 3: Wenn es funktioniert, beginnt erst die Arbeit

...denn dann kommen die nicht-funktionalen Anforderungen und Regulierungen auf Sie zu.

Eine kurze Geschichte

Ein Forschungsteam hatte jahrelang an einem Sensor entwickelt, bis er genau funktionierte. Die Ansteuerung und Auswertung basierte entweder auf einem Rack voll Quellen und Auswertegeräten oder dann auf einem integrierten Baustein, welcher einerseits veraltet und zu wenig leistungsfähig war, andererseits keine aktuellen Schnittstellen nach aussen bot.

In einem Startup sollte der Sensor dann für die Prozessindustrie kommerzialisiert werden. Da er "schon lief", war kein signifikantes Budget für die Entwicklung einer Ansteuerung geplant, welche die Anforderungen einer industriellen Umgebung an Zuverlässigkeit, Sicherheit und Schnittstellen erfüllte. Anstatt auf dem Markt einzuschlagen, dauerte es mehrere Jahre bis in ein paar wenigen Industrien einige Kunden gewonnen werden konnten.

Wenn ein Gerät funktioniert, dann beginnt erst der Aufwand, vor allem, wenn noch funktionale Sicherheit (z.B. die Maschinenrichlinie) beachtet werden muss, der Innovations-Pareto schlägt zu.

Fazit

Weniger Redesigns in der Produktentwicklung müssen erkauft werden mit einer frühzeitigen Berücksichtigung von Kundenanforderungen (Schnittstellen, Bedienung, Umgebungsbedingungen...) und vor allem von Vorschriften.

Um ein klares Bild vom Restaufwand nachdem "es funktioniert" zu bekommen, muss die Entwicklung für die Kundenforderungen und Gesetze und Normen (Sicherheit, funktionale Sicherheit, Datensicherheit...) realistisch geplant werden.

Paradox 4: Wenn Sie technische Probleme haben, lösen Sie die menschlichen

...denn viele technischen Probleme sind Kommunikationsprobleme

Eine kurze Geschichte

Für ein Kunde sollten wir eine Software für ein Funk-Kommunikationssystem an die neue Hardware und an die Anforderungen des Kunden anpassen. Der Aufwand und der Zeitplan des Projektes explodierte wegen den vielen technischen Problemen. Wirklich? Die Software-Gruppe redete nur ungern mit den Hardware-Ingenieuren, "denen auf der anderen Seite des Ganges". Und schon gar nicht mit der Hochfrequenzgruppe, die sich ihrerseits vom externen Lieferanten des Sende-/ Empfangsmoduls brüskiert sah.

Am Schluss war der externe Entwicklungspartner die Drehscheibe aller Information und die "technischen" Probleme konnten ziemlich schnell gelöst werden. Denn der externe Partner übernahm als "Drehscheibe" auch die Verantwortung für die Kommunikation zwischen den Silos und zwischen den technischen Spezialisten.

Dazu passt das Zitat von Gerald Weinberg: "No matter how it looks at first, it's always a people problem" oder ein Bonmot bei meinem ersten Arbeitgeber: "There are not technical, only human problems". Natürlich gibt es auch echte technische Probleme, diejenigen in der Produktentwicklung sind jedoch in meiner Erfahrung meist vom menschlichen Typ.

Fazit

Technische Probleme, die Projekte verzögern sind häufig Schnittstellen-Probleme, d.h. Probleme zwischen Menschen, Gruppen und Kulturen, auch innerhalb derselben Organisation. Effiziente Projekte müssen damit erkauft werden, dass zuerst Zeit und Energie darin investiert werden muss, die Menschen zusammenzubringen.

Paradox 5: Wenn Sie Hardware entwickeln, fragen Sie die Software-Ingenieure

...denn die Anforderungen an die Hardware werden hauptsächlich von der Software bestimmt.

Eine kurze Geschichte

Eine Vorentwicklungsabteilung hatte ein Funktionsmuster entwickelt. Sinnvollerweise hatte sie dazu als Sicherheit viele Bauteile überdimensioniert. Der Wandler war zehnmal zu schnell und viermal zu genau, der Prozessor hatte mehrere Kerne, es hatte Speicher im Überfluss. Das Funktionsmuster lief zur vollen Zufriedenheit, also wurde ein Produktentwicklungsprojekt aufgesetzt.

In der Produktentwicklung wurde diese "gute" Hardware einfach übernommen, es funktionierte ja im Funktionsmuster. Nur stellte sich dann heraus, dass die Software nur einen Kern brauchte. Dass vom Wandler nicht die ganze Auflösung ausgewertet wurde, und auch das nur bei einem Bruchteil der Abtastrate. Im Gegenzug fehlten mehrere Features für Datensicherheit (Security) und der Speicher, der "nicht auf das Layout passte".

Fazit

Obschon es offensichtlich scheint, ist es immer wieder ein Problem: Sprechen sie als Hardware- und Software-Entwickler miteinander, definieren sie die Architektur so, dass sie für die Aufgabe optimal ist. D.h. nicht zu viel kann (hohe Stückkosten), aber v.a. nicht zu wenig (hohe Entwicklungskosten durch Änderungen und Softwareentwicklung "um die Hardware herum").

Haben Sie noch Fragen zu diesen Paradoxen und Widersprüchen? Haben Sie eine andere Meinung? Wenn ja, kontaktieren Sie uns direkt oder kommentieren Sie Ihre Gedanken unten!

Sind Sie bereit für eine widerspruchsfreie Entwicklung? Kontaktieren Sie mich!

Stichworte/ Tags

Fragen & Kommentare

Keine Kommentare

Haben Sie zusätzliche Fragen?

* Diese Felder sind erforderlich

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren