Дизайн и разработка на електронни продукти срещу цифрови продукти

Имах щастието да разработя и управлявам развитието както на физически продукти, така и на дигитални продукти. Докато споделям любовта и страстта и към двамата, реших да представя моите възгледи и някои наблюдения върху разликите и приликите между техните процеси на развитие.

Какво е значението на продукт за ...

Какво е продукт? Нещо, което се произвежда и продава, или нещо, което създава стойност за потребителите? Първото определение се отнася само за физическите продукти и отразява какво правим с продуктите и как ги изграждаме. Второто определение е по-открито и модерно и отразява защо имаме нужда от продукти. Физическите продукти са осезаеми; потребителите могат да ги докоснат, да ги видят, да миришат и да ги усетят. Всички сме гледали видеоклипове на огромни фабрики и можем да разберем колко скъпо и сложно е да ги произвеждаме. Дигиталните продукти живеят в облака или в отдалечени центрове за данни. За нас е по-трудно да разберем техния размер, сложност и какво означава да изградим такъв. Например, ако погледнем предната част на Google Търсене, можем да видим само една линия за търсене, но зад сцената, в задния край, има стотици хиляди сървъри, работещи и милиарди редове кодове.

Когато разработчиците на софтуер започнаха да създават цифрови продукти, преди около 25 години, те използваха подобни процеси и инструменти, които се използват за изграждане на физически продукти. Най-доказаният процес за управление на проекти по това време беше водопадът, тъй като гарантираше съвършенство през целия цикъл на проекта. Въпреки това, тъй като ръководителите на дигитални проекти натрупаха повече опит и се провалиха в почти половината от проектите, те разбраха, че се нуждаят от промяна. Те започнаха да изграждат свои собствени инструменти и излязоха със своите уникални нетрадиционни процеси. Около 2001 г. все повече и повече екипи започват да използват Scrum и Kanban и се появява пъргавия манифест. Git е създаден от Линус Торвалдс през 2005 г., който поставя основите на проекти с отворен код. Може би за цифровите продукти съвършенството не е толкова важно, колкото пъргавината. Днес, 25 години по-късно, процесите на развитие, инструментите и културите на двата продуктови екипа са много далеч един от друг.

През последните пет години беше изключително лесно и евтино да вграждате електроника във физически продукти и да ги свързвате с интернет към някакво приложение - тенденция, която се нарича IOT (Интернет на нещата). Това струва около 2 $ на продукт, което обяснява защо виждаме толкова много нови IOT продукти наскоро, някои от тях са доста забавни ... На ниво продуктов екип тази тенденция обединява два типа култури, два типа процеси и два вида инструменти. Всеки път, когато две култури се сблъскат, започват да се случват интересни неща. Сега хардуерът с отворен код е навсякъде и някои хора започнаха да се наричат ​​производители. Каква е разликата между производител и производител? Ще видим ли конвергенция между тези процеси? или сме обречени, като технически директори и ръководители на продукти на IOT да преодоляват завинаги между тези култури?

Надявам се, че ще намерите този блог за интересен и полезен и че ще помогне на разработчици от целия стек да разберат предизвикателствата един на друг.

Роли и умения

Съществува неотдавнашна тенденция разработчиците на софтуер да разработят пълния пакет от софтуер. Това означава, че те разработват както резервен код: кодът, който работи на сървъра / облака, и код на frontend: кодът, който работи на устройството. Те дори могат да поемат ролята на DevOps: инженери, които са отговорни за настройката на системата, конфигурирането й, осигуряването й и автоматизирането на процеса на промяна. Не е невъзможно един човек да изгради и пусне просто цифрово приложение или игра. Въпреки това, когато разглеждате IOT продукти, които обикновено включват както електронно устройство, така и някакво приложение, технологичният екип изисква повече умения и роли.

Вградените разработчици са отговорни за кода, който работи на устройството, а дизайнерите на платки са отговорни за разработването на електронната платка.

Въпреки че днес, с помощта на Espruino, разработчиците на Javascript могат теоретично да разработят и трите нива на кода: код на фронта, бекенд код и вграден код, те вероятно ще се борят с индустриален и бордов дизайн, който изисква напълно различни видове умения. Видях талантливи разработчици, които са джак на всички сделки и могат да преминат бързо от промяна на CSS класовете до писане на миграционни скриптове за техните бази данни. Лично аз смятам, че професионалните разработчици трябва да овладеят по всяко време само на един слой. Не става въпрос само за това да имате най-добрите умения и техники или да внедрите необходимата функционалност, но и за това, което ви интересува и с какво състояние на ума вършите работата си.

Направих опит да опиша отговорностите на всяка роля в екипа. Оценявам, че влизам в опасна територия, тъй като ролите може леко да се променят в различните екипи, така че, моля, опитайте се да видите гората, а не дърветата.

Защо не може един човек да се грижи за всичко това? Защото има компромиси и конфликти при разработването на продукти и искате да представите всяка нужда балансирано и симетрично.

През годините наблюдавах уважение между различни видове разработчици, но и липса на познания. Виждах разработчици на frontend, които смятат, че бекендът е лесен, и разработчици, които смятат, че фронтендът е скучен. Виждал съм и вградени програмисти, които не знаят какво е REST. Споменах преди това, не вярвам, че професионалните разработчици и инженери трябва да овладеят повече от един слой. Аз обаче силно вярвам, че те трябва да знаят какво означава да бъдеш такъв и може би дори да направят крачка напред и да работят върху един прост проект, който ще ги изложи на различните предизвикателства и процеси. Широките знания могат да помогнат за подобряване на комуникацията, уважението и прозрачността сред членовете на екипа, а също така ще повишат креативността и производителността на екипа като цяло.

Управление на проекти

Каква е разликата между проект и продукт? Проектът е план за постигане на определена цел или обхват в рамките на определено време и ограничения на ресурсите. Проектът има начало и край. Ако нямате срок за проект, вероятно не управлявате проект. Когато проектът приключи, продуктът продължава да живее.

Анализ на риска: Нека обсъдим разликите и приликите между управление на проекти на физически продукт и дигитален. Лично аз обичам да мисля, че управлението на проекти като ръководен от риска процес, при който постоянно идентифицирам основните рискове и се опитвам да измисля план за тяхното минимизиране. Проектните рискове са всичко, което влияе върху успеха на проекта, т.е. неспазването на целта, срока, обхвата, цената или крайното качество на продуктите. За дигиталните продукти един от най-големите рискове е създаването на продукт, който потребителите не се нуждаят или харесват. Дигиталните мениджъри на продукти си представят, вярват, спекулират и разказват добра история, но докато потребителите не започнат да взаимодействат с продукта, това са само предположения. За да проверят предположението, продуктовите мениджъри трябва да изпращат бързо, да тестват хипотезата си и да бъдат пъргави. За физическите продукти най-големият риск е да се намери непоправим проблем на много късен етап, след като вече са произведени стотици и хиляди продукти. Производството изисква съвършенство и без него проектът ще се провали. За да намалят този риск, ръководителите на физически проекти изграждат процес на преглед и отписване между етапите, който се нарича Водопад.

Всеки метод е създаден с цел намаляване на различни рискове и всеки ръководител на проекта трябва да вземе решение за плана на проекта въз основа на анализ на риска. Понякога индивидите и взаимодействията са по-важни от процесите и инструментите, а понякога процесите са по-важни. Понякога работещият софтуер е по-важен от документацията, а понякога документацията е по-важна. Понякога сътрудничеството с клиентите е по-важно от писмения договор. И понякога писмен договор може да спаси вашата компания. Понякога реагирането на промяна е важно, но понякога следването на план е по-важно. Разберете какво имам предвид.

Инструменти и церемонии в екип: Ръководителите на проекти трябва да използват инструменти, които прилагат процеса, чрез който искат да управляват проектите. Microsoft Project е чудесен инструмент за проекти за водопад. JIRA и Trello са чудесен инструмент за гъвкави проекти и поддръжка на процеси като Kanban и Scrum. Какъвто и инструмент да е, не забравяйте, че той е само инструмент, а не същността. Отборите също имат различни церемонии. Във водопад екипите се срещат преди всяко падане и преглеждат документи, CAD генерира резултати или тестови спецификации. Екипът на Agile може да се среща всеки ден за ежедневен резерв и на всеки две седмици за планиране на спринт. Тези церемонии изравняват членовете на екипа по плана и подобряват комуникацията между членовете на екипа.

Дизайн и прототипиране

Дизайн: Има ли продукт днес, в който дизайнът не играе важна роля за неговия успех? Какво е продукт, ако не нещо, което искаме да продадем? Нещо, което трябва да бъде привлекателно и естетично, с което можем да се гордеем. Отминаха дните, в които правилната функционалност и производителност беше достатъчно добра. При електронните продукти индустриалният дизайн трябва да взема предвид не само човешкото взаимодействие, използваемостта и опита на клиентите, но и условията на околната среда, в които се използва продуктът, и производствения процес (DFM: дизайн за производство). За дигиталните продукти дизайнът трябва да адресира и различните устройства, на които софтуерът може да работи (мобилни, настолни, големи екрани) и всички видове роли и потребители, които взаимодействат с него.

Различните видове методология за дизайн се прилагат за различни видове продукти: Опитният дизайн разглежда продукта като част от приятно изживяване, което искаме да създадем, т.е. „Ние не продаваме игра, ние продаваме едночасов семеен опит“. Дизайнът на услугата ще види продукта като част от крайната услуга между доставчик на услуги и потребител. „От момента, в който сте решили да пътувате, докато не пристигнете до вашата дестинация“, „Ние не продаваме охранителна камера, ние ви продаваме 24/7 защита“.

Прототипиране: С помощта на 3D принтери и VR / AR технология е изключително лесно да се създаде механичен прототип на вашия физически продукт. Можете да го покажете на вашите клиенти, да поставите няколко стикера върху него, да свържете някои проводници и светодиоди, те веднага ще разберат целта му и може би ще можете да ги убедите, че вашият продукт е готов и търговски. Можете да го поставите в реалната среда и да видите дали тя се побира механично и дали е лесно да се държи. Можете да направите десет версии и да сравните между тях и да вземете решение за окончателната конфигурация. Няма нищо по-мощно от това да дадете на своите клиенти и инвеститори нещо, което да държат в ръката им. Хората харесват играчки и материални неща и въпреки че понякога механичният дизайн е само 1% от крайния продукт по отношение на времето за разработка, хората ще повярват, че вече сте завършили 80% от него. Със софтуерното прототипиране не е толкова лесно да стигнете до това ниво. Sketch и InVision са чудесни инструменти, но потребителите веднага разбират, че това не е истински продукт. Данните са статични и взаимодействието им няма ефект върху него. Това е част от причината мениджърите на дигитални продукти да възприемат пъргавия подход и концепцията за MVP. Много е трудно да си представим как потребителите ще си взаимодействат и обичат продукта ви, преди той да е готов и да има реални данни, така че искате да го изпратите веднага, когато можете, и да започнете да събирате реална обратна връзка.

Физическо и цифрово прототипиране

развитие

Ранните решения оказват най-голямо въздействие: Всеки път, когато стартирам нов проект, се вълнувам. Каква би била правилната архитектура? коя технология ще бъде най-подходяща за нея? Трябва ли да изберем 8-битов MCU или 32-битов процесор? Това добър проект ли е за въвеждане на GraphQL или отново ще се придържаме към REST? Коя безжична технология отговаря най-добре на случая: Bluetooth 5 или Narrowband IOT? Каква е подходящата база данни за използване? PostgreSQL или може би графична база данни този път? Тези решения са толкова важни за успеха на проекта. Понякога вземаме технически решения твърде бързо без подходящ анализ и след три месеца ги съжаляваме, става твърде трудно и болезнено да ги променим и е по-лесно да гледаме на инвестицията в технология като на актив, а не като на бариера. Това важи както за електронните продукти, така и за дигиталните продукти, въпреки че промяната на типа процесор след изпращане на вашите продукти до вашите клиенти е почти невъзможна задача, ако не и неудобна.

Най-голямо влияние оказват ранните решения

Развитие: Има много разлики между процеса на разработване на електронни продукти и цифрови продукти и няма много прилики. По-голямата част от времето за разработка на платка за печатни платки преминава в избора на правилните компоненти и проектирането на оформлението. Част от работата е чисто техническа, свързване на проводници от компонент U1 пин 120 към компонент U17 пин 12. А някои задачи изискват цялостно прототипиране около три типа сензори, само за да се измери шума и консумацията на енергия на всеки един от тях. Вградената разработка е трудна за отстраняване на грешки и оптимизиране, доста често е да се виждат вградени разработчици, използващи GPIO пинове, за да открият дали е извикана функция и да измерват колко време отнема да се стартира. Използването на FPGA във вашия електронен продукт е смело решение, но понякога е единственото решение за постигане на целите за ефективност / цена. Разработката на FPGA е съвсем различна територия и е някъде между разработката на ASIC, разработката на платки и вградената разработка. За софтуерните разработчици повечето време се инвестира в ... код за писане. Има нещо много удовлетворяващо в разглеждането на ежедневната ви работа, всички тези редове от код, кодове и искания за изтегляне. Това звучи достатъчно просто, но количеството код и промени е огромно, така че правилното управление на конфигурацията и процеса на преглед е от съществено значение за поддържането на организирана база от кодове, намаляване на техническия дълг и увеличаване на знанията в екипа.

Алгоритми, физика и наука за данни: това обикновено е мозъкът на продукта, където компаниите са склонни да твърдят, че IP е в тях. Дизайнерите на борда работят с физици за избор на сензори, за проектиране на AFE (аналогов преден край) около тях или за проектиране на специална антена. Вградените разработчици работят с DSP инженери и математици, за да вграждат DSP алгоритми в реално време в своя софтуер за филтриране на сигнали, за откриване на модели или за внедряване на някаква оптимизирана математическа формула за обработка / кодиране на данните. В реално време означава, че трябва да завършите обработката в рамките на определено количество цикли на процесора, в противен случай няма да сте готови да обработите следващия сигнал и да го пропуснете или няма да можете да извеждате събития в рамките на необходимата латентност. Разработчиците на Backend работят с учени за данни, за да внедрят пакетни процеси, за да препоръчат нови продукти, да намерят аномалии, да предложат приятели, да обучават модел на задълбочено обучение, да използват NLP за анализ на текст, оценка на уеб страници и др. Разработчиците на Frontend имат всичкото забавление. Правят визуализация на данни. С библиотека като D3JS те създават невероятни визуални изображения и представят данните на потребителите по полезен и обобщен начин.

Отвъд стека тези хора ще се грижат за намаляване на шума, подобряване на сигналите и намиране на правилния баланс между откриване на пропускане (фалшив отрицателен) и фалшив алармен сигнал (фалшив положителен), те ще викат, че се нуждаят от повече данни или ще правят повече експерименти и ще скочат щастливо, ако успеят да подобрят представянето си с 5%. Интересно решение за продукта е да решите как да разделите задачите за наука за данни в стека. Като пример, Alexa включва масив от микрофони на нивото на платката, някакъв DSP код на ниво фърмуер и сложна наука за данни на ниво задния ред, за да разпознае речта ни.

Инструменти: Представете си разработчик на интерфейс и вграден програмист, който сравнява своите инструменти за разработка помежду си. Вграденият разработчик ще отиде на разработчика на фронталенд до неговата / нейната маса и ще посочи разликите между захранване, осцилоскоп и логически анализатор. След това разработчикът на frontend ще отведе вградения разработчик до най-близкото място за кафе. Те ще си поръчат кафе и ще намерят спокойно място, където да прекарат няколко часа заедно. След това тя / той ще превключи браузъра си Chrome в режим на разработка и ще покаже на вградения програмист как да гледа на мрежовия трафик и как да види CSS стила на определен HTML елемент.

Какво е значението на devtools за ...

Инструментите за отстраняване на грешки варират от програмист до програмист и използването им ефективно е мястото, където се крие истинското изживяване. Инстинктивното познаване къде е проблемът и използването на вашите инструменти за вкъщи е най-важното умение на разработчиците. Виждах, че разработчиците прекарват часове и дни в отстраняване на грешки в проблема и след това помолете за помощ от опитен програмист, който намери проблема за секунди. Не мога да подчертая това достатъчно, а това, което е професионално означава, да имаш правилни инструменти за всяка задача. И това важи за всяка професия.

Какво е значението на инструментите за отстраняване на грешки и тестове за ...Софтуерните разработчици намират това за плашещо

QA и тестване

Тестове за околната среда: Когато тестваме нашия продукт, искаме да проверим дали той функционира правилно във всички различни конфигурации и среди, които потребителите очакват да го използват. За физическите продукти околната среда обикновено означава температура (изключително студено, изключително горещо), вибрация (представете си автомобилен продукт), шок (пада от ръцете ви върху бетонен под), влажност, UV и слънчева радиация, ESD (тези малки изсветлявания, които идват от електростатично разреждане), EMI / RFI и др. За среда на цифрови продукти обикновено означава тип браузър (Chrome, Internet Explorer, Firefox ..), ОС (Android, IOS, OSX, Windows), устройство (мобилно, настолен компютър, конференция Екран) и ниво на мрежова свързаност (4G, Wifi, офлайн). Обикновено не тестваме всяка възможна комбинация, тъй като би било невъзможно да го направим, така че измисляме набор от конфигурации, които, надяваме се, ще покрият достатъчно сценарии, за да открият проблеми в спецификацията на продукта.

Какво е значението на външната среда за ...

Надеждност / издръжливост (тест на жизнения цикъл): Това са тестове, които се опитват да симулират какво се случва с продукта през целия му живот. По-подходящо е за физическите продукти, при които материалите достигат своите недостатъци. Има някои правила, които индустрията измисли, за да ни помогне да ускорим възрастта на продукта, излагайки го на екстремни условия на околната среда. По принцип, за да проверим дали даден продукт функционира правилно след пет години при стайна температура, можем да го тестваме при 70 градуса и 10g вибрация за един ден (само пример !!!). Те се наричат ​​HALT (силно ускорен живот) тестове

Тестове за екстремни условия (Load, Edge): Това са тестове, които тестват поведението на продукта в екстремни или крайни условия. Например, ако един електронен продукт работи на 5V, ще го тестваме при 4,5V и 5,5V, може дори да инжектираме скокове на напрежение до 25V или -5V, за да видим дали продуктът е издръжлив на потребителски грешки или електрически пренапрежения. За цифрови продукти може да предизвикаме полета за въвеждане с неразумни стойности. За примери можем да въведем имена с дължина 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, вероятно ще си спомните как някои от концепциите за lean и DevOps са получени в книгата от физическата производствена линия. И двата тръбопровода се справят с всичко необходимо за изграждане, тестване и изпращане на вашия продукт. Докато добавите повече автоматизация, можете да доставяте по-бързо. За електронните продукти това означава намаляване на разходите и дефектите и подобряване на капацитета, за цифровите продукти това означава по-бързо тестване на потребителите и адаптивен дизайн.

Доставка в световен мащаб: Има интересно сходство между мрежите за доставка на съдържание (CDN), които се използват за доставяне на уеб активи на потребителите въз основа на географското им местоположение, и как производството се разпространява по целия свят, за да се намалят разходите за доставка и да се локализират продуктите. Кеширането на съдържание може да се разглежда като локални складове или услуги за изпълнение като Amazon. И за двата вида продукти местното присъствие подобрява цялостното изживяване на клиентите в целия свят

Може да изглежда, че присъствието в световен мащаб е по-трудно за физическите продукти, но регулирането на защитата на данните и локализацията на езика също изискват значителни усилия

Облачни услуги: Облачните услуги са страхотни, можете да изградите своя дигитален продукт за секунди, избирайки от стотици уеб услуги. Няколко кликвания и той ще се стартира автоматично в повече от 20 центъра за данни по целия свят и мащаб въз основа на търсенето. В производството няма нищо подобно, но това може да е следващата индустриална революция. Представете си дигитален продукт, при който можете да настроите производствен тръбопровод, като използвате предварително конфигурирани модули като 3D печат, производство на печатни платки, снабдяване на компоненти, монтаж на платки и кабели, провеждане на тестове и доставка директно до вашите клиенти от местна автоматизирана производствена база. Освен това услугата ще позволи на крайния потребител да персонализира цвета на продукта, формата и други функции за персонализиране. Това изглежда като мечта, но съм сигурен, че някъде по света Amazon работи върху такава услуга (поне се надявам, че го правят).

заключение

Има много разлики между процеса на разработване на електронни продукти и дигитални, но гледайки на това от перспектива на 20 години, е невероятно да се види колко от принципите на проектиране и процесите на цифрови продукти се използват от физическите мениджъри на продукти. AWS обяви наскоро FreeRTOS за вградени системи. Прогнозирам, че след 10-20 години няма да има значителна разлика между процеса на разработване на цифровия продукт и физическия.

Ако искате да научите повече за моето пътуване и как да управлявам екип, който живее и в двата свята, не се колебайте да се свържете директно с мен.