<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=504731893395981&amp;ev=PageView&amp;noscript=1">

Projekt mit mehreren Partnern: Die Kosten im Griff und das Produkt pünktlich auf dem Markt

Juli 9, 2021

Projekte mit mehreren Anbietern sind nicht einfach zu realisieren: Sie können entgleisen oder stecken bleiben. Mehr Kommunikation zwischen den Teams kann die Produkteinführung beschleunigen, aber möglicherweise auch verlangsamen. In diesem Artikel erzählen wir Ihnen von einem realen Projekt, bei dem wir mit dem Team eines anderen Dienstleisters kooperierten, um eine Einparkhilfe-Lösung zu erstellen. Zum Schluss präsentieren wir Best Practice-Beispiele, wie man eine produktive Umgebung für die Zusammenarbeit mit mehreren Entwicklungsteams schaffen kann.

Ausgangssituation

Der Held dieser Geschichte war ein 360-Grad-Kamera-Parkassistenzsystem. Seine Aufgabe war es, Autofahrern zu helfen, tote Winkel zu vermeiden und das Einparken sicher zu gestalten. Dafür musste das System hochwertige sphärische Videos produzieren und offline arbeiten können. Technisch gesehen bestand die Herausforderung darin, vier Kameraaufnahmen in Echtzeit zusammenzufügen, um ein nahtloses Video zu erstellen.

Die gesamte Idee dieser Lösung stammte von einem Start-up, das bereits über umfassende Erfahrung mit IoT-Projekten verfügte. Bisher hatte das Start-up nur mit einem bestimmten Anbieter aus Asien zusammengearbeitet. Aber für dieses Projekt bat es Softeq, bei der Firmware-Entwicklung zu helfen, während die Hardware und ihre Architektur bei dem anderen Anbieter aus Asien blieb. Ziel des Start-ups war es, auf diese Weise ein internationales Team zu etablieren und eine Dokumentation erhalten, die besser handhabbar ist. (Wenn die gesamte Dokumentation mit einem logografischen Schriftsystem geschrieben ist, ist es schwierig, das Produkt intern zu unterstützen und fast unmöglich, den Anbieter zu wechseln).

Der Projektstart

Das Projekt begann mit einem gemeinsamen Meeting aller Beteiligten: dem Kunden, dem Hardware-Team (Asien) und dem Firmware-Team (Softeq). Wir vereinbarten und dokumentierten die grundlegenden Funktionen sowie die Verantwortungsbereiche für alle Projektphasen. Das Hardware-Team war für die Hardware-Architektur und die Optimierung der Komponentenkosten verantwortlich. Das Team von Softeq sollte in Zusammenarbeit mit ihnen die zugehörige Firmware entwickeln.

Gemeinsam entschieden wir uns, die i.MX-Prozessorfamilie als Basis für die Lösung zu verwenden. Das Hardware-Team sollte diejenige Prozessorserie auswählen, die die Produktfunktionalität untermauern würde. Das zur Verfügung gestellte Entwicklungskit basierte auf dem i.MX 6-Prozessor. Danach begannen wir mit der Firmware-Entwicklung mit dem gewählten Prozessor.

Das Gute an der i.MX-Prozessorfamilie ist, dass der Hersteller eine vollständige Dokumentation und Anwendungsbeispiele zur Verfügung stellt. Wir können die benötigten Informationen leicht finden, was den Entwicklungsprozess beschleunigt.

Leiter des Entwicklerteams von Softeq

 

Die erste Herausforderung: Mehrere Product Owner

Als das Projekt begann, gab es Änderungen im Kundenteam, und der Product Owner verließ das Unternehmen. Die Aufgaben des Koordinators, wie die Erstellung der Roadmap und die Kontrolle der Umsetzung, wurden auf mehrere Personen verteilt.

In solchen Situationen ist die Wahrscheinlichkeit groß, dass sich die Teams von der vereinbarten Produktvision entfernen. Aber die Zeit war knapp, also haben wir weitergemacht.

Projektleiter von Softeq

1DE

Widersprüchliche Ansätze: Effizienz vs. Kosten

In einer idealen Situation, in der zwei Anbieter remote arbeiten, wird von ihnen erwartet, dass sie bei allen kritischen Aspekten der zukünftigen Lösung kooperieren – was eine Menge Kommunikation bedeutet. Dies gewährleistet eine nahtlose Integration der inhärenten Teile und eine stetige Entwicklung des Produkts. Aber in der Realität hatten wir neben mehreren Anbietern auch mehrere Product Owner auf Kundenseite. Die Koordination der Entwicklung erforderte also noch mehr Kommunikation, um Prioritäten zu setzen. 

Um mit der Firmware-Entwicklung beginnen zu können, benötigten wir detaillierte Informationen über Kamera-Schnittstellen, Auflösung, fps-Rate, Videodatenspeicherung vor der Zusammenführung usw. vom Hardware-Team.

3DE

Unsere praktische Erfahrung hat gezeigt: Wenn man die Firmware entwickelt, ohne die Hardware zu verstehen, kann dies zu Inkonsistenzen zwischen diesen beiden grundlegenden Teilen führen, und die Inbetriebnahme würde scheitern.

Leiter des Entwicklerteams von Softeq

Das Hardware-Team wiederum wollte die Firmware zur Verfügung haben, um mit dem Design der Hardware beginnen zu können, also sollten sie mit der Auswahl der Komponenten beginnen, die die Mindestanforderungen erfüllen und die Hardware des Produkts entwerfen. und das Hardwareteil des Produkts entwerfen. Als Ergebnis würden sie ihr Teil mit minimalen Ausgaben ihrerseits liefern.

4DE

Die beiden Teams hatten offensichtlich unterschiedliche Vorstellungen davon, wie ein effizienter Lösungsdesignprozess aussehen sollte. Je nachdem, was zuerst produziert wird – Firmware oder Hardware –, wird die Lösung entweder effizient oder kostengünstig sein. Der Kunde entschied sich für den Weg der Effizienz, daher stiegen die Kosten leicht an. Das Hardware-Team stellte uns die gesamte notwendige Dokumentation zur Verfügung, und wir begannen mit der Entwicklung der Firmware.

Überlegungen bezüglich des Prozessors: Funktionalität vs. Kosten

Im Laufe der Firmware-Entwicklung fanden wir heraus, dass die Zusammenführung von vier Videostreams einen leistungsfähigeren Prozessor erforderte als den, auf den man sich anfangs geeinigt hatte - den i.MX 6. Der i.MX-Prozessor der nächsten Generation wäre eine viel bessere Option gewesen, aber er war doppelt so teuer wie der ursprüngliche Prozessor. Verständlicherweise hatte der Kunde einige Zweifel und fragte nach möglichen Alternativen.

Option 1: Alternatives Produktkonzept

Das Softeq-Team schlug eine alternative Implementierung vor, bei der der Prozessor nicht durch einen leistungsfähigeren ersetzt werden müsste. Bei diesem Ansatz müsste die Videozusammenführung in die Cloud verlagert werden. In diesem Fall könnte die Lösung nur online betrieben werden: Nutzer könnten das System z. B. im Wald nicht nutzen. Das ursprüngliche Produktkonzept würde dadurch jedoch erheblich verändert. Daher wurde diese Option verworfen.

Der einzige Ausweg aus der Situation schien die Suche nach einem komplett neuen Prozessor zu sein, der die Hardwarekosten reduzieren würde.

Projektleiter von Softeq

Option 2: Leistungsstarkes und erschwingliches Äquivalent des teuren Prozessors

Dem Hardware-Team gelang es, einen günstigeren Prozessor zu finden, der eine gleichwertige Alternative zum i.MX 8 darstellte. Dieser Prozessor wurde von einer chinesischen Firma entwickelt und hergestellt und die gesamte Dokumentation war nur auf Chinesisch verfügbar. Der Kunde stand also vor der Situation, die er durch Beauftragung von Softeq vermeiden wollte. Als wir schließlich versuchten, den bereits entwickelten Firmware-Teil zu portieren, wurde jedoch klar, dass der neue Prozessor nicht den notwendigen technischen Anforderungen entsprach.

Eine versprochene Funktion des Ersatzprozessors war das eingebaute Stitching von mehreren Videostreams, das keine zusätzliche Programmierung erfordert. Aber in unserem Fall funktionierte es nicht richtig, und wir mussten einen eigenen Stitching-Algorithmus implementieren. Unserer Erfahrung nach sind solche Algorithmen sehr leistungsintensiv und erfordern einen Grafikbeschleuniger. Die Prozessoren der i.MX-Familie verfügen über einen Grafikbeschleuniger, der Ersatz jedoch nicht. Daher hat diese kostengünstige Option für uns nicht funktioniert.

Leiter des Entwicklerteams von Softeq

Zurück zum Ursprung – teurer aber effizienter Prozessor

Schlussendlich einigten wir uns alle darauf, die Entwicklung auf der Basis des leistungsfähigeren i.MX 8-Prozessors fortzusetzen. Am Ende überstiegen die endgültigen Hardwarekosten die Zielkosten um mindestens 40 %, und die Markteinführung des Produkts verzögerte sich aufgrund der schlecht koordinierten Kommunikation zwischen allen Beteiligten.

2DE

Die gute Nachricht war, dass der entwickelte Teil der Logik problemlos auf den i.MX 8 Prozessor portiert werden konnte.

Projektleiter von Softeq

Best Practices: Wie baut man ein Multi-Vendor-Projekt auf?

Die Zusammenarbeit mit mehreren Anbietern ist kein einfaches Unterfangen, aber es ist möglich. Die folgenden Empfehlungen können Ihnen helfen, Ihr Projekt auf Kurs zu halten:

  1. Weisen Sie dem Projekt einen einzigen Product Owner zu. Wenn möglich, versuchen Sie zu vermeiden, den Product Owner zu wechseln oder seine Aufgaben auf mehrere Personen aufzuteilen. Andernfalls kann es zu Änderungen an der ursprünglichen Produktvision kommen. Dies könnte zu Widersprüchen zwischen bereits geleisteter Arbeit und der neuen Vision führen, die wiederum Verwirrung im Team und mehrfache Verzögerungen verursachen.
  2. Erstellen Sie eine gut geplante Roadmap mit klaren Etappenzielen und Deadlines, um die Richtung vorzugeben. So wird sichergestellt, dass alle beteiligten Teams das angestrebte Ziel verstehen und darauf hinarbeiten. 
  3. Setzen Sie die richtigen Prioritäten: Kosten vs. Funktionalität? Fortschrittliche Funktionen erfordern einen leistungsstarken Prozessor. Und je leistungsfähiger der Prozessor ist, desto mehr kostet er. Bevor Sie ein Projekt starten, fragen Sie sich: Sind Sie bereit, mehr zu investieren, wenn Ihre Lösung erweiterte Funktionen unterstützen muss? Wenn nicht, welche Kompromisse wären für Sie akzeptabel, um die Hardwarekosten zu optimieren?
  4. Stellen Sie sicher, dass die Hardware- und Firmware-Teams wirklich zusammenarbeiten. Alle Beteiligten sollten sich über die technischen Grenzen und die Kompatibilität der Firmware- und Hardware-Komponenten im Klaren sein. Andernfalls ist die Wahrscheinlichkeit groß, dass die Teams die Hardware neu entwerfen und die Firmware-Teile neu schreiben müssen, was den Entwicklungsprozess unnötig verlangsamt und Ihr Budget verschwendet.
  5. Planen Sie zusätzliche Zeit und zusätzliches Budget ein, wenn Sie unbekannte Komponenten verwenden. Wenn Sie planen, Komponenten von einem Hersteller zu verwenden, mit dem weder Sie noch Ihre Dienstleister bisher gearbeitet haben, können Sie auf ein Problem stoßen. Es kann sich herausstellen, dass diese Komponenten nicht mit den bestehenden Lösungskomponenten kompatibel sind. In diesem Fall wäre es besser, mehr Zeit und Budget für die Recherche einzuplanen, insbesondere wenn es keine Dokumentation in englischer Sprache gibt.

Wenn Sie Hilfe bei der Überprüfung der Kosten eines externen Hardware-Herstellers oder beim Aufbau einer Firmware- und Hardware-Lösung benötigen, senden Sie uns Ihre Anfrage an ask@softeq.com.