Progettazione e sviluppo di prodotti elettronici vs prodotti digitali

Sono stato fortunato a sviluppare e gestire lo sviluppo di prodotti fisici e digitali. Mentre condivido l'amore e la passione per entrambi, ho pensato di presentare le mie opinioni e alcune osservazioni sulle differenze e somiglianze tra i loro processi di sviluppo.

Qual è il significato di un prodotto per ...

Che cos'è un prodotto? Qualcosa che viene prodotto e venduto o qualcosa che crea un valore per gli utenti? La prima definizione si applica solo ai prodotti fisici e riflette ciò che facciamo con i prodotti e il modo in cui li costruiamo. La seconda definizione è più aperta e moderna e riflette il motivo per cui abbiamo bisogno di prodotti. I prodotti fisici sono tangibili; gli utenti possono toccarli, vederli, annusarli e sentirli. Abbiamo visto tutti i video di enormi fabbriche e possiamo capire quanto sia costoso e complesso produrli. I prodotti digitali vivono nel cloud o in data center remoti. Per noi è più difficile capire la loro dimensione, complessità e cosa significa costruirne uno. Ad esempio, se guardiamo al frontend di Ricerca Google, possiamo vedere solo una riga di ricerca, ma dietro la scena, sul backend, ci sono centinaia di migliaia di server in esecuzione e miliardi di righe di codici.

Quando gli sviluppatori di software hanno iniziato a costruire prodotti digitali, circa 25 anni fa, hanno utilizzato processi e strumenti simili che sono stati utilizzati per costruire prodotti fisici. Il processo più comprovato per la gestione del progetto, all'epoca, era Waterfall in quanto garantiva la perfezione durante l'intero ciclo del progetto. Tuttavia, poiché i project manager digitali hanno acquisito maggiore esperienza e fallito in quasi la metà dei progetti, hanno capito che avevano bisogno di un cambiamento. Hanno iniziato a costruire i propri strumenti e hanno escogitato i loro processi non convenzionali unici. Intorno al 2001, sempre più team hanno iniziato a utilizzare Scrum e Kanban ed è emerso l'agile manifesto. Git è stato creato da Linus Torvalds nel 2005 che ha gettato le basi per progetti open source. Forse per i prodotti digitali la perfezione non è importante quanto l'agilità. Oggi, 25 anni dopo, i processi di sviluppo, gli strumenti e le culture di entrambi i team di prodotti sono molto distanti.

Negli ultimi cinque anni, è diventato estremamente facile ed economico integrare l'elettronica nei prodotti fisici e collegarli a Internet a una sorta di app, una tendenza che si chiama IOT (Internet delle cose). Fare questo costa circa 2 $ per prodotto, il che spiega perché recentemente vediamo emergere così tanti nuovi prodotti IOT, alcuni dei quali sono piuttosto divertenti ... A livello di team di prodotto, questa tendenza riunisce due tipi di culture, due tipi di processi e due tipi di strumenti. Ogni volta che due culture si scontrano, iniziano a succedere cose interessanti. L'hardware open source è tutt'attorno a noi e alcune persone hanno iniziato a definirsi produttori. Qual è la differenza tra un produttore e un produttore? Vedremo una convergenza tra questi processi? o siamo condannati, come CTO e IOT product manager a fare un ponte tra queste culture per sempre?

Spero che questo blog sia interessante e utile e che aiuti gli sviluppatori di tutto lo stack a comprendere le sfide reciproche.

Ruoli e competenze

C'è una tendenza recente per gli sviluppatori di software di sviluppare l'intero stack software. Ciò significa che sviluppano sia il codice backend: il codice che viene eseguito sul server / cloud, sia il codice frontend: il codice che viene eseguito sul dispositivo. Potrebbero persino assumere il ruolo di DevOps: ingegneri responsabili della configurazione del sistema, della configurazione, della protezione e quindi dell'automazione del processo di modifica. Non è impossibile per una sola persona creare e lanciare una semplice app digitale o un gioco. Tuttavia, quando si guardano i prodotti IOT che di solito includono sia un dispositivo elettronico sia una sorta di app, il team tecnico richiede più competenze e ruoli.

Gli sviluppatori integrati sono responsabili del codice che viene eseguito sul dispositivo e i progettisti della scheda sono responsabili dello sviluppo della scheda elettronica.

Anche se oggi, con l'aiuto di Espruino, gli sviluppatori Javascript possono teoricamente sviluppare tutti e tre i livelli di codice: codice frontend, codice backend e codice incorporato, probabilmente avranno difficoltà con il design industriale e delle schede che richiede tipi di abilità completamente diversi. Ho visto sviluppatori di talento che sono un tuttofare e possono passare rapidamente dalla modifica delle classi CSS alla scrittura di script di migrazione per i loro database. Personalmente, penso che gli sviluppatori professionisti dovrebbero padroneggiare in qualsiasi momento a un solo livello. Non si tratta solo di avere le migliori competenze e tecniche o di implementare le funzionalità richieste, ma anche di ciò che ti interessa e con quale stato d'animo fai il tuo lavoro.

Ho tentato di descrivere le responsabilità di ciascun ruolo nel team. Apprezzo il fatto di entrare in un territorio pericoloso poiché i ruoli potrebbero leggermente cambiare in squadre diverse, quindi per favore prova a vedere la foresta e non gli alberi.

Perché una persona non può interessarsene? Perché ci sono compromessi e conflitti nello sviluppo del prodotto e si desidera rappresentare ogni esigenza in modo equilibrato e simmetrico.

Nel corso degli anni ho visto il rispetto tra i diversi tipi di sviluppatori, ma anche la mancanza di conoscenza. Ho visto sviluppatori di front-end che pensano che il back-end sia facile e sviluppatori di back-end che pensano che il front-end sia noioso. Ho anche visto sviluppatori embedded che non sanno cosa sia REST. Ho già detto che non credo che sviluppatori e ingegneri professionisti debbano dominare più di un livello. Tuttavia, credo fermamente che dovrebbero sapere cosa significhi essere uno e forse anche fare un passo avanti e lavorare su un semplice progetto che li esporrà alle diverse sfide e processi. Una vasta conoscenza può aiutare a migliorare la comunicazione, il rispetto e la trasparenza tra i membri del team e aumenterà anche la creatività e la produttività dell'intero team.

Gestione di progetto

Qual è la differenza tra un progetto e un prodotto? Un progetto è un piano per raggiungere un determinato obiettivo o ambito entro un certo tempo e vincoli di risorse. Un progetto ha un inizio e una fine. Se non hai una scadenza per il progetto, probabilmente non gestisci un progetto. Al termine del progetto, il prodotto continua a vivere.

Analisi del rischio: discutiamo delle differenze e delle somiglianze tra la gestione del progetto di un prodotto fisico e uno digitale. Personalmente, mi piace pensare alla gestione del progetto come a un processo guidato dal rischio in cui identifico costantemente i rischi maggiori e cerco di elaborare un piano per minimizzarli. I rischi del progetto sono qualcosa che influisce sul successo del progetto, ovvero il mancato rispetto dell'obiettivo, della scadenza, della portata, dei costi o della qualità finale dei prodotti. Per i prodotti digitali, uno dei maggiori rischi è quello di costruire un prodotto di cui gli utenti non hanno bisogno o che non vogliano. I product manager digitali immaginano, credono, speculano e raccontano una buona storia, ma fino a quando gli utenti non iniziano a interagire con il prodotto, questi sono solo dei presupposti. Per testare l'assunto, i responsabili di prodotto devono spedire rapidamente, verificare le loro ipotesi ed essere agili. Per i prodotti fisici, il rischio maggiore è quello di trovare un problema irreparabile in una fase molto avanzata, dopo che centinaia e migliaia di prodotti sono già stati fabbricati. La produzione richiede perfezione e senza di essa il progetto fallirà. Per ridurre questo rischio, i project manager fisici costruiscono un processo di revisione e approvazione tra le fasi che si chiama Waterfall.

Ogni metodo è stato progettato per ridurre i diversi rischi e ogni project manager dovrebbe decidere il piano di progetto in base all'analisi dei rischi. A volte gli individui e le interazioni sono più importanti dei processi e degli strumenti, e talvolta i processi sono più importanti. A volte il software di lavoro è più importante della documentazione e talvolta la documentazione è più importante. A volte la collaborazione con i clienti è più importante del contratto scritto. E a volte un contratto scritto può salvare la tua azienda. A volte rispondere al cambiamento è importante, ma a volte seguire un piano è più importante. Capisci cosa intendo.

Strumenti e cerimonie di gruppo: i project manager dovrebbero usare strumenti che implementano il processo attraverso il quale vogliono gestire i progetti. Microsoft Project è un ottimo strumento per i progetti a cascata. JIRA e Trello sono ottimi strumenti per progetti agili e processi di supporto come Kanban e Scrum. Qualunque sia lo strumento, ricorda che è solo uno strumento e non l'essenza. Le squadre hanno anche cerimonie diverse. In Waterfall, i team si incontrano prima di ogni autunno e riesaminano documenti, output generati da CAD o specifiche di test. Il team agile potrebbe incontrarsi ogni giorno per uno standup giornaliero e ogni due settimane per la pianificazione dello sprint. Queste cerimonie allineano i membri del team sul piano e migliorano la comunicazione tra i membri del team.

Design e prototipazione

Design: esiste un prodotto oggi in cui il design non ha un ruolo importante nel suo successo? Che cos'è un prodotto se non qualcosa che vogliamo vendere? Qualcosa che dovrebbe essere attraente ed estetico, di cui possiamo essere orgogliosi. Sono finiti i giorni in cui avere le giuste funzionalità e prestazioni era abbastanza buono. Per i prodotti elettronici, il design industriale dovrebbe prendere in considerazione non solo l'interazione umana, l'usabilità e l'esperienza del cliente, ma anche le condizioni ambientali in cui il prodotto viene utilizzato e il processo di fabbricazione (DFM: design for manufacturing). Per i prodotti digitali, il design dovrebbe anche riguardare i diversi dispositivi su cui il software potrebbe funzionare (mobile, desktop, grandi schermi) e tutti i tipi di ruoli e utenti che interagiscono con esso.

Diversi tipi di metodologia di progettazione si applicano a diversi tipi di prodotti: Experience design considera il prodotto come parte di un'esperienza piacevole che vogliamo creare, cioè "Non stiamo vendendo un gioco, stiamo vendendo un'esperienza familiare di un'ora". La progettazione del servizio vedrà il prodotto come parte di un servizio end-to-end tra un fornitore di servizi e un utente. "Dal momento in cui hai deciso di viaggiare fino al tuo arrivo a destinazione", "Non vendiamo una videocamera di sicurezza, ti vendiamo protezione 24/7".

Prototipazione: con l'aiuto di stampanti 3D e tecnologia VR / AR, è estremamente facile realizzare un prototipo meccanico del tuo prodotto fisico. Puoi mostrarlo ai tuoi clienti, applicare degli adesivi, collegare alcuni fili e LED, ne capiranno immediatamente lo scopo e potresti essere in grado di convincerli che il tuo prodotto è pronto e commerciale. Puoi posizionarlo nell'ambiente reale e vedere se si adatta meccanicamente e se è facile da impugnare. Puoi creare dieci versioni e confrontarle tra loro e decidere sulla configurazione finale. Non c'è niente di più potente che dare ai tuoi clienti e investitori qualcosa da tenere in mano. Alla gente piacciono i giocattoli e le cose tangibili e sebbene il design meccanico a volte sia solo l'1% del prodotto finale in termini di tempo di sviluppo, le persone crederanno che tu l'abbia già completato l'80%. Con la prototipazione del software non è così facile raggiungere questo livello. Sketch e InVision sono ottimi strumenti, ma gli utenti comprendono immediatamente che questo non è un prodotto reale. I dati sono statici e la loro interazione non ha alcun effetto su di essi. Questo è uno dei motivi per cui i product manager digitali hanno adottato l'approccio agile e il concetto di MVP. È molto difficile immaginare come gli utenti interagiranno e apprezzeranno il tuo prodotto prima che sia pronto e abbia dati reali, quindi vuoi spedirlo il prima possibile e iniziare a raccogliere feedback reali.

Prototipazione fisica e digitale

Sviluppo

Le decisioni iniziali hanno il maggiore impatto: ogni volta che inizio un nuovo progetto, sono entusiasta. Quale sarebbe l'architettura giusta? quale tecnologia sarà la migliore per esso? Dovremmo scegliere una MCU a 8 bit o una CPU a 32 bit? È un buon progetto per introdurre GraphQL o dovremo continuare a utilizzare REST? Quale tecnologia wireless si adatta meglio al caso d'uso: Bluetooth 5 o Narrowband IOT? Qual è il database giusto da usare? PostgreSQL o forse un database grafico questa volta? Queste decisioni sono così importanti per il successo del progetto. A volte, prendiamo decisioni tecniche troppo in fretta senza un'adeguata analisi e poi tre mesi dopo ce ne pentiamo, diventa troppo difficile e doloroso cambiarle ed è più facile considerare l'investimento tecnologico come una risorsa e non come una barriera. Questo è vero sia per i prodotti elettronici che per quelli digitali, sebbene cambiare il tipo di processore dopo aver spedito i tuoi prodotti ai tuoi clienti sia un compito quasi impossibile se non imbarazzante.

Le decisioni iniziali hanno il maggiore impatto

Sviluppo: ci sono molte differenze tra il processo di sviluppo di prodotti elettronici e prodotti digitali e non ci sono molte somiglianze. Gran parte del tempo di sviluppo di una scheda PCB va nella selezione dei componenti giusti e nella progettazione del layout. Parte del lavoro è puramente tecnico, collegando i cavi dal componente U1 pin 120 al componente U17 pin 12. E alcune attività richiedono la prototipazione completa di tre tipi di sensori solo per misurare il rumore e il consumo di energia di ciascuno di essi. Lo sviluppo incorporato è difficile da eseguire il debug e l'ottimizzazione, è abbastanza comune vedere gli sviluppatori incorporati che utilizzano i pin GPIO per rilevare se una funzione è stata chiamata e misurare quanto tempo ha impiegato per essere eseguita. L'uso di FPGA nel tuo prodotto elettronico è una decisione audace, ma a volte è l'unica soluzione per raggiungere i tuoi obiettivi di prestazioni / costi. Lo sviluppo di FPGA è un territorio completamente diverso e si colloca tra sviluppo ASIC, sviluppo di schede PCB e sviluppo integrato. Per gli sviluppatori di software, la maggior parte del tempo viene investita nel ... scrivere codice. C'è qualcosa di molto soddisfacente nel guardare il tuo lavoro quotidiano, tutte quelle righe di codice, commit di codice e richieste pull. Sembra abbastanza semplice, ma la quantità di codice e modifiche è enorme, quindi un corretto processo di gestione e revisione della configurazione è essenziale per mantenere organizzata la base di codice, ridurre il debito tecnico e aumentare le conoscenze in tutto il team.

Algoritmi, fisica e scienza dei dati: di solito si tratta del cervello del prodotto, in cui le aziende tendono a dichiarare che il loro IP è presente. I progettisti di schede lavorano con i fisici per selezionare i sensori, per progettare AFE (front-end analogico) attorno a loro o per progettare un antenna speciale. Gli sviluppatori incorporati lavorano con ingegneri e matematici DSP per incorporare algoritmi DSP in tempo reale nel loro software per filtrare i segnali, rilevare schemi o implementare una formula matematica ottimizzata per elaborare / codificare i dati. In tempo reale significa che devi completare l'elaborazione entro un certo numero di cicli della CPU, altrimenti non sarai pronto per elaborare il segnale successivo e perderlo o non sarai in grado di produrre eventi entro la latenza richiesta. Gli sviluppatori di back-end collaborano con data scientist per implementare processi batch per consigliare nuovi prodotti, trovare anomalie, suggerire amici, formare un modello di apprendimento profondo, utilizzare la PNL per analizzare il testo, classificare pagine Web, ecc. Gli sviluppatori di frontend si divertono molto. Stanno facendo la visualizzazione dei dati. Con librerie come D3JS, creano immagini straordinarie e presentano i dati agli utenti in modo utile e aggregato.

A tutta la pila queste persone si preoccuperanno di ridurre il rumore, migliorare i segnali e trovare il giusto equilibrio tra rilevamento missioni (falso negativo) e falso allarme (falso positivo), piangeranno di aver bisogno di più dati o di fare più esperimenti, e salteranno felicemente se riusciranno a migliorare le prestazioni del 5%. Una decisione interessante sul prodotto è decidere come dividere le attività di data science nello stack. Ad esempio, Alexa include una serie di microfoni a livello di scheda, un codice DSP a livello di firmware e una sofisticata scienza dei dati a livello di backend per riconoscere il nostro discorso.

Strumenti: immagina uno sviluppatore frontend e uno sviluppatore incorporato che confronta i loro strumenti di sviluppo tra loro. Lo sviluppatore incorporato accompagnerà lo sviluppatore frontend verso la sua tabella e indicherà le differenze tra un alimentatore, un oscilloscopio e un analizzatore logico. Lo sviluppatore frontend porterà quindi lo sviluppatore incorporato al posto di caffè più vicino. Ordineranno il caffè e troveranno un posto tranquillo dove trascorrere qualche ora insieme. Passerà quindi il browser Chrome in modalità di sviluppo e mostrerà allo sviluppatore incorporato come guardare il traffico di rete e come vedere lo stile CSS di un determinato elemento HTML.

Qual è il significato di devtools per ...

Gli strumenti di debug variano da sviluppatore a sviluppatore e il loro utilizzo efficiente è la vera esperienza. Conoscere istintivamente dove si trova il problema e utilizzare gli strumenti per adattarsi a esso è l'abilità più importante degli sviluppatori. Ho visto gli sviluppatori dedicare ore e giorni al debug di un problema, quindi chiedere aiuto a uno sviluppatore esperto che trova il problema in pochi secondi. Non posso sottolinearlo abbastanza, avere gli strumenti giusti per ogni compito è ciò che significa essere professionali. E questo è vero per ogni professione.

Qual è il significato degli strumenti di debug e test per ...Gli sviluppatori di software lo trovano intimidatorio

QA e test

Test ambientali: quando testiamo il nostro prodotto, vogliamo verificare che funzioni correttamente in tutte le diverse configurazioni e ambienti che gli utenti prevedono di usarlo. Per i prodotti fisici, ambiente di solito significa temperatura (freddo estremo, estremamente caldo), vibrazioni (immagina un prodotto automobilistico), shock (cade dalle tue mani su un pavimento di cemento), umidità, radiazione UV e solare, ESD (questi piccoli lampi che ne derivano da scarica elettrostatica), EMI / RFI, ecc. Per ambiente di prodotti digitali di solito si intende il tipo di browser (Chrome, Internet Explorer, Firefox ..), il sistema operativo (Android, IOS, OSX, Windows), il dispositivo (mobile, desktop, conferenza Schermo) e livello di connettività di rete (4G, Wifi, Offline). Normalmente non testiamo ogni possibile combinazione in quanto sarebbe impossibile farlo, quindi creiamo una serie di configurazioni che si spera copriranno abbastanza scenari per rilevare problemi all'interno delle specifiche del prodotto.

Qual è il significato di ambiente esterno per ...

Affidabilità / Durabilità (test del ciclo di vita): sono test che tentano di simulare ciò che accade al prodotto durante la sua intera vita. È più rilevante per i prodotti fisici in cui i materiali raggiungono i loro punti deboli. Ci sono alcune regole che l'industria ha escogitato per aiutarci ad accelerare l'età del prodotto esponendola a condizioni ambientali estreme. Fondamentalmente, per verificare se un prodotto funziona correttamente dopo cinque anni a temperatura ambiente, possiamo testarlo a 70 gradi e 10 g di vibrazione per un giorno (solo esempio !!!). Questi sono chiamati test HALT (vita altamente accelerata)

Test per condizioni estreme (carico, bordo): sono test che testano il comportamento del prodotto in condizioni estreme o di bordo. Ad esempio, se un prodotto elettronico funziona a 5 V, lo testeremo a 4,5 V e 5,5 V, potremmo anche iniettare picchi di tensione fino a 25 V o -5 V per vedere se il prodotto è resistente agli errori dell'utente o alle sovratensioni elettriche. Per i prodotti digitali potremmo sfidare i campi di input con valori irragionevoli. Ad esempio, potremmo inserire nomi lunghi 1000 caratteri o con simboli insignificanti. se abbiamo progettato il prodotto per un determinato carico (50 utenti simultanei), testeremo il suo comportamento su 100 utenti simultanei. L'idea di questi test è principalmente quella di scoprire nuove modalità di fallimento. Non ci aspettiamo che il prodotto funzioni perfettamente, ma potremmo scoprire problemi importanti, comportamenti imprevisti o strozzature che sono rilevanti anche per le condizioni normali.

Test di conformità / sicurezza: entrambi i tipi di prodotti sono richiesti, a volte, per soddisfare gli standard ed essere conformi con essi. I prodotti elettronici devono essere sicuri, sicuri e affidabili e proteggere l'utente da scosse elettriche o surriscaldamento (UL, CE, FCC ..), devono inoltre rispettare alcuni standard wireless come Wifi o Bluetooth. I prodotti digitali che gestiscono informazioni di identificazione personale (PII) come numeri di carte di credito (PCI, ISO / IEC 27001, NIST) o numeri di previdenza sociale (GDPR) devono proteggere i dati da ogni tipo di attacco e negligenza dei dipendenti. Per entrambi i prodotti, il processo di conformità è costoso e lungo, ma ci sono modi per ridurre i costi e utilizzare moduli e servizi pre-approvati.

Qual è il significato della conformità a ...

Copertura del test: come progettista di schede non si può mai essere sicuri che il processo di produzione sia stato privo di difetti. In alcuni casi, ci sono piccoli pantaloncini tra le tracce adiacenti che puoi vedere solo al microscopio. In altri casi, i componenti elettronici non sono abbastanza affidabili o potrebbero persino essere componenti contraffatti. Come parte del processo di qualità, i progettisti di schede e gli sviluppatori integrati devono collaborare per scrivere strumenti di test che verificino che ogni connessione e ogni componente funzionino come previsto con una copertura del 100%. Ho lavorato per testare JIG che simulano ogni sensore e ogni input sulla scheda per raggiungere una copertura del 100%. È anche buona norma eseguire questi test in parallelo con test di screening altamente accelerati (HASS) in cui la scheda è esposta a vibrazioni e cicli termici.

Allo stesso modo, con il software, è buona norma scrivere un codice di prova che copra almeno il 99% del codice. Prima di distribuire un nuovo codice nell'ambiente di produzione, uno strumento di automazione esegue la suite di codici di verifica e verifica che tutto ciò che ha funzionato prima funzioni ancora. Per entrambi i casi il lavoro su questi strumenti di test dovrebbe iniziare insieme allo sviluppo del prodotto (a volte anche prima: TDD) e dovrebbe essere dotato di risorse adeguate.

Revisione del design / codice: le persone commettono errori. Chiunque pensi di non farlo, o non ha abbastanza esperienza o ha poca memoria. In particolare, quando si progetta il layout di una scheda PCB e si posizionano nuovi componenti, è estremamente facile commettere errori riguardo alla configurazione della piedinatura e alle dimensioni fisiche dei nuovi componenti. errori che troverai solo settimane o mesi dopo. Puoi guardare il progetto e verificarlo rispetto al foglio dati, guardare di nuovo e verificare di nuovo, e in entrambi i casi ti mancherà. Per questo motivo, una revisione indipendente e l'approvazione sono una pratica standard nello sviluppo di prodotti elettronici. Gli sviluppatori di software spesso commettono errori in termini di sicurezza. Ad esempio, spesso inseriscono chiavi sensibili nei repository di codice pubblico o esposti al client. La richiesta pull è un metodo per comunicare agli altri membri del team le modifiche prima di impegnarle. Servono a molteplici scopi: rilevare difetti e problemi, migliorare la leggibilità e la documentazione del codice e condividere le conoscenze in tutto il team. La programmazione delle coppie è un altro metodo utilizzato dagli sviluppatori di software per condividere conoscenze e rivedere il codice reciproco.

Gestione della configurazione: CM è la pratica di gestire sistematicamente le modifiche. Viene utilizzato per documentare le versioni del prodotto e per tenere traccia delle modifiche applicate ad esso tra le versioni. Un buon sistema di gestione della configurazione ti permetterà di costruire e testare qualsiasi versione del prodotto usando solo i manufatti che sono in esso senza alcuna altra conoscenza esterna. Gli ingegneri DevOps utilizzano strumenti SCM (Software Configuration Management) come GIT, Ansible, Terraform, Chef per registrare il codice, la configurazione e l'infrastruttura del prodotto. Potrebbero anche legare queste modifiche ai problemi di JIRA per documentare la relazione tra la richiesta di bug / difetto / funzionalità e le effettive modifiche che ne sono derivate. Gli ingegneri elettronici utilizzano strumenti che vengono chiamati talvolta PLM (gestione del ciclo di vita del prodotto) e talvolta HCM (gestione della configurazione hardware). Sostanzialmente servono allo stesso scopo, ma includono integrazioni e processi diversi. Ad esempio, un sistema PLM potrebbe anche integrarsi nel tuo sistema ERP per mostrare quali parti della distinta componenti del prodotto sono presenti nel tuo inventario.

Produzione e produzione

Dovresti considerare il tuo produttore come partner e non come fornitore. Dopotutto, dai al tuo produttore le risorse più sensibili: tutto ciò che è necessario per costruire il tuo prodotto! Il produttore ti aiuterà a introdurre nuovi metodi di produzione, ridurre i difetti, migliorare l'efficienza del processo e in qualche modo condividerà alcuni dei rischi e dei benefici del prodotto.

Lean Lean è tutto ciò che riguarda il risparmio sui costi. Per i prodotti fisici, lean significa:

  • Ritardo zero in tutte le fasi della linea di produzione
  • Difetti salariali, massima qualità per ogni prodotto finale
  • Le macchine / persone sono utilizzate al 100%
  • Feedback sulla conoscenza: ogni lezione e approfondimento migliorano il processo
  • Produzione just in time: ogni prodotto viene venduto, nessuno spreco

Per i prodotti digitali lean significa:

  • Ridimensionamento automatico: scala delle risorse di calcolo in base al carico
  • Paga all'ora

Pipeline di produzione: la configurazione di una catena di montaggio non è molto diversa dalla configurazione di una pipeline di software CI / CD (integrazione continua / consegna continua). Se hai letto il libro del progetto Phoenix, probabilmente ricorderai come alcuni dei concetti di lean e DevOps sono stati derivati ​​nel libro dalla linea di produzione fisica. Entrambe le condutture gestiscono tutto ciò che è necessario per costruire, testare e spedire il tuo prodotto. Man mano che aggiungi più automazione, puoi spedire più velocemente. Per i prodotti elettronici ciò significa ridurre costi e difetti e migliorare la capacità, per i prodotti digitali ciò significa test più rapidi per l'utente e progettazione adattiva.

Consegna in tutto il mondo: esiste un'interessante somiglianza tra le reti di distribuzione dei contenuti (CDN) che vengono utilizzate per consegnare risorse Web agli utenti in base alla loro posizione geografica e come la produzione viene distribuita in tutto il mondo per ridurre i costi di spedizione e localizzare i prodotti. La memorizzazione nella cache dei contenuti può essere vista come magazzini locali o servizi di evasione ordini come Amazon. Per entrambi i tipi di prodotti, la presenza locale migliora l'esperienza complessiva del cliente in tutto il mondo

Potrebbe sembrare che la presenza mondiale sia più difficile per i prodotti fisici, tuttavia, anche la regolamentazione della protezione dei dati e la localizzazione della lingua richiedono sforzi significativi

Servizi cloud: i servizi cloud sono fantastici, puoi creare il tuo prodotto digitale in pochi secondi scegliendo tra centinaia di servizi web. Pochi clic e funzionerà automaticamente su oltre 20 data center in tutto il mondo e si ridimensionerà in base alla domanda. Non c'è nulla di simile nella produzione, ma questa potrebbe essere la prossima rivoluzione industriale. Immagina un prodotto digitale in cui è possibile impostare una pipeline di produzione utilizzando moduli preconfigurati come stampa 3D, produzione di PCB, approvvigionamento di componenti, assemblaggio di schede e cavi, esecuzione di test e spedizione direttamente ai clienti da un piano di produzione automatizzato locale. Inoltre, il servizio consentirà all'utente finale di personalizzare il colore del prodotto, la forma e altre caratteristiche di personalizzazione. Sembra un sogno, ma sono sicuro che da qualche parte nel mondo Amazon sta lavorando a un tale servizio (almeno spero che lo facciano).

Conclusione

Ci sono molte differenze tra il processo di sviluppo dei prodotti elettronici e quelli digitali, ma osservandolo da una prospettiva di 20 anni, è sorprendente vedere quanti dei principi di progettazione e processi dei prodotti digitali sono ora utilizzati dai responsabili dei prodotti fisici. AWS ha annunciato di recente su FreeRTOS per sistemi embedded. Prevedo che tra 10-20 anni non ci sarà alcuna differenza significativa tra il processo di sviluppo di un prodotto digitale e uno fisico.

Se desideri saperne di più sul mio viaggio e su come gestire una squadra che vive in entrambi i mondi, sentiti libero di contattarmi direttamente.