Design und Entwicklung von elektronischen Produkten im Vergleich zu digitalen Produkten

Ich hatte das Glück, sowohl physische als auch digitale Produkte zu entwickeln und zu verwalten. Da ich die Liebe und Leidenschaft für beide teile, dachte ich daran, meine Ansichten und einige Beobachtungen zu den Unterschieden und Ähnlichkeiten zwischen ihren Entwicklungsprozessen zu präsentieren.

Was bedeutet ein Produkt für ...

Was ist ein Produkt? Etwas, das hergestellt und verkauft wird, oder etwas, das einen Wert für die Nutzer schafft? Die erste Definition gilt nur für physische Produkte und spiegelt wider, was wir mit Produkten machen und wie wir sie herstellen. Die zweite Definition ist offener und moderner und spiegelt wider, warum wir Produkte brauchen. Physische Produkte sind greifbar; Benutzer können sie berühren, sehen, riechen und fühlen. Wir haben alle Videos von riesigen Fabriken gesehen und können verstehen, wie teuer und komplex es ist, sie herzustellen. Digitale Produkte leben in der Cloud oder in entfernten Rechenzentren. Es ist schwieriger für uns, ihre Größe, Komplexität und die Bedeutung des Baus zu verstehen. Wenn wir uns beispielsweise das Frontend der Google-Suche ansehen, sehen wir nur eine Suchzeile, aber hinter den Kulissen im Backend laufen Hunderttausende von Servern und Milliarden von Codezeilen.

Als Softwareentwickler vor etwa 25 Jahren damit begannen, digitale Produkte zu entwickeln, verwendeten sie ähnliche Prozesse und Tools, die zum Erstellen physischer Produkte verwendet wurden. Der zu dieser Zeit bewährte Prozess für das Projektmanagement war Waterfall, da er die Perfektion während des gesamten Projektzyklus garantierte. Als digitale Projektmanager jedoch mehr Erfahrung sammelten und in fast der Hälfte der Projekte scheiterten, stellten sie fest, dass sie eine Änderung benötigten. Sie begannen, ihre eigenen Werkzeuge zu bauen und entwickelten ihre einzigartigen, unkonventionellen Prozesse. Um das Jahr 2001 herum setzten immer mehr Teams Scrum und Kanban ein, und es entstand das agile Manifest. Git wurde 2005 von Linus Torvalds ins Leben gerufen und legte den Grundstein für Open Source-Projekte. Vielleicht ist für digitale Produkte Perfektion nicht so wichtig wie Agilität. Heute, 25 Jahre später, sind die Entwicklungsprozesse, Werkzeuge und Kulturen beider Produktteams sehr weit voneinander entfernt.

In den letzten fünf Jahren war es extrem einfach und kostengünstig, Elektronik in physische Produkte einzubetten und sie mit einer Art App mit dem Internet zu verbinden - ein Trend, der als IOT (Internet of Things) bezeichnet wird. Die Kosten hierfür betragen ca. 2 US-Dollar pro Produkt, was erklärt, warum in letzter Zeit so viele neue IOT-Produkte auf den Markt kommen, von denen einige ziemlich amüsant sind zwei Arten von Werkzeugen. Immer wenn zwei Kulturen aufeinander treffen, passieren interessante Dinge. Open-Source-Hardware ist jetzt allgegenwärtig und einige Leute haben begonnen, sich selbst als Hersteller zu bezeichnen. Was ist der Unterschied zwischen einem Hersteller und einem Hersteller? Werden wir eine Konvergenz zwischen diesen Prozessen sehen? Oder sind wir als CTOs und IOT-Produktmanager dazu verdammt, für immer eine Brücke zwischen diesen Kulturen zu schlagen?

Ich hoffe, Sie finden diesen Blog sowohl interessant als auch nützlich und er wird Entwicklern aus der ganzen Welt helfen, die Herausforderungen des anderen zu verstehen.

Rollen und Fähigkeiten

Es gibt einen aktuellen Trend für Softwareentwickler, den gesamten Software-Stack zu entwickeln. Dies bedeutet, dass sie sowohl Backend-Code entwickeln: den Code, der auf dem Server / der Cloud ausgeführt wird, als auch Frontend-Code: den Code, der auf dem Gerät ausgeführt wird. Möglicherweise übernehmen sie sogar die Rolle von DevOps: Ingenieure, die für die Einrichtung, Konfiguration, Sicherung und anschließende Automatisierung des Änderungsprozesses des Systems verantwortlich sind. Es ist nicht unmöglich, dass eine einzelne Person eine einfache digitale App oder ein Spiel erstellt und startet. Bei der Betrachtung von IOT-Produkten, die in der Regel sowohl ein elektronisches Gerät als auch eine Art App umfassen, erfordert das Tech-Team jedoch mehr Fähigkeiten und Rollen.

Embedded-Entwickler sind für den Code verantwortlich, der auf dem Gerät ausgeführt wird, und Board-Designer sind für die Entwicklung des elektronischen Boards verantwortlich.

Obwohl JavaScript-Entwickler heute mit Hilfe von Espruino theoretisch alle drei Codeebenen entwickeln können: Frontend-Code, Backend-Code und Embedded-Code, werden sie wahrscheinlich mit Industrie- und Board-Design zu kämpfen haben, das völlig unterschiedliche Fähigkeiten erfordert. Ich habe talentierte Entwickler gesehen, die ein Alleskönner sind und schnell von der Änderung von CSS-Klassen zum Schreiben von Migrationsskripten für ihre Datenbanken übergehen können. Persönlich denke ich, dass professionelle Entwickler zu jedem Zeitpunkt nur eine Ebene beherrschen sollten. Es geht nicht nur darum, über die besten Fähigkeiten und Techniken zu verfügen oder die erforderlichen Funktionen zu implementieren, sondern auch darum, worauf Sie Wert legen und in welchem ​​Geisteszustand Sie Ihre Arbeit erledigen.

Ich habe versucht, die Verantwortlichkeiten der einzelnen Rollen im Team zu beschreiben. Ich schätze, dass ich ein gefährliches Gebiet betrete, da sich die Rollen in verschiedenen Teams leicht ändern können. Versuchen Sie also, den Wald und nicht die Bäume zu sehen.

Warum kümmert sich nicht eine Person um alles? Weil es bei der Produktentwicklung Kompromisse und Konflikte gibt und Sie jedes Bedürfnis ausgewogen und symmetrisch darstellen möchten.

Im Laufe der Jahre habe ich immer wieder Respekt zwischen verschiedenen Entwicklertypen gesehen, aber auch mangelndes Wissen. Ich habe Frontend-Entwickler gesehen, die das Backend für einfach halten, und Backend-Entwickler, die das Frontend für langweilig halten. Ich habe auch Embedded-Entwickler gesehen, die nicht wissen, was REST ist. Ich habe bereits erwähnt, dass ich nicht glaube, dass professionelle Entwickler und Ingenieure mehr als eine Ebene beherrschen sollten. Ich bin jedoch der festen Überzeugung, dass sie wissen sollten, was es bedeutet, einer zu sein, und vielleicht sogar noch einen Schritt weiter gehen und an einem einfachen Projekt arbeiten sollten, das sie den verschiedenen Herausforderungen und Prozessen aussetzen wird. Ein breites Wissen kann dazu beitragen, die Kommunikation, den Respekt und die Transparenz zwischen den Teammitgliedern zu verbessern und die Kreativität und Produktivität des gesamten Teams zu steigern.

Projektmanagement

Was ist der Unterschied zwischen einem Projekt und einem Produkt? Ein Projekt ist ein Plan, um ein bestimmtes Ziel oder einen bestimmten Umfang innerhalb eines bestimmten Zeitraums und mit bestimmten Ressourcen zu erreichen. Ein Projekt hat einen Anfang und ein Ende. Wenn Sie keinen Projekttermin haben, verwalten Sie wahrscheinlich kein Projekt. Wenn das Projekt endet, lebt das Produkt weiter.

Risikoanalyse: Lassen Sie uns die Unterschiede und Ähnlichkeiten zwischen dem Projektmanagement eines physischen und eines digitalen Produkts diskutieren. Persönlich stelle ich mir Projektmanagement gerne als einen risikogesteuerten Prozess vor, bei dem ich ständig die wichtigsten Risiken identifiziere und versuche, einen Plan zu entwickeln, um sie zu minimieren. Projektrisiken sind alles, was sich auf den Erfolg des Projekts auswirkt, d. H. Die Nichteinhaltung des Ziels, der Frist, des Umfangs, der Kosten oder der Endqualität der Produkte. Bei digitalen Produkten besteht eines der größten Risiken darin, ein Produkt zu entwickeln, das Benutzer nicht benötigen oder mögen. Digitale Produktmanager stellen sich vor, glauben, spekulieren und erzählen eine gute Geschichte, aber bis die Benutzer anfangen, mit dem Produkt zu interagieren, sind dies nur Annahmen. Um die Annahme zu überprüfen, müssen Produktmanager schnell liefern, ihre Hypothese überprüfen und agil sein. Bei physischen Produkten besteht das größte Risiko darin, zu einem sehr späten Zeitpunkt ein irreparables Problem zu finden, nachdem bereits Hunderte und Tausende von Produkten hergestellt wurden. Die Herstellung erfordert Perfektion, und ohne sie wird das Projekt scheitern. Um dieses Risiko zu verringern, erstellen physische Projektmanager einen Überprüfungs- und Freigabeprozess zwischen den Phasen, der als Wasserfall bezeichnet wird.

Jede Methode wurde entwickelt, um unterschiedliche Risiken zu reduzieren, und jeder Projektmanager sollte auf der Grundlage einer Risikoanalyse über den Projektplan entscheiden. Manchmal sind Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge, und manchmal sind Prozesse wichtiger. Manchmal ist funktionierende Software wichtiger als Dokumentation, manchmal ist Dokumentation wichtiger. Manchmal ist die Zusammenarbeit mit Kunden wichtiger als ein schriftlicher Vertrag. Und manchmal kann ein schriftlicher Vertrag Ihr Unternehmen retten. Manchmal ist es wichtig, auf Veränderungen zu reagieren, manchmal ist es wichtiger, einem Plan zu folgen. Du verstehst was ich meine.

Tools und Teamzeremonien: Projektmanager sollten Tools verwenden, die den Prozess implementieren, mit dem sie die Projekte verwalten möchten. Microsoft Project ist ein großartiges Tool für Wasserfallprojekte. JIRA und Trello eignen sich hervorragend für agile Projekte und Supportprozesse wie Kanban und Scrum. Was auch immer das Werkzeug ist, denken Sie daran, dass es nur ein Werkzeug ist und nicht die Essenz. Teams haben auch verschiedene Zeremonien. In Waterfall treffen sich Teams vor jedem Sturz und prüfen Dokumente, CAD-generierte Ergebnisse oder Testspezifikationen. Das agile Team trifft sich möglicherweise jeden Tag zum täglichen Aufstehen und alle zwei Wochen zur Sprintplanung. Diese Zeremonien richten die Teammitglieder auf den Plan aus und verbessern die Kommunikation zwischen den Teammitgliedern.

Design und Prototyping

Design: Gibt es heute ein Produkt, bei dem Design für den Erfolg keine große Rolle spielt? Was ist ein Produkt, wenn wir es nicht verkaufen wollen? Etwas, das attraktiv und ästhetisch sein sollte, auf das wir stolz sein können. Vorbei sind die Zeiten, in denen es gut genug war, die richtige Funktionalität und Leistung zu haben. Bei elektronischen Produkten sollte das Industriedesign nicht nur die Interaktion des Menschen, die Benutzerfreundlichkeit und das Kundenerlebnis berücksichtigen, sondern auch die Umgebungsbedingungen, unter denen das Produkt verwendet wird, und den Herstellungsprozess (DFM: Design for Manufacturing). Bei digitalen Produkten sollte das Design auch die verschiedenen Geräte berücksichtigen, auf denen die Software ausgeführt werden kann (Mobilgeräte, Desktops, große Bildschirme), sowie alle Arten von Rollen und Benutzern, die mit ihr interagieren.

Verschiedene Arten von Entwurfsmethoden gelten für verschiedene Arten von Produkten: Experience Design betrachtet das Produkt als Teil einer erfreulichen Erfahrung, die wir erstellen möchten, z. B. „Wir verkaufen kein Spiel, wir verkaufen eine einstündige Familienerfahrung“. Beim Service-Design wird das Produkt als Teil eines End-to-End-Service zwischen einem Service-Provider und einem Benutzer betrachtet. "Von dem Moment an, an dem Sie sich für eine Reise entschieden haben, bis Sie an Ihrem Ziel ankommen", "Wir verkaufen keine Überwachungskamera, wir verkaufen Ihnen 24/7 Schutz".

Prototyping: Mithilfe von 3D-Druckern und VR / AR-Technologie können Sie ganz einfach einen mechanischen Prototyp Ihres physischen Produkts erstellen. Sie können es Ihren Kunden zeigen, einige Aufkleber darauf anbringen, einige Drähte und LEDs anschließen, sie werden den Zweck sofort verstehen und Sie können sie möglicherweise davon überzeugen, dass Ihr Produkt fertig und kommerziell ist. Sie können es in der realen Umgebung platzieren und prüfen, ob es mechanisch passt und leicht zu halten ist. Sie können zehn Versionen erstellen und diese miteinander vergleichen und die endgültige Konfiguration festlegen. Es gibt nichts Mächtigeres, als Ihren Kunden und Anlegern etwas in die Hand zu geben. Menschen mögen Spielzeug und greifbare Dinge, und obwohl das mechanische Design manchmal nur 1% der Entwicklungszeit des Endprodukts ausmacht, glauben die Menschen, dass Sie bereits 80% davon fertiggestellt haben. Mit Software-Prototyping ist es nicht so einfach, dieses Niveau zu erreichen. Sketch und InVision sind großartige Tools, aber Benutzer verstehen sofort, dass dies kein echtes Produkt ist. Die Daten sind statisch und ihre Interaktion hat keinen Einfluss darauf. Dies ist einer der Gründe, warum digitale Produktmanager den agilen Ansatz und das Konzept von MVP gewählt haben. Es ist sehr schwer vorstellbar, wie Benutzer mit Ihrem Produkt interagieren und es lieben werden, bevor es fertig ist und über echte Daten verfügt. Sie möchten es daher so schnell wie möglich versenden und echte Rückmeldungen einholen.

Physisches und digitales Prototyping

Entwicklung

Frühe Entscheidungen haben den größten Einfluss: Jedes Mal, wenn ich ein neues Projekt starte, bin ich aufgeregt. Was wäre die richtige Architektur? Welche Technologie passt am besten dazu? Sollten wir eine 8-Bit-MCU oder eine 32-Bit-CPU wählen? Ist dies ein gutes Projekt, um GraphQL einzuführen, oder bleiben wir wieder bei REST? Welche Funktechnologie passt am besten zum Anwendungsfall: Bluetooth 5 oder Narrowband IOT? Was ist die richtige Datenbank? PostgreSQL oder vielleicht diesmal eine Grafikdatenbank? Diese Entscheidungen sind für den Erfolg des Projekts so wichtig. Manchmal treffen wir technische Entscheidungen ohne angemessene Analyse zu schnell und drei Monate später bereuen wir sie. Es wird zu schwierig und schmerzhaft, sie zu ändern, und es ist einfacher, die Technologieinvestition als Aktivposten und nicht als Barriere zu betrachten. Dies gilt sowohl für elektronische als auch für digitale Produkte. Allerdings ist das Ändern des Prozessortyps nach dem Versand Ihrer Produkte an Ihre Kunden fast unmöglich, wenn nicht sogar peinlich.

Frühzeitige Entscheidungen haben den größten Einfluss

Entwicklung: Es gibt viele Unterschiede zwischen dem Entwicklungsprozess elektronischer und digitaler Produkte, und es gibt nicht viele Ähnlichkeiten. Die meiste Entwicklungszeit für eine Leiterplatte fließt in die Auswahl der richtigen Komponenten und die Gestaltung des Layouts. Ein Teil der Arbeit ist rein technischer Natur und es müssen Drähte von Komponente U1, Pin 120, zu Komponente U17, Pin 12, angeschlossen werden. Bei einigen Aufgaben müssen drei Sensortypen vollständig prototypisiert werden, um das Rauschen und den Stromverbrauch der einzelnen Sensoren zu messen. Embedded-Entwicklung ist schwer zu debuggen und zu optimieren. Es ist durchaus üblich, dass Embedded-Entwickler GPIO-Pins verwenden, um festzustellen, ob eine Funktion aufgerufen wurde, und um zu messen, wie lange die Ausführung gedauert hat. Die Verwendung von FPGA in Ihrem elektronischen Produkt ist eine mutige Entscheidung, aber manchmal die einzige Lösung, um Ihre Leistungs- / Kostenziele zu erreichen. Die FPGA-Entwicklung ist ein völlig anderes Gebiet und bewegt sich zwischen der ASIC-Entwicklung, der Leiterplattenentwicklung und der Embedded-Entwicklung. Für Softwareentwickler wird die meiste Zeit in das Schreiben von Code investiert. Es ist sehr befriedigend, Ihre tägliche Arbeit zu betrachten, all diese Codezeilen, Code-Commits und Pull-Anforderungen. Das hört sich einfach an, aber die Menge an Code und Änderungen ist enorm. Ein ordnungsgemäßes Konfigurationsmanagement und ein entsprechender Überprüfungsprozess sind daher unerlässlich, um die Codebasis zu organisieren, die technische Verschuldung zu verringern und das Wissen im gesamten Team zu erweitern.

Algorithmen, Physik und Datenwissenschaft: Dies ist in der Regel das Gehirn des Produkts, in dem Unternehmen ihre geistigen Eigentumsrechte behaupten. Board-Designer arbeiten mit Physikern zusammen, um Sensoren auszuwählen, AFE (analoges Front-End) um sie herum zu entwerfen oder eine zu entwerfen spezielle Antenne. Embedded-Entwickler arbeiten mit DSP-Ingenieuren und Mathematikern zusammen, um Echtzeit-DSP-Algorithmen in ihre Software einzubetten, um Signale zu filtern, Muster zu erkennen oder um eine optimierte mathematische Formel zur Verarbeitung / Codierung der Daten zu implementieren. Echtzeit bedeutet, dass Sie die Verarbeitung innerhalb einer bestimmten Anzahl von CPU-Zyklen abschließen müssen, da Sie sonst nicht bereit sind, das nächste Signal zu verarbeiten und es zu verpassen, oder Ereignisse nicht innerhalb der erforderlichen Latenz ausgeben können. Backend-Entwickler arbeiten mit Datenwissenschaftlern zusammen, um Batch-Prozesse zu implementieren, um neue Produkte zu empfehlen, Anomalien zu finden, Freunde vorzuschlagen, ein Deep-Learning-Modell zu trainieren, NLP zum Analysieren von Text zu verwenden, Webseiten zu bewerten usw. Frontend-Entwickler haben den ganzen Spaß. Sie machen Datenvisualisierung. Mit einer Bibliothek wie D3JS erstellen sie beeindruckende Grafiken und präsentieren den Benutzern die Daten auf nützliche und aggregierte Weise.

Überall im Stapel kümmern sich diese Leute darum, das Rauschen zu reduzieren, die Signale zu verbessern und das richtige Gleichgewicht zwischen Fehlerkennung (falsch negativ) und falschem Alarm (falsch positiv) zu finden. Sie werden weinen, dass sie mehr Daten benötigen oder mehr Experimente machen und springen Zum Glück, wenn es ihnen gelingt, die Leistung um 5% zu verbessern. Eine interessante Produktentscheidung besteht darin, zu entscheiden, wie die datenwissenschaftlichen Aufgaben auf den Stapel aufgeteilt werden sollen. Alexa enthält beispielsweise eine Reihe von Mikrofonen auf Platinenebene, DSP-Code auf Firmware-Ebene und ausgefeilte Datenwissenschaft auf Backend-Ebene, um unsere Sprache zu erkennen.

Tools: Stellen Sie sich einen Frontend-Entwickler und einen Embedded-Entwickler vor, die ihre Entwicklungstools miteinander vergleichen. Der Embedded-Entwickler führt den Frontend-Entwickler an seinen Tisch und macht ihn auf die Unterschiede zwischen einem Netzteil, einem Oszilloskop und einem Logikanalysator aufmerksam. Der Frontend-Entwickler bringt den eingebetteten Entwickler dann zur nächsten Kaffeestelle. Sie werden Kaffee bestellen und einen ruhigen Ort finden, an dem sie ein paar Stunden zusammen verbringen können. Anschließend wechselt er in den Entwicklungsmodus seines Chrome-Browsers und zeigt dem eingebetteten Entwickler, wie er den Netzwerkverkehr betrachtet und den CSS-Stil eines bestimmten HTML-Elements erkennt.

Was bedeutet devtools für ...

Die Debug-Tools sind von Entwickler zu Entwickler unterschiedlich, und ihre effiziente Verwendung ist die eigentliche Erfahrung. Instinktiv zu wissen, wo das Problem liegt, und Ihre Tools zu nutzen, um sich darauf einzulassen, ist die wichtigste Fähigkeit der Entwickler. Ich habe gesehen, wie Entwickler Stunden und Tage damit verbracht haben, ein Problem zu beheben, und dann einen erfahrenen Entwickler um Hilfe gebeten, der das Problem in Sekundenschnelle findet. Ich kann das nicht genug betonen, für jede Aufgabe das richtige Werkzeug zu haben, heißt professionell zu sein. Und das gilt für jeden Beruf.

Welche Bedeutung haben Debug- und Testtools für ...Software-Entwickler empfinden dies als einschüchternd

QS und Testen

Umgebungstests: Wenn wir unser Produkt testen, möchten wir sicherstellen, dass es in allen verschiedenen Konfigurationen und Umgebungen, in denen Benutzer es voraussichtlich verwenden, ordnungsgemäß funktioniert. Bei physischen Produkten bedeutet Umwelt normalerweise Temperatur (extrem kalt, extrem heiß), Vibration (stellen Sie sich ein Automobilprodukt vor), Schock (fällt von Ihren Händen auf einen Betonboden), Feuchtigkeit, UV- und Sonnenstrahlung, ESD (diese kleinen Blitze, die auftreten können) (vor elektrostatischer Entladung geschützt), EMI / RFI usw. Für digitale Produkte bedeutet Umgebung normalerweise Browsertyp (Chrome, Internet Explorer, Firefox ..), Betriebssystem (Android, IOS, OSX, Windows), Gerät (Mobil, Desktop, Konferenz) Bildschirm) und Netzwerkkonnektivität (4G, Wifi, Offline). Normalerweise testen wir nicht jede mögliche Kombination, da dies unmöglich wäre. Daher haben wir eine Reihe von Konfigurationen entwickelt, die hoffentlich genügend Szenarien abdecken, um Probleme innerhalb der Produktspezifikation zu erkennen.

Was bedeutet externe Umgebung für ...

Zuverlässigkeit / Haltbarkeit (Lebensdauertest): Dies sind Tests, die simulieren sollen, was mit dem Produkt während seiner gesamten Lebensdauer passiert. Es ist relevanter für physische Produkte, bei denen Materialien ihre Fehlerstellen erreichen. Die Branche hat sich bestimmte Regeln ausgedacht, um das Produktalter zu beschleunigen, indem wir es extremen Umweltbedingungen aussetzen. Um zu testen, ob ein Produkt nach fünf Jahren bei Raumtemperatur ordnungsgemäß funktioniert, können wir es einen Tag lang bei 70 Grad und 10 g Vibration testen (nur als Beispiel !!!). Diese Tests werden als HALT-Tests (Highly Accelerated Life-Tests) bezeichnet

Tests unter extremen Bedingungen (Last, Kante): Dies sind Tests, die das Verhalten des Produkts unter extremen oder Kantenbedingungen testen. Wenn ein elektronisches Produkt beispielsweise mit 5 V arbeitet, wird es bei 4,5 V und 5,5 V getestet. Es können sogar Spannungsspitzen von bis zu 25 V oder -5 V eingespeist werden, um festzustellen, ob das Produkt gegen Benutzerfehler oder elektrische Überspannungen beständig ist. Bei digitalen Produkten können Eingabefelder mit unangemessenen Werten in Frage gestellt werden. Zum Beispiel könnten wir Namen eingeben, die 1000 Zeichen lang sind oder bedeutungslose Symbole haben. Wenn wir das Produkt für eine bestimmte Auslastung (50 gleichzeitige Benutzer) entwickelt haben, testen wir das Verhalten unter 100 gleichzeitigen Benutzern. Die Idee dieser Tests besteht hauptsächlich darin, neue Fehlermodi aufzudecken. Wir erwarten nicht, dass das Produkt einwandfrei funktioniert, stellen jedoch möglicherweise wichtige Probleme, unerwartete Verhaltensweisen oder Engpässe fest, die auch unter normalen Bedingungen relevant sind.

Konformitäts- / Sicherheitstests: Manchmal müssen beide Produkttypen den Standards entsprechen und diese erfüllen. Elektronische Produkte müssen sicher und zuverlässig sein und den Benutzer vor elektrischem Schlag oder Überhitzung schützen (UL, CE, FCC ..). Außerdem müssen sie bestimmten Funkstandards wie Wifi oder Bluetooth entsprechen. Digitale Produkte, die mit personenbezogenen Daten (PII) wie Kreditkartennummern (PCI, ISO / IEC 27001, NIST) oder Sozialversicherungsnummern (GDPR) umgehen, müssen die Daten vor Angriffen jeglicher Art und vor Fahrlässigkeit der Mitarbeiter schützen. Für beide Produkte ist der Compliance-Prozess teuer und langwierig. Es gibt jedoch Möglichkeiten, die Kosten zu senken und vorab genehmigte Module und Services zu verwenden.

Was bedeutet Compliance für ...

Testabdeckung: Als Boarddesigner können Sie nie sicher sein, dass der Herstellungsprozess fehlerfrei war. In einigen Fällen befinden sich zwischen benachbarten Spuren winzige Kurzschlüsse, die Sie nur mit einem Mikroskop sehen können. In anderen Fällen sind elektronische Komponenten nicht zuverlässig genug oder können sogar gefälschte Komponenten sein. Im Rahmen des Qualitätsprozesses müssen Board-Designer und Embedded-Entwickler zusammen Test-Tools schreiben, die sicherstellen, dass jede Verbindung und jede Komponente erwartungsgemäß mit einer 100% igen Abdeckung funktioniert. Ich habe JIGs getestet, die jeden Sensor und jeden Eingang auf der Platine simulieren, um eine 100% ige Abdeckung zu erreichen. Es ist auch eine gute Praxis, diese Tests parallel zu hochbeschleunigten Screening-Tests (HASS) durchzuführen, bei denen die Platine Vibrationen und thermischen Zyklen ausgesetzt ist.

In ähnlicher Weise empfiehlt es sich bei Software, Testcode zu schreiben, der mindestens 99% Ihres Codes abdeckt. Bevor Sie neuen Code in der Produktionsumgebung bereitstellen, führt ein Automatisierungstool die Test-Code-Suite aus und überprüft, ob alles, was zuvor funktioniert hat, noch funktioniert. In beiden Fällen sollte die Arbeit an diesen Testwerkzeugen zusammen mit der Produktentwicklung beginnen (manchmal sogar vor: TDD) und angemessen finanziert werden.

Design / Code Review: Menschen machen Fehler. Jeder, der denkt, dass er das nicht tut, hat entweder nicht genug Erfahrung oder ein kurzes Gedächtnis. Insbesondere beim Entwerfen des Layouts einer Leiterplatte und beim Platzieren neuer Komponenten können Fehler in Bezug auf die Anschlussbelegung und die physischen Abmessungen der neuen Komponenten leicht auftreten. Fehler finden Sie erst Wochen oder Monate später. Sie können sich das Design ansehen und es anhand des Datenblattes überprüfen, erneut suchen und erneut überprüfen, und in beiden Fällen werden Sie es vermissen. Aus diesem Grund sind eine unabhängige Prüfung und Abnahme eine Standardpraxis bei der Entwicklung elektronischer Produkte. Softwareentwickler machen häufig Fehler in Bezug auf die Sicherheit. Beispielsweise legen sie häufig vertrauliche Schlüssel in öffentlichen Code-Repositorys ab oder legen sie dem Client offen. Pull Request ist eine Methode, mit der andere Teammitglieder über Ihre Änderungen informiert werden, bevor Sie sie festschreiben. Sie dienen mehreren Zwecken: Erkennen von Fehlern und Problemen, Verbessern der Lesbarkeit und Dokumentation des Codes und Weitergeben von Wissen im gesamten Team. Die Paarprogrammierung ist eine weitere Methode, mit der Softwareentwickler Wissen austauschen und den Code des jeweils anderen überprüfen.

Konfigurationsmanagement: CM ist die Praxis des systematischen Umgangs mit Änderungen. Es wird verwendet, um Versionen des Produkts zu dokumentieren und Änderungen zwischen den Versionen nachzuverfolgen. Mit einem guten Konfigurationsverwaltungssystem können Sie jede Version des Produkts erstellen und testen, indem Sie nur die darin enthaltenen Artefakte ohne weiteres externes Wissen verwenden. Die Entwickler von DevOps verwenden SCM-Tools (Software Configuration Management) wie GIT, Ansible, Terraform und Chef, um den Code, die Konfiguration und die Infrastruktur des Produkts aufzuzeichnen. Sie können diese Änderungen auch mit JIRA-Problemen verknüpfen, um die Beziehung zwischen der Fehler- / Fehler- / Funktionsanforderung und den tatsächlichen daraus resultierenden Änderungen zu dokumentieren. Elektronikingenieure verwenden Tools, die manchmal als PLM (Product Lifecycle Management) und manchmal als HCM (Hardware Configuration Management) bezeichnet werden. Im Wesentlichen dienen sie demselben Zweck, beinhalten jedoch unterschiedliche Integrationen und Prozesse. Beispielsweise kann ein PLM-System auch in Ihr ERP-System integriert werden, um anzuzeigen, welche Teile der Stückliste des Produkts in Ihrem Bestand vorhanden sind.

Herstellung und Produktion

Sie sollten Ihren Hersteller als Ihren Partner und nicht als Ihren Lieferanten betrachten. Schließlich geben Sie Ihrem Hersteller Ihr sensibelstes Kapital: alles, was für die Herstellung Ihres Produkts erforderlich ist! Ihr Hersteller wird Sie dabei unterstützen, neue Fertigungsmethoden einzuführen, Fehler zu reduzieren, die Effizienz des Prozesses zu verbessern und in gewisser Weise einen Teil der Risiken und Vorteile des Produkts zu teilen.

Lean Lean ist alles, was mit Kosteneinsparungen zu tun hat. Lean bedeutet für physische Produkte:

  • Keine Verzögerung in allen Phasen der Produktionslinie
  • Pay Defects, höchste Qualität für jedes Endprodukt
  • Maschinen / Menschen sind zu 100% ausgelastet
  • Wissensfeedback: Jede Lektion und jeder Einblick verbessern den Prozess
  • Just in Time Fertigung: Jedes Produkt wird verkauft, kein Abfall

Für digitale Produkte bedeutet Lean:

  • Automatische Skalierung: Skalierung der Rechenressourcen basierend auf der Last
  • Zahlen Sie pro Stunde

Fertigungspipelines: Das Einrichten einer Montagelinie unterscheidet sich nicht wesentlich vom Einrichten einer Software-CI / CD-Pipeline (Continuous Integration / Continuous Delivery). Wenn Sie das Phoenix-Projektbuch gelesen haben, werden Sie sich wahrscheinlich daran erinnern, wie einige der Konzepte von Lean und DevOps im Buch aus der physischen Fertigungslinie abgeleitet wurden. Beide Pipelines übernehmen alles, was zum Bau, Testen und Versenden Ihres Produkts erforderlich ist. Wenn Sie mehr Automatisierung hinzufügen, können Sie schneller versenden. Für elektronische Produkte bedeutet dies, Kosten und Fehler zu reduzieren und die Kapazität zu verbessern, für digitale Produkte bedeutet dies schnellere Benutzertests und adaptives Design.

Weltweite Lieferung: Es gibt eine interessante Ähnlichkeit zwischen Content Delivery Networks (CDN), mit denen Web-Assets basierend auf ihrem geografischen Standort an Benutzer geliefert werden, und der Art und Weise, wie die Fertigung weltweit verteilt wird, um die Versandkosten zu senken und Produkte zu lokalisieren. Das Zwischenspeichern von Inhalten kann als lokales Warehouse oder als Fulfillment-Service wie Amazon angesehen werden. Bei beiden Produkttypen verbessert die Präsenz vor Ort das allgemeine Kundenerlebnis auf der ganzen Welt

Es mag den Anschein haben, dass die weltweite Präsenz physischer Produkte schwieriger ist. Datenschutzbestimmungen und die Lokalisierung von Sprachen erfordern jedoch ebenfalls erhebliche Anstrengungen

Cloud-Dienste: Cloud-Dienste sind fantastisch. Sie können Ihr digitales Produkt in Sekundenschnelle erstellen, indem Sie aus Hunderten von Webdiensten auswählen. Ein paar Klicks und es wird automatisch in mehr als 20 Rechenzentren auf der ganzen Welt ausgeführt und je nach Bedarf skaliert. In der Fertigung gibt es nichts Vergleichbares, aber dies könnte die nächste industrielle Revolution sein. Stellen Sie sich ein digitales Produkt vor, in dem Sie mithilfe vorkonfigurierter Module wie 3D-Druck, Leiterplattenherstellung, Komponentenbeschaffung, Leiterplatten- und Kabelkonfektionierung eine Fertigungspipeline einrichten, Tests durchführen und direkt von einer lokal automatisierten Fertigungsstätte an Ihre Kunden versenden können. Darüber hinaus ermöglicht der Service dem Endbenutzer, die Farbe des Produkts, die Form und andere Personalisierungsmerkmale anzupassen. Dies scheint ein Traum zu sein, aber ich bin mir sicher, dass Amazon irgendwo auf der Welt an einem solchen Service arbeitet (zumindest hoffe ich, dass dies der Fall ist).

Fazit

Es gibt viele Unterschiede zwischen dem Entwicklungsprozess elektronischer und digitaler Produkte, aber wenn man es aus einer Perspektive von 20 Jahren betrachtet, ist es erstaunlich, wie viele Designprinzipien und Prozesse digitaler Produkte heute von physischen Produktmanagern verwendet werden. AWS hat kürzlich FreeRTOS für eingebettete Systeme angekündigt. Ich gehe davon aus, dass es in 10 bis 20 Jahren keinen signifikanten Unterschied zwischen dem Entwicklungsprozess eines digitalen und eines physischen Produkts geben wird.

Wenn Sie mehr über meine Reise erfahren und erfahren möchten, wie Sie ein Team führen, das in beiden Welten lebt, können Sie mich gerne direkt erreichen.