Elektrooniliste toodete ja digitaalsete toodete kujundamine ja arendamine

Mul oli õnne arendada ja juhtida nii füüsiliste toodete kui ka digitaalsete toodete arendamist. Kuna ma jagan armastust ja kirge mõlema vastu, mõtlesin esitada oma seisukohad ja mõned tähelepanekud nende arenguprotsesside erinevuste ja sarnasuste kohta.

Mida tähendab toode…

Mis on toode? Midagi, mida toodetakse ja müüakse, või midagi, mis loob kasutajatele väärtust? Esimene määratlus kehtib ainult füüsiliste toodete kohta ja kajastab seda, mida me toodetega teeme ja kuidas neid ehitame. Teine määratlus on avatum ja kaasaegsem ning kajastab, miks me tooteid vajame. Füüsilised tooted on käegakatsutavad; kasutajad saavad neid puudutada, neid näha, neid nuusutada ja tunda. Oleme kõik näinud tohutute tehaste videoid ja saame aru, kui kallis ja keeruline on nende tootmine. Digitaaltooted asuvad pilves või kaugetes andmekeskustes. Meil on raskem mõista nende suurust, keerukust ja seda, mida nende ehitamine tähendab. Näiteks kui vaadata Google'i otsingu esikülge, näeme ainult ühte otsingurida, kuid stseeni taga, taustal, töötab sadu tuhandeid servereid ja miljardeid ridu koode.

Kui tarkvaraarendajad hakkasid digitooteid looma, umbes 25 aastat tagasi, kasutasid nad sarnaseid protsesse ja tööriistu, mida kasutati füüsiliste toodete valmistamiseks. Projektijuhtimise kõige tõestatud protsess oli sel ajal juga, kuna see tagas täiuslikkuse kogu projektitsükli vältel. Kuna digitaalsete projektijuhtide kogemused olid peaaegu pooltes projektides ebaõnnestunud, mõistsid nad, et vajavad muudatust. Nad hakkasid ise oma tööriistu ehitama ja tulid välja oma ainulaadsete tavapäraste protsessidega. 2001. aasta paiku hakkasid üha enam meeskondi kasutama Scrumit ja Kanbanit ning tekkis vilgas manifest. Giti lõi 2005. aastal Linus Torvalds, kes pani aluse avatud lähtekoodiga projektidele. Võib-olla pole digitaaltoodete jaoks täiuslikkus nii oluline kui paindlikkus. Täna, 25 aastat hiljem, on mõlema tootetiimi arendusprotsessid, tööriistad ja kultuurid üksteisest väga kaugel.

Viimase viie aasta jooksul on olnud väga lihtne ja odav kinnistada elektroonikat füüsilistesse toodetesse ja ühendada see Internetiga mingisuguse rakendusega - trend, mida nimetatakse IOT-ks (asjade Internet). See läks maksma umbes 2 dollarit toote kohta, mis selgitab, miks näeme viimasel ajal nii palju uusi IOT-tooteid ilmumas, mõned neist on üsna lõbusad ... Tooterühma tasemel ühendab see trend kahte tüüpi kultuure, kahte tüüpi protsesse ja kahte tüüpi tööriistu. Kui kaks kultuuri põrkuvad, hakkavad juhtuma huvitavad asjad. Avatud lähtekoodiga riistvara on praegu meie ümber kõik ja mõned inimesed hakkasid end tegijateks nimetama. Mis vahe on tegijal ja tootjal? Kas me näeme nende protsesside lähenemist? või oleme CTO-de ja IOT-i tootejuhtidena määratud hukkuma nende kultuuride vahel igavesti?

Loodan, et see ajaveeb on teile nii huvitav kui ka kasulik ning see aitab kogu arendajatel üksteise väljakutsetest aru saada.

Rollid ja oskused

Tarkvaraarendajate seas on hiljuti ilmnenud trend kogu tarkvarapaki väljaarendamiseks. See tähendab, et nad arendavad mõlemad tagakoodi: serveris / pilves töötava koodi ja kasutajaliidese koodi: seadmes töötavat koodi. Nad võivad isegi võtta DevOps'i rolli: insenerid, kes vastutavad süsteemi seadistamise, konfigureerimise, turvamise ja seejärel muutuste protsessi automatiseerimise eest. Üksiku inimese jaoks pole võimatu luua ja käivitada lihtne digitaalne rakendus või mäng. Kui vaadata IOT-tooteid, mis sisaldavad tavaliselt nii elektroonilisi seadmeid kui ka mingisuguseid rakendusi, nõuab tehnikameeskond rohkem oskusi ja rolle.

Manustatud arendajad vastutavad seadmes töötava koodi eest ja tahvli kujundajad vastutavad elektroonilise tahvli väljatöötamise eest.

Kuigi täna saavad Javascripti arendajad Espruino abiga teoreetiliselt välja töötada kõik kolm koodi taset: kasutajaliidese kood, taustaprogrammi kood ja manustatud kood, näevad nad tõenäoliselt vaeva tööstusliku ja tahvlite kujundamisega, mis nõuab täiesti teistsuguseid oskusi. Olen näinud andekaid arendajaid, kes on kõigi tehingute tungraud ja saavad kiiresti liikuda CSS-i klasside muutmisest oma andmebaaside migratsiooniskriptide kirjutamiseni. Isiklikult arvan, et professionaalsed arendajad peaksid igal ajahetkel omandama ainult ühe kihi. See ei tähenda ainult parimate oskuste ja tehnikate omandamist või vajalike funktsioonide rakendamist, vaid see on ka see, mis teile hoolib ja millise meeleseisundiga oma tööd teete.

Olen proovinud kirjeldada meeskonnas iga rolli vastutust. Hindan seda, et sisenen ohtlikule territooriumile, kuna rollid võivad erinevates meeskondades veidi muutuda, seega proovige näha metsa ja mitte puid.

Miks ei saa üks inimene sellest kõigest hoolida? Kuna tootearenduses on kompromisse ja konflikte ning soovite kajastada iga vajadust tasakaalustatult ja sümmeetriliselt.

Läbi aastate olen näinud erinevat tüüpi arendajate vahel austust, aga ka teadmiste puudust. Olen näinud esiplaanil töötavaid arendajaid, kes arvavad, et taustaprogramm on lihtne, ja taustaprogrammide arendajaid, kes arvavad, et kasutajaliides on igav. Olen näinud ka manustatud arendajaid, kes ei tea, mis on REST. Mainisin juba varem, et ma ei usu, et professionaalsed arendajad ja insenerid peaksid omandama mitu kihti. Usun siiski kindlalt, et nad peaksid teadma, mida tähendab olla üks ja võib-olla isegi astuda sammu edasi ja töötama lihtsa projekti kallal, mis paljastaks nad erinevatele väljakutsetele ja protsessidele. Laiad teadmised aitavad parandada meeskonnaliikmete vahelist suhtlust, austust ja läbipaistvust ning suurendavad ka kogu meeskonna loovust ja produktiivsust.

Projekti juht

Mis vahe on projektil ja tootel? Projekt on plaan teatud eesmärgi või ulatuse saavutamiseks teatud aja- ja ressursipiirangute piires. Projektil on algus ja lõpp. Kui teil pole projekti tähtaega, siis tõenäoliselt ei halda te projekti. Kui projekt lõpeb, jätkub toote elamine.

Riskianalüüs: arutame füüsilise toote ja digitaalse tootehalduse erinevusi ja sarnasusi. Mulle isiklikult meeldib mõelda projektijuhtimisest kui riskipõhisest protsessist, kus tuvastan pidevalt peamised riskid ja püüan välja töötada plaani nende minimeerimiseks. Projektiriskid on kõik, mis mõjutavad projekti edukust, st toodete eesmärgi, tähtaja, ulatuse, maksumuse või lõpliku kvaliteedi mittetäitmine. Digitaalsete toodete puhul on üks suurimaid riske toote loomine, mida kasutajad ei vaja ega meeldi. Digitaaltoodete juhid kujutavad ette, usuvad, spekuleerivad ja räägivad head lugu, kuid seni, kuni kasutajad tootega suhelda hakkavad, on need vaid oletused. Eelduse kontrollimiseks peavad tootejuhid kiiresti kohale jõudma, oma hüpoteesi kontrollima ja olema paindlikud. Füüsiliste toodete puhul on suurim oht ​​leida korvamatu probleem väga hilises etapis pärast seda, kui sajad ja tuhanded tooted olid juba valmistatud. Tootmine nõuab täiuslikkust ja ilma selleta kukub projekt läbi. Selle riski vähendamiseks loovad füüsilised projektijuhid etappide vahel ülevaatuse ja väljalogimise protsessi, mida nimetatakse jugaks.

Iga meetod oli loodud erinevate riskide vähendamiseks ja iga projektijuht peaks riskianalüüsi põhjal otsustama projekti plaani. Mõnikord on isikud ja interaktsioonid olulisemad kui protsessid ja tööriistad ning mõnikord on protsessid olulisemad. Mõnikord on töötav tarkvara olulisem kui dokumentatsioon ja mõnikord on dokumentatsioon olulisem. Mõnikord on kliendikoostöö olulisem kui kirjalik leping. Ja mõnikord võib kirjalik leping teie ettevõtte päästa. Mõnikord on oluline reageerida muutustele, kuid mõnikord on tähtsam kava järgimine. Saad aru, mida ma mõtlen.

Tööriistad ja meeskonna tseremooniad: projektijuhid peaksid kasutama tööriistu, mis rakendavad protsessi, mille kaudu nad soovivad projekte juhtida. Microsoft Project on suurepärane vahend jugaprojektide jaoks. JIRA ja Trello on suurepärased tööriistad agiilsete projektide ja tugiprotsesside jaoks, näiteks Kanban ja Scrum. Ükskõik, mis tööriist see on, pidage meeles, et see on ainult tööriist, mitte olemus. Võistkonnad korraldavad ka erinevaid tseremooniaid. Waterfallis kohtuvad meeskonnad enne igat sügist ja vaatavad läbi dokumente, CAD-i loodud väljundeid või testi spetsifikatsioone. Agile meeskond võib kokku tulla iga päev standupi jaoks ja iga kahe nädala tagant sprindi kavandamiseks. Need tseremooniad viivad meeskonna liikmed plaani ja parandavad meeskonnaliikmete vahelist suhtlust.

Kujundus ja prototüüpimine

Kujundus: kas tänapäeval on mõni toode, kus disain ei mängi selle õnnestumises suurt rolli? Mis on toode, kui mitte midagi, mida tahame müüa? Midagi, mis peaks olema atraktiivne ja esteetiline, mille üle võime uhked olla. Möödas on päevad, kus õige funktsionaalsus ja jõudlus olid piisavalt head. Elektrooniliste toodete puhul peaks tööstusdisainilahendus arvestama mitte ainult inimeste vastastikuse mõju, kasutatavuse ja kliendikogemustega, vaid ka keskkonnatingimustega, milles toodet kasutatakse, ja tootmisprotsessist (DFM: valmistamise disain). Digitaaltoodete puhul peaks kujundus käsitlema ka erinevaid seadmeid, mida tarkvara võib kasutada (mobiil, lauaarvuti, suured ekraanid), ning igat tüüpi rolle ja kasutajaid, kes sellega suhelda saavad.

Erinevat tüüpi toodetele kehtivad erinevad disainimetoodikad: Elamuse kujundamisel vaadeldakse toodet osana nauditavast kogemusest, mida soovime luua, st. „Me ei müü mängu, vaid müüme ühe tunni perekogemust“. Teenuse kujundamisel nähakse toodet osana teenuse osutaja ja kasutaja vahelisest tervikteenusest. “Alates hetkest, kui olete otsustanud reisida, kuni jõuate sihtkohta”, “Me ei müü turvakaamerat, vaid müüme teile ööpäevaringset kaitset”.

Prototüüpimine: 3D-printerite ja VR / AR-tehnoloogia abil on äärmiselt lihtne välja töötada oma füüsilise toote mehaaniline prototüüp. Saate seda oma klientidele näidata, kleebiseid kleepida, juhtmeid ja LED-e ühendada, nad saavad kohe aru selle eesmärgist ja võite neid veenda, et teie toode on valmis ja müügil. Saate selle reaalsesse keskkonda paigutada ja vaadata, kas see sobib mehaaniliselt ja kas seda on lihtne käes hoida. Saate teha kümme versiooni ja neid omavahel võrrelda ning otsustada lõpliku konfiguratsiooni üle. Pole midagi võimsamat kui anda oma klientidele ja investoritele midagi nende käes hoida. Inimestele meeldivad mänguasjad ja käegakatsutavad asjad ning kuigi mehaaniline disain moodustab arendusaja poolest mõnikord ainult 1% lõpptootest, usuvad inimesed, et olete sellest juba 80% valmis saanud. Tarkvara prototüüpimisega pole sellele tasemele jõudmine nii lihtne. Visand ja InVision on suurepärased tööriistad, kuid kasutajad saavad kohe aru, et see pole päris toode. Andmed on staatilised ja nende koostoime seda ei mõjuta. See on osa põhjusest, miks digitaalsete toodete juhid võtsid kasutusele vilgas lähenemise ja MVP kontseptsiooni. On väga raske ette kujutada, kuidas kasutajad suhtlevad ja armastavad teie toodet enne, kui see on valmis ja kui tal on reaalseid andmeid, nii et soovite selle võimalikult kiiresti saata ja hakata koguma reaalset tagasisidet.

Füüsiline ja digitaalne prototüüpimine

Areng

Varasemad otsused avaldavad suurimat mõju: iga kord, kui alustan uut projekti, olen ma elevil. Milline oleks õige arhitektuur? milline tehnoloogia sobib sellele kõige paremini? Kas peaksime valima 8-bitise MCU või 32-bitise CPU? Kas see on hea projekt GraphQL-i tutvustamiseks või peame uuesti REST-i kasutama? Milline traadita tehnoloogia sobib kõige paremini kasutusega: Bluetooth 5 või kitsasriba IOT? Milline on õige andmebaas, mida kasutada? PostgreSQL või võib-olla seekord graafikute andmebaas? Need otsused on projekti õnnestumiseks nii olulised. Mõnikord teeme tehnilisi otsuseid liiga kiiresti ilma korraliku analüüsita ja siis kahe kuu pärast kahetseme neid. Nende muutmine muutub liiga raskeks ja valusaks ning tehnoloogiainvesteeringut on lihtsam vaadata kui vara ja mitte tõkkeid. See kehtib nii elektrooniliste toodete kui ka digitaalsete toodete kohta, ehkki protsessori tüübi muutmine pärast toodete klientidele saatmist on peaaegu võimatu ülesanne, kui mitte piinlik.

Varasemad otsused avaldavad suurimat mõju

Areng: elektrooniliste toodete ja digitaalsete toodete arendusprotsesside vahel on palju erinevusi ja sarnasusi pole palju. Suurem osa PCB-plaadi arendusajast kulub õigete komponentide valimisele ja paigutuse kujundamisele. Osa tööst on puhtalt tehniline, ühendades juhtmed komponendist U1 pin 120 ja komponendini U17 pin 12. Ja mõned ülesanded nõuavad kolme tüüpi andurite täielikku prototüüpimist, et mõõta nende kõigi müra ja energiatarbimist. Manustatud arendust on raske siluda ja optimeerida, üsna tavaline on näha manustatud arendajaid, kes kasutavad GPIO tihvte, et tuvastada funktsiooni kutsumist ja mõõta, kui palju aega kulus selle käivitamiseks. FPGA kasutamine elektroonilises tootes on julge otsus, kuid mõnikord on see ainus lahendus jõudluse / kulueesmärgi saavutamiseks. FPGA arendus on täiesti erinev territoorium ja asub kuskil ASIC-i arendamise, PCB-plaatide arendamise ja manustatud arendamise vahel. Tarkvaraarendajate jaoks investeeritakse suurem osa ajast koodi kirjutamisse. Teie igapäevast tööd vaadates on midagi väga rahuldust pakkuvat - kõik need koodiridad, koodikinnitused ja tõmbetaotlused. See kõlab piisavalt lihtsalt, kuid koodi ja muudatuste hulk on tohutu, seega on õige konfiguratsioonihaldus ja ülevaatusprotsess vajalik, et hoida koodi alus korras, vähendades tehnilist võlga ja suurendades kogu meeskonna teadmisi.

Algoritmid, füüsika ja andmeteadus: see on tavaliselt toote aju, kus ettevõtted kipuvad väidetavalt oma IP-d kasutama. Lauakujundajad teevad füüsikutega koostööd, et valida sensoreid, kujundada AFE (analoog esiosa) nende ümber või kujundada spetsiaalne antenn. Manustatud arendajad töötavad koos DSP inseneride ja matemaatikutega, et manustada oma tarkvarasse reaalajas DSP algoritme signaalide filtreerimiseks, mustrite tuvastamiseks või optimeeritud matemaatilise valemi rakendamiseks andmete töötlemiseks / kodeerimiseks. Reaalaeg tähendab, et peate töötlemise lõpule viima teatud hulga CPU-tsüklite piires, vastasel juhul ei ole te valmis järgmise signaali töötlemiseks ja sellest ilma jääma või ei saa te sündmusi vajaliku latentsusaja jooksul väljastada. Taustprogrammide arendajad töötavad koos andmeteadlastega pakettprotsesside rakendamisel, et soovitada uusi tooteid, leida kõrvalekaldeid, soovitada sõpru, koolitada sügavat õppimismudelit, kasutada NLP-d teksti analüüsimiseks, veebilehtede skoorimiseks jne. Frontendi arendajatel on kõik lõbus. Nad teevad andmete visualiseerimist. Sellise raamatukoguga nagu D3JS loovad nad hämmastavaid visuaale ja esitavad andmeid kasutajatele kasulikul ja koondatud viisil.

Need inimesed hoolitsevad kogu virna eest müra vähendamise, signaalide parandamise ja õige tasakaalu leidmise vahele jäämise tuvastamise (valenegatiivne) ja valehäire (valepositiivne) vahel, nad nutavad, et vajavad rohkem andmeid või teevad rohkem katseid, ja hüppavad õnnelikult, kui neil õnnestub jõudlust 5% parandada. Huvitav tooteotsus on otsustada, kuidas jagada andmeteaduse ülesanded kogu virna vahel. Näitena sisaldab Alexa tahvlite tasemel mikrofonide massiivi, mõnda DSP-koodi püsivara tasemel ja keerulist andmeteadust taustaprogrammi tasemel, et meie kõnet ära tunda.

Tööriistad: kujutlege esiplaanil töötavat arendajat ja manustatud arendajat, kes võrdlevad oma arendustööriistu üksteisega. Manustatud arendaja viib esiplaanil töötava arendaja oma laua juurde ja osutab erinevustele toiteallika, ostsilloskoobi ja loogikaanalüsaatori vahel. Esiosa arendaja viib seejärel manustatud arendaja lähimasse kohvikusse. Nad tellivad kohvi ja leiavad vaikse koha, kus nad saavad paar tundi koos veeta. Seejärel lülitab ta nende Chrome'i brauseri arendusrežiimi ja näitab manustatud arendajale, kuidas vaadata võrguliiklust ja kuidas näha teatud HTML-i elemendi CSS-i stiili.

Mis tähendus on devtoolidel…

Silumisriistad on arendajate vahel erinevad ja nende efektiivne kasutamine on koht, kus tõeline kogemus on. Arendajate kõige olulisem oskus on instinktiivselt teada saada, kus probleem on, ja oma tööriistade abil seda kodus kasutada. Olen näinud, et arendajad veedavad tunde ja päevi probleemi siludes ja küsivad seejärel abi kogenud arendajalt, kes leiab mõne sekundiga probleemi. Ma ei saa seda piisavalt rõhutada, et professionaalseks olemine tähendab iga ülesande jaoks sobivate tööriistade olemasolu. Ja see kehtib iga kutseala kohta.

Mida tähendab silumis- ja testimisriistad ...Tarkvaraarendajad leiavad, et see on hirmutav

QA ja testimine

Keskkonnakatsed: oma toodet katsetades tahame veenduda, et see töötab korrektselt kõigis erinevates konfiguratsioonides ja keskkondades, mida kasutajad loodavad selle kasutamiseks. Füüsiliste toodete puhul tähendab keskkond tavaliselt temperatuuri (äärmiselt külm, eriti kuum), vibratsiooni (kujutage ette autotoodet), lööki (langeb teie kätelt betoonpõrandale), niiskust, ultraviolett- ja päikesekiirgust, ESD-d (neid väikseid valguseid, mis tulevad digitaalsest keskkonnast tähendab tavaliselt brauseri tüüpi (Chrome, Internet Explorer, Firefox ..), OS (Android, IOS, OSX, Windows), seade (mobiil, töölaud, konverents) Ekraan) ja võrguühenduse tase (4G, Wifi, ühenduseta). Tavaliselt ei testi me kõiki võimalikke kombinatsioone, kuna seda oleks võimatu teha, seega pakume välja konfiguratsioonikomplekti, mis hõlmab loodetavasti piisavalt stsenaariume toote spektris probleemide tuvastamiseks.

Mida tähendab väliskeskkond…

Usaldusväärsus / vastupidavus (olelustsükli test): Need on testid, mille eesmärk on simuleerida seda, mis tootega kogu selle eluea jooksul toimub. See on asjakohasem füüsiliste toodete puhul, kus materjalid jõuavad tõrkepunkti. On olemas teatud reeglid, mis tööstuses välja töötasid, et aidata meil toote vanust kiirendada, pakkudes tootele ekstreemseid keskkonnatingimusi. Põhimõtteliselt võime testida, kas toode töötab viis aastat pärast toatemperatuuri korrektselt, proovida seda ühe päeva jooksul 70 kraadi ja 10 g vibratsiooni korral (ainult näide !!!). Neid nimetatakse HALT-testideks (kiirendatud eluiga)

Äärmuslike tingimuste testid (koormus, serv): need on testid, millega testitakse toote käitumist ekstreemsetes või ääreoludes. Näiteks kui elektrooniline toode töötab 5 V voolul, katsetame seda 4,5 V ja 5,5 V pinge korral, võime süstida isegi 25 V või -5 V pinget, et kontrollida, kas toode on vastupidav kasutaja vigadele või elektrilistele pingetele. Digitaaltoodete puhul võime väljakutse sisendväljadele põhjendamatute väärtustega. Näidetena võiksime sisestada nimesid, mis on 1000 tähemärki või millel on mõttetud sümbolid. kui kavandasime toote kindlale koormusele (50 samaaegset kasutajat), siis testime selle käitumist 100 samaaegse kasutaja korral. Nende testide mõte on peamiselt avastada uusi tõrkerežiime. Me ei eelda, et toode töötab ideaalselt, kuid võime avastada olulisi probleeme, ootamatuid käitumisharjumusi või kitsaskohti, mis on asjakohased ka tavaolukorras.

Vastavus- / turvatestid: Mõlemat tüüpi tooted peavad mõnikord vastama standarditele ja olema nendega vastavuses. Elektroonilised tooted peavad olema ohutud, turvalised ja usaldusväärsed ning kaitsma kasutajat elektrilöögi või ülekuumenemise eest (UL, CE, FCC ..), samuti peavad nad vastama teatud raadioside standarditele, nagu näiteks Wifi või Bluetooth. Digitaalsed tooted, mis käsitlevad isikut tuvastavat teavet (PII), näiteks krediitkaardinumbrid (PCI, ISO / IEC 27001, NIST) või sotsiaalkindlustuse numbrid (GDPR), peavad andmeid kaitsma igasuguste rünnakute ja töötajate hooletuse eest. Mõlema toote puhul on vastavusprotsess kallis ja pikk, kuid on olemas viise kulude vähendamiseks ja eelnevalt kinnitatud moodulite ja teenuste kasutamiseks.

Mida tähendab järgimine ...

Testkatvus: Tahvli kujundajana ei saa te kunagi kindel olla, et tootmisprotsess oli puudusteta. Mõnel juhul on külgnevate jälgede vahel pisikesed lühikesed püksid, mida saate näha ainult mikroskoobiga. Muudel juhtudel pole elektroonilised komponendid piisavalt usaldusväärsed või võivad olla isegi võltsitud komponendid. Kvaliteediprotsessi osana peavad tahvlite kujundajad ja manustatud arendajad tegema koostööd testimisriistade kirjutamiseks, mis kinnitavad, et iga ühendus ja iga komponent toimivad ootuspäraselt 100% katvusega. Olen töötanud JIG-ide testimisel, mis simuleerivad iga andurit ja iga sisendit tahvlile, et saavutada 100% katvus. Samuti on hea tava viia need testid läbi paralleelselt kiirendatud sõeltestidega (HASS), kus tahvlit mõjutavad vibratsioon ja termilised tsüklid.

Samamoodi on tarkvara puhul hea tava kirjutada testimiskood, mis katab vähemalt 99% teie koodist. Enne uue koodi juurutamist tootmiskeskkonda käivitab automatiseerimistööriist testimiskoodikomplekti ja kontrollige, kas see, mis kunagi varem töötas, ikka töötab. Mõlemal juhul peaks nende testimisriistade kallal töötamine algama koos tootearendusega (mõnikord isegi enne: TDD) ja neid tuleks piisavalt varustada.

Kujundus / koodi ülevaade: inimesed teevad vigu. Kõik, kes arvavad, et neil pole, pole kas piisavalt kogenud või neil on lühike mälu. PCB-plaadi paigutuse kujundamisel ja uute komponentide paigutamisel on eriti lihtne teha vigu seoses uute komponentide pinout-konfiguratsiooni ja füüsiliste mõõtmetega. vigu leiad alles nädalaid või kuid hiljem. Võite vaadata disainilahendust ja kontrollida seda andmelehe abil, uuesti vaadata ja uuesti kinnitada. Mõlemal juhul jätate selle kahe silma vahele. Sel põhjusel on sõltumatu ülevaatus ja registreerumine elektrooniliste toodete arendamise tavapraktika. Tarkvaraarendajad teevad turvalisuse osas sageli vigu. Näiteks panevad nad tundlikud võtmed avalikesse koodiandmete hoidlatesse või puutuvad kokku klientidega. Päringutaotlus on meetod, mille abil saate teistele meeskonnaliikmetele enne muudatuste tegemist muudatustest teada saada. Need teenivad mitut eesmärki: puuduste ja probleemide tuvastamiseks, koodi loetavuse ja dokumenteerimise parandamiseks ning meeskonna vahel teadmiste jagamiseks. Paariprogrammeerimine on veel üks meetod, mida tarkvaraarendajad kasutavad teadmiste jagamiseks ja üksteise koodi ülevaatamiseks.

Konfiguratsioonihaldus: CM on tava muudatuste süsteemseks käsitlemiseks. Seda kasutatakse toote versioonide dokumenteerimiseks ja versioonide vahel sellele tehtud muudatuste jälgimiseks. Hea konfiguratsioonihaldussüsteem võimaldab teil luua ja testida toote mis tahes versiooni, kasutades ainult selles sisalduvaid esemeid ilma muude väliste teadmisteta. DevOps-i insenerid kasutavad toote koodi, konfiguratsiooni ja infrastruktuuri salvestamiseks SCM-i (tarkvara konfiguratsioonihaldus) tööriistu nagu GIT, Ansible, Terraform, Chef. Samuti võivad nad siduda need muudatused JIRA probleemidega, et dokumenteerida seos vea / defekti / funktsiooni taotluse ja sellest tulenevate tegelike muudatuste vahel. Elektroonikainsenerid kasutavad tööriistu, mida mõnikord nimetatakse PLM (toote elutsükli haldus) ja mõnikord HCM (riistvara konfiguratsiooni haldus). Põhimõtteliselt teenivad nad sama eesmärki, kuid hõlmavad erinevaid integratsioone ja protsesse. Näiteks võib PLM-süsteem integreeruda ka teie ERP-süsteemi, et näidata, millised toote BOM-i osad teie laos asuvad.

Tootmine ja tootmine

Peaksite vaatama oma tootjat kui oma partnerit, mitte kui tarnijat. Lõppude lõpuks annate tootjale oma kõige tundlikumad varad: kõik, mis teie toote ehitamiseks vajalik! Teie tootja aitab teil tutvustada uusi tootmismeetodeid, vähendab defekte, parandab protsessi tõhusust ja jagab mingil moel osa tootega kaasnevatest riskidest ja eelistest.

Lean Lean on kõik, mis on seotud kulude kokkuhoiuga. Füüsiliste toodete puhul tähendab lahja:

  • Null viivitus kõigis tootmisliini etappides
  • Tasuge puudused, iga lõpptoote kõrgeim kvaliteet
  • Masinad / inimesed on 100% ära kasutatud
  • Teadmiste tagasiside: iga õppetund ja ülevaade parandavad protsessi
  • Tootmine just õigel ajal: iga toodet müüakse, jäätmeid pole

Digitaalsete toodete puhul tähendab lahja:

  • Automaatne skaleerimine: arvutuslike ressursside skaala koormuse põhjal
  • Tasu tunnis

Torustike tootmine: Monteerimisliini seadistamine ei erine oluliselt tarkvara CI / CD (pidev integreerimine / pidev tarnimine) torujuhtme seadistamisest. Kui olete lugenud Phoenixi projektiraamatut, mäletate tõenäoliselt seda, kuidas mõned kontseptsioonid lahja ja DevOps tuletati raamatus füüsilisest tootmisliinist. Mõlemad torujuhtmed käitlevad kõike, mida on vaja teie toote ehitamiseks, testimiseks ja saatmiseks. Automaatika lisamisel saate kiiremini kohale toimetada. Elektrooniliste toodete puhul tähendab see kulude ja puuduste vähendamist ning digitaaltoodete mahu parandamist, digitaaltoodete puhul tähendab see kiiremat kasutajate testimist ja kohanemisvõimet.

Edastamine kogu maailmas: on huvitav sarnasus sisu edastamise võrkude (CDN) vahel, mida kasutatakse veebivarade edastamiseks kasutajatele vastavalt nende geograafilisele asukohale, ja kuidas tootmine on jaotatud üle maailma, et vähendada saatmiskulusid ja toodete lokaliseerimist. Sisu vahemällu salvestamist võib käsitleda kohalike ladude või täitmisteenustena, näiteks Amazon. Mõlemat tüüpi toodete puhul parandab kohalik kohalolek kliendi üldist kogemust kogu maailmas

Võib tunduda, et füüsiliste toodete olemasolu on kogu maailmas raskem, kuid ka andmekaitse reguleerimine ja keele lokaliseerimine nõuavad olulisi jõupingutusi

Pilveteenused: pilveteenused on fantastilised. Saate oma digitoote mõne sekundiga ehitada, kui valite sadade veebiteenuste hulgast. Paar hiireklõpsu ja see töötab automaatselt enam kui 20 andmekeskuses üle kogu maailma ja skaala vastavalt nõudlusele. Tootmises pole midagi sellist, kuid see võib olla järgmine tööstusrevolutsioon. Kujutage ette digitaaltoodet, kus saate seadistada tootmistorustiku, kasutades eelkonfigureeritud mooduleid, näiteks 3D-printimine, trükkplaatide tootmine, komponentide hankimine, plaatide ja kaablite kokkupanek, testide käitamine ja otse klientidele saatmine kohalikust automatiseeritud tootmispõrandast. Lisaks võimaldab teenus lõppkasutajal kohandada toote värvi, kuju ja muid isikupärastamise funktsioone. See näib unistusena, kuid olen kindel, et kuskil maailmas töötab Amazon sellise teenuse kallal (vähemalt loodan, et nad seda teevad).

Järeldus

Elektrooniliste toodete ja digitaalsete arendusprotsesside vahel on palju erinevusi, kuid vaadates seda 20 aasta perspektiivist, on hämmastav näha, kui palju digitaalsete toodete kujundamise põhimõtteid ja protsesse kasutavad nüüd füüsilised tootejuhid. AWS teatas hiljuti manustatud süsteemide FreeRTOS-ist. Ma ennustan, et 10–20 aasta jooksul ei ole digitaalse toote ja füüsilise toote arendusprotsessis olulisi erinevusi.

Kui soovite rohkem teada saada minu teekonna kohta ja kuidas juhtida meeskonda, mis elab mõlemas maailmas, võtke minuga otse ühendust.