Дызайн і распрацоўка электронных прадуктаў супраць лічбавых прадуктаў

Мне пашанцавала распрацаваць і кіраваць развіццём як фізічных прадуктаў, так і лічбавых прадуктаў. Калі я падзяляю любоў і запал да абодвух, я думаў прадставіць свае погляды і некаторыя назіранні адносна адрозненняў і падабенства паміж працэсамі іх развіцця.

Што значыць прадукт ...

Што такое прадукт? Што-небудзь, што вырабляецца і прадаецца, ці нешта, што стварае каштоўнасць для карыстальнікаў? Першае вызначэнне тычыцца толькі фізічных прадуктаў і адлюстроўвае, што мы робім з прадуктамі і як мы іх будуем. Другое вызначэнне больш адкрытае і сучаснае і адлюстроўвае, навошта нам патрэбныя прадукты. Фізічныя прадукты адчувальныя; карыстальнікі могуць дакрануцца да іх, убачыць іх, панюхаць і адчуць іх. Мы ўсе бачылі відэа з вялізных заводаў і можам зразумець, наколькі дорага і складана іх вырабіць. Лічбавыя прадукты жывуць у воблаку або ў аддаленых цэнтрах апрацоўкі дадзеных. Нам складаней зразумець іх памер, складанасць і што значыць будаваць. Напрыклад, калі мы паглядзім на пярэдні край пошуку Google, мы можам бачыць толькі адну лінію пошуку, але за сцэнай, у задняй частцы, працуюць сотні тысяч сервераў і мільярды радкоў кодаў.

Калі распрацоўшчыкі праграмнага забеспячэння пачалі ствараць лічбавыя прадукты, каля 25 гадоў таму яны выкарыстоўвалі падобныя працэсы і інструменты, якія выкарыстоўваліся для стварэння фізічных прадуктаў. У той час самым правераным працэсам кіравання праектамі быў Вадаспад, які гарантаваў дасканаласць на працягу ўсяго цыкла праектаў. Аднак, калі кіраўнікі лічбавых праектаў атрымалі большы досвед і праваліліся амаль у палове праектаў, яны зразумелі, што патрэбныя змены. Яны пачалі ствараць уласныя інструменты і прыдумалі свае унікальныя нетрадыцыйныя працэсы. Прыблізна ў 2001 годзе ўсё больш і больш каманд пачалі выкарыстоўваць Scrum і Kanban, і з'явіўся спрытны маніфест. Git быў створаны Лінусам Торвальдсам у 2005 годзе, які заклаў аснову праектаў з адкрытым зыходным кодам. Магчыма, для лічбавых прадуктаў дасканаласць не так важная, як спрыт. Сёння, праз 25 гадоў, працэсы распрацоўкі, інструменты і культуры абедзвюх каманд прадуктаў вельмі далёкія адзін ад аднаго.

За апошнія пяць гадоў убудаваць электроніку ў фізічную прадукцыю і падключыць іх да Інтэрнэту ў нейкае прыкладанне стала надзвычай проста і нядорага - гэта тэндэнцыя, якая называецца IOT (Інтэрнэт рэчаў). Кошт гэтага прадукту складае каля 2 долараў за адзін прадукт, які тлумачыць, чаму мы з'яўляемся, што ў апошні час з'явілася так шмат новых прадуктаў IOT, некаторыя з іх вельмі пацешныя ... На ўзроўні каманды прадуктаў гэтая тэндэнцыя аб'ядноўвае два тыпы культур, два тыпы працэсаў і два віды інструментаў. Кожны раз, калі сутыкнуліся дзве культуры, пачынаюць адбывацца цікавыя рэчы. Зараз абсталяванне з адкрытым зыходным кодам ёсць вакол нас, і некаторыя людзі пачалі называць сябе вытворцамі. У чым розніца паміж вытворцам і вытворцам? Ці будзем мы ўбачыць збліжэнне гэтых працэсаў? ці мы асуджаныя, як тэхнічныя дырэктары і менеджэры IOT, каб назаўжды пераадолець гэтыя культуры?

Спадзяюся, вы знойдзеце гэты блог і цікавым, і карысным, і ён дапаможа распрацоўнікам з усяго стэка разабрацца ў праблемах адзін аднаго.

Ролі і навыкі

Існуе нядаўняя тэндэнцыя для распрацоўшчыкаў праграмнага забеспячэння па распрацоўцы поўнага пакета праграмнага забеспячэння. Гэта азначае, што яны распрацоўваюць як бэкэнд-код: код, які працуе на серверы / воблаку, так і код франтальнага доступу: код, які працуе на прыладзе. Яны могуць нават узяць на сябе ролю DevOps: інжынеры, якія адказваюць за наладу сістэмы, яе настройку, яе бяспеку і аўтаматызацыю. Зрабіць і запусціць простае лічбавае прыкладанне ці гульню нельга немагчыма. Аднак пры праглядзе прадуктаў IOT, якія звычайна ўключаюць як электронныя прылады, так і нейкае прыкладанне, тэхнічная каманда патрабуе дадатковых навыкаў і роляў.

Убудаваныя распрацоўшчыкі нясуць адказнасць за код, які працуе на прыладзе, а распрацоўшчыкі платы адказваюць за распрацоўку электроннай платы.

Хоць сёння, з дапамогай Espruino, распрацоўшчыкі Javascript змогуць тэарэтычна распрацаваць усе тры ўзроўня кода: код франтальнага зваротнага, запаснога і ўбудаванага кода, яны, верагодна, будуць змагацца з прамысловым і дошкавым дызайнам, які патрабуе зусім розных тыпаў навыкаў. Я бачыў таленавітых распрацоўшчыкаў, якія працуюць з усімі здзелкамі і могуць хутка пераходзіць ад змены класаў CSS да напісання сцэнарыяў міграцыі для сваіх баз дадзеных. Асабіста я лічу, што прафесійныя распрацоўшчыкі павінны асвоіць у любы момант часу толькі адзін пласт. Гаворка ідзе не толькі пра тое, каб валодаць лепшымі навыкамі і прыёмамі ці рэалізаваць неабходную функцыянальнасць, але і пра тое, што вам важна і з якім душэўным настроем вы займаецеся сваёй працай.

Я паспрабаваў апісаць абавязкі кожнай ролі ў камандзе. Я разумею, што я трапляю на небяспечную тэрыторыю, бо ролі могуць злёгку мяняцца ў розных камандах, таму, калі ласка, паспрабуйце ўбачыць лес, а не дрэвы.

Чаму адзін чалавек не можа пра ўсё гэта клапаціцца? Таму што ў працэсе распрацоўкі прадукту ўзнікаюць кампрамісы і канфлікты, і вы хочаце прадставіць кожную патрэбу збалансавана і сіметрычна.

На працягу многіх гадоў я бачыў павагу паміж рознымі распрацоўшчыкамі, але і недахоп ведаў. Я бачыў распрацоўшчыкаў франтавых дзвярэй, якія лічаць, што бэкэнд просты, і бэкэндаў, якія лічаць, што фронтэнд сумны. Я таксама бачыў убудаваных распрацоўшчыкаў, якія не ведаюць, што такое REST. Я ўжо згадваў, што не веру, што прафесійныя распрацоўшчыкі і інжынеры павінны асвойваць больш, чым адзін пласт. Аднак я цвёрда перакананы, што яны павінны ведаць, што значыць быць адным, і, магчыма, нават зрабіць крок наперад і працаваць над простым праектам, які падвяргае іх розным праблемам і працэсам. Шырокія веды могуць дапамагчы ў паляпшэнні зносін, павагі і празрыстасці сярод членаў каманды, а таксама павысяць творчы патэнцыял і прадукцыйнасць каманды ў цэлым.

Кіраваньне праектам

У чым розніца паміж праектам і прадуктам? Праект - гэта план дасягнення пэўнай мэты або маштабу за пэўны час і абмежаванне рэсурсаў. Праект мае пачатак і канец. Калі ў вас няма тэрміну, вы, верагодна, не кіруеце праектам. Калі праект заканчваецца, прадукт працягвае жыць.

Аналіз рызык: Давайце абмяркуем адрозненні і падабенства паміж кіраваннем праектам фізічнага прадукту і лічбавым. Асабіста мне падабаецца разглядаць кіраванне праектамі як працэс, кіраваны рызыкай, дзе я ўвесь час вызначаю асноўныя рызыкі і імкнуся прыдумаць план па мінімізацыі іх. Рызыкі праекта - гэта ўсё, што ўплывае на поспех праекта, гэта значыць невыкананне мэты, тэрміну, маштабу, кошту або канчатковай якасці прадукцыі. Для лічбавых прадуктаў адзін з самых вялікіх рызык - стварыць прадукт, які карыстальнікам не трэба і не падабаецца. Кіраўнікі лічбавых прадуктаў уяўляюць, вераць, разважаюць і распавядаюць добрую гісторыю, але пакуль карыстальнікі не пачнуць узаемадзейнічаць з прадуктам, гэта толькі здагадкі. Каб праверыць здагадку, кіраўнікі прадуктаў павінны хутка адпраўляць, выпрабаваць сваю гіпотэзу і быць спрытнымі. Для фізічных прадуктаў вялікая рызыка - знайсці непапраўную праблему на вельмі познім этапе, пасля таго як сотні і тысячы прадуктаў былі ўжо выраблены. Вытворчасць патрабуе дасканаласці, і без гэтага праект будзе правалены. Каб знізіць гэты рызыка, кіраўнікі фізічных праектаў будуюць працэс агляду і выхаду паміж этапамі, які называецца Вадаспад.

Кожны метад быў распрацаваны для зніжэння розных рызык, і кожны кіраўнік праекта павінен вызначыцца з планам праекта на аснове аналізу рызык. Часам людзі і ўзаемадзеянне важней працэсаў і інструментаў, а часам працэсы важней. Часам рабочае праграмнае забеспячэнне важней дакументацыі, а часам дакументацыя важней. Часам супрацоўніцтва з кліентамі важней, чым пісьмовая дамова. І часам пісьмовы кантракт можа выратаваць вашу кампанію. Часам рэагаванне на змены вельмі важна, але часам важна выконваць план. Вы разумееце, што я маю на ўвазе.

Інструменты і абрады каманд: Кіраўнікі праектаў павінны выкарыстоўваць інструменты, якія рэалізуюць працэс, якім яны хочуць кіраваць праектамі. Праект Microsoft - выдатны інструмент для праектаў вадаспадаў. JIRA і Trello - выдатны інструмент для спрытных праектаў і працэсаў падтрымкі, такіх як Kanban і Scrum. Якімі б інструментамі не было, памятайце, што гэта толькі інструмент, а не сутнасць. Каманды таксама праводзяць розныя цырымоніі. У Вадаспадзе каманды збіраюцца перад кожным падзеннем і разглядаюць дакументы, атрыманыя вынікі CAD або тэставыя характарыстыкі. Спрытная каманда можа сустракацца кожны дзень для штодзённага становішча і раз у два тыдні для планавання спрынту. Гэтыя абрады выраўноўваюць членаў каманды па плане і паляпшаюць зносіны паміж членамі каманды.

Дызайн і прататыпаванне

Дызайн: ці ёсць сёння прадукт, у якім дызайн не гуляе галоўнай ролі ў яго поспеху? Што такое тавар, калі не тое, што мы хочам прадаць? Тое, што павінна быць прывабным і эстэтычным, чым мы можам ганарыцца. Прайшлі дні, калі правільная функцыянальнасць і працаздольнасць былі дастаткова добрымі. У электронных прадуктах прамысловы дызайн павінен улічваць не толькі ўзаемадзеянне чалавека, зручнасць выкарыстання і вопыт кліентаў, але і экалагічныя ўмовы, у якіх гэты прадукт выкарыстоўваецца, і вытворчы працэс (DFM: распрацоўка для вытворчасці). Для лічбавых прадуктаў дызайн павінен таксама тычыцца розных прылад, на якіх можа працаваць праграмнае забеспячэнне (мабільныя, настольныя, вялікія экраны), а таксама ўсіх тыпаў роляў і карыстальнікаў, якія ўзаемадзейнічаюць з ім.

Розныя тыпы метадалогіі дызайну прымяняюцца да розных тыпаў прадуктаў: ​​дызайн вопыту разглядае прадукт як частку прыемнага вопыту, які мы хочам стварыць, то ёсць "мы не прадаем гульню, мы прадаем адначасовы сямейны досвед". Дызайн сэрвісу будзе разглядаць прадукт як частка канчатковага абслугоўвання паміж пастаўшчыком паслуг і карыстальнікам. "З таго моманту, як вы вырашылі падарожнічаць да прыезду ў пункт прызначэння", "Мы не прадаем камеры бяспекі, мы прадаем вам абарону 24/7".

Складанне прататыпаў: З дапамогай 3D-прынтэраў і тэхналогіі VR / AR вельмі складана прыдумаць механічны прататып вашага фізічнага прадукту. Вы можаце паказаць гэта сваім кліентам, пакласці на яго налепкі, падключыць некалькі правадоў і святлодыёдаў, яны адразу зразумеюць яго прызначэнне і вы зможаце пераканаць іх у тым, што ваш прадукт гатовы і камерцыйны. Вы можаце змясціць яго ў рэальную абстаноўку і паглядзець, ці падыходзіць ён механічна і ці лёгка яго трымаць. Вы можаце зрабіць дзесяць версій і параўнаць паміж імі і вызначыцца з канчатковай канфігурацыяй. Няма нічога больш магутнага, чым даць кліентам і інвестарам што-небудзь трымаць у руках. Людзям падабаюцца цацкі і матэрыяльныя рэчы, і хоць механічны дызайн часам складае толькі 1% ​​канчатковага прадукту з пункту гледжання часу распрацоўкі, людзі павераць, што вы ўжо завяршылі 80%. З дапамогай прататыпавання праграмнага забеспячэння дабрацца да гэтага ўзроўню не так проста. Эскіз і InVision - выдатны інструмент, але карыстальнікі адразу разумеюць, што гэта не сапраўдны прадукт. Дадзеныя статычныя і іх узаемадзеянне не ўплывае на іх. Гэта частка прычыны, па якой кіраўнікі лічбавых прадуктаў узялі на сябе гнуткі падыход і канцэпцыю MVP. Вельмі цяжка ўявіць, як карыстальнікі будуць узаемадзейнічаць і любіць ваш прадукт, перш чым ён будзе гатовы і мае рэальныя дадзеныя, таму вы хочаце адправіць яго, як толькі зможаце, і пачаць збіраць рэальную зваротную сувязь.

Фізічная і лічбавая прататыпізацыя

Развіццё

Раннія рашэнні аказваюць найбольшы ўплыў: кожны раз, калі я пачынаю новы праект, я ўсхваляваны. Якая была б правільная архітэктура? якая тэхналогія будзе лепш за ўсё падыходзіць для яе? Ці варта выбраць 8-бітны MCU ці 32-бітны працэсар? Гэта добры праект па ўкараненні GraphQL, альбо мы зноў будзем прытрымлівацца REST? Якая бесправадная тэхналогія лепш за ўсё падыходзіць для выкарыстання: Bluetooth 5 або Narrowband IOT? Якую правільную базу дадзеных выкарыстоўваць? PostgreSQL ці, магчыма, база дадзеных графікаў на гэты раз? Гэтыя рашэнні настолькі важныя для поспеху праекта. Часам мы прымаем тэхнічныя рашэнні занадта хутка без належнага аналізу, а потым праз тры месяцы мы шкадуем пра іх, становіцца занадта цяжка і балюча змяніць іх, і прасцей успрымаць інвестыцыі ў тэхналогіі як актыў, а не як перашкоду. Гэта датычыцца як электронных, так і лічбавых прадуктаў, хаця змяненне тыпу працэсара пасля дастаўкі прадукцыі кліентам - практычна немагчымая задача, калі не непрыемная.

Раннія рашэнні аказваюць найбольшы ўплыў

Распрацоўка: паміж працэсам распрацоўкі электронных прадуктаў і лічбавых прадуктаў існуе мноства адрозненняў. Большая частка часу на распрацоўку платы друкаванай платы ідзе на выбар патрэбных кампанентаў і распрацоўку кампаноўкі. Некаторыя работы носяць выключна тэхнічны характар, злучаючы правады ад кампанента U1 штыфта 120 да кампанента U17 кантакту 12. А некаторыя задачы патрабуюць поўнага прататыпавання вакол трох тыпаў датчыкаў толькі для вымярэння шуму і энергаспажывання кожнага з іх. Убудаваную распрацоўку складана адладзіць і аптымізаваць; даволі часта можна ўбачыць убудаваныя распрацоўшчыкі, якія выкарыстоўваюць штыфты GPIO, каб даведацца, ці была выклікана функцыя, і вымераць, колькі часу спатрэбіцца для запуску. Выкарыстанне FPGA ў сваім электронным прадукце - смелае рашэнне, але часам гэта адзінае рашэнне для дасягнення пастаўленых мэтаў. Распрацоўка FPGA - гэта зусім іншая тэрыторыя і знаходзіцца дзесьці паміж распрацоўкай ASIC, распрацоўкай платы і ўбудаванай платай. Для распрацоўшчыкаў праграмнага забеспячэння большую частку часу ўкладваюць у ... напісанне кода. У поглядзе на вашу паўсядзённую працу ёсць нешта вельмі задавальняе, усе гэтыя радкі кода, код здзяйсняюць і цягнуць запыты. Гэта гучыць досыць проста, але колькасць змяненняў і кодаў велізарная, таму правільнае кіраванне канфігурацыяй і праверка важна для падтрымання арганізаванасці базавых кодаў, зніжэння тэхнічнай запазычанасці і павелічэння ведаў у камандзе.

Алгарытмы, фізіка і навука дадзеных: звычайна гэта прадукт, дзе кампаніі, як правіла, сцвярджаюць, што іх IP з'яўляецца. Дызайнеры саветаў працуюць з фізікамі, каб выбраць датчыкі, распрацаваць вакол іх AFE (аналаг пярэдняга канца) альбо распрацаваць праект спецыяльная антэна. Убудаваныя распрацоўшчыкі працуюць з інжынерамі DSP і матэматыкамі, каб убудаваць алгарытмы DSP у рэжыме рэальнага часу ў сваё праграмнае забеспячэнне для фільтрацыі сігналаў, выяўлення шаблонаў альбо для рэалізацыі нейкай аптымізаванай матэматычнай формулы для апрацоўкі / кадавання дадзеных. У рэжыме рэальнага часу азначае, што вы павінны завяршыць апрацоўку на працягу пэўнай колькасці цыклаў працэсара, інакш вы не будзеце гатовыя апрацаваць наступны сігнал і прапусціце яго альбо не зможаце выводзіць падзеі ў межах патрабаванага затрымкі. Распрацоўшчыкі Backkend працуюць з даследчыкамі дадзеных, каб рэалізаваць пакетныя працэсы, каб рэкамендаваць новыя прадукты, знайсці анамаліі, прапанаваць сяброў, навучыць глыбокай мадэлі навучання, выкарыстоўваць NLP для аналізу тэксту, ацэнкі вэб-старонак і г.д. Распрацоўшчыкі Frontend маюць усё задавальненне. Яны робяць візуалізацыю дадзеных. З такой бібліятэкай, як D3JS, яны ствараюць дзівосную візуальную інфармацыю і прадстаўляюць карыстачам дадзеныя ў карысным і абагульненым выглядзе.

На працягу ўсяго стэка гэтыя людзі будуць клапаціцца аб зніжэнні шуму, паляпшэнні сігналаў і пошуку правільнага балансу паміж выяўленнем прапушчаных (ілжывы адмоўны) і ілжывым сігналам трывогі (ілжывы станоўчы), яны будуць плакаць, што ім трэба больш дадзеных, або рабіць больш эксперыментаў, і яны будуць скакаць шчасліва, калі ім удасца павысіць прадукцыйнасць на 5%. Цікавым рашэннем прадукту з'яўляецца прыняцце рашэння, як падзяліць задачы па навуцы дадзеных на стэк. У якасці прыкладу Alexa ўключае масіў мікрафонаў на ўзроўні платы, нейкі DSP-код на ўзроўні прашыўкі і складаную навуку дадзеных на ўзроўні рэзервовых сістэм, каб распазнаць нашу гаворку.

Інструменты: Уявіце распрацоўшчык франтальнай і ўбудаванай праграмы, параўноўваючы інструменты распрацоўкі адзін з адным. Убудаваны распрацоўшчык пройдзе распрацоўшчык франтальнага стала да свайго стала і пазначыць адрозненні паміж блокам харчавання, асцылографам і лагічным аналізатарам. Затым распрацоўшчык інтэрфейсу адправіць убудаваны распрацоўшчык да бліжэйшага кававага месца. Яны замовяць каву і знойдуць ціхае месца, дзе могуць правесці некалькі гадзін разам. Затым ён пераключыць аглядальнік Chrome у рэжым распрацоўкі і пакажа ўбудаванаму распрацоўніку, як выглядаць сеткавы трафік і як бачыць стыль CSS пэўнага элемента HTML.

Які сэнс дэвтолаў ...

Інструменты для адладкі вар'іруюцца ад распрацоўніка да распрацоўшчыка і эфектыўна выкарыстоўваць іх менавіта там, дзе ляжыць рэальны досвед. Інстыктыўна ведаць, у чым праблема, і выкарыстоўваць вашыя інструменты для ўваходу ў яе - гэта найважнейшае майстэрства распрацоўшчыкаў. Я бачыў, як распрацоўшчыкі праводзяць гадзіну і дні, адладжваючы праблему, а потым звяртаюцца па дапамогу ў дасведчанага распрацоўшчыка, які выяўляе праблему за лічаныя секунды. Я не магу гэта падкрэсліць дастаткова, а прафесійныя сродкі - правільныя інструменты для кожнай задачы. І гэта дакладна для кожнай прафесіі.

Які сэнс адладкі і інструментаў для тэсціравання ...Распрацоўшчыкі праграмнага забеспячэння лічаць гэта страшным

Якасць і тэсціраванне

Экалагічныя выпрабаванні: калі мы тэсціруем наш прадукт, мы хочам пераканацца, што ён функцыянуе правільна ва ўсіх розных канфігурацыях і асяроддзях, якія карыстальнікі разлічваюць выкарыстаць. Для фізічных прадуктаў навакольнае асяроддзе звычайна азначае тэмпературу (моцны мароз, вельмі гарачае), вібрацыю (уявіце сабе аўтамабільны прадукт), шок (падае з вашых рук на бетонную падлогу), вільготнасць, ультрафіялетавае і сонечнае выпраменьванне, СОЭ (гэтыя невялікія асвятлення, якія прыходзяць ад электрастатычнага разраду), EMI / RFI і інш. Для асяроддзя лічбавых прадуктаў звычайна азначаюць тып браўзэра (Chrome, Internet Explorer, Firefox ..), АС (Android, IOS, OSX, Windows), прылады (мабільны, працоўны стол, канферэнцыя Экран) і ўзровень падключэння да сеткі (4G, Wifi, аўтаномна). Звычайна мы не праводзім тэсты на любой магчымай камбінацыі, бо зрабіць гэта немагчыма, таму мы прыдумалі набор канфігурацый, якія, спадзяюся, ахопліваюць дастаткова сцэнарыяў для выяўлення праблем у спецыфікацыі прадукту.

Які сэнс знешняга асяроддзя для ...

Надзейнасць / даўгавечнасць (выпрабаванне жыццёвага цыкла): Гэта выпрабаванні, якія спрабуюць мадэляваць тое, што адбываецца з прадуктам на працягу ўсяго яго жыцця. Гэта больш актуальна для фізічных вырабаў, дзе матэрыялы дасягаюць сваіх няўдалых кропак. Ёсць пэўныя правілы, якія гэтая індустрыя прыдумала, каб дапамагчы нам паскорыць узрост прадукту, падвяргаючы яго экстрэмальным умовам навакольнага асяроддзя. У асноўным, каб праверыць, ці правільна працуе прадукт пасля пяці гадоў пры пакаёвай тэмпературы, мы можам праверыць яго на 70 градусаў і 10 г вібрацыі на працягу аднаго дня (толькі прыклад !!!). Яны называюцца выпрабаваннямі HALT (з высокай хуткасцю жыцця)

Тэсты на экстрэмальныя ўмовы (Load, Edge): Гэта выпрабаванні, якія правяраюць паводзіны прадукту ў экстрэмальных умовах і на ўскраінах. Напрыклад, калі электронны прадукт працуе на 5 В, мы паспрабуем яго на 4,5 У і 5,5 У, мы можам нават уводзіць скокі напружання да 25В ці -5В, каб даведацца, ці прадукт устойлівы да памылак карыстальнікаў і электрычных перанапружанняў. Для лічбавых прадуктаў мы можам аспрэчваць палі ўводу з неабгрунтаванымі значэннямі. Напрыклад, мы можам уводзіць імёны, якія маюць 1000 знакаў, альбо якія маюць бессэнсоўныя сімвалы. калі мы распрацавалі прадукт для пэўнай нагрузкі (50 адначасовых карыстальнікаў), мы будзем правяраць яго паводзіны ў межах 100 адначасовых карыстальнікаў. Ідэя гэтых тэстаў у асноўным заключаецца ў раскрыцці новых рэжымаў адмовы. Мы не чакаем, што прадукт будзе працаваць выдатна, але мы можам выявіць важныя праблемы, нечаканае паводзіны альбо вузкія месцы, якія адносяцца таксама да звычайных умоў.

Тэсты на адпаведнасць / бяспека: Часам абодва прадукту патрабуюцца, каб адпавядаць стандартам і быць ім адпаведнымі. Электронныя прадукты павінны быць бяспечнымі, надзейнымі і надзейнымі і абараняць карыстальніка ад паразы электрычным токам ці перагрэвам (UL, CE, FCC ..), яны таксама павінны адпавядаць пэўным стандартам бесправадной сувязі, напрыклад, Wifi або Bluetooth. Лічбавыя прадукты, якія атрымліваюць асабістую інфармацыю (PII), напрыклад, нумары крэдытных карт (PCI, ISO / IEC 27001, NIST) або нумары сацыяльнага страхавання (GDPR), павінны абараняць дадзеныя ад усялякіх нападаў і нядбайнасці супрацоўнікаў. Для абодвух прадуктаў працэс захавання патрабаванняў дарагі і доўгі, але ёсць спосабы скараціць выдаткі і выкарыстоўваць папярэдне зацверджаныя модулі і паслугі.

Які сэнс захавання ...

Пакрыццё выпрабаванняў: Як дызайнер дошкі вы ніколі не можаце быць упэўнены, што вытворчы працэс прайшоў без дэфектаў. У некаторых выпадках ёсць мініяцюрныя шорты паміж суседнімі слядамі, якія можна ўбачыць толькі з дапамогай мікраскопа. У іншых выпадках электронныя кампаненты недастаткова надзейныя ці нават могуць быць падробленымі кампанентамі. У рамках працэсу якасці дызайнеры саветаў і ўбудаваныя распрацоўшчыкі павінны сумесна пісаць сродкі тэсціравання, якія правяраюць, што кожнае злучэнне і кожны кампанент працуюць, як чакалася, са 100% пакрыццём. Я працаваў над тэставаннем JIG, якія імітуюць кожны датчык і кожны ўваход на плату, каб дасягнуць 100% пакрыцця. Таксама добрая практыка праводзіць гэтыя тэсты паралельна з вельмі паскоранымі тэстамі скрынінга (HASS), калі плата падвяргаецца вібрацыі і цеплавым цыклам.

Падобным чынам, з праграмным забеспячэннем добрай практыкай з'яўляецца напісанне тэставага кода, які ахоплівае па меншай меры 99% вашага кода. Перад разгортваннем новага кода ў вытворчым асяроддзі інструмент аўтаматызацыі запускае набор тэставых кодаў і правярае, што тое, што раней працавала, усё яшчэ працуе. У абодвух выпадках праца над гэтымі інструментамі тэсціравання павінна пачынацца разам з распрацоўкай прадукту (часам нават раней: TDD) і павінна атрымліваць адпаведныя рэсурсы.

Дызайн / агляд кода: людзі робяць памылкі. Той, хто думае, што гэтага не робіць, альбо недастаткова перажыты, альбо мае кароткую памяць. У прыватнасці, пры распрацоўцы планіроўкі платы друкаванай платы і размяшчэнні новых кампанентаў вельмі лёгка памыляцца ў наладах канфігурацыі і фізічных памерах новых кампанентаў. памылкі вы знойдзеце толькі праз некалькі тыдняў ці месяцаў. Вы можаце паглядзець на дызайн і праверыць яго на ліст дадзеных, паглядзець яшчэ раз і зноў праверыць, і ў абодвух выпадках вы прапусціце яго. З гэтай прычыны незалежная рэцэнзія і выходны працэс - гэта звычайная практыка распрацоўкі электронных прадуктаў. Распрацоўшчыкі праграмнага забеспячэння часта робяць памылкі ў дачыненні да бяспекі. Напрыклад, яны часта кладуць адчувальныя ключы ў адкрытыя сховішчы кода альбо падвяргаюцца кліенту. Запыт на выезд - гэта спосаб паведаміць іншым членам каманды пра змены, перш чым здзейсніць іх. Яны служаць некалькім мэтам: выявіць дэфекты і праблемы, палепшыць чытанне і дакументацыю кода і абмен ведамі ў камандзе. Парнае праграмаванне - гэта яшчэ адзін метад, які распрацоўнікі праграмнага забеспячэння выкарыстоўваюць для абмену ведамі і прагляду кода адзін аднаго.

Кіраванне канфігурацыямі: CM - гэта практыка сістэматычнай апрацоўкі змяненняў. Ён выкарыстоўваецца для дакументавання версій прадукту і адсочвання змяненняў, якія прымяняюцца да яго паміж версіямі. Добрая сістэма кіравання канфігурацыяй дазволіць вам стварыць і пратэставаць любую версію прадукту, выкарыстоўваючы толькі прадметы, якія ёсць у ім, без якіх-небудзь іншых знешніх ведаў. Інжынеры DevOps выкарыстоўваюць інструменты SCM (кіраванне канфігурацыяй праграмнага забеспячэння), такія як GIT, Ansible, Terraform, Chef для запісу кода, канфігурацыі і інфраструктуры прадукту. Яны могуць таксама звязаць гэтыя змены з праблемамі JIRA, каб зафіксаваць сувязь паміж запытам пра памылку / дэфект / функцыю і фактычнымі зменамі, якія ўзніклі ў выніку. Інжынеры-электронікі выкарыстоўваюць інструменты, якія часам называюць PLM (кіраванне жыццёвым цыклам прадукту), а часам HCM (кіраванне канфігурацыяй абсталявання). Па сутнасці яны служаць адной і той жа мэты, але ўключаюць розныя інтэграцыі і працэсы. Напрыклад, сістэма PLM можа таксама інтэгравацца ў вашу ERP-сістэму, каб паказаць, якія часткі BOM прадукту прысутнічаюць у вашым інвентарызацыі.

Вытворчасць і вытворчасць

Вы павінны глядзець на свайго вытворцу як на партнёра, а не як на пастаўшчыка. У рэшце рэшт, вы дасце свайму вытворцу самыя адчувальныя актывы: усё, што трэба для стварэння вашага прадукту! Ваш вытворца дапаможа вам укараніць новыя спосабы вырабу, паменшыць дэфекты, павысіць эфектыўнасць працэсу і нейкім чынам падзяліцца некаторымі рызыкамі і выгадамі прадукту.

Lean Lean - усё, што тычыцца эканоміі сродкаў. Для фізічных прадуктаў хударлявыя сродкі:

  • Нулявая затрымка на ўсіх этапах вытворчай лініі
  • Аплата дэфектаў, самая высокая якасць для кожнага канчатковага прадукту
  • Машыны / Людзі на 100% выкарыстоўваюцца
  • Водгукі ведаў: Кожны ўрок і разуменне паляпшаюць працэс
  • Толькі своечасова выраб: Кожны прадукт прадаецца, без адходаў

Для лічбавых прадуктаў нішчымнае азначае:

  • Аўтамаштаб: маштабы вылічальных рэсурсаў у залежнасці ад нагрузкі
  • Плаціць за гадзіну

Вытворчасць трубаправодаў: Наладка зборачнай лініі не надта адрозніваецца ад налады праграмнага трубаправода CI / CD (бесперапынная інтэграцыя / бесперапынная пастаўка). Калі вы прачыталі кнігу праектаў Phoenix, вы, верагодна, памятаеце, як некаторыя з паняццяў хударлявых і DevOps былі атрыманы ў гэтай кнізе па лініі вытворчасці. Абодва трубаправода атрымліваюць усё, што неабходна для стварэння, праверкі і дастаўкі вашага прадукту. Калі вы дадасце дадатковую аўтаматызацыю, вы можаце даставіць хутчэй. Для электронных прадуктаў гэта азначае зніжэнне выдаткаў і дэфектаў і павышэнне магутнасці, для лічбавых прадуктаў гэта азначае больш хуткае тэставанне карыстальнікаў і адаптыўны дызайн.

Дастаўка ва ўсім свеце: Існуе цікавае падабенства паміж сеткамі дастаўкі змесціва (CDN), якія выкарыстоўваюцца для дастаўкі вэб-актываў карыстальнікам у залежнасці ад іх геаграфічнага месцазнаходжання, і тым, як выраб распаўсюджваецца па ўсім свеце, каб скараціць выдаткі на дастаўку і лакалізаваць прадукцыю. Кэшаванне змесціва можа разглядацца як мясцовыя склады альбо паслугі выканання, такія як Amazon. Для абодвух тыпаў прадуктаў мясцовая прысутнасць паляпшае агульны досвед пакупнікоў ва ўсім свеце

Можа здацца, што ў фізічных прадуктах прысутнасць ва ўсім свеце цяжэй, аднак рэгуляванне абароны дадзеных і лакалізацыя мовы таксама патрабуюць значных намаганняў

Воблачныя паслугі: Воблачныя паслугі з'яўляюцца дзіўнымі, вы можаце стварыць свой лічбавы прадукт за лічаныя секунды, выбраўшы адзін з сотняў вэб-сэрвісаў. Некалькі клікаў, і ён запускаецца аўтаматычна ў больш чым 20 цэнтрах апрацоўкі дадзеных па ўсім свеце і маштабуецца ў залежнасці ад попыту. У вытворчасці няма нічога падобнага, але гэта можа быць наступная прамысловая рэвалюцыя. Уявіце сабе лічбавы прадукт, у якім вы можаце наладзіць канвеер з выкарыстаннем папярэдне наладжаных модуляў, такіх як 3D-друк, выраб друкаванай платы, зборка кампанентаў, зборка платы і кабеля, запушчаныя тэсты і дастаўка непасрэдна кліентам з мясцовага аўтаматызаванага вытворчага паверха. Акрамя таго, паслуга дазволіць канчатковаму карыстачу наладзіць колер прадукту, форму і іншыя функцыі персаналізацыі. Гэта здаецца марай, але я ўпэўнены, што дзесьці ва ўсім свеце Amazon працуе над такой паслугай (прынамсі, я спадзяюся, што яны ёсць).

Выснова

Існуе мноства адрозненняў паміж працэсам распрацоўкі электронных прадуктаў і лічбавымі, але, гледзячы на ​​іх з пункту гледжання 20 гадоў, дзіўна бачыць, колькі прынцыпаў распрацоўкі і працэсаў лічбавай прадукцыі зараз выкарыстоўваюць фізічныя кіраўнікі прадуктаў. Нядаўна AWS абвясціла пра FreeRTOS для ўбудаваных сістэм. Я прагназую, што праз 10–20 гадоў не будзе істотнай розніцы паміж працэсам распрацоўкі лічбавага прадукту і фізічным.

Калі вы хочаце даведацца больш пра маё падарожжа і як кіраваць камандай, якая жыве ў абодвух свеце, не саромейцеся звяртацца да мяне непасрэдна.