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 klaren 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 wurden für eine Art von (IT-) Problemen entwickelt, wo sie ihre Berechtigung haben. Es geht häufig um das Anpassen von Lösungen an Kundenwünsche,  bei denen sowohl die grundsätzliche Plattform wie auch die grundsätzliche Funktion (Webauftritt, Webshop...) schon bekannt sind. In der embedded Produktenwicklung, wo man nicht einfach noch ein Rack voll Server zuschalten kann, ist die Erzeugung von Spezifikationen während des Projektes sicher nicht die schnellste Variante. Bei kritischen Systemen ist sie sogar durch die Normen abgeblockt.

Das heisst nicht, dass andere "agile" Prozesse keine Berechtigung haben. Auch wir machen iterative Auslieferung und Integration, automatisierte Test etc., auch bei kritischen Projekten.

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 Entwicklugn 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ändnisse fressen den gesamten Kostenvorteil wieder auf.

Fazit

Die Einsparungen, die sich über 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.

 

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