Traum oder Wirklichkeit? Embedded Entwicklungsprojekte erfolgreich umsetzen

Stellen sie sich einmal vor, alle am Projekt beteiligten Personen wissen Bescheid, handeln ebenso gewissenhaft wie eigenverantwortlich und liefern dann ihre Aufgabe aus dem Lastenheft auch noch pünktlich und ohne Mängel ab. Ist das ein Traum? Nicht unbedingt! Wie es geht, zeigt der folgende Artikel.

Gute Ausbildung, langjährige Erfahrung, effiziente Kommunikation ohne Eitelkeiten und computergestütztes Projekt-Controlling sind die Stichworte, welche diesen Traum tatsächlich Wirklichkeit werden lassen können.

Das Projektgeschäft hatte schon immer seine eigenen Regeln. Im Unterschied zum Produktgeschäft wird hier kein bereits fertiges Produkt verkauft, sondern es wird ein Projekt definiert, an dessen Ende das vom Kunden gewünschte Ergebnis erreicht worden ist.

Hierzu werden die zu erfüllenden Aufgaben sowie die gewünschten Eigenschaften des zu entwickelnden Produkts vom Auftraggeber in einem Lastenheft festgelegt.

Nun beginnt die oft mühsame und zeitraubende Arbeit, den notwendigen Aufwand und Ressourcen (z. B. Personal, Material, Werkzeuge und Fertigungskapazitäten) abzuschätzen und daraus ein Pflichtenheft sowie ein Angebot zu entwickeln. 

Planung ist alles, aber nicht alles lässt sich planen

Damit dabei keiner der Geschäftspartner auf der Strecke bleibt, muss der Ablauf des Projektes sorgfältig geplant werden. Grundvoraussetzungen sind eine realistische Einschätzung der Machbarkeit wie auch ein realistischer Zeitrahmen. Darüber hinaus müssen die benötigten Ressourcen zum rechten Zeitpunkt verfügbar sein, damit es nicht zu unnötigen Verzögerungen kommt.

Überraschungen können auch bei sorgfältigster Planung immer wieder vorkommen. Einerseits ist es ja positiv, wenn Konzeptverbesserungen noch im Projekt eingepflegt werden können, andererseits müssen die Auswirkungen auf Zeitverlauf und Budget überschaubar und vor allem auch kontrollierbar bleiben. Da hilft nur eine offen gelegte Kalkulation und ehrliche Kommunikation, damit der Kunde sofort sieht beziehungsweise nachvollziehen kann, wie sich eine gewünschte Änderung finanziell und zeitlich auf die jeweiligen Budgets auswirkt.

Dies setzt in der heutigen Zeit computergestützte Planungswerkzeuge voraus, die aber nur so gut sein können wie der Datenbestand, auf dem sie basieren.

Eine hohe Qualität der Planungsdaten setzt immer Erfahrung und gute Ausbildung sowie eine hohe Eigenmotivation der Mitarbeiter voraus. Planungs- und Abrechnungswerkzeuge sollen im Tagesgeschäft als Unterstützung und nicht als Gängelung der Mitarbeiter aufgefasst werden.

Offenheit, Transparenz, Nachvollziehbarkeit, Respekt und das daraus resultierende Vertrauen sind aber nicht nur hausintern, sondern auch im Umgang mit dem Kunden wichtig. Dies ist für ein erfolgreiches Projekt elementar, da neue Technologien immer unbekannte und damit schwer einschätzbare Risiken mit sich bringen. Diese können nur gemeinsam optimal bewältigt werden.

Lösungsansätze in der Praxis

Ausgangspunkt ist ein Konzept der Aufgabenteilung mit überschaubaren Einzelstrukturen beziehungsweise Aufgaben. Ein strukturierter Ansatz mit bewährten Checklisten und Vorlagen (Templates) hilft nicht nur bei der Planung, sondern später auch bei Abrechnung, Prüfung und Dokumentation, da auf Bewährtes zugegriffen werden kann. Neue Templates werden bereits bei der Entwicklung auf Wiederverwendbarkeit ausgelegt, sofern dies vom Projekt her möglich ist, und dann für den jeweiligen konkreten Kontext optimiert. Die Zeitplanung kann ruhig großzügig ausfallen, solange sie transparent und aktuell ist. So wird einerseits unnötige Hektik vermieden, aber andererseits werden auch keine freien Ressourcen verschwendet, da jederzeit festgestellt werden kann, wo diese gerade verfügbar sind. Eine sinnvolle Partitionierung der Projektaufgaben erhöht die Transparenz und ermöglicht Concurrent Engineering, wie etwa in Form von paralleler Entwicklung von Hard- und Software-Komponenten. 

Im Gegensatz zu den meisten Firmen, die Projektmanagement nach dem Pull-Prinzip betreiben, das heißt, ein Projektleiter holt sich die Infos von allen Beteiligten, arbeitet DH electronics nach dem Push-Prinzip. Hier pflegen alle Team Mitarbeiter ihre Arbeitszeiten aufgabenbezogen ein und geben darüber hinaus bei Bedarf noch weitere Rückmeldungen ins System ein. Dadurch sind alle wichtigen Basisdaten im System und man kann sich übergeordnete Infos daraus auf Knopfdruck erzeugen. Bei kurzfristigen Änderungen am Lastenheft sind so die Auswirkungen unmittelbar und transparent nachvollziehbar. 

Das konkrete Projekt und seine speziellen Anforderungen

Zu entwickeln war ein universelles NFC-basierendes Programmiergerät für eine neue Generation von industriellen Deckenleuchten. Anforderungen waren: Kompakte Maße, gut ablesbare, grafische Benutzerschnittstelle (HMI), stromsparender Batteriebetrieb mit umfangreichem Power- und Lademanagement, drahtlose Kommunikation mit Zentrale und Zielgeräten via Bluetooth-Low-Energy (BLE) und Near-Field-Communication (NFC) sowie ein robustes, sturzfestes Gehäuse. Auf den ersten Blick ein relativ simples Gerät, welches aber im Detail betrachtet eine Ansammlung von doch sehr speziellen Herausforderungen enthielt (siehe Bilder).

Eine davon war die Kommunikation mit dem Kunden. Da der Kunde die Entwicklung der zu programmierenden Leistungselektronik an einen Zulieferer ausgelagert hatte, gestaltete sich die Kommunikation als ausgesprochen komplex. Ohne das Push-Prinzip, bei dem die DH-Mitarbeiter ihren Projektfortschritt regelmäßig – wöchentlich oder bei konkretem Bedarf – aktiv kommunizierten, hätte es sicher viele Verständnisprobleme gegeben. Angesichts von Concurrent Engineering und einer agilen Arbeitsweise hätte das Projekt bei klassischer Kommunikation über die Projektleiter und nur zu den Milestones erheblich länger gedauert. So aber konnten viele sich anbahnende Probleme bereits frühzeitig und teilweise auch im Vorfeld der Entwicklung abgefangen oder ganz vermieden werden. Damit wurden einige Fehler und Unklarheiten bereits im internen Review der zugeteilten Aufgaben nach dem Vier-Augen-Prinzip erkannt und behoben. Da die NFC- und BLE- Kommunikation auf bewährten Standards aufsetzt und soweit möglich bereits fertige Lösungen in Form von bereits verfügbaren Kommunikations-Stacks verwendet wurden, verlief die Software-Entwicklung für die Programmierung des Steuergeräts weitgehend unproblematisch. Für den im Bediengerät verwendeten Arm-Cortex-M0-basierenden Controller kamen FreeRTOS sowie dazu passende, bereits im Haus vorhandene, Software-Module zum Einsatz. Somit hielt sich der Aufwand für die Integration auch hier in vertretbaren Grenzen.

Deutlich aufwändiger gestaltete sich die Entwicklung der Hardware. Das Gehäuse sollte kompakt, robust und spritzwassergeschützt sein. Insbesondere sollte es den Fall auch aus größeren Höhen ohne Schaden überleben, da viele der zu installierenden Lampen in mehreren Metern Höhe montiert werden. Dies war in Verbindung mit der Integration eines Oled-Displays, dem integrierten Akku und der geforderten Schutzklasse nicht trivial. Die Gehäuselösung sollte ja auch den Funkverkehr per NFC und BLE zulassen und daher nicht allzu sehr dämpfen. Schließlich wurde eine neue, innovative Vergusslösung entwickelt, die nach mehreren Anläufen gute Ergebnisse brachte und auch tauglich für eine Serienfertigung war. Entscheidend für den Erfolg waren hier der Mut neue Wege zugehen, agile Arbeitsmethoden mit kurzen Sprints und guter Kommunikation zwischen den Gehäuseentwicklern, dem Hochfrequenzteam und dem Fertigungspartner.

Ähnlich intensiv war die Kommunikation bei der Entwicklung des Power- und Lademanagements, da die beim Laden entstehende Verlustwärme ja auch irgendwie über das Gehäuse abgeführt werden musste. Während das Oled-Display relativ problemlos integriert werden konnte, gestaltete sich die Programmierung des grafischen Interfaces (HMI) insbesondere aufgrund der agilen Entwicklung und dazu notwendigen Kommunikation mit dem Kunden und dem dritten Entwicklungspartner als aufwändig.

Aufwändig und tückisch: NFC im Stabgehäuse

Größere Herausforderungen und Abweichungen vom ursprünglichen Zeitplan gab es beim NFC-Interface. Dies lag einerseits daran, dass es für das Projektteam eine neue Technologie war, andererseits an den konkreten Tatsachen der Physik. NFC arbeitet mit einer Frequenz von nur 13,65 MHz und damit relativ großen Wellenlängen von rund 22 Metern. Dementsprechend groß und/oder kompliziert gestaltet ist dann auch bei einem guten Wirkungsgrad die NFC-Antenne, speziell wenn sie dann auch noch eine Richtwirkung haben soll. Im Projekt war die Herausforderung, das System so zu gestalten, dass die Kommunikation mit der montierten Leuchte im Servicefall von einem auf einer Leiter stehenden Mitarbeiter durch Zeigen auf das Steuergerät in beliebiger Einbaulage ausgeführt werden konnte. Dazu bedurfte es einer Antenne mit Richtwirkung nach vorne und dies bei einer relativ geringen Stirnfläche von nur 2,5 cm².

Das Ganze hatte natürlich auch noch eine starke Wechselwirkung mit Bauart, Bauform und Material des Gehäuses. Planungen und Simulationen mussten hier mit vielen und aufwändigen Versuchs- und Messreihen kombiniert und ausgewertet werden, bis die Ergebnisse gut genug für einen praktischen Einsatz im Feld waren. 
Letztendlich wurde das Gehäuse als Vergusslösung ausgeführt, da nur so nicht nur Dichtheit und Robustheit, sondern auch ein innerhalb des Gehäuses homogenes Hochfrequenzverhalten mit geringste Reflexionen und einheitlicher Dielektrizitätskonstante Epsilon-r erreicht werden konnten.

Ende gut, alles gut

Wenn man von den erheblichen Verzögerungen absieht, die bei der Entwicklung des Gehäuses und dessen Überführung in die Serienproduktion auftraten, dann konnte das Projekt doch weitgehend zügig und in einem für beide Seiten akzeptablen Zeitrahmen abgeschlossen werden. Voraussetzung dafür war eine passende Partitionierung des Projekts, welche die Projektaufgaben so strukturierte, dass kurzfristige Verzögerungen in einem Bereich sich nicht gleich auf das ganze Projekt auswirkten. Im konkreten Fall waren dies Hard- und Softwareentwicklung und innerhalb der Hardware-Entwicklung die allgemeine Hardware mit Mikroprozessor und Stromversorgung, der HF-Teil und das Gehäuse.

Dies hatte den Vorteil, dass zwischen wenigen großen Milestones die Entwicklung je nach Aufgabenstellung und bereits vorhandenen Bibliothekselementen beziehungsweise Modulen mit verschiedenen Zeitrastern für die jeweiligen Sprints arbeiten konnte. Die Entwicklung der neuartigen, symbolbasierten Benutzerschnittstelle mit möglichst wenig Text erforderte sehr kurze Zykluszeiten. Hier wurden sukzessiv jeweils neue Features implementiert, getestet und mit dem Kunden und dessen weiteren Entwicklungspartner kommuniziert. Ohne diese agile Konzeption und das Push-Prinzip, in dem der Entwickler aktiv und ständig die neuesten Fortschritte an alle Partner kommuniziert, hätte die Entwicklung wesentlich länger gedauert. So aber konnte auch das Lastenheft dynamisch mit der Entwicklung weitergeführt und spontane Verbesserungen konnten transparent eingepflegt werden. Durch diese Transparenz waren alle Beteiligten einschließlich des Kunden ständig auf dem Laufenden.

Jeder wusste immer über den aktuellen Fortschritt Bescheid und Prioritäten konnten so frühzeitig gesetzt und Ressourcen und Kosten optimal geplant werden. Die Ergebnisse der einzelnen Sprints (Entwicklungszyklus) wurden noch vor Veröffentlichung in Reviews nach dem Vier-Augen-Prinzip geprüft. Dies sorgte dafür, dass sich menschliche Fehler, wie sie trotz größter Sorgfalt unter Stress immer wieder passieren können, frühzeitig erkannt und beseitigt werden konnten, bevor sie sich auf die anderen Projektteilnehmer auswirkten.

Das modulare Konzept mit Standardkomponenten und modernsten Entwicklungswerkzeugen ermöglichten es, große Teile der Software bereits parallel zur Hardware-Entwicklung und vor der Fertigstellung der Ziel-Hardware zu entwickeln und zu testen. So konnte Zeit gespart und die Entwicklungszeit verkürzt werden. Dass diese Methode nicht immer reibungslos funktioniert, zeigte die Entwicklung des HF-Interfaces für NFC und BLE sowie der Antenne für NFC. Diese erfolgte losgelöst vom eigentlichen Gerät erst einmal mit Testschaltungen und wurde mit aufwändigen Tests und Messungen sukzessive optimiert.

Da sich bei den HF-Interfaces und insbesondere auch der NFC-Antenne für die Entwickler um technisches Neuland handelte, war hier schon vorab mit mehr Zeit und Verzögerungen kalkuliert worden. Trotzdem kam es hier aufgrund der Komplexität der Aufgabenstellung zu größeren Verzögerungen als erwartet. Weil durch die transparente Projektkommunikation nach dem Push-Prinzip jeder stets auf dem Laufenden war, konnten die Prioritäten in diesem und parallel laufenden anderen Projekten rechtzeitig und weitgehend stressfrei angepasst werden. Daher konnten die anderen Teammitglieder rechtzeitig umplanen und es entstanden keine teuren Leerlaufzeiten durch Wartezeiten. So blieben die produktive Auslastung der beteiligten Entwickler und damit auch die Wertschöpfung trotzdem hoch.

Das Geheimnis des Erfolgs

In einem von allen Teammitgliedern akzeptierten Projektplanungssystem sind alle wesentlichen Fakten und Parameter transparent dokumentiert:

  • Wann wird was gebraucht?
  • Welches Personal mit welcher Qualifikation wird wann benötigt?
  • Welche Arbeitsmittel sind erforderlich?
  • Wie sieht es mit möglichen Fertigungskapazitäten intern/extern aus?
  • Sind die benötigten Personen und Ressourcen rechtzeitig verfügbar?
  • Sind wir noch im Zeit- und Kostenplan?

Exakte Projektplanung und konsequente Nutzung des Systems nach dem Push-Prinzip ermöglichen eine realistische, vorausschauende Planung, weil die Auswirkungen von Änderungen und Verschiebungen sofort evaluiert werden können. Der Projektstand kann jederzeit Live abgerufen werden und die Planung jedes Mitarbeiters eigenverantwortlich aktualisiert und optimiert werden. Alle relevanten Daten im Projekt liegen dabei offen und nachvollziehbar vor und können somit bei der Planung stets berücksichtigt werden. Da sich bei guter Planung die Auslastung der Ressourcen erhöht, sinken damit die Kosten und die Wertschöpfung steigt. Sinnvolles Concurrent Engineering senkt die Projektdurchlaufzeit und berücksichtigt Hardware-Entwicklung, Software-Entwicklung und Test.

Mit den im System gespeicherten Erfahrungswerten können neue Projektangebote schneller erstellt werden, da aufgrund hoher Wiederverwertbarkeit der Aufwand primär in den jeweils wenigen neuen Technologieelementen liegt.

Änderungen des Lastenheftes können im laufenden Projekt mit relativ geringem Aufwand nachgeführt und kommuniziert werden und sorgen für Transparenz. Der Kunde ist stets mit im Boot und das Projekt samt Lastenheft können gemeinsam bei voller Kostentransparenz während der Laufzeit weiter entwickelt werden.

So können beide Seiten agil entwickeln und schnell auf neue, sich aus dem laufenden Projekt ergebende oder von außen herein kommende Änderungsanforderungen reagieren. Das Bestechende dabei ist die absolute Kostentransparenz für beide Seiten. Der Kunde sieht nicht nur sofort, welche Kosten durch gewünschte oder benötigte Änderungen verursacht werden, sondern auch welcher Nutzen daraus entsteht beziehungsweise was er für sein Geld wirklich bekommt. Kurz zusammengefasst: Es gibt mehr Spaß bei der Arbeit für das Projektteam und ein besseres Produkt für den Kunden.(fr)