Antworten zum Management von embedded Produkt- und Softwareentwicklungsprojekten

Kann eine Person alles, wirklich alles?

"...entwickelt C++ Software und VHDL programmierbare Logik. Erstellt Schemas und Layouts und nimmt dann die Hardware gerade auch selbst in Betrieb. Führt zusätzlich die EMV und CE Zertifizierung durch und übernimmt die Zertifizierung für funktionale Sicherheit und IoT Security..." Das ist die nicht untypische Stellenbeschreibung für einen Entwicklern oder die Selbst-Beschreibung von Ein-Mann Entwicklungsanbietern.

Geht das überhaupt? Sicher, es gab mal eine Zeit, da war das so ähnlich möglich. Aber: das war im letzen Jahrtausend: 8-bit Prozessoren, keine EMV-Vorschriften, die den Namen verdienen, 1K EPROM, 256 Byte RAM, die Sprache hiess Assembler, die Entwicklungsumgebung hiess "Monitor"... Diese Zeit ist definitiv vorbei!

Wenn eine oder zwei Personen heute alleine alle diese Aufgaben übernehmen, dann ist häufig das Desaster vorprogrammiert. Es entsteht eine Steuerung die eigentlich funktioniert. Und dann kurz vor Produktionsstart die EMV-Tests nicht besteht, weil Layout- und EMV-Grundlagen nicht beachtet wurden. Beim Produktions-Ramp-Up zeigt sich, dass die die Ausbeute beim Löten unterirdisch ist, weil Footprints schlecht sind. Der erste Prototyp beim Kunden stürzt ab, und niemand weiss wieso (der erste Parameter, den der Kunde veränderte, hatte keine Fehlerbehandlung, wie alle anderen auch...). Die Sicherheitsprüfung erfordert ein komplettes Redesign. Und so weiter...

Wieso ist das heute so? Wieso ging das früher? Dafür gibt es drei Gründe:

• Komplexitäts-Zuwachs: In Elektronik und Software sind heute Systeme im Einsatz, welche vor einigen Jahren als Server durchgegangen wären. Deren inhärente Komplexität sorgt dafür, dass nur noch gut zusammenarbeitende Spezialisten solche Entwicklungen auch effizient durchführen können.
• Time-to-Market: Wie schnell mussten neue Produkte auf dem Markt sein? Es gab Projekte, die dauerten zehn Jahre. Würde das heute akzeptiert? Die Bauteile wären schon obsolet, wenn die Produktion beginnt...
• Nicht-funktionale Anforderungen: Die meisten Lastenhefte denken in den funktionalen Anforderungen, im Geradeaus-Fall. Das war beim 8-bit Mikrocontroller auch genügend, jeder war froh, wenn man die Funktion in den vorhandenen Speicher quetschen konnte. Dreissig Jahre später sind die funktionalen Ansprüche an ein System innert 20% der Entwicklungszeit erfüllt. Dann kommen die nicht-funktionalen Anforderungen: Zertifizierung für CE, EMV, Betriebssicherheit, funktionale Sicherheit. Die meisten Geräte haben grafische Oberflächen mit Touch-Bedienung, daraus folgen Forderungen nach Usability und Mehrsprachigkeit. Und auch die Industrie 4.0 fordert IoT Funktionen, welche sofort Cyber-Security nach sich ziehen...

Alle Arbeit nur einem Generalisten zu geben, ist wohl eines der am weitesten verbreiteten und für den Projekterfolg folgenschwersten Entscheide. Und leider der, welcher alle embedded Entwickler in ein schlechtes Licht rückt: "Es geht alles sowieso immer viel länger und funktioniert dann doch nicht".

Was heisst das?

Wir finden, dass embedded Entwicklung Team-Arbeit ist. Keiner kann alles, stellen Sie ein Team für das Projekt zusammen, in dem alle embedded Fachbereiche mit einem echten Spezialisten vertreten sind.

Ist der Aufwand für eine Spezifikation nicht Verschwendung?

Ist es nicht eine Verschwendung, mehr oder weniger detaillierte Anforderungen zu erstellen für ein Produkt oder noch mehr für eine Software? Würde man nicht besser gerade mit der Entwicklung beginnen um so schnell wie mögliche in Produkt auf den Markt zu bringen?

Auch wenn das in Zeiten von "agil" nicht unbedingt gerne gehört wird, ein klares Ziel hilft bei der schnellen Entwicklung. Dies, weil gerade in embedded Systemen nachträgliche Änderungen und die Korrektur von falschen Annahmen sehr aufwändig werden können, aufwändiger als eine gute Spezifikation.

Der Wert von guten Anforderungen zeigt sich zusätzlich, wenn es um die Abschätzung und Planung einer Neuentwicklung geht, wenn die Rentabilität des Produktes beurteilt werden soll. Spätestens bei der Weiterentwicklung des Produktes ist eine klare Spezifikation dann die solide Basis für die Diskussionen um neue oder wegzulassende Features.

Die Alternative ist die Spezifikation auf Zuruf, manchmal "getarnt" als agile Entwicklung. Diese Projekte sind häufig "Open End" und dadurch ist keine Schätzung der Entwicklungskosten möglich für einen Rentabilitätsbetrachtung.

Was heisst das?

Wir finden, Spezifikationen und Anforderungen zu erstellen macht Sinn und lohnt den Aufwand. Investieren Sie in Ihre Anforderungen. Und wenn Sie mit Externen zusammenarbeiten, behalten Sie alle Rechte an diesem Vermögenswert!

Macht uns das Tool viel schneller?

Der Anbieter der Software hat uns gesagt, dass wir um einen Faktor schneller entwickeln werden. Die neue Sprache verspricht einen Produktivitätszuwachs...

Gibt es diese Wundermittel, diese "Silver Bullets"? Die Antwort ist leider nach 34 Jahren immer noch: "There Is Still No Silver Bullet", ein Artikel welcher sich auf Brooks aus dem Jahr 1987 bezieht... Software-Projekte können sich immer noch ohne Vorwarnung in Werwölfe verwandeln, welche Ressourcen, Termine, Geld und Karrieren verschlingen. 

Werkzeug bringen pragmatisch angewandt und verstanden Fortschritte in der Qualität der Entwicklung und haben das Potential, den Aufwand zu verringern. Nur lösen diese Tools nicht alle Probleme auf einen Schlag, sondern sie können auch neue Probleme aufkommen lassen. Unter anderem, da sie zuerst geschult, verstanden und richtig angewandt werden müssen.

Was heisst das?

Verstehen Sie uns richtig, auch wir verwenden viele Software-Werkzeuge und die neusten Sprachen. Nur glauben wir daran, dass wir nur das verwenden, was für das Projekt und das Produkt Sinn macht, dass wir pragmatisch aus dem grossen Angebot das auswählen, was echte Vorteile bringt.

Können uns agile Methoden retten?

Der Agile-Berater hat gesagt, dass alles viel einfacher geht und alle Probleme verschwinden. Wenn wir uns exakt an seine Methode halten! Ist das wirklich so?

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 sind die Ressourcen (Rechenleistung, Stromverbrauch...) immer beschränkt. Genau wieviele zur Verfügung stehen, wird am Anfang des Projektes beim Design der Elektronik bestimmt. Wenn die Spezifikationen sich ändern und es mehr braucht, dann ist diese Erhöhung meist eine sehr teure Übung.

Die Erzeugung von Spezifikationen während des Projektes ist also nicht die preiswerteste und schnellste Variante. Bei kritischen Systemen ist sie sogar durch die Normen abgeblockt. Und auch hier gilt wie bei den Tools: "There Is Still No Silver Bullet"!

Was heisst das?

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

Probieren Sie die Methoden aus, die für Ihr Problem die beste Lösung sind. Haben Sie den Mut, auch nur Teile davon zu benützen und Ihr Vorgehen bei Bedarf anzupassen. Und erwarten Sie keine Quantensprünge, vor allem, wenn diese von quasi-religiösen Eiferern versprochen wurden.

Sparen Freelancer den Spezifikationsaufwand?

Ein Argument dafür, alle Entwickler vor Ort zu haben und/ oder mit Freelancern zu arbeiten ist es, dass dann die Arbeit nicht spezifiziert werden muss. Dies wird als Gegensatz gesehen zu der Entwicklung als Projekt bei einem Ingenieurbüro: "Da muss man alles spezifizieren".

Ist das wirklich der Fall? Wir glauben, dass die ständige und unstrukturierte Definition der Arbeit während der Entwicklung einen grösseren Aufwand für das Team bedeutet. Nur hat dieser den Vorteil, dass er einfach im gesamten Projektaufwand verschwindet, er wird über das ganze Projekt verschmiert.

Was heisst das?

Einerseits heisst das, dass ein Projekt effizienter wird, wenn das ganze Team von Anfang an klare Ziele hat, z.B. eine Spezifikation. Andererseits, falls dies nicht geht, ermöglicht eine iterative, "agile" Projektdurchführung, den Aufwand für die Spezifikation beim Start niedrig zu halten.

Wie führt man externe Projekte effizient und effektiv?

Wenn Sie ein Projekt extern vergeben, dann sind Sie aus dem Schneider. Oder vielleicht doch nicht ganz?

Denn es gibt immer wieder Fragen und Entscheide zu den Zielen und Anforderungen des Projektes. Typische Management-Aufgaben also.

Was heisst das?

Zunächst einmal muss für das Management des externen Projekts genügend Zeit und auch die entsprechende fachliche Kompetenz vorhanden sein.

Dann sollten die Personen, die das externe Projekt führen diese Fachlichkeit auch zurücknehmen können. Denn zu hohe technische Mitwirkung, Mikromanagement führt zu teuren Zusatzschlaufen. Z.B. wenn die persönlichen technischen Vorlieben über Projektziele gestellt werden: "Diese Softwarebibliothek ist die beste", "Nur Prozessoren dieses Herstellers sind gut". Vor allem, wenn diese Leidenschaften erst geäussert werden, nachdem mit der ungeliebten Komponente schon einige Zeit entwickelt wurde.

Und zu guter Letzt sollte die Person, die das externe Projekt betreut auch die Budgetverantwortung für das Projekt haben. Sonst ist es einfach Dinge zu verlangen, die die Kosten explodieren lassen, für die dann aber jemand anderer den Kopf hinhalten muss...

Soll man Engineering und Consulting wie Schrauben kaufen?

Dienstleistungen für Entwicklung und Beratung sollen massgeschneidert genau Ihr Problem lösen, genau Ihre Ziele erreichen. Nur, welcher Partner macht das am besten? Der Entscheid ist schwierig...

Kann man mit einer Tabellenkalkulation, z.B. einer Nutzwertanalyse den Entscheid für einen Partner durchführen? Dadurch soll Unvergleichbares vergleichbar werden. Wie steht es dann mit den Gewichtungen? Sind diese wirklich objektiv? Werden wirklich die Ziele des Projektes bewertet (auch langfristige: TCO (Total Cost of Ownership)?

Oder ist es so, dass die Kosten als das einzige genau vergleichbare, kurzfristige Kriterium die Bewertung dominieren? Wir sind der Überzeugung, dass es nicht möglich ist, den Entscheid solcherarts in eine reine Wahl zu verwandeln (Eine Entscheidung ist, wenn eine Ungewissheit bleibt, wenn sich die Entscheidung vollständig auf klare Fakten stützen kann, ist sie eine Wahl).

Für massgeschneiderte Lösungen ist eine Diskussion der Ziele und Lösungsansätze auch mit den obersten Entscheidern der wichtigste Punkt. Denn sonst kann es sein, dass die im Gesamten preiswerteste oder höchstwertige Lösung bzw. der Partner der diese liefern kann verpasst wird, bzw. die Lösung in den Tiefen einer Tabellenkalkulation verschwindet.

Was heisst das?

Wenn Sie als Geschäftsleitung, als oberster Entscheider die Zeit nicht investieren, in einer Diskussion mit Ihren potentiellen Partnern Ihre Ziele auszurichten, dann verpassen Sie eventuell die beste Lösung. Denn nicht alles kann aufgeschrieben werden, ein Lastenheft, ein RFQ, eine Outsourcing-Checkliste ist nie vollständig. Und vielleicht stellt Ihnen der eine potentielle Partner die wichtigen Fragen, welche Sie auch mit den anderen diskutieren müssten?