Paradoxe

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 von 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 technische "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 no 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, zu kommunizieren.

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").

Paradox 6: Wenn sie Hardware entwickeln, nutzen Sie agile Methoden, auch wenn das für Hardware gar nicht geht

...denn wenn der jeder Prototyp schon ein Release Kandidat ist, der durch alle "Pre-Compliance" Tests geht, dann sparen Sie die Industrialisierungsphase.

Eine kurze Geschichte

Wir haben immer wieder Kunden, welche  eine Technologie z.B. vom Forschungsprojekt bis zur Serie entwickelt haben. Dann fragen sie uns für die Zertifizierung nach CE und UL an, für eine Industrialisierung. Meist, sobald das Produkt "bereit ist für die Serienproduktion".

Häufig ergibt sich während der Zertifizierung kleinere und leider auch grössere Änderungen an Leiterplatten, Steckern und Komponenten. Manchmal müssen ganze Erdungskonzepte oder die mechanische Konstruktionen (Abstände...) neu gedacht werden. Dies führt zu Zusatzverzögerungen (Markteintritt!) und -aufwänden. 

Fazit

Schauen Sie schon den ersten Prototypen als "Vorserie" an, so wie die Software-Ingenieure jeden Sprint-Release als "Produkt" anschauen. Führen Sie mit diesen eine Vorzertifizierung ("Pre-Compliance") durch, neben den rein funktionalen Tests. Dann können Sie die Anpassungen einfach in den nächsten Prototypen einfliessen lassen. Dies kann dazu führen, dass Sie bis zur Serie nur zwei Layoutversionen erzeugen müssen!

Jedoch: Damit man "agil" ist alle zwei Wochen als Resultat des Sprints eine Leiterplatte abliefern, das macht meiner Meinung definitiv keinen Sinn. Dies, da die Kosten und Verzögerungen für einen "Release" für Hardware massiv grösser sind als für Software, wo sie vernachlässigbar sind.

Paradox 7: Wenn Sie schneller Erfolg wollen, machen Sie mehr Fehler

...denn wenn Sie Funktionsmustern und MVP (Minimum Viable Product) schneller und weniger "genau" entwickeln, wenn Sie mehr Risiken eingehen, dann haben Sie schneller Feedback was Sie noch verbessern können (auch "Fehler" genannt).

Eine kurze Geschichte

Ein Maschinenbauunternehmen hat eine Idee, wie es seine Produkte dank Internet der Dinge (IoT) Zusatzfunktionen für ganz neue Bereiche vermarkten kann. Es gibt viele Workshops, Konzepte, Ideen, aber keine  Modelle, kein Minimum Viable Product... "Da noch nicht ganz klar ist, welcher der Märkte, welche Funktionen man genau angehen soll. Denn wir wollen keine Fehler machen mit dem ersten neuen Produkt..."

Wäre das MVP nicht gerade dazu da, die interne Analyse durch echte Marktabklärung zu ergänzen? Dazu, der nun zweijährigen internen Analysephase die wirklichen Bedürfnisse der Benutzer hinzuzufügen?

Fazit

Die Zeit, die Sie verlieren, um die letzten Unklarheiten bei Innovationen auszuräumen, können sie nicht zurückgewinnen. Aber Sie können Fehler, die Sie bei Ihren ersten Prototypen oder MVP machen, sofort korrigieren.

Und manifestieren sich dann wirklich alle Bedenken in der Analyse am Markt als Fehler? Vielleicht investieren Sie in den Workshops Zeit in etwas, das viel weniger wichtig ist als die Dinge, an die Sie gar nicht gedacht haben, die Ihnen die Kunden aber zum MVP sagen?

Paradox 8: Wenn Sie namhafte Partner suchen, bleiben Sie nicht beim Namen haften

...denn auch bekannte Partner können Ihnen unbekannte Spezialisten liefern.

Eine kurze Geschichte

Ein Schweizer Startup macht das erste Produkt mit einem kleinem, schnellen Ingenieurbüro, es wird ein Markterfolg. Nun, da genügend Geld vorhanden ist, entwickelt es die nächste "wireless" Version mit einem "namhaften Partner". Nur leider erwischt er dort das falsche Team: es geht doppelt so lang, es entsteht eine schlechte Lösung die zu allem Unglück auch noch schwer zu produzieren ist...

Fazit

Was macht namhaft aus? Sind es die Mitarbeiter (alle hunderte?, auch die im "Near-Shoring-Office"?), sind es die Prozesse (nur ISO 9001 oder CMMI Level 3?)... Oder sind es andere Gründe: unser CEO kennt den Bereichsleiter oder ist es FUD (Fear, Uncertainty, Doubt: "Nobody was fired because he bought ...") oder Gruppendruck ("andere wählen auch...")?

Lesen Sie den Partner Ihres Vertrauens nach objektiven Kriterien aus?

Paradox 9: Wenn Sie ein Low-Cost Produkt entwickeln wollen, rechnen Sie mit hohen Entwicklungskosten

...denn die preiswerteste Lösung zu finden benötigt viel Aufwand.

Eine kurze Geschichte

Ein Hersteller wollte sein Portfolio um einen simplen IoT-Knoten erweitern. Die vielen Schnittstellen verteuerten das Gerät gegenüber der bestehenden, einfachen Lösung. Um eine preiswerte Lösung zu bekommen, optimiert über die Herstellkosten von Elektronik und Mechanik, mussten viele Lösungen evaluiert werden. Die gewählte, preiswerteste Lösung war dann auch nicht die, die den Software-Aufwand minimierte. Die Geschäftsleitung erschrak zuerst ab dem Aufwand für diese Optimierung.

Fazit

Wenn Sie das Optimum der Herstellkosten finden wollen, dann müssen Sie bereit sein, mehr in die Lösungssuche und in die Entwicklung mit nicht-idealen Plattformen investieren. Oder anders herum: die einfachste Lösung (z.B. Maker-Boards) mag die schnellste in der Entwicklung sein, aber je nach Stückzahl zahlen Sie bei den Herstellkosten und über die Produktlebensdauer den Preis für die tiefen Entwicklungskosten.

Übrigens ist es sinnvoll, die Diskussion über "tiefe Herstellkosten" ganz am Anfang des Projektes zu führen, denn je nach Stückzahlen fallen die Entwicklungskosten dann doch irgendwann ins Gewicht. Voraussetzung für eine solche Abwägung wären dann eine möglichst zuverlässige Aufwandsschätzung für die Entwicklung.

Paradox 10: Wenn Sie ein ein Gesamtprojekt managen, managen Sie vor allem die Schnittstellen

...denn in den Schnittstellen (Hardware, Software und Mechanik!) können Sie zukunftsgerichtet Probleme und Aufwand minimieren ("Frontloading"). Zukunftsgerichtet, damit die Schnittstelle in dem Moment klar ist, sobald irgend jemand mit ihrer Implementation beginnt.

Eine kurze Geschichte

Ein Hersteller setzte ein kompliziertes Projekt mit IoT, Cloud und Apps auf. Leider entstanden die Schnittstellen während der Implementation on-the-go oder bei der Integration, einerseits Protokolle und grafische Bedienung, aber auch vergleichsweise einfache mechanische Passungen. Dann wurde in der Integrationsphase viel Energie und Aufwand in die Fehlerkorrektur der Schnittstellenbeschreibung investiert, in unnötige "Known Unknowns". Nicht nur in die Korrektur von Implementationsfehlern und Missverständnissen, d.h. von "Unknown Unknowns". 

Fazit

Stellen Sie als Projektmanager oder Auftraggeber eines Entwicklungsprojektes den jeweilig "Betroffenen" vor allem die Schnittstellendefinitionen frühzeitig zur Verfügung, d.h. die "Unknowns", die Sie auf Systemebene bereits auflösen können. Dadurch verringert sich der Integrations- und Fehlerbehebungsaufwand massiv.

Andreas Stucki

Haben Sie zusätzliche Fragen zu diesen Paradoxen und Widersprüchen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!