Elektroninių ir skaitmeninių gaminių projektavimas ir tobulinimas

Man pasisekė sukurti ir valdyti tiek fizinių, tiek skaitmeninių produktų kūrimą. Dalydamasi meile ir aistra abiem, maniau pateikti savo požiūrį ir keletą pastebėjimų apie jų vystymosi procesų skirtumus ir panašumus.

Kokia yra produkto reikšmė…

Kas yra produktas? Tai, kas gaminama ir parduodama, ar kažkas, kas sukuria vertę vartotojams? Pirmasis apibrėžimas taikomas tik fiziniams gaminiams ir atspindi tai, ką mes darome su produktais ir kaip mes juos kuriame. Antrasis apibrėžimas yra atviresnis ir modernesnis ir atspindi, kodėl mums reikia produktų. Fiziniai produktai yra apčiuopiami; vartotojai gali juos liesti, pamatyti, užuosti ir pajusti. Mes visi matėme didžiulių gamyklų vaizdo įrašus ir galime suvokti, kokia brangi ir sudėtinga yra juos gaminti. Skaitmeniniai produktai gyvena debesyje arba atokiuose duomenų centruose. Mums sunkiau suprasti jų dydį, sudėtingumą ir ką reiškia juos sukurti. Pvz., Jei pažvelgsime į „Google“ paieškos priekinę dalį, mes galime pamatyti tik vieną paieškos eilutę, tačiau už scenos, užpakalinėje dalyje, veikia šimtai tūkstančių serverių ir milijardai kodų eilučių.

Kai programinės įrangos kūrėjai pradėjo kurti skaitmeninius produktus, maždaug prieš 25 metus jie naudojo panašius procesus ir įrankius, kurie buvo naudojami fiziniams produktams kurti. Tuo metu labiausiai patikrintas projekto valdymo procesas buvo krioklys, nes jis užtikrino tobulumą per visą projekto ciklą. Tačiau, kai skaitmeninių projektų vadovai įgijo daugiau patirties ir žlugo beveik pusėje projektų, jie suprato, kad reikia pokyčių. Jie pradėjo kurti savo įrankius ir sugalvojo savo unikalius netradicinius procesus. Apie 2001 m. Vis daugiau komandų pradėjo naudoti „Scrum“ ir „Kanban“ ir atsirado judrus manifestas. „Git“ sukūrė Linusas Torvaldsas 2005 m., Kuris padėjo pagrindą atviro kodo projektams. Galbūt skaitmeniniams gaminiams tobulumas nėra toks svarbus kaip judrumas. Šiandien, praėjus 25 metams, abiejų gaminių komandų kūrimo procesai, įrankiai ir kultūros yra labai nutolę.

Per pastaruosius penkerius metus buvo nepaprastai lengva ir nebrangu įterpti elektroniką į fizinius gaminius ir prijungti juos prie interneto prie kažkokios programos - tendencijos, vadinamos IOT (daiktų internetas). Tai kainuoja apie 2 USD už produktą, o tai paaiškina, kodėl pastaruoju metu atsiranda tiek daug naujų IOT produktų, kai kurie iš jų yra gana juokingi ... Produktų komandos lygiu ši tendencija sujungia dviejų tipų kultūras, dviejų rūšių procesus ir dviejų tipų įrankiai. Kai susiduria dvi kultūros, pradeda atsitikti įdomūs dalykai. Dabar atvirojo kodo aparatūra yra aplink mus, ir kai kurie žmonės pradėjo vadinti save kūrėjais. Kuo skiriasi gamintojas nuo gamintojo? Ar matysime šių procesų suartėjimą? ar mes pasmerkti kaip CTO ir IOT produktų vadybininkai amžiams sujungti šias kultūras?

Tikiuosi, kad šis tinklaraštis jums bus įdomus ir naudingas, ir kad jis padės kūrėjams iš visų kitų žmonių suprasti vienas kito iššūkius.

Vaidmenys ir įgūdžiai

Pastaruoju metu pastebima tendencija, kad programinės įrangos kūrėjai kuria visą programinės įrangos paketą. Tai reiškia, kad jie kuria abu pagrindinius kodus: kodą, kuris veikia serveryje / debesyje, ir programos „Frontend“ kodą: kodą, kuris veikia įrenginyje. Jie netgi gali imtis „DevOps“ vaidmens: inžinieriai, atsakingi už sistemos nustatymą, jos konfigūravimą, apsaugą ir automatizuoti pakeitimų procesą. Neįmanoma vienam asmeniui sukurti ir paleisti paprastą skaitmeninę programą ar žaidimą. Tačiau žiūrint į IOT produktus, kuriuose paprastai yra ir elektroninis įrenginys, ir tam tikra programa, technikos komanda reikalauja daugiau įgūdžių ir vaidmenų.

Įterptieji kūrėjai yra atsakingi už kodą, kuris veikia įrenginyje, o plokštės dizaineriai yra atsakingi už elektroninės plokštės kūrimą.

Nors šiandien, naudodamiesi „Espruino“, „Javascript“ kūrėjai gali teoriškai sukurti visus tris kodo lygius: „frontend“ kodą, „backend“ kodą ir įterptą kodą, jie greičiausiai susidurs su pramoniniu ir plokščių dizainu, kuriam reikia visiškai skirtingų įgūdžių. Aš mačiau talentingų kūrėjų, kurie yra visų mainų atranka ir gali greitai pereiti nuo CSS klasių modifikavimo prie duomenų bazių perkėlimo scenarijų rašymo. Aš asmeniškai manau, kad profesionalūs kūrėjai bet kuriuo metu turėtų įsisavinti tik vieną sluoksnį. Tai svarbu ne tik turėti geriausius įgūdžius ir techniką ar įdiegti reikiamas funkcijas, bet ir tai, kas jums rūpi ir kokia proto būsena yra jūsų darbas.

Bandžiau apibūdinti kiekvieno vaidmens komandoje atsakomybę. Aš vertinu, kad įvažiuoju į pavojingą teritoriją, nes vaidmenys skirtingose ​​komandose gali šiek tiek pasikeisti, todėl pabandykite pamatyti mišką, o ne medžius.

Kodėl vienam asmeniui visa tai gali nerūpėti? Kuriant produktus yra kompromisų ir konfliktų, ir jūs norite atspindėti kiekvieną poreikį subalansuotai ir simetriškai.

Per daugelį metų mačiau pagarbą skirtingų tipų kūrėjams, tačiau trūko ir žinių. Mačiau „Frontend“ kūrėjus, kurie mano, kad „backend“ yra lengva, ir „backend“ kūrėjus, kurie mano, kad „Frontend“ yra nuobodu. Aš taip pat mačiau įterptus kūrėjus, kurie nežino, kas yra REST. Anksčiau minėjau, kad netikiu, jog profesionalūs kūrėjai ir inžinieriai turėtų įvaldyti daugiau nei vieną sluoksnį. Tačiau aš tvirtai tikiu, kad jie turėtų žinoti, ką reiškia būti vienu, ir galbūt net žengti žingsnį toliau ir dirbti prie paprasto projekto, kuris jiems pateisintų įvairius iššūkius ir procesus. Plačios žinios gali padėti pagerinti komandos narių bendravimą, pagarbą ir skaidrumą, taip pat padidins visos komandos kūrybiškumą ir produktyvumą.

Projektų valdymas

Kuo skiriasi projektas nuo produkto? Projektas yra planas pasiekti tam tikrą tikslą ar apimtį per tam tikrą laiko ir išteklių apribojimą. Projektas turi pradžią ir pabaigą. Jei neturite projekto galutinio termino, tikriausiai netvarkote projekto. Pasibaigus projektui, produktas ir toliau gyvena.

Rizikos analizė: aptarsime fizinio produkto ir skaitmeninio projekto valdymo skirtumus ir panašumus. Asmeniškai man patinka galvoti apie projektų valdymą kaip į riziką nukreiptą procesą, kurio metu aš nuolat identifikuoju svarbiausias rizikas ir stengiuosi sugalvoti planą, kaip jas sumažinti. Projekto rizika yra bet kas, kas daro įtaką projekto sėkmei, t. Y. Nesugebėjimas pasiekti produkto tikslo, termino, apimties, išlaidų ar galutinės kokybės. Skaitmeniniams gaminiams viena didžiausių rizikų yra sukurti produktą, kurio vartotojams nereikia ar kurie nepatinka. Skaitmeninių produktų vadovai įsivaizduoja, tiki, spėlioja ir papasakoja gerą istoriją, tačiau kol vartotojai nepradės bendrauti su produktu, tai tik prielaidos. Norėdami patikrinti prielaidą, produktų vadovai turi greitai pristatyti, patikrinti savo hipotezę ir būti judrūs. Fiziniams gaminiams didžiausia rizika yra rasti nepataisomą problemą labai vėlyvame etape, kai šimtai ir tūkstančiai produktų jau buvo pagaminti. Gamyba reikalauja tobulumo, be jos projektas žlugs. Norėdami sumažinti šią riziką, fiziniai projektų vadovai sukuria peržiūros ir atsijungimo procesą tarp pakopų, vadinamą kriokliu.

Kiekvienas metodas buvo skirtas sumažinti skirtingas rizikas, o kiekvienas projekto vadovas, remdamasis rizikos analize, turėtų nuspręsti dėl projekto plano. Kartais asmenys ir sąveika yra svarbesni nei procesai ir įrankiai, o kartais procesai yra svarbesni. Kartais darbo programinė įranga yra svarbesnė už dokumentaciją, o kartais - svarbesnė dokumentacija. Kartais klientų bendradarbiavimas yra svarbesnis nei rašytinė sutartis. Kartais rašytinė sutartis gali išgelbėti jūsų įmonę. Kartais svarbu reaguoti į pokyčius, bet kartais svarbiau laikytis plano. Jūs gaunate tai, ką turiu galvoje.

Priemonės ir komandos ceremonijos: Projektų vadovai turėtų naudoti įrankius, kurie įgyvendina procesą, kurio metu jie nori valdyti projektus. „Microsoft Project“ yra puikus krioklio projektų įrankis. „JIRA“ ir „Trello“ yra puikūs įrankiai judriems projektams ir palaikymo procesams, tokiems kaip „Kanban“ ir „Scrum“. Kad ir koks būtų įrankis, atminkite, kad tai tik įrankis, o ne jo esmė. Komandos taip pat rengia skirtingas ceremonijas. Krioklyje komandos susitinka prieš kiekvieną rudenį ir peržiūri dokumentus, CAD sugeneruotus išteklius ar bandymų specifikacijas. Judri komanda gali susitikti kiekvieną dieną, norėdama parodyti standupą, o kas dvi savaites - planuodama sprintą. Šios ceremonijos suderina komandos narius pagal planą ir pagerina komandos narių bendravimą.

Projektavimas ir prototipų sudarymas

Dizainas: Ar šiandien yra produktas, kurio dizainas vaidina ne didelę reikšmę jo sėkmei? Kas yra produktas, jei ne tai, ką norime parduoti? Tai, kas turėtų būti patrauklu, ir estetika, kuria galime didžiuotis. Praėjo tos dienos, kai tinkamas funkcionalumas ir našumas buvo pakankamai geri. Kalbant apie elektroninius gaminius, pramoniniame dizaine turėtų būti atsižvelgiama ne tik į žmonių sąveiką, tinkamumą naudoti ir klientų patirtį, bet taip pat į aplinkos sąlygas, kuriomis produktas naudojamas, ir gamybos procesą (DFM: gamybos projektas). Skaitmeninių gaminių dizainas taip pat turėtų būti skirtas skirtingiems įrenginiams, kuriuose gali veikti programinė įranga (mobiliesiems, staliniams kompiuteriams, dideliems ekranams), ir visų rūšių vaidmenims bei vartotojams, kurie su ja sąveikauja.

Skirtingi gaminių tipai taikomi skirtingiems projektavimo metodikos tipams: Patirties dizainas žvelgia į produktą kaip į malonios patirties dalį, kurią norime sukurti, t. Y. „Mes neparduodame žaidimo, mes parduodame vienos valandos šeimos patirtį“. Aptarnaujant produktą, produktas bus matomas kaip paslaugų teikėjo ir vartotojo paslaugų teikimo pabaiga. „Nuo tada, kai nusprendėte keliauti, kol atvykstate į savo tikslą“, „Mes neparduodame apsaugos kameros, mes parduodame jums apsaugą visą parą“.

Prototipų formavimas: naudojant 3D spausdintuvus ir VR / AR technologijas, yra nepaprastai lengva sugalvoti mechaninį jūsų fizinio produkto prototipą. Galite parodyti tai savo klientams, užklijuoti lipdukus, prijungti laidus ir šviesos diodus. Jie iš karto supras jo paskirtį ir galėsite juos įtikinti, kad jūsų produktas yra paruoštas ir parduodamas. Galite įdėti jį į realią aplinką ir pamatyti, ar jis tinka mechaniškai, ir ar jį lengva laikyti. Galite padaryti dešimt versijų, palyginti ir nuspręsti dėl galutinės konfigūracijos. Nėra nieko daugiau, nei duoti ką nors savo klientams ir investuotojams laikyti rankoje. Žmonėms patinka žaislai ir apčiuopiami daiktai ir, nors mechaninė konstrukcija kartais sudaro tik 1% galutinio produkto, atsižvelgiant į vystymosi laiką, žmonės tikės, kad jūs jau pabaigėte 80% jo. Naudojant programinės įrangos prototipus, pasiekti šį lygį nėra taip paprasta. Eskizas ir „InVision“ yra puikūs įrankiai, tačiau vartotojai iškart supranta, kad tai nėra tikras produktas. Duomenys yra statiniai ir jų sąveika neturi jokios įtakos. Tai yra priežastis, dėl kurios skaitmeninių gaminių vadybininkai pasirinko judrų požiūrį ir MVP koncepciją. Labai sunku įsivaizduoti, kaip vartotojai bendraus ir pamėgs jūsų produktą, kol jis bus paruoštas ir turės realius duomenis, todėl norėsite jį išsiųsti kuo greičiau ir pradėsite rinkti tikrus atsiliepimus.

Fizinis ir skaitmeninis prototipų sudarymas

Plėtra

Ankstyvieji sprendimai daro didžiausią įtaką: kiekvieną kartą, kai pradedu naują projektą, jaudinuosi. Kokia būtų tinkama architektūra? kuri technologija tam bus tinkamiausia? Ar turėtume pasirinkti 8 bitų MCU arba 32 bitų CPU? Ar tai geras projektas, skirtas pristatyti „GraphQL“, ar vėl turėtume laikytis REST? Kuri belaidė technologija labiausiai tinka naudoti: „Bluetooth 5“ ar „Siaurajuoste“ IOT? Kokia yra tinkama naudoti duomenų bazė? PostgreSQL, o gal grafų duomenų bazė šį kartą? Šie sprendimai yra tokie svarbūs projekto sėkmei. Kartais techninius sprendimus priimame per greitai, neatlikdami tinkamos analizės, o po trijų mėnesių apgailestaujame, kad juos pakeisti tampa per sunku ir skaudu, o į investicijas į technologijas lengviau žiūrėti kaip į kaip turtą, o ne kaip į kliūtį. Tai pasakytina ir apie elektroninius produktus, ir apie skaitmeninius produktus, nors procesoriaus tipo keitimas, pristačius produktus klientams, yra beveik neįmanoma, jei ne gėdingas.

Ankstyvieji sprendimai daro didžiausią įtaką

Plėtra: elektroninių produktų ir skaitmeninių gaminių kūrimo procesas yra labai skirtingas, o panašumų nėra daug. Didžioji PCB plokštės kūrimo laiko dalis yra tinkamų komponentų parinkimas ir išdėstymo dizainas. Dalis darbų yra grynai techniniai, jungiant laidus nuo U1 komponento 120 jungties iki U17 komponento 12. Kai kurioms užduotims atlikti reikia prototipų sudarymo iš trijų tipų jutiklių, kad būtų galima įvertinti kiekvieno iš jų triukšmą ir sunaudojamą energiją. Įterptųjų kūrimą sunku derinti ir jo optimizuoti. Gana įprasta, kad įterptieji kūrėjai naudoja GPIO kaiščius, kad galėtų nustatyti, ar funkcija buvo iškviesta, ir įvertinti, kiek laiko reikėjo atlikti. Naudoti FPGA savo elektroniniame gaminyje yra drąsus sprendimas, tačiau kartais tai yra vienintelis sprendimas jūsų našumo / išlaidų tikslams pasiekti. FPGA plėtra yra visiškai kitokia teritorija ir yra kažkur tarp ASIC plėtros, PCB plokštės kūrimo ir įterptosios plėtros. Programinės įrangos kūrėjams daugiausia laiko investuojama į… kodo rašymą. Žvelgiant į savo kasdienį darbą yra kažkas tenkinančio, visos tos kodo eilutės, kodas įsipareigoja ir traukia užklausas. Tai skamba pakankamai paprastai, tačiau kodo ir pakeitimų kiekis yra didžiulis, todėl tinkamas konfigūracijos valdymas ir peržiūros procesas yra būtinas, kad kodo bazė būtų tvarkinga, sumažėtų techninės skolos ir padidėtų visos komandos žinios.

Algoritmai, fizika ir duomenų mokslas: dažniausiai tai yra produkto smegenys, kuriose įmonės linkusios reikalauti savo intelekto. Lentų dizaineriai bendradarbiauja su fizikais, norėdami pasirinkti jutiklius, suprojektuoti AFE (analoginį priekinį galą) aplink juos arba suprojektuoti speciali antena. Įterptieji kūrėjai dirba su DSP inžinieriais ir matematikais, kad į savo programinę įrangą galėtų įterpti realaus laiko DSP algoritmus, kad filtruotų signalus, aptiktų modelius arba įgyvendintų optimizuotą matematinę formulę duomenims apdoroti / užkoduoti. Realusis laikas reiškia, kad turite atlikti apdorojimą per tam tikrą kiekį procesoriaus ciklų, kitaip nebūsite pasirengę apdoroti kito signalo ir jo nepraleisti arba negalėsite išvesti įvykių per reikiamą latenciją. Programų kūrėjai bendradarbiauja su duomenų mokslininkais, įgyvendindami paketinius procesus, norėdami rekomenduoti naujus produktus, rasti anomalijas, siūlyti draugus, mokyti giluminio mokymosi modelio, naudoti NLP analizuoti tekstą, vertinti tinklalapius ir kt. „Frontend“ kūrėjams smagu. Jie daro duomenų vizualizaciją. Naudodamiesi tokia biblioteka kaip D3JS, jie sukuria nuostabų vaizdą ir pateikia duomenis vartotojams naudingai ir apibendrintai.

Šie žmonės rinksis, kaip sumažinti triukšmą, pagerinti signalus ir surasti tinkamą pusiausvyrą tarp klaidų aptikimo (klaidingai neigiamas) ir klaidingo aliarmo (klaidingai teigiamas), jie šauks, kad jiems reikia daugiau duomenų ar atliks daugiau eksperimentų, ir šoks laimingi, jei jiems pavyks pagerinti spektaklį 5%. Įdomus produkto sprendimas yra nuspręsti, kaip suskaidyti duomenų mokslo užduotis į krūvą. Kaip pavyzdį, „Alexa“ apima mikrofonų rinkinį plokštės lygyje, tam tikrą DSP kodą programinės įrangos lygiu ir sudėtingą duomenų mokslą pagrindiniame lygmenyje, kad atpažintų mūsų kalbą.

Įrankiai: įsivaizduokite priekinių programų kūrėją ir įterptąjį kūrėją, palygindami jų kūrimo įrankius. Įterptasis kūrėjas nustos priekinės dalies kūrėją prie savo stalo ir nurodys skirtumus tarp maitinimo šaltinio, osciloskopo ir loginio analizatoriaus. Tuomet priekinės dalies kūrėjas nuves įterptą kūrėją į artimiausią kavos vietą. Jie užsisakys kavos ir ras ramią vietą, kur galės praleisti keletą valandų kartu. Tada jis / jis perjungs „Chrome“ naršyklę į kūrimo režimą ir parodys įdėtajam kūrėjui, kaip žiūrėti į tinklo srautą ir kaip matyti tam tikro HTML elemento CSS stilių.

Kokia yra velnių reikšmė…

Derinimo įrankiai skirtingiems kūrėjams skiriasi, o tikroji patirtis yra efektyvus jų naudojimas. Svarbiausias kūrėjų įgūdis yra instinktyviai žinoti, kur yra problema, ir naudoti savo įrankius namuose. Mačiau, kaip kūrėjai valandų valandas ir dienas praleidžia derindami problemą, tada kreipiasi pagalbos į patyrusį kūrėją, kuris per kelias sekundes nustato problemą. Aš to negaliu pabrėžti pakankamai, nes tai, ką turi profesionalus, turi kiekvienai užduočiai tinkamus įrankius. Tai pasakytina apie kiekvieną profesiją.

Ką reiškia derinimo ir testavimo įrankiai ...Programinės įrangos kūrėjai tai gąsdina

Kokybės užtikrinimas ir testavimas

Aplinkosaugos testai: Tikrindami savo gaminį norime įsitikinti, kad jis tinkamai veikia visose skirtingose ​​konfigūracijose ir aplinkose, kurių vartotojai tikisi naudoti. Fiziniams gaminiams aplinka paprastai reiškia temperatūrą (ypač šaltą, labai karštą), vibraciją (įsivaizduokite automobilių gaminį), šoką (nukritimas nuo jūsų rankų ant betoninių grindų), drėgmę, UV ir saulės spinduliuotę, ESD (šiuos mažus apšvietimus, kurie ateina) nuo elektrostatinės iškrovos), EMI / RFI ir kt. Skaitmeninių produktų aplinka dažniausiai reiškia naršyklės tipą („Chrome“, „Internet Explorer“, „Firefox“), OS („Android“, IOS, OSX, „Windows“), įrenginį (mobilusis, darbalaukis, konferencija). Ekranas) ir tinklo jungiamumo lygis (4G, „Wifi“, „Offline“). Paprastai netikriname visų galimų derinių, nes to padaryti būtų neįmanoma, todėl mes sugalvojame konfigūracijos rinkinį, kuris, tikiuosi, apims pakankamai scenarijų, kad būtų galima aptikti produkto specifikacijų problemas.

Kuo išorinė aplinka reiškia…

Patikimumas / ilgaamžiškumas (gyvavimo ciklo testas): tai testai, kuriais bandoma imituoti, kas nutinka gaminiui per visą jo gyvavimo laiką. Tai labiau tinka fiziniams gaminiams, kai medžiagos pasiekia gedimo taškus. Yra tam tikros taisyklės, kurias pramonė sugalvojo, kad padėtų mums pagreitinti gaminio senėjimą, veikiant jį ekstremaliomis aplinkos sąlygomis. Iš esmės, norėdami patikrinti, ar produktas tinkamai veikia po penkerių metų kambario temperatūroje, galime vieną dieną išbandyti esant 70 laipsnių ir 10 g vibracijai (tik pavyzdys !!!). Tai vadinami HALT (labai pagreitinto gyvenimo) testai

Ekstremalių sąlygų bandymai (apkrova, kraštas): tai testai, kuriais tikrinamas gaminio elgesys ekstremaliomis ar kraštinėmis sąlygomis. Pvz., Jei elektroninis gaminys veikia 5 V, mes jį išbandysime esant 4,5 V ir 5,5 V, mes galime įpurkšti net 25 V ar -5 V įtampos šuolius, kad pamatytume, ar produktas yra atsparus vartotojo klaidoms ar elektros bangai. Skaitmeniniams gaminiams mes galime užginčyti įvesties laukus su nepagrįstomis vertėmis. Pavyzdžiams galime įvesti vardus, kurių ilgis yra 1000 simbolių arba kurie neturi prasmės simbolių. jei mes suprojektavome produktą tam tikrai apkrovai (50 vienu metu besinaudojančių vartotojų), išbandysime jo elgesį su 100 vienu metu besinaudojančių vartotojų. Šių testų idėja daugiausia yra atskleisti naujus gedimo būdus. Mes nesitikime, kad produktas veiks nepriekaištingai, tačiau galime pastebėti svarbių problemų, netikėto elgesio ar kliūčių, susijusių ir su normaliomis sąlygomis.

Atitikties / saugumo testai: Kartais reikia abiejų tipų gaminių, kad jie atitiktų standartus ir atitiktų juos. Elektroniniai gaminiai turi būti saugūs, patikimi ir patikimi bei apsaugoti vartotoją nuo elektros smūgio ar perkaitimo (UL, CE, FCC ..), jie taip pat turi atitikti tam tikrus belaidžio ryšio standartus, tokius kaip „Wifi“ ar „Bluetooth“. Skaitmeniniai produktai, tvarkantys asmenį identifikuojančią informaciją (PII), pavyzdžiui, kreditinių kortelių numeriai (PCI, ISO / IEC 27001, NIST) ar socialinės apsaugos numeriai (GDPR), turi apsaugoti duomenis nuo visų rūšių išpuolių ir darbuotojų aplaidumo. Abiem gaminiams atitikties procesas yra brangus ir ilgas, tačiau yra būdų, kaip sumažinti sąnaudas ir naudoti iš anksto patvirtintus modulius ir paslaugas.

Ką reiškia atitiktis…

Testo aprėptis: Būdamas plokštės dizaineris, niekada negali būti tikras, kad gamybos procesas vyko be trūkumų. Kai kuriais atvejais tarp gretimų pėdsakų yra mažų šortų, kuriuos galite pamatyti tik mikroskopu. Kitais atvejais elektroniniai komponentai nėra pakankamai patikimi arba gali būti net suklastoti. Kokybės proceso metu plokščių dizaineriai ir įterptieji kūrėjai turi dirbti kartu, norėdami parašyti testavimo įrankius, kurie patikrintų, ar kiekvienas ryšys ir kiekvienas komponentas veikia taip, kaip tikėtasi, aprėpiant 100 proc. Aš dirbau bandydamas JIG, imituojančius kiekvieną jutiklį ir kiekvieną plokštės įvestį, kad būtų pasiekta 100% aprėptis. Taip pat gera praktika atlikti šiuos bandymus lygiagrečiai su labai pagreitintais atrankos bandymais (HASS), kai plokštę veikia vibracija ir šiluminiai ciklai.

Panašiai kaip ir programinė įranga, gera praktika yra rašyti testavimo kodą, kuris apima bent 99% jūsų kodo. Prieš diegdami naują kodą į gamybos aplinką, automatikos įrankis paleidžia testavimo kodų rinkinį ir patikrinkite, ar vis dar veikia tai, kas kada nors anksčiau veikė. Abiem atvejais darbas su šiomis bandymo priemonėmis turėtų būti pradėtas nuo produkto kūrimo (kartais net anksčiau: TDD) ir turėtų būti tinkamai aprūpintas ištekliais.

Dizaino / kodo peržiūra: žmonės daro klaidas. Kiekvienas, kuris mano, kad to nedaro, yra arba nepakankamai patyręs, arba turi trumpą atmintį. Visų pirma, projektuojant PCB plokštės išdėstymą ir dedant naujus komponentus, nepaprastai lengva padaryti klaidų, susijusių su naujų komponentų pakabinimo konfigūracija ir fiziniais matmenimis. klaidų rasite tik po savaičių ar mėnesių. Galite pažvelgti į dizainą ir patikrinti jį pagal duomenų lapą, dar kartą pažvelgti ir vėl patvirtinti, ir abiem atvejais jo praleisite. Dėl šios priežasties nepriklausoma peržiūra ir atsijungimas yra įprasta elektroninių gaminių kūrimo praktika. Programinės įrangos kūrėjai dažnai daro saugumo klaidų. Pavyzdžiui, jie dažnai įdeda slaptus raktus viešose kodų saugyklose arba yra matomi kliento. „Patraukimo užklausa“ yra būdas informuoti kitus komandos narius apie jūsų pakeitimus prieš juos atlikdami. Jie tarnauja keliems tikslams: nustatyti defektus ir problemas, pagerinti kodo skaitomumą ir dokumentavimą bei dalintis žiniomis visoje komandoje. Porinis programavimas yra dar vienas metodas, kurį programinės įrangos kūrėjai naudoja dalijimosi žiniomis ir vieno kito kodo peržiūrai.

Konfigūracijos valdymas: CM yra sistemingas pakeitimų tvarkymo praktika. Jis naudojamas gaminio versijoms dokumentuoti ir pokyčiams, kurie buvo taikomi tarp versijų, sekti. Gera konfigūracijos valdymo sistema leis jums sukurti ir išbandyti bet kurią gaminio versiją naudojant tik jame esančius artefaktus be jokių kitų išorinių žinių. „DevOps“ inžinieriai naudoja SCM (programinės įrangos konfigūracijos valdymo) įrankius, tokius kaip GIT, Ansible, Terraform, Chef, kad įrašytų produkto kodą, konfigūraciją ir infrastruktūrą. Jie taip pat gali susieti šiuos pakeitimus su JIRA problemomis, kad būtų užfiksuotas ryšys tarp klaidos / defekto / funkcijos užklausos ir tikrųjų pakeitimų, kurie atsirado dėl to. Elektronikos inžinieriai naudoja įrankius, kurie kartais vadinami PLM (produkto gyvavimo ciklo valdymas), o kartais - HCM (aparatinės įrangos konfigūracijos valdymas). Iš esmės jie atlieka tą patį tikslą, tačiau apima skirtingas integracijas ir procesus. Pvz., PLM sistema taip pat gali būti integruota į jūsų ERP sistemą ir parodyti, kurios produkto BOM dalys yra jūsų inventoriuje.

Gamyba ir gamyba

Turėtumėte žiūrėti į savo gamintoją kaip į savo partnerį, o ne į tiekėją. Galų gale jūs suteikiate gamintojui savo jautriausią turtą: viską, ko reikia jūsų produktui sukurti! Jūsų gamintojas padės jums įdiegti naujus gamybos metodus, sumažins trūkumus, pagerins proceso efektyvumą ir tam tikru būdu pasidalins tam tikra produkto rizika ir nauda.

„Lean Lean“ yra viskas, kas susiję su išlaidų taupymu. Fiziniams gaminiams liesa reiškia:

  • Nulinis visos gamybos linijos stadijos delsimas
  • Apmokėkite trūkumus, aukščiausia kiekvieno galutinio produkto kokybė
  • Mašinos / žmonės yra 100% išnaudojami
  • Žinių grįžtamasis ryšys: kiekviena pamoka ir įžvalgos pagerina procesą
  • Gamyba tik laiku: kiekvienas produktas yra parduodamas, be atliekų

Skaitmeniniams gaminiams liesos reiškia:

  • Automatinis mastelio keitimas: skaičiavimo išteklių skalė, pagrįsta apkrova
  • Mokėti už valandą

Gamybos vamzdynai: Surinkimo linijos nustatymas nelabai skiriasi nuo programinės įrangos CI / CD (nuolatinio integravimo / nepertraukiamo tiekimo) dujotiekio nustatymo. Jei perskaitėte „Phoenix“ projekto knygą, greičiausiai prisiminsite, kaip kai kurios iš „lean“ ir „DevOps“ sąvokų buvo išvestos iš fizinės gamybos linijos. Abu vamzdynai tvarko viską, ko reikia jūsų produktui sukurti, išbandyti ir išsiųsti. Pridėdami daugiau automatikos, galėsite pristatyti greičiau. Elektroniniams gaminiams tai reiškia išlaidų ir trūkumų mažinimą bei skaitmeninių gaminių talpos gerinimą, tai reiškia greitesnį vartotojo bandymą ir pritaikomą dizainą.

Pristatymas visame pasaulyje: Yra įdomus turinio pateikimo tinklų (CDN), kurie naudojami teikiant žiniatinklio išteklius vartotojams atsižvelgiant į jų geografinę vietą, ir to, kaip gamyba paskirstoma visame pasaulyje, siekiant sumažinti siuntimo išlaidas ir lokalizuoti gaminius. Turinio talpyklos kaupimas gali būti laikomas vietiniu sandėliu ar vykdymo paslauga, pavyzdžiui, „Amazon“. Abiejų tipų gaminiams vietinis buvimas pagerina bendrą klientų patirtį visame pasaulyje

Gali atrodyti, kad fiziniams produktams visame pasaulyje yra sunkiau, tačiau duomenų apsaugos reglamentavimas ir kalbos lokalizavimas taip pat reikalauja didelių pastangų

Debesies paslaugos: debesies paslaugos yra nuostabios, galite sukurti savo skaitmeninį produktą per kelias sekundes pasirinkdami iš šimtų interneto paslaugų. Keli paspaudimai ir ji bus automatiškai paleista daugiau nei 20 duomenų centrų visame pasaulyje ir masteliu, atsižvelgiant į paklausą. Gamyboje nieko panašaus nėra, tačiau tai gali būti kita pramonės revoliucija. Įsivaizduokite skaitmeninį gaminį, kuriame galite nustatyti gamybos dujotiekį naudodami iš anksto sukonfigūruotus modulius, tokius kaip 3D spausdinimas, PCB gamyba, komponentų tiekimas, plokščių ir kabelių surinkimas, bandymai ir pristatymas tiesiai klientams iš vietinių automatizuotų gamybos grindų. Be to, paslauga galutiniam vartotojui leis pritaikyti gaminio spalvą, formą ir kitas pritaikymo ypatybes. Tai atrodo kaip svajonė, tačiau esu tikras, kad kažkur visame pasaulyje „Amazon“ dirba su tokia paslauga (bent jau tikiuosi, kad jie tai daro).

Išvada

Tarp elektroninių ir skaitmeninių gaminių kūrimo proceso yra daug skirtumų, tačiau pažvelgus į tai nuo 20 metų perspektyvos, nuostabu matyti, kiek skaitmeninių gaminių projektavimo principų ir procesų dabar naudoja fiziniai gaminių valdytojai. Neseniai AWS paskelbė apie įterptųjų sistemų „FreeRTOS“. Aš prognozuoju, kad per 10–20 metų nebus jokio reikšmingo skirtumo tarp skaitmeninio produkto ir fizinio kūrimo proceso.

Jei norite sužinoti daugiau apie mano kelionę ir kaip suvaldyti komandą, kuri gyvena abiejuose pasauliuose, nedvejodami susisiekite su manimi tiesiogiai.