Dizajnimi dhe zhvillimi i produkteve elektronike vs produkteve digjitale

Pata fatin të zhvilloja dhe menaxhoja zhvillimin e produkteve fizike dhe atyre dixhitale. Ndërsa ndaja dashurinë dhe pasionin për të dy, mendova të paraqesja pikëpamjet e mia dhe disa vëzhgime mbi ndryshimet dhe ngjashmëritë midis proceseve të tyre të zhvillimit.

Cili është kuptimi i një produkti për…

Farë është një produkt? Diqka që prodhohet dhe shitet, ose diçka që krijon një vlerë për përdoruesit? Përkufizimi i parë vlen vetëm për produktet fizike dhe pasqyron atë që ne bëjmë me produkte dhe si i ndërtojmë ato. Përkufizimi i dytë është më i hapur dhe modern dhe pasqyron pse kemi nevojë për produkte. Produktet fizike janë të prekshme; përdoruesit mund t'i prekin, t'i shohin ato, t'i nuhasin dhe t'i ndiejnë ato. Të gjithë kemi parë video të fabrikave të mëdha dhe mund të kuptojmë se sa e kushtueshme dhe e ndërlikuar është prodhimi i tyre. Produktet digjitale jetojnë në cloud ose në qendrat e largëta të të dhënave. Shtë më e vështirë për ne të kuptojmë madhësinë e tyre, kompleksitetin dhe çfarë do të thotë të ndërtosh një. Për shembull, nëse shikojmë pjesën e përparme të Kërkimit Google, ne mund të shohim vetëm një linjë kërkimi, por prapa skenës, në sfondin, ka qindra mijëra servera që funksionojnë dhe miliarda linja kode.

Kur zhvilluesit e softuerëve filluan të ndërtojnë produkte dixhitale, rreth 25 vjet më parë, ata përdorën procese dhe mjete të ngjashme, të cilat u përdorën për të ndërtuar produkte fizike. Procesi më i provuar për menaxhimin e projektit, në atë kohë, ishte Ujëvara pasi garantonte përsosmërinë gjatë gjithë ciklit të projektit. Megjithatë, pasi menaxherët e projekteve dixhitale fituan më shumë përvojë dhe dështuan në pothuajse gjysmën e projekteve, ata kuptuan se kishin nevojë për një ndryshim. Ata filluan të ndërtojnë mjetet e tyre dhe dolën me proceset e tyre unike jo konvencionale. Rreth 2001, gjithnjë e më shumë ekipe filluan të përdorin Scrum dhe Kanban dhe u shfaq manifesti i shkathët. Git u krijua nga Linus Torvalds në 2005 i cili hodhi themelet për projekte me burim të hapur. Ndoshta për produktet dixhitale përsosja nuk është aq e rëndësishme sa gatishmëria. Sot, 25 vjet më vonë, proceset e zhvillimit, mjetet dhe kulturat e të dy ekipeve të produkteve janë shumë larg.

Gjatë pesë viteve të fundit, u bë jashtëzakonisht e lehtë dhe e lirë për të futur elektronikën në produktet fizike dhe për t'i lidhur ato në internet me një lloj aplikacioni - një trend i cili quhet IOT (Internet of things). Kushton rreth 2 $ për produkt për ta bërë këtë gjë që shpjegon pse ne shohim së fundmi kaq shumë produkte të reja IOT, disa prej tyre janë mjaft zbavitëse ... Në nivelin e ekipit të produktit, kjo prirje bashkon dy lloje të kulturave, dy lloje të proceseve dhe dy lloje mjetesh. Kurdoherë që dy kultura përplasen, fillojnë të ndodhin gjëra interesante. Pajisjet me burim të hapur janë të gjithë rreth nesh tani, dhe disa njerëz filluan ta quajnë veten prodhues. Cili është ndryshimi midis një prodhuesi dhe një prodhuesi? A do të shohim një konvergjencë midis këtyre proceseve? apo jemi të dënuar, si CTOs dhe menaxherët e produkteve IOT të lidhin përgjithmonë midis këtyre kulturave?

Shpresoj ta gjeni këtë blog si interesant, ashtu edhe të dobishëm dhe do të ndihmojë zhvilluesit nga të gjithë pirgët të kuptojnë sfidat e njëri-tjetrit.

Rolet dhe aftësitë

Ekziston një prirje e kohëve të fundit për zhvilluesit e programeve kompjuterike për të zhvilluar rafte të plotë të softverit. Kjo do të thotë që ata zhvillojnë të dy kodin e prapambetur: kodin që funksionon në server / cloud dhe kodin frontend: kodin që funksionon në pajisje. Ata madje mund të marrin rolin DevOps: inxhinierë që janë përgjegjës për vendosjen e sistemit, konfigurimin e tij, sigurimin e tij dhe më pas automatizimin e procesit të ndryshimit. Nuk është e pamundur që një person i vetëm të ndërtojë dhe të nisë një aplikacion të thjeshtë dixhital ose një lojë. Sidoqoftë, kur shikoni produktet IOT që zakonisht përfshijnë një pajisje elektronike dhe një lloj aplikacioni, ekipi i teknologjisë kërkon më shumë aftësi dhe role.

Zhvilluesit e integruar janë përgjegjës për kodin që funksionon në pajisje dhe projektuesit e bordit janë përgjegjës për zhvillimin e bordit elektronik.

Edhe pse sot, me ndihmën e Espruino, zhvilluesit e Javascript mund të zhvillojnë teorikisht të tre nivelet e kodit: kodin frontend, kodin backend dhe kodin e ngulitur, ata ndoshta do të luftojnë me dizajnin industrial dhe atë të bordit, i cili kërkon aftësi krejtësisht të ndryshme. Kam parë zhvillues të talentuar që janë një fole e të gjitha tregtive, dhe mund të lëvizin me shpejtësi nga modifikimi i klasave CSS në shkrimin e skripteve të migracionit për bazat e të dhënave të tyre. Personalisht, unë mendoj se zhvilluesit profesional duhet të zotërojnë në çdo moment të kohës vetëm në një shtresë. Nuk ka të bëjë vetëm me aftësitë dhe teknikat më të mira ose për të zbatuar funksionalitetin e kërkuar, por është edhe për atë që ju intereson dhe me cilën gjendje mendjeje ju bëni punën tuaj.

Kam bërë një përpjekje për të përshkruar përgjegjësitë e secilit rol në ekip. Vlerësoj që hyj në një territor të rrezikshëm pasi rolet mund të ndryshojnë pak në ekipe të ndryshme, kështu që ju lutemi përpiquni të shihni pyllin dhe jo pemët.

Pse nuk mund një person të kujdeset për të gjitha? Sepse ka tregti dhe konflikte në zhvillimin e produktit, dhe ju dëshironi të përfaqësoni secilën nevojë në një mënyrë të ekuilibruar dhe simetrike.

Përgjatë viteve kam parë respekt midis llojeve të ndryshëm të zhvilluesve, por edhe mungesë njohurish. Kam parë zhvillues të fronteve që mendojnë se pamja e jashtme është e lehtë, dhe zhvilluesit e backend-it që mendojnë se frontend është i mërzitshëm. Kam parë gjithashtu zhvillues të ngulitur që nuk e dinë se çfarë është REST. Unë përmenda më parë se nuk besoj se zhvilluesit profesionistë dhe inxhinierët duhet të zotërojnë më shumë se një shtresë. Sidoqoftë, besoj fuqimisht se ata duhet ta dinë se çfarë do të thotë të jesh një dhe mbase madje të hedhin një hap më tej dhe të punojnë në një projekt të thjeshtë i cili do t'i ekspozojë ato në sfida dhe procese të ndryshme. Njohuri të gjera mund të ndihmojnë në përmirësimin e komunikimit, respektit dhe transparencës midis anëtarëve të ekipit, dhe gjithashtu do të rrisin kreativitetin dhe produktivitetin e ekipit në tërësi.

Menaxhimi i projektit

Cili është ndryshimi midis një projekti dhe një produkti? Një projekt është një plan për të arritur një qëllim ose fushëveprim të caktuar brenda një kohe të caktuar dhe kufizime të burimeve. Një projekt ka një fillim dhe një fund. Nëse nuk keni një afat kohor të projektit, me siguri nuk keni menaxhuar një projekt. Kur projekti përfundon, produkti vazhdon të jetojë.

Analiza e rrezikut: Le të diskutojmë ndryshimet dhe ngjashmëritë midis menaxhimit të projektit të një produkti fizik dhe atij dixhital. Personalisht, më pëlqen të mendoj për menaxhimin e projektit si një proces i drejtuar nga rreziku ku unë vazhdimisht identifikoj rreziqet kryesore dhe përpiqem të dal me një plan për t'i minimizuar ato. Rreziqet e projektit janë gjithçka që ndikon në suksesin e projektit d.m.th. duke mos përmbushur qëllimin, afatin, qëllimin, koston ose cilësinë përfundimtare të produkteve. Për produktet dixhitale, një nga rreziqet më të mëdha është të ndërtoni një produkt të cilin përdoruesit nuk i duhen ose nuk dëshirojnë. Menaxherët e produkteve digjitale imagjinojnë, besojnë, spekulojnë dhe tregojnë një histori të mirë, por derisa përdoruesit të fillojnë të bashkëveprojnë me produktin këto janë vetëm supozime. Për të provuar supozimin, menaxherët e produktit duhet të transportojnë shpejt, të testojnë hipotezën e tyre dhe të jenë të shkathët. Për produktet fizike, rreziku më i madh është gjetja e një problemi të pariparueshëm në një fazë shumë të vonë, pasi qindra e mijëra produkte ishin prodhuar tashmë. Prodhimi kërkon përsosmëri, dhe pa atë projekti do të dështojë. Për të ulur këtë rrezik, menaxherët e projektit fizikë ndërtojnë një proces rishikimi dhe nënshkrimi midis fazave që quhet Ujëvara.

Methoddo metodë ishte krijuar për të zvogëluar rreziqet e ndryshme, dhe çdo menaxher i projektit duhet të vendosë për planin e projektit bazuar në analizën e rrezikut. Ndonjëherë individët dhe bashkëveprimet janë më të rëndësishme se proceset dhe mjetet, dhe nganjëherë proceset janë më të rëndësishme. Ndonjëherë softueri i punës është më i rëndësishëm se dokumentacioni dhe ndonjëherë dokumentacioni është më i rëndësishëm. Ndonjëherë bashkëpunimi i klientit është më i rëndësishëm sesa kontrata me shkrim. Dhe ndonjëherë një kontratë e shkruar mund të shpëtojë kompaninë tuaj. Ndonjëherë përgjigjja ndaj ndryshimit është e rëndësishme, por ndonjëherë ndjekja e një plani është më e rëndësishme. Ju merrni atë që dua të them.

Mjetet dhe ceremonitë ekipore: Menaxherët e projektit duhet të përdorin mjete që implementojnë procesin me të cilin ata duan të menaxhojnë projektet. Microsoft Project është një mjet i shkëlqyeshëm për projektet e ujëvareve. JIRA dhe Trello janë një mjet i shkëlqyeshëm për projekte të shkathëta dhe procese mbështetëse si Kanban dhe Scrum. Sido që të jetë, mjet mos harroni se është vetëm një mjet dhe jo thelbi. Ekipet gjithashtu kanë ceremoni të ndryshme. Në Ujëvarë, skuadrat takohen para çdo vjeshte dhe dokumentet e rishikimit, CAD prodhuar rezultate ose specifikime të provës. Ekipi i shkathët mund të takohet çdo ditë për një qëndrim ditor dhe çdo dy javë për planifikimin e sprintit. Këto ceremoni rreshtojnë anëtarët e ekipit në plan dhe përmirësojnë komunikimin midis anëtarëve të ekipit.

Dizajnimi dhe Prototipizimi

Dizajni: A ekziston një produkt sot ku dizajni nuk luan një rol të madh në suksesin e tij? Farë është një produkt nëse jo diçka që ne duam të shesim? Diçka që duhet të jetë tërheqëse dhe estetike, për të cilën mund të krenohemi. Kanë kaluar ditët ku të kesh funksionimin dhe performancën e duhur ishte mjaft e mirë. Për produktet elektronike, dizajni industrial duhet të marrë në konsideratë jo vetëm ndërveprimin njerëzor, përdorueshmërinë dhe përvojën e klientit, por edhe kushtet mjedisore në të cilat është duke u përdorur produkti dhe procesin e prodhimit (DFM: dizajn për prodhim). Për produktet digjitale, dizajni duhet të adresojë gjithashtu pajisjet e ndryshme që softveri mund të ekzekutohet (celular, desktop, ekranet e mëdha) dhe të gjitha llojet e roleve dhe përdoruesve që bashkëveprojnë me të.

Lloje të ndryshme të metodologjisë së dizajnit aplikohen për lloje të ndryshme të produkteve: Dizajni i përvojës shikon produktin si pjesë e një përvoje të këndshme që duam të krijojmë d.m.th "Ne nuk po shesim një lojë, ne po shesim një përvojë një-orëshe të familjes". Dizajni i shërbimit do të shohë produktin si pjesë e shërbimit një fund për t'i dhënë fund midis një ofruesi të shërbimit dhe një përdoruesi. "Që nga momenti kur keni vendosur të udhëtoni deri sa të arrini në destinacionin tuaj", "Ne nuk po shesim një aparat fotografik sigurie, po ju shesim mbrojtje 24/7".

Prototyping: Me ndihmën e printerëve 3D dhe teknologjisë VR / AR, është jashtëzakonisht e lehtë të paraqitni një prototip mekanik të produktit tuaj fizik. Ju mund t'i tregoni klientët tuaj, të vendosni disa afishe, të lidhni disa tela dhe LED, ata menjëherë do ta kuptojnë qëllimin e tij dhe ju mund të jeni në gjendje t'i bindni ata që produkti juaj është gati dhe komercial. Mund ta vendosni në mjedisin real dhe të shihni nëse ai përshtatet mekanikisht dhe nëse është i lehtë për tu mbajtur. Ju mund të bëni dhjetë versione dhe të krahasoni midis tyre dhe të vendosni për konfigurimin përfundimtar. Nuk ka asgjë më të fuqishme sesa t'u jepni klientëve dhe investitorëve tuaj diçka për të mbajtur në dorë. Njerëzit i pëlqejnë lodrat dhe gjërat e prekshme dhe megjithëse dizajni mekanik ndonjëherë është vetëm 1% e produktit përfundimtar përsa i përket kohës së zhvillimit, njerëzit do të besojnë se ju keni përfunduar tashmë 80% të tij. Me prototipimin e softuerit nuk është aq e thjeshtë për të arritur në këtë nivel. Skica dhe InVision janë mjete të shkëlqyera, por përdoruesit menjëherë e kuptojnë se ky nuk është një produkt i vërtetë. Të dhënat janë statike dhe ndërveprimi i tyre nuk ka asnjë efekt në të. Kjo është pjesë e arsyes pse menaxherët e produkteve digjitale adoptuan qasjen e shkathët dhe konceptin e MVP. Shtë shumë e vështirë të imagjinohet se si përdoruesit do të bashkëveprojnë dhe e duan produktin tuaj përpara se të jetë gati dhe të ketë të dhëna reale, kështu që ju dëshironi ta dërgoni atë sa më shpejt që të keni mundësi dhe të filloni të mblidhni reagime të vërteta.

Prototipika fizike dhe dixhitale

zhvillim

Vendimet e hershme kanë ndikimin më të madh: Sa herë që filloj një projekt të ri, unë jam i ngazëllyer. Cila do të ishte arkitektura e duhur? cila teknologji do të jetë më e përshtatshme për të? A duhet të zgjedhim një MCU 8 bit ose një CPU 32 bit? A është ky një projekt i mirë për të prezantuar GraphQL, apo do të përmbahemi përsëri me REST? Cila teknologji pa tel i përshtatet më së miri rastit të përdorimit: Bluetooth 5 ose Narrowband IOT? Cila është baza e të dhënave e duhur për t’u përdorur? PostgreSQL ose mbase një databazë grafike këtë herë? Këto vendime janë kaq të rëndësishme për suksesin e projektit. Ndonjëherë, marrim vendime teknike shumë shpejt pa analiza të duhura dhe pastaj tre muaj më vonë i pendojmë për ta, bëhet shumë e vështirë dhe e dhimbshme t'i ndryshosh ato, dhe është më e lehtë të shikosh investimin e teknologjisë si një aktiv dhe jo si një pengesë. Kjo është e vërtetë si për produktet elektronike ashtu edhe për produktet dixhitale, megjithëse ndryshimi i llojit të procesorit pasi të dërgoni produktet tuaja tek klientët tuaj është pothuajse një detyrë e pamundur nëse jo një e turpshme.

Vendimet e hershme kanë ndikimin më të madh

Zhvillimi: Ka shumë dallime midis procesit të zhvillimit të produkteve elektronike dhe produkteve dixhitale, dhe nuk ka shumë ngjashmëri. Shumica e kohës së zhvillimit për një bord PCB shkon në zgjedhjen e komponentëve të duhur dhe hartimin e paraqitjes. Disa nga punimet janë thjesht teknike, duke lidhur tela nga komponenti U1 pin 120 me përbërësin P17 12. Dhe disa detyra kërkojnë prototipim të plotë rreth tre llojeve të sensorëve vetëm për të matur zhurmën dhe konsumin e energjisë të secilit prej tyre. Zhvillimi i integruar është i vështirë për të debuguar dhe optimizuar, është mjaft e zakonshme të shihen zhvilluesit e ngulitur që përdorin kunjat GPIO për të zbuluar nëse një funksion është thirrur dhe për të matur sa kohë u desh për të ekzekutuar. Përdorimi i FPGA në produktin tuaj elektronik është një vendim i guximshëm, por ndonjëherë është zgjidhja e vetme për të arritur qëllimet tuaja të performancës / kostos. Zhvillimi i FPGA është një territor krejtësisht i ndryshëm dhe është diku midis zhvillimit të ASIC, zhvillimit të bordit PCB dhe zhvillimit të ngulitur. Për zhvilluesit e programeve kompjuterike, shumica e kohës investohen në… shkrim kod. Somethingshtë diçka shumë e kënaqshme në shikimin e punës suaj të përditshme, të gjitha ato linja kodesh, kodesh dhe angazhimesh për tërheqje. Kjo tingëllon mjaft e thjeshtë, por sasia e kodit dhe ndryshimeve është shumë e madhe, kështu që një proces i duhur i menaxhimit dhe rishikimit të konfigurimit është thelbësor për të mbajtur të organizuar bazën e kodit, uljen e borxhit teknik dhe rritjen e njohurive në të gjithë ekipin.

Algoritmet, Fizika, dhe Shkenca e të Dhënave: ky është zakonisht truri i produktit, ku kompanitë priren të pretendojnë se IP e tyre është in. Dizajnerët e bordit punojnë me fizikantë për të zgjedhur sensorë, për të hartuar AFE (fund analoge të përparme) rreth tyre ose për të hartuar një antenë speciale. Zhvilluesit e integruar punojnë me inxhinierë dhe matematikanë të DSP për të futur algoritme DSP në kohë reale në programin e tyre për të filtruar sinjalet, për të zbuluar modele ose për të zbatuar ndonjë formulë matematikore të optimizuar për të përpunuar / koduar të dhënat. Në kohë reale do të thotë që ju duhet të kryeni përpunimin brenda një sasie të caktuar të cikleve të CPU, përndryshe nuk do të jeni të gatshëm të përpunoni sinjalin tjetër dhe ta humbisni atë ose nuk do të mund të nxirrni ngjarje brenda latencës së kërkuar. Zhvilluesit e backend-it punojnë me shkencëtarët e të dhënave për të zbatuar procese të grupeve për të rekomanduar produkte të reja, të gjejnë anomali, të sugjerojnë miq, të trajnojnë një model të thellë të mësimit, të përdorin NLP për të analizuar tekstin, për të shënuar faqet në internet, etj. Zhvilluesit e Frontend kanë kënaqësi. Ata po bëjnë vizualizimin e të dhënave. Me një bibliotekë të tillë si D3JS, ato krijojnë pamje vizuale të mahnitshme dhe paraqesin të dhënat për përdoruesit në një mënyrë të dobishme dhe të grumbulluar.

Në të gjithë pirgët këta njerëz do të kujdesen për uljen e zhurmës, përmirësimin e sinjaleve dhe gjetjen e ekuilibrit të duhur midis zbulimit të gabimit (negativit të rremë) dhe alarmit të rremë (pozitiv i rremë), ata do të qajnë se kanë nevojë për më shumë të dhëna ose do të bëjnë më shumë eksperimente, dhe ata do të kërcejnë për fat të mirë nëse ata do të kenë sukses në përmirësimin e performancës me 5%. Një vendim interesant i produktit është të vendosni se si të ndani detyrat e shkencës së të dhënave në rafte. Si shembull, Alexa përfshin një grup mikrofonesh në nivelin e bordit, disa kode DSP në nivelin e firmware dhe shkencë të sofistikuar të të dhënave në nivelin e prapambetjes për të njohur fjalimin tonë.

Mjetet: Imagjinoni një zhvillues të frontit dhe një zhvillues të ngulitur duke krahasuar mjetet e tyre të zhvillimit me njëri-tjetrin. Zhvilluesi i ngulitur do të ecë zhvilluesin e frontit në tryezën e tij / saj dhe do të tregojë ndryshimet midis furnizimit me energji elektrike, një oshiloskopi dhe një analist logjik. Zhvilluesi i frontit do ta çojë zhvilluesin e ngulitur në vendin më të afërt të kafesë. Ata do të porosisin kafe dhe do të gjejnë një vend të qetë ku mund të kalojnë disa orë së bashku. Ajo / ai do të zhvendos shfletuesin e tyre Chrome në modalitetin e zhvillimit dhe do t'i tregojë zhvilluesit të ngulitur se si të shikojë trafikun e rrjetit dhe si të shohë stilin CSS të një elementi të caktuar HTML.

Cili është kuptimi i devotools për të ...

Mjetet e debugimit ndryshojnë nga zhvilluesi në zhvillues dhe përdorimi i tyre në mënyrë efikase është aty ku qëndron përvoja e vërtetë. Njohja instinktive se ku është problemi, dhe përdorimi i mjeteve tuaja për të hyrë në të është aftësia më e rëndësishme e zhvilluesve. Kam parë që zhvilluesit kalojnë orë dhe ditë duke debuguar për një problem, dhe pastaj të kërkojnë ndihmë nga një zhvillues me përvojë i cili e gjen problemin në sekonda. Nuk mund ta stresoj kaq sa duhet, të kesh mjetet e duhura për secilën detyrë është ajo që të thotë të jesh profesional. Dhe kjo është e vërtetë për çdo profesion.

Cili është kuptimi i mjeteve të debugimit dhe testimit për të…Zhvilluesit e softuerëve e shohin këtë frikësuese

QA dhe Testimi

Testet mjedisore: Kur testojmë produktin tonë, duam të verifikojmë se funksionon në mënyrë korrekte në të gjitha konfigurimet dhe mjediset e ndryshme që përdoruesit presin ta përdorin atë. Për produktet fizike, ambienti zakonisht nënkupton temperaturën (të ftohtit ekstrem, jashtëzakonisht të nxehtë), dridhjen (imagjinoni një produkt automobilistik), shokun (bie nga duart tuaja në një dysheme betoni), lagështia, rrezatimi UV dhe rrezatimi diellor, ESD (këto vetëtima të vogla që vijnë nga shkarkimi elektrik-statik), EMI / RFI, etj. Për mjedisin e produkteve digjitale zakonisht nënkupton llojin e shfletuesit (Chrome, Internet Explorer, Firefox ..), OS (Android, IOS, OSX, Windows), Pajisja (Mobile, Desktop, Konferencë Ekrani) dhe niveli i lidhjes në rrjet (4G, Wifi, Offline). Ne normalisht nuk testojmë për çdo kombinim të mundshëm pasi do të ishte e pamundur ta bëjmë këtë, kështu që ne arrijmë në një grup konfigurimi që shpresojmë të mbulojë skenarë të mjaftueshëm për të zbuluar çështje brenda specit të produktit.

Cili është kuptimi i mjedisit të jashtëm për të…

Besueshmëria / Qëndrueshmëria (Testi i Ciklit të Jetës): Këto janë teste që përpiqen të simulojnë atë që ndodh me produktin gjatë gjithë jetës së tij. Shtë më e rëndësishme për produktet fizike kur materialet arrijnë pikat e tyre të dështuara. Ekzistojnë rregulla të caktuara me të cilat u shfaq industria për të na ndihmuar të përshpejtojmë epokën e produktit duke e ekspozuar atë në kushte ekstreme të mjedisit. Në thelb, për të provuar nëse një produkt funksionon në mënyrë korrekte pas pesë vjetësh në temperaturën e dhomës, ne mund ta provojmë atë në 70 gradë dhe dridhje 10g për një ditë (vetëm shembulli !!!). Këto quhen teste HALT (Jetë shumë e përshpejtuar)

Testet e kushteve ekstreme (Load, Edge): Këto janë teste që testojnë sjelljen e produktit në kushte ekstreme ose skaji. Për shembull, nëse një produkt elektronik funksionon në 5V, ne do ta testojmë atë në 4.5V dhe 5.5V, madje mund të injektojmë thumba të tensionit deri në 25V ose -5V për të parë nëse produkti është elastik ndaj gabimeve të përdoruesit ose ngritjeve elektrike. Për produktet digjitale mund të sfidojmë fushat e dhëna me vlera të paarsyeshme. Për shembuj mund të futim emra që janë 1000 karaktere të gjatë, ose kanë simbole të pakuptimta. nëse e projektuam produktin për një ngarkesë të caktuar (50 përdorues të njëkohshëm), do ta testojmë sjelljen e tij nën 100 përdorues të njëkohshëm. Ideja e këtyre testeve është kryesisht për të zbuluar mënyra të reja të dështimit. Ne nuk presim që produkti të funksionojë në mënyrë të përsosur, por mund të zbulojmë çështje të rëndësishme, sjellje të papritura ose tela që lidhen me kushtet normale.

Testet e pajtueshmërisë / sigurisë: Të dy llojet e produkteve kërkohen, nganjëherë, të plotësojnë standardet dhe të jenë në përputhje me to. Produktet elektronike duhet të jenë të sigurta, të sigurta dhe të besueshme dhe të mbrojnë përdoruesin nga goditja elektrike ose nga mbinxehja (UL, CE, FCC ..), ato gjithashtu duhet të përputhen me standarde të caktuara pa tela si Wifi ose Bluetooth. Produktet dixhitale të cilat merren me informacionin e identifikueshëm personalisht (PII) si numrat e kartave të kreditit (PCI, ISO / IEC 27001, NIST) ose numrat e sigurimeve shoqërore (GDPR) duhet të mbrojnë të dhënat kundër të gjitha llojeve të sulmeve dhe neglizhencës së punonjësve. Për të dy produktet, procesi i pajtueshmërisë është i shtrenjtë dhe i gjatë, por ka mënyra për të ulur koston dhe për të përdorur module dhe shërbime të paracaktuara.

Cili është kuptimi i pajtueshmërisë me…

Mbulimi i provës: Si një dizajnues i bordit nuk mund të jeni kurrë të sigurt se procesi i prodhimit ishte pa defekte. Në disa raste, ka pantallona të shkurtra të vogla midis gjurmëve ngjitur që mund t’i shihni vetëm me mikroskop. Në raste të tjera, përbërësit elektronikë nuk janë mjaft të besueshëm ose madje mund të jenë përbërës të falsifikuar. Si pjesë e procesit të cilësisë, projektuesit e bordit dhe zhvilluesit e ngulitur duhet të punojnë së bashku për të shkruar mjete testimi që vërtetojnë se çdo lidhje dhe çdo punë e komponentëve siç pritet me mbulim 100%. Kam punuar në testimin e JIG-ve që simulojnë çdo sensor dhe çdo input në tabelë për të arritur mbulimin 100%. Shtë gjithashtu një praktikë e mirë për të ekzekutuar këto teste paralelisht me testet e ekranit shumë të përshpejtuara (HASS) ku bordi është i ekspozuar ndaj cikleve të dridhjeve dhe termike.

Në mënyrë të ngjashme, me softuer, një praktikë e mirë është të shkruani kodin e testimit që mbulon të paktën 99% të kodit tuaj. Para vendosjes së kodit të ri në mjedisin e prodhimit, një mjet automatizimi drejton kompletin e kodeve të testimit dhe verifikon se ajo që ka punuar ndonjëherë më parë, është ende duke punuar. Për të dy rastet që punojnë në këto mjete testimi duhet të fillojnë së bashku me zhvillimin e produktit (ndonjëherë edhe më parë: TDD) dhe duhet të burohen në mënyrën e duhur.

Dizajni / rishikimi i kodit: Njerëzit bëjnë gabime. Kushdo që mendon se nuk e ka, nuk janë me përvojë të mjaftueshme ose kanë një kujtesë të shkurtër. Në veçanti, kur hartoni paraqitjen e një bordi PCB dhe vendosni komponentë të rinj, është jashtëzakonisht e lehtë të bëni gabime në lidhje me konfigurimin e pinout dhe dimensionet fizike të përbërësve të rinj. gabime që do të gjeni vetëm javë ose muaj më vonë. Ju mund ta shikoni modelin, dhe ta verifikoni atë kundër fletës së të dhënave, të shikoni përsëri, dhe të verifikoni përsëri, dhe në të dyja rastet, do ta humbni. Për këtë arsye, një përmbledhje e pavarur dhe nënshkrimi janë një praktikë standarde në zhvillimin e produktit elektronik. Zhvilluesit e softuerëve shpesh bëjnë gabime në lidhje me sigurinë. Për shembull, ata shpesh vendosin çelësa të ndjeshëm në depot e kodit publik ose i ekspozohen klientit. Tërheqja e kërkesës është një metodë për t'i lënë anëtarët e tjerë të ekipit të dinë për ndryshimet tuaja përpara se t'i kryeni ato. Ato shërbejnë për qëllime të shumta: Për të zbuluar defektet dhe çështjet, për të përmirësuar lexueshmërinë dhe dokumentacionin e kodit dhe për të shkëmbyer njohuri në të gjithë ekipin. Programimi i palëve është një metodë tjetër që përdoret nga zhvilluesit e programeve kompjuterike për të shkëmbyer njohuri dhe për të rishikuar kodin e njëri-tjetrit.

Menaxhimi i konfigurimit: CM është praktikë e trajtimit të ndryshimeve në mënyrë sistematike. Përdoret për të dokumentuar versionet e produktit dhe për të gjurmuar ndryshimet që janë aplikuar në të midis versioneve. Një sistem i mirë i menaxhimit të konfigurimit do t'ju lejojë të ndërtoni dhe testoni çdo version të produktit duke përdorur vetëm artefakte që janë në të pa ndonjë njohuri tjetër të jashtme. Inxhinierët DevOps përdorin mjete SCM (Menaxhim të konfigurimit të softuerëve) si GIT, Ansible, Terraform, Chef për të regjistruar kodin, konfigurimin dhe infrastrukturën e produktit. Ata gjithashtu mund t'i lidhin këto ndryshime në çështjet JIRA për të dokumentuar lidhjen midis kërkesës për defekt / defekt / karakteristikë dhe ndryshimeve aktuale që rezultuan prej tij. Inxhinierët elektronikë përdorin mjete që quhen nganjëherë PLM (menaxhimi i ciklit jetësor të produktit) dhe nganjëherë HCM (menaxhimi i konfigurimit të pajisjeve). Në thelb ato shërbejnë për të njëjtin qëllim, por ato përfshijnë integrime dhe procese të ndryshme. Për shembull, një sistem PLM mund të integrohet gjithashtu në sistemin tuaj ERP për të treguar se cilat pjesë të BOM të produktit janë të pranishme në inventarin tuaj.

Prodhim dhe prodhim

Ju duhet ta shikoni prodhuesin tuaj si partnerin tuaj dhe jo si furnizuesin tuaj. Në fund të fundit, ju i jepni prodhuesit tuaj pasuritë tuaja më të ndjeshme: gjithçka që është e nevojshme për të ndërtuar produktin tuaj! Prodhuesi juaj do t'ju ndihmojë të prezantoni metoda të reja prodhimi, të zvogëloni defektet, të përmirësoni efikasitetin e procesit dhe në një farë mënyre do të ndani disa nga rreziqet dhe përfitimet e produktit.

Lean Lean është gjithçka që lidhet me kursimin e kostos. Për produktet fizike, mjetet e ligët:

  • Vonesa zero në të gjitha fazat e linjës së prodhimit
  • Paguaj defektet, cilësi më të lartë për çdo produkt përfundimtar
  • Makineritë / Njerëzit shfrytëzohen 100%
  • Reagime të njohurive: lessondo mësim dhe njohuri përmirësojnë procesin
  • Vetëm në prodhimin e kohës: productdo produkt është shitur, pa mbeturina

Për produktet dixhitale, mjetet e ligët do të thotë:

  • Shkallëzimi automatik: shkalla e burimeve llogaritëse bazuar në ngarkesën
  • Paguaj në orë

Tubacionet e Prodhimit: Vendosja e një linje asambleje nuk është shumë e ndryshme nga vendosja e një tubacioni softuerësh CI / CD (Integrimi i vazhdueshëm / Dorëzimi i vazhdueshëm). Nëse keni lexuar librin e projektit Phoenix, me siguri do të mbani mend se si disa nga konceptet e ligët dhe DevOps u nxorrën në libër nga linja e prodhimit fizik. Të dy tubacionet merren me gjithçka që kërkohet për të ndërtuar, testuar dhe dërguar produktin tuaj. Ndërsa shtoni më shumë automatizëm, mund të transportoni më shpejt. Për produktet elektronike kjo nënkupton zvogëlimin e kostove dhe defekteve dhe përmirësimin e kapacitetit, për produktet digjitale, kjo nënkupton testim më të shpejtë të përdoruesit dhe modelim adaptiv.

Dorëzimi në të gjithë botën: Ekziston një ngjashmëri interesante midis rrjeteve të shpërndarjes së përmbajtjes (CDN) të cilat përdoren për të shpërndarë asetet e uebit për përdoruesit bazuar në vendndodhjen e tyre gjeografike, dhe se si prodhimi shpërndahet në të gjithë botën për të zvogëluar kostot e transportit dhe për të lokalizuar produktet. Ruajtja e përmbajtjes mund të shihet si depo lokale ose shërbime përmbushjeje siç është Amazon. Për të dy llojet e produkteve, prania lokale përmirëson përvojën e përgjithshme të klientit në të gjithë botën

Mund të duket se prania në mbarë botën është më e vështirë për produktet fizike, megjithatë, rregullimi i mbrojtjes së të dhënave dhe lokalizimi i gjuhës kërkojnë gjithashtu përpjekje të konsiderueshme

Shërbime në re: Shërbimet në re janë të mrekullueshme, ju mund të ndërtoni produktin tuaj dixhital në sekonda duke zgjedhur nga qindra shërbime në internet. Disa klikime dhe ajo do të funksionojë automatikisht në më shumë se 20 qendra të të dhënave në të gjithë botën dhe në shkallë të bazuar në kërkesën. Nuk ka asgjë të tillë në prodhim por kjo mund të jetë revolucioni tjetër industrial. Imagjinoni një produkt dixhital ku mund të vendosni një tubacion prodhues duke përdorur module të parafabrikuara siç janë shtypja 3D, prodhimi PCB, burimi i përbërësve, montimi i bordit dhe kabllove, testet e drejtimit dhe dërgimi direkt te klientët tuaj nga një dysheme prodhimi automatik vendas. Për më tepër, shërbimi do t'i lejojë përdoruesit përfundimtar të rregullojë ngjyrën e produktit, formën dhe veçoritë e tjera të personalizimit. Kjo duket si një ëndërr, por jam i sigurt se diku në mbarë botën Amazon po punon për një shërbim të tillë (Të paktën shpresoj se do ta bëjnë).

përfundim

Ekzistojnë shumë dallime midis procesit të zhvillimit të produkteve elektronike dhe atyre dixhitale, por duke e parë atë nga një perspektivë prej 20 vjetësh, është e mahnitshme të shihet se sa prej parimeve të projektimit dhe proceseve të produkteve digjitale përdoren tani nga menaxherët e produkteve fizike. AWS ka njoftuar së fundmi në FreeRTOS për sistemet e ngulitura. Parashikoj që në 10-20 vjet nuk do të ketë ndonjë ndryshim të rëndësishëm ndërmjet procesit të zhvillimit të një produkti dixhital dhe atij fizik.

Nëse dëshironi të mësoni më shumë rreth udhëtimit tim, dhe si të menaxhoni një ekip i cili jeton në të dy botët, mos ngurroni të më drejtoni drejtpërdrejt.