Návrh a vývoj elektronických produktů vs digitální produkty

Měl jsem štěstí, že jsem vyvíjel a řídil vývoj fyzických i digitálních produktů. Když sdílím lásku a vášeň pro oba, myslel jsem, že představím své názory a některá pozorování o rozdílech a podobnostech mezi jejich vývojovými procesy.

Jaký je význam produktu pro ...

Co je to produkt? Něco, co se vyrábí a prodává, nebo něco, co vytváří hodnotu pro uživatele? První definice se týká pouze fyzických produktů a odráží to, co s výrobky děláme a jak je vytváříme. Druhá definice je otevřenější a modernější a odráží to, proč potřebujeme výrobky. Fyzické produkty jsou hmotné; uživatelé se jich mohou dotknout, vidět, cítit a cítit. Všichni jsme viděli videa velkých továren a můžeme pochopit, jak drahé a složité je jejich výroba. Digitální produkty žijí v cloudu nebo ve vzdálených datových centrech. Je pro nás těžší pochopit jejich velikost, složitost a co to znamená vybudovat. Pokud se například podíváme na rozhraní Google Search, můžeme vidět pouze jednu vyhledávací linku, ale za scénou na pozadí jsou spuštěny stovky tisíc serverů a miliardy řádků kódů.

Když vývojáři softwaru začali stavět digitální produkty, používali přibližně před 25 lety podobné procesy a nástroje, které byly použity k vytváření fyzických produktů. Nejzkušenějším postupem pro řízení projektů v té době byl Waterfall, protože zaručoval dokonalost v průběhu celého projektového cyklu. Avšak jak digitální projektoví manažeři získali více zkušeností a selhali v téměř polovině projektů, uvědomili si, že potřebují změnu. Začali stavět vlastní nástroje a přišli se svými jedinečnými nekonvenčními procesy. Kolem roku 2001 začalo stále více týmů používat Scrum a Kanban a objevil se agilní manifest. Git vytvořil Linus Torvalds v roce 2005, který položil základy pro open source projekty. Možná pro digitální produkty není dokonalost tak důležitá jako obratnost. Dnes, o 25 let později, jsou vývojové procesy, nástroje a kultury obou produktových týmů velmi vzdálené.

Během posledních pěti let bylo velmi snadné a levné vkládat elektroniku do fyzických produktů a připojit je k internetu k nějaké aplikaci - trend, který se nazývá IOT (internet věcí). Stálo to asi 2 $ na produkt, což vysvětluje, proč vidíme, že se v poslední době objevuje tolik nových produktů IOT, některé z nich jsou docela zábavné ... Na úrovni produktového týmu tento trend spojuje dva typy kultur, dva typy procesů a dva typy nástrojů. Kdykoli se střetnou dvě kultury, začnou se stávat zajímavé věci. Hardware s otevřeným zdrojovým kódem je nyní všude kolem nás a někteří lidé se začali nazývat výrobci. Jaký je rozdíl mezi výrobcem a výrobcem? Uvidíme konvergenci mezi těmito procesy? nebo jsme odsouzeni jako CTO a produktoví manažeři IOT k navazování spojení mezi těmito kulturami navždy?

Doufám, že tento blog bude zajímavý i užitečný a pomůže vývojářům z celého zásobníku porozumět výzvám ostatních.

Role a dovednosti

Vývojáři softwaru v poslední době vyvíjejí kompletní sadu softwaru. To znamená, že vyvíjejí jak backend kód: kód, který běží na serveru / cloudu, a frontend kód: kód, který běží na zařízení. Mohou dokonce převzít roli DevOps: inženýři, kteří jsou zodpovědní za nastavení systému, jeho konfiguraci, zabezpečení a následnou automatizaci procesu změn. Není nemožné, aby jediná osoba vytvořila a spustila jednoduchou digitální aplikaci nebo hru. Avšak při pohledu na produkty IOT, které obvykle zahrnují jak elektronické zařízení, tak nějaký druh aplikace, vyžaduje technický tým více dovedností a rolí.

Embedded vývojáři jsou zodpovědní za kód, který běží na zařízení a návrháři desek jsou zodpovědní za vývoj elektronické desky.

Ačkoli dnes, s pomocí Espruina, mohou vývojáři Javascriptu teoreticky rozvíjet všechny tři úrovně kódu: frontendový kód, backendový kód a zabudovaný kód, pravděpodobně se potýkají s průmyslovým designem a návrhem desky, který vyžaduje zcela odlišné typy dovedností. Viděl jsem talentované vývojáře, kteří se zabývají všemi obory, a mohou rychle přecházet od úpravy tříd CSS k psaní migračních skriptů pro své databáze. Osobně si myslím, že profesionální vývojáři by měli v každém okamžiku zvládnout pouze jednu vrstvu. Nejde jen o nejlepší dovednosti a techniky nebo o implementaci požadované funkce, ale také o to, na čem vám záleží as jakým stavem mysli děláte svou práci.

Pokusil jsem se popsat povinnosti jednotlivých rolí v týmu. Oceňuji, že vstupuji na nebezpečné území, protože role se mohou v různých týmech mírně měnit, takže prosím zkuste vidět les a ne stromy.

Proč se o to nemůže starat jeden člověk? Protože ve vývoji produktů dochází ke kompromisům a konfliktům a vy chcete reprezentovat každou potřebu vyváženým a symetrickým způsobem.

V průběhu let jsem viděl respekt mezi různými typy vývojářů, ale také nedostatek znalostí. Viděl jsem vývojáře frontendu, kteří si myslí, že backend je snadný, a backend vývojáře, kteří si myslí, že frontend je nuda. Viděl jsem také vestavěné vývojáře, kteří nevědí, co REST je. Už jsem zmínil, že nevěřím, že by profesionální vývojáři a inženýři měli ovládat více než jednu vrstvu. Jsem však pevně přesvědčen, že by měli vědět, co to znamená být jedním, a možná dokonce udělat další krok a pracovat na jednoduchém projektu, který je vystaví různým výzvám a procesům. Rozsáhlé znalosti mohou pomoci při zlepšování komunikace, respektu a transparentnosti mezi členy týmu a také zvýší kreativitu a produktivitu týmu jako celku.

Projektový management

Jaký je rozdíl mezi projektem a produktem? Projekt je plán k dosažení určitého cíle nebo rozsahu v určitém časovém a zdrojovém omezení. Projekt má začátek a konec. Pokud nemáte konečný termín projektu, pravděpodobně jej nestavíte. Po skončení projektu bude produkt nadále žít.

Analýza rizik: Pojďme diskutovat o rozdílech a podobnostech mezi projektovým řízením fyzického produktu a digitálního produktu. Osobně si myslím, že řízení projektů je proces řízený riziky, kde neustále identifikuji nejvyšší rizika a snažím se navrhnout plán na jejich minimalizaci. Rizika projektu jsou cokoli, co ovlivňuje úspěch projektu, tj. Nesplnění cíle, termínu, rozsahu, nákladů nebo konečné kvality produktů. V případě digitálních produktů je jedním z největších rizik vytvoření produktu, který uživatelé nepotřebují nebo nemají rádi. Digitální produktoví manažeři si představují, věří, spekulují a vyprávějí dobrý příběh, ale dokud uživatelé nezačnou s produktem interagovat, jedná se pouze o předpoklady. Aby se tento předpoklad otestoval, musí manažeři produktů dodávat rychle, otestovat svou hypotézu a být obratní. U fyzických produktů je největším rizikem nalezení nenapravitelného problému ve velmi pozdní fázi poté, co již byly vyrobeny stovky a tisíce produktů. Výroba vyžaduje dokonalost a bez ní projekt selže. Aby se toto riziko snížilo, sestavují fyzické projektové manažery proces přezkumu a odhlášení mezi fázemi, který se nazývá Vodopád.

Každá metoda byla navržena tak, aby snížila různá rizika, a každý projektový manažer by se měl rozhodnout o plánu projektu na základě analýzy rizik. Někdy jsou jednotlivci a interakce důležitější než procesy a nástroje a někdy jsou procesy důležitější. Někdy je pracovní software důležitější než dokumentace a někdy je důležitější dokumentace. Spolupráce se zákazníky je někdy důležitější než písemná smlouva. A někdy může vaši společnost zachránit písemná smlouva. Někdy je důležitá reakce na změnu, ale někdy je důležitější sledovat plán. Získáte, co tím myslím.

Nástroje a týmové obřady: Projektoví manažeři by měli používat nástroje, které implementují proces, kterým chtějí řídit projekty. Microsoft Project je skvělý nástroj pro projekty vodopádů. JIRA a Trello jsou skvělé nástroje pro agilní projekty a podpůrné procesy jako Kanban a Scrum. Ať už je tento nástroj jakýkoli, pamatujte, že je to pouze nástroj, a nikoli podstata. Týmy mají také různé obřady. Ve vodopádu se týmy scházejí před každým pádem a přezkoumávají dokumenty, výstupy generované CAD nebo specifikace testů. Agilní tým se může scházet každý den pro každodenní standup a každé dva týdny pro plánování sprintu. Tyto obřady zarovnávají členy týmu na plánu a zlepšují komunikaci mezi členy týmu.

Design a prototypování

Design: Existuje dnes produkt, kde design nehraje hlavní roli v jeho úspěchu? Co je to produkt, ne-li něco, co chceme prodat? Něco, co by mělo být atraktivní a estetické, na které můžeme být hrdí. Pryč jsou dny, kdy měla správná funkčnost a výkon dost dobrý. U elektronických výrobků by průmyslový design měl zohledňovat nejen interakci člověka, použitelnost a zkušenosti se zákazníkem, ale také podmínky prostředí, ve kterém se produkt používá, a výrobní proces (DFM: návrh pro výrobu). V případě digitálních produktů by se návrh měl zaměřit také na různá zařízení, na kterých může software běžet (mobilní, stolní, velké obrazovky), a všechny typy rolí a uživatelů, kteří s ním pracují.

Různé typy metodiky designu se vztahují na různé typy produktů: Návrh zážitku se dívá na produkt jako na součást zábavného zážitku, který chceme vytvořit, tj. „Neprodáváme hru, prodáváme hodinovou rodinnou zkušenost“. Návrh služby uvidí produkt jako součást komplexní služby mezi poskytovatelem služby a uživatelem. "Od okamžiku, kdy jste se rozhodli cestovat, až dorazíte do cíle", "Neprodáváme bezpečnostní kameru, prodáváme vám 24/7 ochranu".

Prototypování: Pomocí 3D tiskáren a technologie VR / AR je velmi snadné přijít s mechanickým prototypem vašeho fyzického produktu. Můžete jim ukázat své klienty, dát na ně nějaké samolepky, připojit některé vodiče a LED, okamžitě pochopí jeho účel a možná je budete moci přesvědčit, že váš produkt je připraven a komerční. Můžete jej umístit do skutečného prostředí a zjistit, zda se mechanicky hodí a zda se snadno drží. Můžete si vytvořit deset verzí a porovnat mezi nimi a rozhodnout o konečné konfiguraci. Není nic mocnějšího, než dát svým klientům a investorům něco, co drží v ruce. Lidé mají rádi hračky a hmotné věci, a přestože mechanický design je z hlediska doby vývoje někdy jen 1% konečného produktu, lidé budou věřit, že jste již dokončili 80%. Díky prototypování softwaru není snadné se dostat na tuto úroveň. Skica a InVision jsou skvělé nástroje, ale uživatelé okamžitě chápou, že se nejedná o skutečný produkt. Data jsou statická a jejich interakce na ně nemá žádný vliv. To je část důvodu, proč manažeři digitálních produktů přijali agilní přístup a koncept MVP. Je velmi těžké si představit, jak uživatelé budou produkt interagovat a milovat, než bude připraven a bude mít skutečná data, takže jej chcete odeslat co nejdříve a začít sbírat skutečnou zpětnou vazbu.

Fyzické a digitální prototypování

Rozvoj

Včasná rozhodnutí mají největší dopad: Při každém zahájení nového projektu jsem nadšená. Jaká by byla správná architektura? která technologie bude pro ni nejvhodnější? Měli bychom zvolit 8bitový MCU nebo 32bitový procesor? Je to dobrý projekt představit GraphQL, nebo bychom se měli znovu držet REST? Která bezdrátová technologie se nejlépe hodí pro případ použití: Bluetooth 5 nebo úzkopásmový IOT? Jaká je správná databáze k použití? PostgreSQL nebo možná grafová databáze tentokrát? Tato rozhodnutí jsou tak důležitá pro úspěch projektu. Někdy děláme technická rozhodnutí příliš rychle bez řádné analýzy a poté o tři měsíce později je litujeme, je příliš těžké a bolestivé je změnit a je snazší podívat se na technologickou investici jako na aktivum a ne jako na překážku. To platí jak pro elektronické výrobky, tak pro digitální produkty, i když změna typu procesoru po odeslání vašich produktů zákazníkům je téměř nemožný, ne-li trapný.

Včasná rozhodnutí mají největší dopad

Vývoj: Existuje mnoho rozdílů mezi procesem vývoje elektronických produktů a digitálních produktů a není mnoho podobností. Většina času na vývoj desky PCB jde do výběru správných součástí a návrhu rozvržení. Část práce je čistě technická, spojuje dráty z komponentu U1 pin 120 ke komponentu U17 pin 12. A některé úkoly vyžadují kompletní prototypování kolem tří typů senzorů, aby se změřila hlučnost a spotřeba energie každého z nich. Vestavěný vývoj je obtížné ladit a optimalizovat, je docela běžné sledovat vývojáře, kteří používají kolíky GPIO, aby zjistili, zda byla funkce volána, a změřili, kolik času trvalo spuštění. Použití FPGA ve vašem elektronickém produktu je odvážné rozhodnutí, ale někdy je jediným řešením k dosažení vašich cílů v oblasti výkonu / nákladů. Vývoj FPGA je zcela odlišné území a je někde mezi vývojem ASIC, vývojem desek PCB a vestavěným vývojem. Pro vývojáře softwaru je většina času investována do ... psaní kódu. Při pohledu na vaši každodenní práci je něco velmi uspokojivého, všechny tyto řádky kódu, potvrzování kódu a požadavky na vyžádání. Zní to dostatečně jednoduše, ale množství kódu a změn je obrovské, a proto je nezbytný řádný proces správy a kontroly konfigurace, aby byla základna kódu organizována, snížil se technický dluh a zvyšovaly se znalosti celého týmu.

Algoritmy, fyzika a věda o údajích: to je obvykle mozek produktu, ve kterém společnosti mají tendenci tvrdit, že je jejich IP. Designéři desek pracují s fyziky na výběru senzorů, na návrhu AFE (analogový frontend) kolem nich nebo na návrhu speciální anténa. Integrovaní vývojáři spolupracují s DSP inženýry a matematiky na vkládání DSP algoritmů v reálném čase do svého softwaru pro filtrování signálů, detekci vzorců nebo implementaci nějakého optimalizovaného matematického vzorce pro zpracování / kódování dat. Real-time znamená, že musíte dokončit zpracování v určitém množství CPU cyklů, jinak nebudete připraveni zpracovat další signál a nechat si ujít nebo nebudete moci vydávat události v požadované latenci. Backendoví vývojáři spolupracují s datovými vědci při implementaci dávkových procesů k doporučování nových produktů, hledání anomálií, navrhování přátel, trénování hlubokého učení modelu, použití NLP k analýze textu, skóre webových stránek atd. Vývojáři frontendu mají veškerou zábavu. Dělají vizualizaci dat. S knihovnou, jako je D3JS, vytvářejí úžasné vizuální prvky a představují data uživatelům užitečným a agregovaným způsobem.

V celé komoře se tito lidé budou starat o snižování šumu, zlepšování signálů a nalezení správné rovnováhy mezi detekcí chybných zpráv (falešně negativní) a falešným poplachem (falešně pozitivní), budou volat, že potřebují více dat nebo více experimentů, a budou skákat šťastně, pokud se jim podaří zlepšit výkon o 5%. Zajímavým produktovým rozhodnutím je rozhodnout, jak rozdělit úkoly v oblasti vědy o údajích napříč zásobníkem. Jako příklad, Alexa zahrnuje řadu mikrofonů na úrovni desky, nějaký kód DSP na úrovni firmwaru a sofistikovanou vědu o údajích na úrovni backendu, abychom rozpoznali naši řeč.

Nástroje: Představte si vývojáře frontendu a integrovaného vývojáře, kteří si vzájemně porovnají své vývojové nástroje. Vestavěný vývojář přivede vývojáře frontendu ke svému stolu a upozorní na rozdíly mezi zdrojem napájení, osciloskopem a logickým analyzátorem. Vývojář frontendu pak zavedeného vývojáře odvede na nejbližší kávové místo. Objednají si kávu a najdou klidné místo, kde mohou spolu strávit několik hodin. Poté přepne jejich prohlížeč Chrome do vývojového režimu a ukáže integrovanému vývojáři, jak se dívat na síťový provoz a jak vidět styl CSS určitého prvku HTML.

Jaký je význam devtoolů pro…

Ladicí nástroje se liší od vývojáře k vývojáři a jeho efektivní použití je tím pravým místem. Instinktivně věděl, kde je problém, a pomocí svých nástrojů k domovu na to je nejdůležitější dovednost vývojářů. Viděl jsem vývojáře trávit hodiny a dny laděním problému a poté požádat o pomoc zkušeného vývojáře, který problém najde během několika sekund. Nemohu to dostatečně zdůraznit, mít správné nástroje pro každý úkol je to, co znamená profesionál. A to platí pro každou profesi.

Jaký je význam nástrojů pro ladění a testování ...Vývojáři softwaru to považují za zastrašující

QA a testování

Environmentální testy: Když testujeme náš produkt, chceme ověřit, zda funguje správně ve všech různých konfiguracích a prostředích, které uživatelé očekávají, že jej budou používat. Pro fyzikální produkty prostředí obvykle znamená teplotu (extrémně chladná, extrémně horká), vibrace (představte si automobilový výrobek), náraz (pády z rukou na betonovou podlahu), vlhkost, UV a sluneční záření, ESD (tato malá osvětlení, která přicházejí) z elektrostatického výboje), EMI / RFI atd. Pro prostředí digitálních produktů obvykle znamená typ prohlížeče (Chrome, Internet Explorer, Firefox ..), OS (Android, IOS, OSX, Windows), zařízení (mobilní, stolní, konferenční) Obrazovka) a úroveň síťového připojení (4G, Wifi, offline). Normálně netestujeme každou možnou kombinaci, protože by to nebylo možné, a proto přicházíme s konfigurací, která snad pokryje dostatek scénářů k detekci problémů v rámci specifikace produktu.

Jaký je význam vnějšího prostředí pro…

Spolehlivost / trvanlivost (Test životního cyklu): Jedná se o testy, které se snaží simulovat, co se s produktem děje během jeho celé životnosti. Je relevantnější pro fyzikální produkty, kde materiály dosáhnou svého bodu selhání. Existují určitá pravidla, s nimiž toto odvětví přišlo, aby nám pomohlo urychlit stáří produktu vystavením extrémním podmínkám prostředí. V zásadě, abychom mohli otestovat, zda produkt funguje správně po pěti letech při pokojové teplotě, můžeme jej testovat při 70 stupních a 10 g vibrací po dobu jednoho dne (příklad pouze !!!). Tyto testy se nazývají HALT (Vysoce zrychlený život)

Zkoušky extrémních podmínek (zatížení, okraj): Jedná se o testy, které testují chování produktu v extrémních nebo okrajových podmínkách. Pokud například elektronický produkt pracuje na 5 V, vyzkoušíme jej při 4,5 V a 5,5 V, můžeme dokonce vstříknout napěťové špičky až 25 V nebo -5 V, abychom zjistili, zda je produkt odolný vůči chybám uživatelů nebo elektrickým rázům. U digitálních produktů bychom mohli vyzvat vstupní pole s nepřiměřenými hodnotami. Například bychom mohli zadat názvy, které jsou dlouhé 1000 znaků nebo mají nesmyslné symboly. pokud jsme produkt navrhli pro určité zatížení (50 souběžných uživatelů), otestujeme jeho chování pod 100 souběžnými uživateli. Cílem těchto testů je především odhalit nové režimy selhání. Neočekáváme, že produkt bude fungovat dokonale, ale můžeme objevit důležité problémy, neočekávané chování nebo úzká místa, která jsou relevantní i pro normální podmínky.

Testy shody / zabezpečení: Oba typy produktů jsou někdy povinny splňovat standardy a být s nimi v souladu. Elektronické výrobky musí být bezpečné, bezpečné a spolehlivé a chránit uživatele před úrazem elektrickým proudem nebo přehřátím (UL, CE, FCC ..), musí také splňovat určité bezdrátové standardy, jako je Wi-Fi nebo Bluetooth. Digitální produkty, které zpracovávají informace umožňující identifikaci osob (PII), jako jsou čísla kreditních karet (PCI, ISO / IEC 27001, NIST) nebo čísla sociálního zabezpečení (GDPR), musí chránit data před všemi druhy útoků a nedbalostí zaměstnanců. U obou produktů je proces dodržování předpisů nákladný a dlouhý, existují však způsoby, jak snížit náklady a použít předem schválené moduly a služby.

Jaký je význam dodržování…

Pokrytí testu: Jako designér desky si nikdy nemůžete být jisti, že výrobní proces byl bez závad. V některých případech jsou mezi sousedními stopami drobné šortky, které můžete vidět pouze mikroskopem. V jiných případech nejsou elektronické komponenty dostatečně spolehlivé nebo dokonce mohou být padělané. V rámci procesu kvality musí návrháři desek a vývojáři vestavěných spolupracovat na psaní testovacích nástrojů, které ověřují, že každé připojení a každá komponenta fungují podle očekávání se 100% pokrytím. Pracoval jsem na testování JIG, které simulují každý senzor a každý vstup na desku, aby dosáhly 100% pokrytí. Je také dobré provádět tyto testy paralelně s vysoce akcelerovanými screeningovými testy (HASS), kde je deska vystavena vibracím a tepelným cyklům.

Podobně se softwarem je dobré napsat testovací kód, který pokrývá alespoň 99% vašeho kódu. Před nasazením nového kódu do produkčního prostředí spustí automatizační nástroj sadu testovacích kódů a ověří, že to, co kdy předtím fungovalo, stále funguje. V obou případech by práce na těchto zkušebních nástrojích měla začít společně s vývojem produktu (někdy i předtím: TDD) a měla by být zajištěna odpovídající podpora.

Design / Code review: Lidé dělají chyby. Každý, kdo si myslí, že to není, buď není dostatečně zkušený, nebo má krátkou paměť. Zejména při navrhování rozvržení desky plošných spojů a umisťování nových součástí je velmi snadné dělat chyby, pokud jde o konfiguraci vývodů a fyzické rozměry nových součástí. chyby najdete jen o týdny nebo měsíce později. Můžete se podívat na návrh a ověřit jej proti datovému listu, znovu se podívat a znovu ověřit, a v obou případech vám bude chybět. Z tohoto důvodu je nezávislý přezkum a odhlášení běžnou praxí ve vývoji elektronických produktů. Vývojáři softwaru často dělají chyby, pokud jde o bezpečnost. Například často ukládají citlivé klíče do veřejných úložišť kódů nebo jsou vystaveny klientovi. Požadavek na vytažení je způsob, jak ostatním členům týmu poskytnout informace o vašich změnách, než je provedete. Slouží k několika účelům: Zjištění vad a problémů, zlepšení čitelnosti a dokumentace kódu a sdílení znalostí v celém týmu. Párové programování je další metoda, kterou používají vývojáři softwaru ke sdílení znalostí a vzájemnému prohlížení kódu.

Správa konfigurace: CM je praxe systematického zpracování změn. Používá se k dokumentování verzí produktu a ke sledování změn, které se na něj vztahovaly mezi verzemi. Dobrý systém správy konfigurace vám umožní vytvořit a otestovat jakoukoli verzi produktu pomocí pouze artefaktů, které jsou v něm, bez jakýchkoli dalších externích znalostí. Inženýři společnosti DevOps používají k zaznamenání kódu, konfigurace a infrastruktury produktu nástroje SCM (Software Configuration Management), jako je GIT, Ansible, Terraform, Chef. Mohou také spojit tyto změny s problémy JIRA, aby dokumentovaly vztah mezi požadavkem na chybu / vadu / funkci a skutečnými změnami, které z toho vyplynuly. Elektroničtí inženýři používají nástroje, které se někdy nazývají PLM (správa životního cyklu produktu) a někdy HCM (správa hardwarové konfigurace). V zásadě slouží stejnému účelu, ale zahrnují různé integrace a procesy. Například systém PLM se může také integrovat do vašeho ERP systému a ukázat, které části kusovníku produktu jsou ve vašem inventáři.

Výroba a výroba

Měli byste se na svého výrobce dívat jako na svého partnera a ne jako na svého dodavatele. Koneckonců, dáváte svému výrobci nejcitlivější aktiva: vše, co je potřeba k sestavení vašeho produktu! Váš výrobce vám pomůže zavést nové výrobní metody, snížit závady, zlepšit účinnost procesu a určitým způsobem se bude dělit o některá rizika a výhody produktu.

Lean Lean je vše, co souvisí s úsporou nákladů. Pro fyzické produkty znamená lean:

  • Nulové zpoždění ve všech fázích výrobní linky
  • Plaťte vady, nejvyšší kvalita pro každý finální produkt
  • Stroje / lidé jsou 100% využívány
  • Zpětná vazba znalostí: Každá lekce a informace zlepšují tento proces
  • Právě včasná výroba: Každý produkt se prodává, žádný odpad

Pro digitální produkty štíhlé znamená:

  • Automatické měřítko: měřítko výpočetních zdrojů na základě zatížení
  • Platit za hodinu

Výrobní potrubí: Nastavení montážní linky se příliš neliší od instalace softwarového potrubí CI / CD (kontinuální integrace / kontinuální dodávka). Pokud jste si přečetli projektovou knihu Phoenix, pravděpodobně si budete pamatovat, jak byly některé koncepty štíhlé a DevOps v knize odvozeny z fyzické výrobní linky. Oba potrubí zpracovávají vše, co je nutné k sestavení, testování a odeslání produktu. Jakmile přidáte další automatizaci, můžete dodávat rychleji. U elektronických produktů to znamená snížení nákladů a závad a zlepšení kapacity, u digitálních produktů to znamená rychlejší testování uživatelů a přizpůsobivý design.

Celosvětové doručování: Existuje zajímavá podobnost mezi sítěmi pro doručování obsahu (CDN), které se používají k doručování webových aktiv uživatelům na základě jejich geografického umístění, a jak je výroba distribuována po celém světě, aby se snížily náklady na dopravu a lokalizovaly produkty. Ukládání obsahu do mezipaměti lze považovat za místní sklady nebo služby plnění, jako je Amazon. U obou typů produktů zlepšuje místní přítomnost celkovou spokojenost zákazníků po celém světě

Mohlo by se zdát, že celosvětová přítomnost je pro fyzické produkty těžší, nicméně regulace údajů a lokalizace jazyků vyžadují značné úsilí

Cloudové služby: Cloudové služby jsou úžasné, svůj digitální produkt můžete vytvořit za několik sekund výběrem ze stovek webových služeb. Několik kliknutí a bude probíhat automaticky ve více než 20 datových centrech po celém světě a škálovat podle poptávky. Ve výrobě není nic podobného, ​​ale může to být další průmyslová revoluce. Představte si digitální produkt, ve kterém můžete nastavit výrobní potrubí pomocí předkonfigurovaných modulů, jako je 3D tisk, výroba PCB, získávání komponentů, montáž desek a kabelů, provádění testů a expedice přímo k vašim klientům z místního automatizovaného výrobního závodu. Služba navíc umožní koncovému uživateli přizpůsobit barvu produktu, tvar a další funkce přizpůsobení. Zdá se to jako sen, ale jsem si jist, že někde na světě Amazon pracuje na takové službě (alespoň doufám, že ano).

Závěr

Existuje mnoho rozdílů mezi procesem vývoje elektronických produktů a digitálních produktů, ale při pohledu na to z pohledu 20 let je úžasné vidět, kolik návrhových principů a procesů digitálních produktů nyní používají fyzické produktové manažery. AWS nedávno oznámila FreeRTOS pro vestavěné systémy. Předpovídám, že za 10–20 let nebude žádný významný rozdíl mezi procesem vývoje digitálního produktu a fyzického produktu.

Pokud se chcete dozvědět více o mé cestě ao tom, jak řídit tým, který žije v obou světech, neváhejte mě přímo oslovit.