Ontwerp en ontwikkeling van elektronische producten versus digitale producten

Ik had het geluk om de ontwikkeling van zowel fysieke producten als digitale producten te ontwikkelen en te beheren. Terwijl ik de liefde en passie voor beide deel, dacht ik mijn standpunten en enkele observaties over de verschillen en overeenkomsten tussen hun ontwikkelingsprocessen te presenteren.

Wat betekent een product voor ...

Wat is een product? Iets dat wordt vervaardigd en verkocht, of iets dat waarde creëert voor gebruikers? De eerste definitie is alleen van toepassing op fysieke producten en geeft weer wat we met producten doen en hoe we ze bouwen. De tweede definitie is opener en moderner en weerspiegelt waarom we producten nodig hebben. Fysieke producten zijn tastbaar; gebruikers kunnen ze aanraken, zien, ruiken en voelen. We hebben allemaal video's gezien van enorme fabrieken en we kunnen begrijpen hoe duur en complex het is om ze te produceren. Digitale producten leven in de cloud of in externe datacenters. Het is moeilijker voor ons om hun omvang, complexiteit en wat het betekent om er een te bouwen te begrijpen. Als we bijvoorbeeld naar de frontend van Google Zoeken kijken, zien we slechts één zoekregel, maar achter de scène, aan de backend, zijn er honderdduizenden servers actief en miljarden regels codes.

Toen softwareontwikkelaars ongeveer 25 jaar geleden begonnen met het bouwen van digitale producten, gebruikten ze vergelijkbare processen en tools die werden gebruikt om fysieke producten te bouwen. Het meest beproefde proces voor projectbeheer was destijds Waterfall, omdat het perfectie gedurende de hele projectcyclus garandeerde. Toen digitale projectmanagers echter meer ervaring opdeden en in bijna de helft van de projecten faalden, realiseerden ze zich dat ze verandering nodig hadden. Ze begonnen hun eigen tools te bouwen en kwamen met hun unieke onconventionele processen. Rond 2001 begonnen steeds meer teams Scrum en Kanban te gebruiken en ontstond het agile manifest. Git werd opgericht door Linus Torvalds in 2005, die de basis legde voor open source-projecten. Misschien is perfectie voor digitale producten niet zo belangrijk als behendigheid. Tegenwoordig, 25 jaar later, liggen de ontwikkelingsprocessen, de tools en de culturen van beide productteams ver uit elkaar.

Gedurende de laatste vijf jaar werd het uiterst eenvoudig en goedkoop om elektronica in fysieke producten te integreren en deze met internet te verbinden met een soort app - een trend die IOT (Internet of Things) wordt genoemd. Het kost ongeveer 2 $ per product om dit te doen, wat verklaart waarom we zo veel nieuwe IOT-producten de laatste tijd zien opkomen, waarvan sommige behoorlijk grappig zijn ... Op productteamniveau combineert deze trend twee soorten culturen, twee soorten processen en twee soorten hulpmiddelen. Wanneer twee culturen met elkaar botsen, gebeuren er interessante dingen. Open source hardware is nu overal om ons heen en sommige mensen begonnen zichzelf makers te noemen. Wat is het verschil tussen een maker en een fabrikant? Zullen we een convergentie tussen deze processen zien? of zijn we gedoemd, als CTO's en IOT-productmanagers om voor altijd een brug te slaan tussen deze culturen?

Ik hoop dat je deze blog zowel interessant als nuttig vindt en dat het ontwikkelaars uit de hele stapel helpt elkaars uitdagingen te begrijpen.

Rollen en vaardigheden

Er is een recente trend voor softwareontwikkelaars om de volledige softwarestack te ontwikkelen. Dit betekent dat ze zowel backend-code ontwikkelen: de code die op de server / cloud draait, als frontend-code: de code die op het apparaat wordt uitgevoerd. Ze kunnen zelfs de rol van DevOps overnemen: technici die verantwoordelijk zijn voor het opzetten, configureren, beveiligen en vervolgens automatiseren van het veranderingsproces. Het is niet onmogelijk voor een enkele persoon om een ​​eenvoudige digitale app of een game te bouwen en te starten. Wanneer we echter naar IOT-producten kijken die meestal zowel een elektronisch apparaat als een soort app bevatten, vereist het technische team meer vaardigheden en rollen.

Ingesloten ontwikkelaars zijn verantwoordelijk voor de code die op het apparaat wordt uitgevoerd en bordontwerpers zijn verantwoordelijk voor het ontwikkelen van het elektronische bord.

Hoewel vandaag, met behulp van Espruino, Javascript-ontwikkelaars in theorie alle drie de niveaus van code kunnen ontwikkelen: frontend-code, backend-code en ingebedde code, zullen ze waarschijnlijk worstelen met industrieel en bordontwerp dat volledig verschillende soorten vaardigheden vereist. Ik heb getalenteerde ontwikkelaars gezien die van alle markten thuis zijn en die snel kunnen overstappen van het aanpassen van CSS-klassen naar het schrijven van migratiescripts voor hun databases. Persoonlijk vind ik dat professionele ontwikkelaars op elk moment op slechts één laag moeten beheersen. Het gaat niet alleen om het hebben van de beste vaardigheden en technieken of om de vereiste functionaliteit te implementeren, het gaat ook om wat u belangrijk vindt en met welke gemoedstoestand u uw werk doet.

Ik heb een poging gedaan om de verantwoordelijkheden van elke rol in het team te beschrijven. Ik waardeer dat ik een gevaarlijk gebied betreed, omdat rollen in verschillende teams enigszins kunnen veranderen, dus probeer alsjeblieft het bos te zien en niet de bomen.

Waarom kan één persoon er niet om geven? Omdat er afwegingen en conflicten zijn bij de productontwikkeling en u elke behoefte op een evenwichtige en symmetrische manier wilt weergeven.

Door de jaren heen heb ik respect gezien tussen verschillende soorten ontwikkelaars, maar ook gebrek aan kennis. Ik heb frontend-ontwikkelaars gezien die denken dat backend gemakkelijk is en backend-ontwikkelaars die denken dat frontend saai is. Ik heb ook ingesloten ontwikkelaars gezien die niet weten wat REST is. Ik heb eerder gezegd dat ik niet geloof dat professionele ontwikkelaars en ingenieurs meer dan één laag moeten beheersen. Ik geloof echter sterk dat ze moeten weten wat het betekent om er één te zijn en misschien zelfs een stap verder gaan en werken aan een eenvoudig project dat hen blootstelt aan de verschillende uitdagingen en processen. Brede kennis kan helpen bij het verbeteren van de communicatie, het respect en de transparantie tussen de teamleden, en zal ook de creativiteit en productiviteit van het team als geheel vergroten.

Project management

Wat is het verschil tussen een project en een product? Een project is een plan om een ​​bepaald doel of bereik binnen een bepaalde tijd en middelenbeperkingen te bereiken. Een project heeft een begin en een einde. Als u geen projectdeadline hebt, beheert u waarschijnlijk geen project. Wanneer het project eindigt, blijft het product leven.

Risicoanalyse: Laten we de verschillen en overeenkomsten tussen projectbeheer van een fysiek product en een digitaal bespreken. Persoonlijk beschouw ik projectmanagement graag als een risicogestuurd proces waarbij ik constant de toprisico's identificeer en probeer een plan te bedenken om ze te minimaliseren. Projectrisico's zijn alles wat het succes van het project beïnvloedt, d.w.z. het niet bereiken van het doel, de deadline, de scope, de kosten of de uiteindelijke kwaliteit van de producten. Voor digitale producten is een van de grootste risico's het bouwen van een product dat gebruikers niet nodig hebben of leuk vinden. Digitale productmanagers bedenken, geloven, speculeren en vertellen een goed verhaal, maar totdat gebruikers met het product beginnen te communiceren, zijn dit slechts aannames. Om de veronderstelling te testen, moeten productmanagers snel verzenden, hun hypothese testen en behendig zijn. Voor fysieke producten is het grootste risico om in een zeer laat stadium een ​​onherstelbaar probleem te vinden, nadat er al honderden en duizenden producten zijn vervaardigd. Productie vereist perfectie, en zonder dit zal het project mislukken. Om dit risico te verminderen, bouwen fysieke projectmanagers een evaluatie- en afmeldproces tussen fasen, wat Waterfall wordt genoemd.

Elke methode is ontworpen om verschillende risico's te verminderen en elke projectmanager moet op basis van risicoanalyse een besluit nemen over het projectplan. Soms zijn individuen en interacties belangrijker dan processen en tools, en soms zijn processen belangrijker. Soms is werkende software belangrijker dan documentatie en soms is documentatie belangrijker. Soms is klantensamenwerking belangrijker dan schriftelijk contract. En soms kan een schriftelijk contract uw bedrijf redden. Soms is reageren op verandering belangrijk, maar soms is het volgen van een plan belangrijker. Je snapt wat ik bedoel.

Tools en teamceremonies: projectmanagers moeten tools gebruiken die het proces implementeren waarmee ze de projecten willen beheren. Microsoft Project is een geweldig hulpmiddel voor watervalprojecten. JIRA en Trello zijn geweldige hulpmiddelen voor agile projecten en ondersteunende processen zoals Kanban en Scrum. Wat de tool ook is, onthoud dat het slechts een tool is en niet de essentie. Teams hebben ook verschillende ceremonies. In Waterfall komen teams vóór elke herfst samen en bekijken documenten, door CAD gegenereerde outputs of testspecificaties. Agile-team kan elke dag samenkomen voor een dagelijkse stand-up en om de twee weken voor sprintplanning. Deze ceremonies brengen de teamleden op één lijn met het plan en verbeteren de communicatie tussen de teamleden.

Ontwerp en prototyping

Ontwerp: is er tegenwoordig een product waarbij ontwerp geen grote rol speelt in het succes ervan? Wat is een product als het niet iets is dat we willen verkopen? Iets dat aantrekkelijk en esthetisch moet zijn, waar we trots op kunnen zijn. Voorbij zijn de dagen voorbij dat de juiste functionaliteit en prestaties goed genoeg waren. Voor elektronische producten moet bij industrieel ontwerp niet alleen rekening worden gehouden met menselijke interactie, bruikbaarheid en klantervaring, maar ook met de omgevingsomstandigheden waarin het product wordt gebruikt en het productieproces (DFM: ontwerp voor productie). Voor digitale producten moet het ontwerp ook betrekking hebben op de verschillende apparaten waarop de software kan worden uitgevoerd (mobiel, desktop, grote schermen) en alle soorten rollen en gebruikers die er interactie mee hebben.

Verschillende soorten ontwerpmethodiek zijn van toepassing op verschillende soorten producten: ontwerp van ervaring beschouwt het product als onderdeel van een plezierige ervaring die we willen creëren, d.w.z. “we verkopen geen game, we verkopen een familie-ervaring van een uur”. Serviceontwerp ziet het product als onderdeel van een end-to-end-service tussen een serviceprovider en een gebruiker. “Vanaf het moment dat u hebt besloten om te reizen tot u op uw bestemming aankomt”, “Wij verkopen geen beveiligingscamera, wij verkopen u 24/7 bescherming”.

Prototyping: met behulp van 3D-printers en VR / AR-technologie is het uiterst eenvoudig om een ​​mechanisch prototype van uw fysieke product te bedenken. Je kunt het je klanten laten zien, er wat stickers op plakken, wat draden en LED's aansluiten, ze zullen het doel ervan onmiddellijk begrijpen en je kunt ze misschien overtuigen dat je product klaar en commercieel is. Je kunt het in de echte omgeving plaatsen en kijken of het mechanisch past en of het gemakkelijk vast te houden is. U kunt tien versies maken en deze vergelijken en de definitieve configuratie bepalen. Er is niets krachtiger dan uw klanten en beleggers iets te geven om in hun hand te houden. Mensen houden van speelgoed en tastbare dingen en hoewel het mechanische ontwerp soms slechts 1% van het eindproduct is in termen van ontwikkelingstijd, zullen mensen geloven dat je er al 80% van hebt voltooid. Met software-prototyping is het niet zo eenvoudig om dit niveau te bereiken. Sketch en InVision zijn geweldige hulpmiddelen, maar gebruikers begrijpen meteen dat dit geen echt product is. De gegevens zijn statisch en hun interactie heeft er geen effect op. Dit is een deel van de reden waarom digitale productmanagers de agile-aanpak en het concept van MVP hebben gekozen. Het is heel moeilijk om je voor te stellen hoe gebruikers zullen communiceren en dol zullen zijn op je product voordat het klaar is en echte gegevens heeft, dus je wilt het zo snel mogelijk verzenden en beginnen met het verzamelen van echte feedback.

Fysieke en digitale prototyping

Ontwikkeling

Vroege beslissingen hebben de grootste impact: elke keer dat ik een nieuw project start, ben ik enthousiast. Wat zou de juiste architectuur zijn? welke technologie past daar het beste bij? Moeten we een 8-bits MCU of een 32-bits CPU kiezen? Is dit een goed project om GraphQL te introduceren, of zullen we het opnieuw bij REST houden? Welke draadloze technologie past het beste bij de use case: Bluetooth 5 of Narrowband IOT? Wat is de juiste database om te gebruiken? PostgreSQL of misschien een grafische database deze keer? Deze beslissingen zijn zo belangrijk voor het succes van het project. Soms nemen we technische beslissingen te snel zonder goede analyse en dan drie maanden later hebben we er spijt van, het wordt te moeilijk en pijnlijk om ze te veranderen, en het is gemakkelijker om de technologische investering als een pluspunt en niet als een barrière te beschouwen. Dit geldt zowel voor elektronische producten als digitale producten, hoewel het wijzigen van het processortype na verzending van uw producten naar uw klanten bijna een onmogelijke taak is, zo niet een pijnlijke klus.

Vroege beslissingen hebben de grootste impact

Ontwikkeling: er zijn veel verschillen tussen het ontwikkelingsproces van elektronische producten en digitale producten en er zijn niet veel overeenkomsten. Het grootste deel van de ontwikkeltijd voor een printplaat gaat naar het selecteren van de juiste componenten en het ontwerpen van de lay-out. Een deel van het werk is puur technisch, het verbinden van draden van component U1 pin 120 met component U17 pin 12. En sommige taken vereisen volledige prototyping rond drie soorten sensoren alleen om het geluid en het stroomverbruik van elk van hen te meten. Ingebedde ontwikkeling is moeilijk te debuggen en te optimaliseren, het is heel gebruikelijk om ingebedde ontwikkelaars GPIO-pinnen te zien gebruiken om te detecteren of een functie werd aangeroepen en om te meten hoeveel tijd het kostte om te werken. Het gebruik van FPGA in uw elektronische product is een gewaagde beslissing, maar is soms de enige oplossing om uw prestatie- / kostendoelstellingen te bereiken. FPGA-ontwikkeling is een heel ander territorium en bevindt zich ergens tussen ASIC-ontwikkeling, ontwikkeling van printplaten en ingebedde ontwikkeling. Voor softwareontwikkelaars wordt meestal geïnvesteerd in ... het schrijven van code. Het is heel bevredigend om naar je dagelijkse werk te kijken, al die regels code, code commits en pull-aanvragen. Dit klinkt eenvoudig genoeg, maar de hoeveelheid code en wijzigingen is enorm, dus een goed configuratiebeheer en beoordelingsproces is essentieel om de codebasis georganiseerd te houden, de technische schuld te verminderen en de kennis binnen het team te vergroten.

Algoritmen, natuurkunde en gegevenswetenschap: dit is meestal het brein van het product, waar bedrijven de neiging hebben te beweren dat hun IP erin zit. Bestuursontwerpers werken samen met fysici om sensoren te selecteren, AFE (analoge front-end) rondom hen te ontwerpen of een ontwerp te maken speciale antenne. Ingesloten ontwikkelaars werken met DSP-ingenieurs en wiskundigen om realtime DSP-algoritmen in hun software in te bedden om signalen te filteren, patronen te detecteren of een geoptimaliseerde wiskundige formule te implementeren om de gegevens te verwerken / coderen. Real-time betekent dat u de verwerking binnen een bepaalde hoeveelheid CPU-cycli moet voltooien, anders bent u niet klaar om het volgende signaal te verwerken en te missen of kunt u geen gebeurtenissen uitvoeren binnen de vereiste latentie. Backend-ontwikkelaars werken met datawetenschappers om batchprocessen te implementeren om nieuwe producten aan te bevelen, afwijkingen te vinden, vrienden voor te stellen, een diep leermodel te trainen, NLP te gebruiken om tekst te analyseren, webpagina's te scoren, enz. Frontend-ontwikkelaars hebben alle plezier. Ze doen datavisualisatie. Met een bibliotheek zoals D3JS creëren ze verbluffende beelden en presenteren ze de gegevens op een nuttige en geaggregeerde manier.

Overal in de stapel zullen deze mensen zich zorgen maken over het verminderen van ruis, het verbeteren van signalen en het vinden van de juiste balans tussen misserdetectie (vals negatief) en vals alarm (vals positief), ze zullen huilen dat ze meer gegevens nodig hebben of meer experimenten doen, en ze zullen springen gelukkig als ze erin slagen de prestaties met 5% te verbeteren. Een interessante productbeslissing is om te beslissen hoe de data science-taken over de stapel worden verdeeld. Als voorbeeld bevat Alexa een reeks microfoons op directieniveau, wat DSP-code op firmwareniveau en geavanceerde gegevenswetenschap op backend-niveau om onze spraak te herkennen.

Tools: stel u voor dat een frontend-ontwikkelaar en een embedded ontwikkelaar hun ontwikkeltools met elkaar vergelijken. De embedded ontwikkelaar zal de frontend ontwikkelaar naar zijn / haar tafel brengen en wijzen op de verschillen tussen een voeding, een oscilloscoop en een logische analysator. De frontend-ontwikkelaar brengt de ingebedde ontwikkelaar vervolgens naar de dichtstbijzijnde koffieplaats. Ze zullen koffie bestellen en een rustige plek vinden waar ze een paar uur samen kunnen doorbrengen. Zij / hij zal dan hun Chrome-browser in de ontwikkelingsmodus schakelen en de ingebedde ontwikkelaar laten zien hoe hij naar het netwerkverkeer moet kijken en hoe hij de CSS-stijl van een bepaald HTML-element kan zien.

Wat is de betekenis van devtools om ...

Debugtools variëren van ontwikkelaar tot ontwikkelaar en de efficiënte ervaring ligt daar bij de echte ervaring. Instinctief weten waar het probleem is en je tools gebruiken om erbij te horen, is de belangrijkste vaardigheid van ontwikkelaars. Ik heb gezien dat ontwikkelaars uren en dagen een probleem opsporen en vervolgens hulp vragen aan een ervaren ontwikkelaar die het probleem binnen enkele seconden vindt. Ik kan dit niet genoeg benadrukken, het hebben van de juiste tools voor elke taak is wat professioneel zijn betekent. En dat geldt voor elk beroep.

Wat betekent debug- en testtools om ...Softwareontwikkelaars vinden dit intimiderend

QA en testen

Milieutests: wanneer we ons product testen, willen we controleren of het correct werkt in alle verschillende configuraties en omgevingen die gebruikers verwachten te gebruiken. Voor fysieke producten betekent omgeving meestal temperatuur (extreem koud, extreem warm), trillingen (stel je een autoproduct voor), schok (valt van je handen op een betonnen vloer), vochtigheid, UV- en zonnestraling, ESD (deze kleine bliksem die komt van elektrostatische ontlading), EMI / RFI, enz. Voor digitale producten betekent omgeving meestal browsertype (Chrome, Internet Explorer, Firefox ..), OS (Android, IOS, OSX, Windows), Apparaat (mobiel, desktop, conferentie) Scherm) en netwerkconnectiviteitsniveau (4G, Wifi, Offline). We testen normaal gesproken niet op elke mogelijke combinatie, omdat dit onmogelijk zou zijn, dus komen we met een set van configuratie die hopelijk voldoende scenario's omvat om problemen binnen de specificatie van het product te detecteren.

Wat is de betekenis van externe omgeving om ...

Betrouwbaarheid / duurzaamheid (Life Cycle Test): dit zijn tests die proberen te simuleren wat er gedurende de hele levensduur van het product gebeurt. Het is relevanter voor fysieke producten waar materialen hun falen bereiken. Er zijn bepaalde regels die de industrie heeft bedacht om ons te helpen het productleeftijd te versnellen door het bloot te stellen aan extreme omgevingscondities. Kortom, om te testen of een product na vijf jaar bij kamertemperatuur correct functioneert, kunnen we het gedurende één dag testen op 70 graden en 10 g trillingen (alleen voorbeeld !!!). Dit worden HALT-tests (Highly accelerated life) genoemd

Tests voor extreme omstandigheden (belasting, rand): dit zijn tests die het gedrag van het product in extreme of randomstandigheden testen. Als een elektronisch product bijvoorbeeld op 5 V werkt, testen we het op 4,5 V en 5,5 V, kunnen we zelfs spanningspieken van maximaal 25 V of -5 V injecteren om te zien of het product bestand is tegen fouten van gebruikers of stroompieken. Voor digitale producten kunnen we invoervelden met onredelijke waarden uitdagen. We kunnen bijvoorbeeld namen invoeren met een lengte van 1000 tekens of betekenisloze symbolen. als we het product voor een bepaalde belasting hebben ontworpen (50 gelijktijdige gebruikers), zullen we het gedrag testen onder 100 gelijktijdige gebruikers. Het idee van deze tests is vooral om nieuwe faalwijzen te ontdekken. We verwachten niet dat het product perfect werkt, maar we kunnen belangrijke problemen, onverwacht gedrag of knelpunten ontdekken die ook relevant zijn voor normale omstandigheden.

Nalevings- / beveiligingstests: beide soorten producten zijn soms vereist om aan normen te voldoen en hieraan te voldoen. Elektronische producten moeten veilig, beveiligd en betrouwbaar zijn en de gebruiker beschermen tegen elektrische schokken of oververhitting (UL, CE, FCC ..), ze moeten ook voldoen aan bepaalde draadloze normen zoals Wifi of Bluetooth. Digitale producten die omgaan met persoonlijk identificeerbare informatie (PII) zoals creditcardnummers (PCI, ISO / IEC 27001, NIST) of sofinummers (GDPR) moeten de gegevens beschermen tegen alle soorten aanvallen en nalatigheid van medewerkers. Voor beide producten is het nalevingsproces duur en lang, maar er zijn manieren om de kosten te verlagen en vooraf goedgekeurde modules en services te gebruiken.

Wat betekent naleving van ...

Testdekking: als boarddesigner weet je nooit zeker of het productieproces foutloos was. In sommige gevallen zijn er kleine shorts tussen aangrenzende sporen die je alleen met een microscoop kunt zien. In andere gevallen zijn elektronische componenten niet betrouwbaar genoeg of kunnen ze zelfs vervalste componenten zijn. Als onderdeel van het kwaliteitsproces moeten boardontwerpers en embedded ontwikkelaars samenwerken om testtools te schrijven die verifiëren dat elke verbinding en elk component werkt zoals verwacht met een dekking van 100%. Ik heb gewerkt aan het testen van JIG's die elke sensor en elke input op het bord simuleren om een ​​dekking van 100% te bereiken. Het is ook een goede gewoonte om deze tests parallel uit te voeren met zeer versnelde screeningstests (HASS) waarbij het bord wordt blootgesteld aan trillingen en thermische cycli.

Evenzo is het met software een goede gewoonte om testcode te schrijven die ten minste 99% van uw code dekt. Voordat de nieuwe code in de productieomgeving wordt geïmplementeerd, voert een automatiseringstool de testcodesuite uit en controleert u of wat ooit eerder werkte, nog steeds werkt. In beide gevallen moet het werken aan deze testtools samen met de productontwikkeling beginnen (soms zelfs daarvoor: TDD) en op passende wijze worden voorzien van middelen.

Ontwerp / codebeoordeling: mensen maken fouten. Iedereen die denkt dat niet te doen, heeft onvoldoende ervaring of heeft een kort geheugen. Met name bij het ontwerpen van de lay-out van een printplaat en het plaatsen van nieuwe componenten is het uiterst eenvoudig om fouten te maken met betrekking tot de pinout-configuratie en fysieke afmetingen van de nieuwe componenten. fouten die je pas weken of maanden later zult vinden. U kunt het ontwerp bekijken en het vergelijken met het gegevensblad, nogmaals kijken en opnieuw verifiëren, en in beide gevallen mist u het. Om deze reden zijn een onafhankelijke beoordeling en afmelding een standaardpraktijk bij de ontwikkeling van elektronische producten. Softwareontwikkelaars maken vaak fouten met betrekking tot beveiliging. Ze stoppen bijvoorbeeld vaak gevoelige sleutels in openbare code-opslagplaatsen of worden blootgesteld aan de client. Pull-verzoek is een methode om andere teamleden op de hoogte te stellen van uw wijzigingen voordat u ze vastlegt. Ze dienen meerdere doelen: om defecten en problemen te detecteren, de leesbaarheid en documentatie van de code te verbeteren en kennis binnen het team te delen. Paarprogrammering is een andere methode die door softwareontwikkelaars wordt gebruikt om kennis te delen en elkaars code te beoordelen.

Configuratiebeheer: CM is de praktijk om veranderingen systematisch te verwerken. Het wordt gebruikt om versies van het product te documenteren en om wijzigingen bij te houden die erop van toepassing waren tussen versies. Met een goed configuratiebeheersysteem kunt u elke versie van het product bouwen en testen met alleen de artefacten die erin zitten zonder enige andere externe kennis. DevOps-ingenieurs gebruiken SCM-tools (Software Configuration Management) zoals GIT, Ansible, Terraform, Chef om de code, configuratie en infrastructuur van het product vast te leggen. Ze kunnen deze wijzigingen ook koppelen aan JIRA-problemen om de relatie tussen het verzoek om een ​​bug / defect / functie en de daadwerkelijke wijzigingen die hieruit voortvloeiden te documenteren. Elektronische ingenieurs gebruiken hulpmiddelen die soms PLM (product lifecycle management) en soms HCM (hardware configuratiebeheer) worden genoemd. In wezen dienen ze hetzelfde doel, maar ze omvatten verschillende integraties en processen. Een PLM-systeem kan bijvoorbeeld ook worden geïntegreerd in uw ERP-systeem om te laten zien welke delen van de stuklijst van het product in uw inventaris aanwezig zijn.

Fabricage en productie

U moet uw fabrikant als uw partner beschouwen en niet als uw leverancier. U geeft uw fabrikant tenslotte uw meest gevoelige activa: alles wat nodig is om uw product te bouwen! Uw fabrikant zal u helpen om nieuwe productiemethoden te introduceren, defecten te verminderen, de efficiëntie van het proces te verbeteren en zal op een of andere manier een deel van de risico's en voordelen van het product delen.

Lean Lean is alles met betrekking tot kostenbesparing. Voor fysieke producten betekent lean:

  • Geen vertraging door alle fasen van de productielijn
  • Pay Defects, Hoogste kwaliteit voor elk eindproduct
  • Machines / mensen worden 100% gebruikt
  • Kennisfeedback: elke les en elk inzicht verbetert het proces
  • Just in time manufacturing: elk product wordt verkocht, geen afval

Voor digitale producten betekent lean:

  • Autoschaling: schaal van computationele bronnen op basis van de belasting
  • Betaal per uur

Productie van pijpleidingen: het opzetten van een assemblagelijn verschilt niet al te veel van het opzetten van een software CI / CD (continue integratie / continue levering) pijplijn. Als je het Phoenix-projectboek hebt gelezen, zul je je waarschijnlijk herinneren hoe sommige concepten van lean en DevOps in het boek zijn afgeleid van de fysieke productielijn. Beide pijpleidingen verwerken alles wat nodig is om uw product te bouwen, testen en verzenden. Naarmate u meer automatisering toevoegt, kunt u sneller verzenden. Voor elektronische producten betekent dit het verlagen van kosten en defecten en het verbeteren van de capaciteit, voor digitale producten betekent dit snellere gebruikerstests en een adaptief ontwerp.

Wereldwijde bezorging: er is een interessante overeenkomst tussen inhoudbezorgingsnetwerken (CDN) die worden gebruikt om webactiva te leveren aan gebruikers op basis van hun geografische locatie en hoe productie over de hele wereld wordt verdeeld om verzendkosten te verlagen en producten te lokaliseren. Contentcaching kan worden gezien als lokale magazijnen of fulfilmentdiensten zoals Amazon. Voor beide soorten producten verbetert de lokale aanwezigheid de algehele klantervaring over de hele wereld

Het lijkt misschien dat wereldwijde aanwezigheid voor fysieke producten moeilijker is, maar ook regelgeving voor gegevensbescherming en taallokalisatie vereist aanzienlijke inspanningen

Cloudservices: cloudservices zijn geweldig, u kunt uw digitale product in seconden bouwen door te kiezen uit honderden webservices. Een paar klikken en het wordt automatisch uitgevoerd in meer dan 20 datacenters over de hele wereld en schaalt op basis van de vraag. Er is niets dergelijks in de productie, maar dit kan de volgende industriële revolutie zijn. Stelt u zich een digitaal product voor waar u een productiepijplijn kunt opzetten met behulp van vooraf geconfigureerde modules zoals 3D-printen, PCB-productie, sourcing van componenten, assemblage van platen en kabels, lopende tests en verzending rechtstreeks naar uw klanten vanaf een lokale geautomatiseerde productievloer. Bovendien stelt de service de eindgebruiker in staat om de kleur van het product, de vorm en andere personalisatiefuncties aan te passen. Dit lijkt een droom, maar ik weet zeker dat Amazon ergens ter wereld aan zo'n dienst werkt (althans dat hoop ik).

Gevolgtrekking

Er zijn veel verschillen tussen het ontwikkelingsproces van elektronische producten en digitale producten, maar vanuit een perspectief van 20 jaar is het verbluffend om te zien hoeveel van de ontwerpprincipes en -processen van digitale producten nu worden gebruikt door fysieke productmanagers. AWS heeft onlangs aangekondigd op FreeRTOS voor embedded systemen. Ik voorspel dat er binnen 10-20 jaar geen significant verschil zal zijn tussen het ontwikkelingsproces van een digitaal product en een fysiek product.

Als u meer wilt weten over mijn reis, en hoe u een team kunt beheren dat in beide werelden woont, neem dan gerust contact met me op.