Proiectare și dezvoltare de produse electronice vs produse digitale

Am avut norocul să dezvolt și să gestionez atât dezvoltarea produselor fizice, cât și a celor digitale. În timp ce împărtășesc dragostea și pasiunea pentru amândoi, m-am gândit să-mi prezint părerile și câteva observații despre diferențele și asemănările dintre procesele lor de dezvoltare.

Care este sensul unui produs la ...

Ce este un produs? Ceva care este fabricat și vândut sau ceva care creează o valoare pentru utilizatori? Prima definiție se aplică numai produselor fizice și reflectă ceea ce facem cu produsele și modul în care le construim. A doua definiție este mai deschisă și mai modernă și reflectă de ce avem nevoie de produse. Produsele fizice sunt tangibile; utilizatorii le pot atinge, vedea, mirosi și simți. Cu toții am văzut videoclipuri cu fabrici uriașe și putem înțelege cât de scump și complex este să le fabricăm. Produsele digitale trăiesc în cloud sau în centre de date la distanță. Pentru noi este mai greu să înțelegem dimensiunea, complexitatea și ce înseamnă să construim unul. De exemplu, dacă ne uităm la frontendul Căutării Google, putem vedea doar o linie de căutare, dar în spatele scenei, în backend, există sute de mii de servere care rulează și miliarde de linii de coduri.

Când dezvoltatorii de software au început să creeze produse digitale, în urmă cu aproximativ 25 de ani, au folosit procese și instrumente similare care au fost utilizate pentru a construi produse fizice. Cel mai dovedit proces pentru managementul de proiect, la acea vreme, a fost Cascada, deoarece a garantat perfecțiunea pe parcursul întregului ciclu de proiect. Cu toate că managerii de proiecte digitale au câștigat mai multă experiență și au eșuat în aproape jumătate din proiecte, au realizat că au nevoie de o schimbare. Au început să-și construiască propriile instrumente și au venit cu procesele lor unice neconvenționale. În jurul anului 2001, tot mai multe echipe au început să folosească Scrum și Kanban și a apărut manifestul agil. Git a fost creat de Linus Torvalds în 2005, care a pus bazele proiectelor open source. Poate că pentru produsele digitale perfecțiunea nu este la fel de importantă ca și agilitatea. Astăzi, 25 de ani mai târziu, procesele de dezvoltare, instrumentele și culturile ambelor echipe de produse sunt foarte depărtate.

În ultimii cinci ani, a devenit extrem de ușor și ieftin să încorporați produse electronice în produse fizice și să le conectați la internet la un fel de aplicație - o tendință care se numește IOT (Internet of things). A costat în jur de 2 $ pe produs, ceea ce explică de ce vedem că atât de multe produse IOT apar recent, unele dintre ele sunt destul de amuzante ... La nivelul echipei de produse, această tendință reunește două tipuri de culturi, două tipuri de procese și două tipuri de instrumente. Ori de câte ori se ciocnesc două culturi, lucruri interesante încep să se întâmple. Hardware-ul open source este în jurul nostru acum și unii au început să se numească producători. Care este diferența dintre un producător și un producător? Vom vedea o convergență între aceste procese? sau suntem condamnați, în calitate de CTO-uri și manageri de produse IOT, să punem punct între aceste culturi pentru totdeauna?

Sper că veți găsi acest blog atât interesant, cât și util și că va ajuta dezvoltatorii din toată stiva să înțeleagă provocările celuilalt.

Roluri și abilități

Există o tendință recentă pentru dezvoltatorii de software să dezvolte stiva software completă. Aceasta înseamnă că dezvoltă atât codul backend: codul care rulează pe server / cloud, cât și codul frontend: codul care rulează pe dispozitiv. Aceștia ar putea chiar să-și asume rolul DevOps: ingineri responsabili de configurarea sistemului, configurarea acestuia, securizarea acestuia și automatizarea procesului de schimbare. Nu este imposibil pentru o singură persoană să construiască și să lanseze o simplă aplicație digitală sau un joc. Cu toate acestea, atunci când analizăm produsele IOT, care includ de obicei atât un dispozitiv electronic, cât și un fel de aplicație, echipa tehnică necesită mai multe abilități și roluri.

Dezvoltatorii încorporați sunt responsabili pentru codul care rulează pe dispozitiv, iar designerii plăcii sunt responsabili pentru dezvoltarea plăcii electronice.

Deși astăzi, cu ajutorul lui Espruino, dezvoltatorii Javascript pot dezvolta teoretic toate cele trei niveluri de cod: cod frontend, cod backend și cod încorporat, probabil că vor lupta cu designul industrial și al plăcii care necesită tipuri complet diferite de abilități. Am văzut dezvoltatori talentați care sunt un jack al tuturor tranzacțiilor și pot trece rapid de la modificarea claselor CSS la scrierea scripturilor de migrare pentru bazele lor de date. Personal, cred că dezvoltatorii profesioniști ar trebui să stăpânească în orice moment al timpului la un singur strat. Nu este vorba doar de a avea cele mai bune abilități și tehnici sau de a implementa funcționalitatea necesară, ci și despre ceea ce vă pasă și cu ce stare de spirit vă desfășurați munca.

Am încercat să descriu responsabilitățile fiecărui rol din echipă. Apreciez că intru pe un teritoriu periculos, deoarece rolurile s-ar putea schimba ușor în diferite echipe, așa că vă rugăm să încercați să vedeți pădurea și nu copacii.

De ce o singură persoană nu poate să le pese de toate? Deoarece există compromisuri și conflicte în dezvoltarea produselor și doriți să reprezentați fiecare nevoie într-un mod echilibrat și simetric.

De-a lungul anilor am văzut respect între diferite tipuri de dezvoltatori, dar și lipsă de cunoștințe. Am văzut dezvoltatori frontend care consideră că backend-ul este ușor și dezvoltatori backend care cred că frontend-ul este plictisitor. Am văzut și dezvoltatori încorporați care nu știu ce este REST. Am menționat înainte că nu cred că dezvoltatorii și inginerii profesioniști ar trebui să stăpânească mai mult de un strat. Cu toate acestea, cred cu tărie că ar trebui să știe ce înseamnă să fii unul și poate chiar să facă un pas mai departe și să lucreze la un proiect simplu care să le expună diferitelor provocări și procese. Cunoașterea largă poate ajuta la îmbunătățirea comunicării, a respectului și a transparenței dintre membrii echipei și va crește, de asemenea, creativitatea și productivitatea echipei în ansamblu.

Management de proiect

Care este diferența dintre un proiect și un produs? Un proiect este un plan pentru a atinge un anumit obiectiv sau obiectiv într-un anumit timp și restricții de resurse. Un proiect are un început și un sfârșit. Dacă nu aveți un termen limită de proiect, probabil că nu gestionați un proiect. Când proiectul se încheie, produsul continuă să trăiască.

Analiza riscurilor: Să discutăm diferențele și asemănările dintre managementul de proiect al unui produs fizic și unul digital. Personal, îmi place să mă gândesc la managementul de proiect ca la un proces bazat pe riscuri, în care identific constant riscurile de vârf și încerc să vin cu un plan care să le reducă la minimum. Riscurile proiectului sunt orice afectează succesul proiectului, adică neîndeplinirea obiectivului, termenului limită, domeniul de aplicare, costul sau calitatea finală a produselor. Pentru produsele digitale, unul dintre cele mai mari riscuri este construirea unui produs de care utilizatorii nu au nevoie sau nu le place. Managerii de produse digitale își imaginează, cred, speculează și spun o poveste bună, dar până când utilizatorii încep să interacționeze cu produsul, acestea sunt doar presupuneri. Pentru a testa presupunerea, managerii de produse trebuie să expedieze rapid, să-și testeze ipoteza și să fie agili. Pentru produsele fizice, cel mai mare risc este de a găsi o problemă ireparabilă într-un stadiu foarte târziu, după ce sute și mii de produse erau deja fabricate. Fabricarea necesită perfecțiune și fără ea proiectul nu va reuși. Pentru a reduce acest risc, managerii de proiecte fizice construiesc un proces de revizuire și înscriere între etapele care se numește Cascadă.

Fiecare metodă a fost concepută pentru a reduce riscurile diferite, iar fiecare manager de proiect ar trebui să decidă asupra planului de proiect pe baza analizei riscurilor. Uneori, indivizii și interacțiunile sunt mai importante decât procesele și instrumentele, iar alteori procesele sunt mai importante. Uneori, software-ul de lucru este mai important decât documentația, iar alteori documentația este mai importantă. Uneori, colaborarea cu clienții este mai importantă decât contractul scris. Și uneori un contract scris vă poate salva compania. Uneori este important să răspunzi la schimbare, dar alteori să urmezi un plan este mai important. Ai ce vreau să spun.

Instrumente și ceremonii de echipă: managerii de proiecte ar trebui să utilizeze instrumente care pun în aplicare procesul prin care doresc să gestioneze proiectele. Microsoft Project este un instrument excelent pentru proiecte de cascadă. JIRA și Trello sunt un instrument excelent pentru proiecte agile și procese de sprijin precum Kanban și Scrum. Oricare ar fi instrumentul, nu uitați că este doar un instrument și nu esența. Echipele au, de asemenea, diferite ceremonii. În Cascadă, echipele se întâlnesc înainte de fiecare toamnă și examinează documentele, rezultatele generate de CAD sau specificațiile de testare. Echipa agilă s-ar putea întâlni în fiecare zi pentru un standup zilnic și la fiecare două săptămâni pentru planificarea sprint-ului. Aceste ceremonii aliniază membrii echipei în plan și îmbunătățesc comunicarea între membrii echipei.

Proiectare și prototipare

Design: Există astăzi un produs în care designul nu joacă un rol major în succesul său? Ce este un produs dacă nu ceva pe care vrem să-l vindem? Ceva care ar trebui să fie atractiv și estetic, de care să fim mândri. Au dispărut zilele în care funcționalitatea și performanțele potrivite au fost suficient de bune. Pentru produsele electronice, proiectarea industrială ar trebui să ia în considerare nu numai interacțiunea umană, capacitatea de utilizare și experiența clienților, ci și condițiile de mediu în care produsul este utilizat și procesul de fabricație (DFM: design pentru fabricație). Pentru produsele digitale, designul ar trebui să se adreseze și diferitelor dispozitive pe care software-ul ar putea rula (mobil, desktop, ecrane mari) și toate tipurile de roluri și utilizatori care interacționează cu acesta.

Diferite tipuri de metodologie de proiectare se aplică diferitelor tipuri de produse: Proiectarea experienței privește produsul ca parte a unei experiențe plăcute pe care dorim să o creăm adică „Nu vindem un joc, vindem o experiență familială de o oră”. Proiectarea serviciului va vedea produsul ca parte a unui serviciu final la sfârșit între un furnizor de servicii și un utilizator. „Din momentul în care ați decis să călătoriți până ajungeți la destinație”, „Nu vindem o cameră de securitate, vă vindem protecție 24/7”.

Prototipare: cu ajutorul imprimantelor 3D și a tehnologiei VR / AR, este extrem de ușor să creezi un prototip mecanic al produsului tău fizic. Îi puteți arăta clienților dvs., puteți pune niște autocolante, conectați câteva fire și LED-uri, vor înțelege imediat scopul acestuia și este posibil să le puteți convinge că produsul dvs. este pregătit și comercial. Îl puteți plasa în mediul real și vedeți dacă se potrivește mecanic și dacă este ușor de reținut. Puteți face zece versiuni și compara între ele și puteți decide cu privire la configurația finală. Nu este nimic mai puternic decât să le oferiți clienților și investitorilor ceva care să le țină în mână. Oamenilor le plac jucăriile și lucrurile corporale și, deși designul mecanic este uneori doar 1% din produsul final în termeni de dezvoltare, oamenii vor crede că ați finalizat deja 80% din acesta. Cu prototipurile software nu este atât de ușor să ajungi la acest nivel. Sketch și InVision sunt instrumente excelente, dar utilizatorii înțeleg imediat că acesta nu este un produs real. Datele sunt statice, iar interacțiunea lor nu are niciun efect asupra lor. Acesta este o parte din motivul pentru care managerii de produse digitale au adoptat abordarea agilă și conceptul de MVP. Este foarte greu să vă imaginați cum vor interacționa utilizatorii și vor iubi produsul dvs. înainte să fie gata și să aibă date reale, așa că doriți să-l expediați cât mai curând posibil și să începeți să colectați feedback real.

Prototipare fizică și digitală

Dezvoltare

Primele decizii au cel mai mare impact: de fiecare dată când încep un nou proiect, sunt încântat. Care ar fi arhitectura potrivită? ce tehnologie va fi cea mai potrivită pentru ea? Ar trebui să alegem un MCU pe 8 biți sau un procesor pe 32 biți? Este un proiect bun pentru a introduce GraphQL, sau trebuie să rămânem din nou cu REST? Care tehnologie wireless se potrivește cel mai bine cazului de utilizare: Bluetooth 5 sau Narrowband IOT? Care este baza de date potrivită să folosești? PostgreSQL sau poate o bază de date grafică de data asta? Aceste decizii sunt atât de importante pentru reușita proiectului. Uneori, luăm decizii tehnice prea repede fără analize adecvate și apoi trei luni mai târziu le regretăm, devine prea greu și dureros să le schimbăm și este mai ușor să privim investiția în tehnologie ca un atu și nu ca o barieră. Acest lucru este valabil atât pentru produsele electronice, cât și pentru produsele digitale, deși schimbarea tipului de procesor după expedierea produselor către clienții dvs. este aproape o sarcină imposibilă, dacă nu chiar una jenantă.

Deciziile timpurii au cel mai mare impact

Dezvoltare: Există multe diferențe între procesul de dezvoltare a produselor electronice și produsele digitale și nu există multe asemănări. Cea mai mare parte a timpului de dezvoltare pentru o placă PCB trece în selectarea componentelor potrivite și proiectarea machetei. O parte din lucrare este pur tehnică, conectând firele de la componenta U1 pin 120 la componenta U17 pin 12. Și unele sarcini necesită o prototipare completă în jurul a trei tipuri de senzori doar pentru a măsura zgomotul și consumul de energie al fiecăruia dintre ei. Dezvoltarea încorporată este greu de depanat și de optimizat, este destul de comun să vezi dezvoltatori încorporați care folosesc pins GPIO pentru a detecta dacă a fost apelată o funcție și pentru a măsura cât timp a durat să funcționeze. Utilizarea FPGA în produsul dvs. electronic este o decizie îndrăzneață, dar uneori este singura soluție pentru a vă atinge obiectivele de performanță / cost. Dezvoltarea FPGA este un teritoriu complet diferit și este undeva între dezvoltarea ASIC, dezvoltarea plăcii PCB și dezvoltarea încorporată. Pentru dezvoltatorii de software, de cele mai multe ori este investit în… scrierea codului. Există ceva foarte satisfăcător când te uiți la munca ta zilnică, toate aceste linii de coduri, coduri de comitere și solicitări de tragere. Acest lucru sună destul de simplu, dar cantitatea de cod și modificări este enormă, astfel încât un proces de gestionare și revizuire a configurației corespunzătoare este esențial pentru a menține baza de cod organizată, reducerea datoriei tehnice și creșterea cunoștințelor din toată echipa.

Algoritmi, fizică și știința datelor: acesta este de obicei creierul produsului, unde companiile tind să revendice IP-ul lor. Designerii de bord lucrează cu fizicieni pentru a selecta senzori, pentru a proiecta AFE (front end analogic) în jurul lor sau pentru a proiecta un antena specială. Dezvoltatorii încorporați colaborează cu ingineri și matematicieni DSP pentru a încorpora algoritmi DSP în timp real în software-ul lor pentru a filtra semnale, pentru a detecta tipare sau pentru a implementa o formulă matematică optimizată pentru procesarea / codificarea datelor. În timp real înseamnă că trebuie să finalizați procesarea într-o anumită cantitate de cicluri CPU, în caz contrar, nu veți fi gata să procesați următorul semnal și să-l pierdeți sau nu veți putea emite evenimente în latența dorită. Dezvoltatorii Backend colaborează cu oamenii de știință de date pentru a implementa procese de loturi pentru a recomanda noi produse, pentru a găsi anomalii, pentru a sugera prieteni, pentru a instrui un model de învățare profundă, utiliza NLP pentru a analiza text, a scrie pagini web, etc. Ei fac vizualizarea datelor. Cu biblioteca precum D3JS, creează imagini vizuale uimitoare și prezintă datele utilizatorilor într-un mod util și agregat.

Peste stivă, acești oameni le va pasa de reducerea zgomotului, de îmbunătățirea semnalelor și de găsirea echilibrului corect între detectarea ratelor (fals negativ) și falsă alarmă (fals pozitiv), vor striga că au nevoie de mai multe date sau vor face mai multe experimente și vor sări fericit dacă vor reuși să îmbunătățească performanța cu 5%. O decizie interesantă a produsului este de a decide cum să împărțiți sarcinile de știință a datelor în stivă Ca exemplu, Alexa include o serie de microfoane la nivel de placă, unele coduri DSP la nivel de firmware și științe de date sofisticate la nivel de backend pentru a recunoaște discursul nostru.

Instrumente: imaginați-vă un dezvoltator frontend și un dezvoltator încorporat comparându-și instrumentele de dezvoltare unul cu celălalt. Dezvoltatorul încorporat va duce dezvoltatorul frontend până la masa sa și va evidenția diferențele dintre o sursă de alimentare, un osciloscop și un analizator logic. Dezvoltatorul frontend va duce apoi dezvoltatorul încorporat la cel mai apropiat loc de cafea. Vor comanda cafea și vor găsi un loc liniștit unde pot petrece câteva ore împreună. Ea / el va schimba apoi browserul Chrome în modul de dezvoltare și va arăta dezvoltatorului încorporat cum să privească traficul de rețea și cum să vadă stilul CSS al unui anumit element HTML.

Care este sensul devotelor la ...

Instrumentele de depanare variază de la dezvoltator la dezvoltator și utilizarea lor eficient este locul în care se află experiența reală. Cunoașterea instinctivă a locului unde se află problema și folosirea instrumentelor pentru a accepta este cea mai importantă abilitate a dezvoltatorilor. Am văzut dezvoltatorii care petrec ore și zile depunând o problemă și apoi cer ajutorul unui dezvoltator cu experiență care găsește problema în câteva secunde. Nu pot sublinia acest lucru suficient, faptul că uneltele potrivite pentru fiecare sarcină înseamnă ceea ce înseamnă a fi profesional. Și acest lucru este valabil pentru fiecare profesie.

Care este sensul instrumentelor de depanare și testare pentru ...Dezvoltatorii de software consideră că acest lucru este intimidant

QA și testare

Testele de mediu: Când testăm produsul nostru, dorim să verificăm dacă acesta funcționează corect în toate configurațiile și mediile diferite pe care utilizatorii se așteaptă să le folosească. Pentru produsele fizice, mediu înseamnă, de obicei, temperatură (frig extrem, extrem de cald), vibrație (imaginați-vă un produs auto), șoc (cade din mâinile dvs. pe o podea de beton), umiditate, radiații UV și solare, ESD (aceste mici iluminări care vin de la descărcarea electro-statică), EMI / RFI, etc. Pentru mediu de produse digitale înseamnă de obicei tip de browser (Chrome, Internet Explorer, Firefox ..), sistem de operare (Android, IOS, OSX, Windows), Dispozitiv (mobil, desktop, conferință) Ecran) și nivel de conectivitate de rețea (4G, Wifi, Offline). În mod normal, nu testăm orice combinație posibilă, întrucât ar fi imposibil să o facem, așa că am venit cu un set de configurații care, în speranță, vor acoperi suficiente scenarii pentru a detecta probleme din specificația produsului.

Care este sensul mediului extern la ...

Fiabilitate / durabilitate (Testul ciclului de viață): Acestea sunt teste care încearcă să simuleze ceea ce se întâmplă cu produsul pe parcursul întregii sale vieți. Este mai relevant pentru produsele fizice în care materialele își ating punctele de avarie. Există anumite reguli pe care industria le-a creat pentru a ne ajuta să accelerăm vârsta produsului, expunându-l la condiții extreme de mediu. Practic, pentru a testa dacă un produs funcționează corect după cinci ani la temperatura camerei, îl putem testa la 70 de grade și la 10g de vibrații timp de o zi (doar exemplu !!!). Acestea se numesc teste HALT (viață puternic accelerată)

Teste de condiții extreme (încărcare, muchie): sunt teste care testează comportamentul produsului în condiții extreme sau de margine. De exemplu, dacă un produs electronic funcționează pe 5V, îl vom testa la 4.5V și 5.5V, am putea chiar injecta vârfuri de tensiune de până la 25V sau -5V pentru a vedea dacă produsul este rezistent la greșelile utilizatorului sau la supratensiunile electrice. Pentru produsele digitale, putem contesta câmpurile de intrare cu valori nerezonabile. De exemplu, am putea introduce nume care au 1000 de caractere sau care au simboluri lipsite de sens. dacă am proiectat produsul pentru o anumită încărcare (50 de utilizatori concurenti), vom testa comportamentul acestuia sub 100 de utilizatori concomitenți. Ideea acestor teste este în principal să descopere noi moduri de eșec. Nu ne așteptăm ca produsul să funcționeze perfect, dar am putea descoperi probleme importante, comportamente neașteptate sau blocaje care sunt relevante și pentru condițiile normale.

Teste de conformitate / securitate: Ambele tipuri de produse sunt necesare, uneori, pentru a respecta standardele și a le respecta. Produsele electronice trebuie să fie sigure, sigure și fiabile și să protejeze utilizatorul împotriva șocurilor electrice sau supraîncălzirii (UL, CE, FCC ..), trebuie să respecte, de asemenea, anumite standarde wireless, cum ar fi Wifi sau Bluetooth. Produsele digitale care gestionează informații de identificare personală (PII), cum ar fi numerele cărților de credit (PCI, ISO / IEC 27001, NIST) sau numere de securitate socială (GDPR) trebuie să protejeze datele împotriva oricăror atacuri și neglijenței angajaților. Pentru ambele produse, procesul de conformitate este costisitor și lung, dar există modalități de a reduce costul și de a utiliza module și servicii pre-aprobate.

Care este sensul conformității cu ...

Acoperire test: Ca proiectant de bord nu poți fi niciodată sigur că procesul de fabricație a fost fără defecte. În unele cazuri, există mici pantaloni scurți între urmele adiacente pe care le puteți vedea doar la microscop. În alte cazuri, componentele electronice nu sunt suficient de fiabile sau pot fi chiar componente contrafăcute. Ca parte a procesului de calitate, designerii de bord și dezvoltatorii încorporați trebuie să lucreze împreună pentru a scrie instrumente de testare care verifică dacă fiecare conexiune și fiecare componentă funcționează așa cum este de așteptat cu o acoperire de 100%. Am lucrat la testarea JIG-urilor care simulează fiecare senzor și fiecare intrare pe placă pentru a atinge o acoperire de 100%. De asemenea, este o practică bună să efectuați aceste teste în paralel cu teste de screening extrem de accelerate (HASS), în cazul în care placa este expusă ciclurilor termice de vibrații și termice.

În mod similar, cu software-ul, o bună practică este să scrieți cod de testare care să acopere cel puțin 99% din codul dvs. Înainte de a implementa un cod nou în mediul de producție, un instrument de automatizare rulează suita de coduri de testare și verifică dacă ceea ce a funcționat până acum, încă funcționează. Pentru ambele cazuri, lucrul la aceste instrumente de testare ar trebui să înceapă împreună cu dezvoltarea produsului (uneori chiar înainte: TDD) și ar trebui să fie resurse adecvate.

Proiectare / revizuire cod: Oamenii fac greșeli. Oricine crede că nu, fie nu are suficient experiență, fie are o memorie scurtă. În special, atunci când proiectăm aspectul unei plăci PCB și plasăm noi componente, este extrem de ușor să greșești în ceea ce privește configurația de pinout și dimensiunile fizice ale noilor componente. greșeli pe care le vei găsi doar săptămâni sau luni mai târziu. Puteți să priviți designul și să îl verificați pe foaia de date, să priviți din nou și să verificați din nou, și în ambele cazuri, veți lipsi. Din acest motiv, o revizuire independentă și înscriere sunt o practică standard în dezvoltarea de produse electronice. Dezvoltatorii de software adesea fac greșeli în ceea ce privește securitatea. De exemplu, de multe ori pun chei sensibile în depozitele de coduri publice sau expuse clientului. Solicitarea de tragere este o metodă de a permite altor membri ai echipei să afle despre modificările dvs. înainte de a le angaja. Acestea servesc mai multe scopuri: pentru a detecta defecte și probleme, pentru a îmbunătăți lizibilitatea și documentarea codului și pentru a împărtăși cunoștințe între echipă. Programarea perechilor este o altă metodă folosită de dezvoltatorii de software pentru a împărtăși cunoștințe și a revizui codul celuilalt.

Managementul configurației: CM este practica de a gestiona modificările în mod sistematic. Este utilizat pentru a documenta versiunile produsului și pentru a urmări modificările care i-au fost aplicate între versiuni. Un bun sistem de gestionare a configurației vă va permite să construiți și să testați orice versiune a produsului folosind numai artefacte care se află în el fără alte cunoștințe externe. Inginerii DevOps utilizează instrumente SCM (Management configurare software) precum GIT, Ansible, Terraform, Chef pentru a înregistra codul, configurația și infrastructura produsului. De asemenea, ar putea lega aceste modificări la problemele JIRA pentru a documenta relația dintre solicitarea bug / defect / caracteristică și modificările efective care au rezultat din aceasta. Inginerii electronici folosesc instrumente care se numesc uneori PLM (managementul ciclului de viață al produsului) și alteori HCM (managementul configurației hardware). În esență, ele servesc același scop, dar includ integrări și procese diferite. De exemplu, un sistem PLM s-ar putea integra și în sistemul ERP pentru a arăta ce părți ale BOM-ului produsului sunt prezente în inventarul dvs.

Fabricare și producție

Ar trebui să vă uitați la producătorul dvs. ca partener și nu ca furnizor. Până la urmă, oferiți producătorului dvs. cele mai sensibile active: tot ceea ce este necesar pentru a vă construi produsul! Producătorul dvs. vă va ajuta să introduceți noi metode de fabricație, să reduceți defectele, să îmbunătățiți eficiența procesului și, într-un fel, vor împărtăși unele dintre riscuri și recompense ale produsului.

Lean Lean este tot ce ține de economisirea costurilor. Pentru produsele fizice, lean înseamnă:

  • Întârziere zero prin toate etapele liniei de producție
  • Defecte de plată, de cea mai înaltă calitate pentru fiecare produs final
  • Mașinile / persoanele sunt utilizate 100%
  • Feedback-ul cunoștințelor: fiecare lecție și perspectivă îmbunătățesc procesul
  • Doar la fabricarea timpului: fiecare produs este vândut, fără deșeuri

Pentru produsele digitale înseamnă:

  • Auto-scalare: scala resurselor de calcul bazate pe sarcină
  • Plătește pe oră

Fabricarea conductelor: Configurarea unei linii de asamblare nu este prea diferită de configurarea unei conducte CI / CD software (integrare continuă / livrare continuă). Dacă ați citit cartea de proiecte Phoenix, vă veți aminti probabil cum unele dintre conceptele de lean și DevOps au fost derivate în carte din linia de fabricație fizică. Ambele conducte se ocupă de tot ceea ce este necesar pentru a construi, testa și expedia produsul. Pe măsură ce adăugați mai multe automatizări, puteți expedia mai rapid. Pentru produsele electronice, aceasta înseamnă reducerea costurilor și a defectelor și îmbunătățirea capacității, pentru produsele digitale, aceasta înseamnă testarea rapidă a utilizatorului și designul adaptiv.

Livrare la nivel mondial: Există o similaritate interesantă între rețelele de livrare de conținut (CDN), care sunt utilizate pentru a livra resurse web utilizatorilor în funcție de locația lor geografică și modul în care producția este distribuită în întreaga lume pentru a reduce costurile de transport și pentru a localiza produsele. Cache-ul de conținut poate fi văzut ca depozite locale sau servicii de îndeplinire, cum ar fi Amazon. Pentru ambele tipuri de produse, prezența locală îmbunătățește experiența globală a clienților din întreaga lume

S-ar putea părea că prezența la nivel mondial este mai dificilă pentru produsele fizice, cu toate acestea, reglementarea privind protecția datelor și localizarea limbii necesită, de asemenea, eforturi semnificative

Servicii cloud: serviciile cloud sunt nemaipomenite, puteți construi produsul dvs. digital în câteva secunde, alegând dintre sute de servicii web. Câteva clicuri și se vor rula automat pe mai mult de 20 de centre de date din întreaga lume și la scară în funcție de cerere. Nu există nimic asemănător în fabricație, dar aceasta ar putea fi următoarea revoluție industrială. Imaginați-vă un produs digital în care puteți configura o conductă de fabricație folosind module preconfigurate, cum ar fi imprimarea 3D, fabricarea de PCB, aprovizionarea de componente, asamblarea placii și a cablurilor, testarea și expedierea direct către clienții dvs. de la un etaj local de fabricație automatizat. Mai mult, serviciul va permite utilizatorului final să personalizeze culoarea produsului, forma și alte caracteristici de personalizare. Acest lucru pare a fi un vis, dar sunt sigur că, undeva în întreaga lume, Amazon lucrează la un astfel de serviciu (cel puțin sper că o fac).

Concluzie

Există multe diferențe între procesul de dezvoltare a produselor electronice și cele digitale, dar privind-o dintr-o perspectivă de 20 de ani, este uimitor să vezi cât de multe dintre principiile și procesele de proiectare ale produselor digitale sunt acum utilizate de către managerii de produse fizice. AWS a anunțat recent despre FreeRTOS pentru sisteme încorporate. Prevăd că în 10-20 de ani nu va exista nicio diferență semnificativă între procesul de dezvoltare a unui produs digital și unul fizic.

Dacă doriți să aflați mai multe despre călătoria mea și cum să gestionați o echipă care trăiește în ambele lumi, nu ezitați să mă contactați direct.