Paradoxe der Produktentwicklung

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

Um den Aufwand für Redesigns zu sparen, müssen Sie Kundenanforderungen (Schnittstellen, Bedienung, Umgebungsbedingungen...) und Vorschriften im Innovationsprozess frühzeitig berücksichtigt werden.

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.

 

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