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

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

Предизвикателства пред управлението на хардуерни продукти

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

Локално е трудно да се намери специализиран технически талант

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

Системите за контрол на версиите не са адаптирани към хардуерния дизайн

Повечето системи за контрол на версиите (VCS) са ориентирани да поддържат текстов формат, тъй като са създадени за съвместна работа по разработване на софтуер. В проекти, включващи разработване на хардуер, информацията вместо това се обвива в дизайнерски файлове, създадени с помощта на специални инструменти като OrCAD. И някои от тези инструменти поддържат само двоични файлове, които дори не са оптимизирани за използване във VCS. CADLAB е сравнително нов опит за създаване на хардуерно съвместим VCS и се надяваме, че в близко бъдеще ще има още инструменти като този.

Съоръженията за производство на хардуер са делокализирани

Съоръженията за производство на хардуер често се намират в друг регион, държава или континент. Комуникацията между производителя на хардуер и производителя се нуждае от специално внимание и е ключът към успешната доставка на продукта. Успешната комуникация изисква по-стратегическо кадриране, за да се гарантира качеството на продукта и да се гарантира, че той може да се справи с промените на етапа на валидиране на динамичния продуктов пазар. За да постигне това, производителят на хардуер трябва да създаде много подробни спецификации, изпратени до производителя. Рамката за сътрудничество трябва да осигури бърза доставка на информация и управление на жизнения цикъл на спецификациите, тъй като те могат лесно да остареят бързо.

Хардуерните промени са по-малко гъвкави

Популярният оперативен модел в софтуерните стартиращи компании жертва качеството на скоростта в ранните етапи. Дори Facebook от доста време отстояваше мантрата „движи се бързо и разбивай нещата“. Друг познат подход е „фалшифицирайте го, докато го направите.“ Това работи за стартиране на софтуер поради евтини инфраструктурни разходи и рационализирани програмни рамки, които позволяват на разработчиците да разгръщат актуализации на кода ежедневно.

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

Капана на краудфъндинга

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

Сертификати, регламенти и одобрения

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

Възможности за управление на хардуерни продукти

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

Включете Agile в разработването на хардуер

Опитните продуктови мениджъри са наясно с предизвикателствата пред изграждането на хардуерни продукти с вграден софтуер, който се опитва да използва пазарната възможност, създадена от новите технологични разработки. Те се научават да балансират ускорявайки времето за пускане на пазара, без да компрометират вероятността от успех на продукта от етапа на планиране. През повечето време това се формира чрез вода-скрам-падане Приближаване.

Фазата на идеята за продукта разширява продуктовите принципи, цели и характеристики на високо ниво с възможно най-много подробности. Страхотните продуктови мениджъри отделят повече време за усъвършенстване на резултатите от тази фаза: визия, мисия, оценка на възможностите, хардуерни продуктови цели и характеристики. Това е северната звезда на продукта, която трябва да бъде достатъчно ясна, преди да започне да работи върху какъвто и да е хардуерен прототип, поради което се препоръчва подход на водопад.

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

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

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

Включете Agile във вградената разработка на софтуер

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

Група учени и професионалисти от Бразилия предложи потенциално решение: Методология за проектиране на софтуер, базирана на платформа за вградени системи за управление: гъвкав инструментариум . Тази методология включва пъргав принципи в разработката на вграден софтуер. По-долу е дадено кратко резюме на методологията, но мениджърите на хардуерни продукти силно се препоръчват да прочетат пълно описание преди да го приложат в практиката си.

Ролите, включени в тази методология, са:

• Собственик на платформа - Отговаря за определянето на целите за качество, планиране и разходи
• Продуктов лидер - Отговаря за внедряването, интегрирането и тестването на продукта
• Лидер на функция - Отговорен за управление на проекти на подсистема и проследяване на напредъка на предоставената функция
• Разработващ екип - Работа върху разработването на продукта

Методологията разделя развитието на вградения софтуер в три групи процеси:

1. Група на процесите на системната платформа. Системата избира системните компоненти, които ще бъдат част от архитектурата и API платформите, от библиотека на платформата и ги персонализира, за да задоволи ограниченията на въпросното приложение. Процесът на персонализиране се извършва в итеративни цикли чрез програмиране на конфигурируемите от дизайнера процесори и логиката, преконфигурируема по време на изпълнение, интегрирани в платформата.
2. Група процеси за разработване на продукти. Функционалностите, съставляващи продукта, са разделени или на хардуерни, или на софтуерни елементи на платформата. Методологията предоставя алгоритми за разделяне, за да се вземе предвид консумацията на енергия, времето за изпълнение и размерът на паметта на компонентите на приложението.
3. Група процеси за управление на продукти следи и контролира обхвата на продукта, времето, качеството и параметрите на разходите. Предложените подходи се състоят главно от практиките, насърчавани от Scrum Agile метода, както и от пъргавите модели.

Създайте програма за разработване на хардуер

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

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

Успешно тестване на хардуер с вграден софтуер

Тестването е ключов компонент на управлението на хардуерни продукти, защото за разлика от гъвкаво тестване на софтуер , повечето хардуерни грешки могат да бъдат отстранени само чрез създаване на нова партида продукти. Устройствата Samsung Galaxy Note 7, които бяха запалване е чудесен пример за това защо тестването на хардуер трябва да бъде основен приоритет за всички продуктови мениджъри.

Функционални тестове са ключовата цел на техническата проверка за хардуер с вградени софтуерни продукти. Сложността на тези процедури идва от факта, че е вероятно грешките да идват от която и да е част от системата.

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

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

Тестване на системата включва тестване на цялата система за грешки и грешки. Този тест се извършва чрез взаимодействие на хардуерните и софтуерните компоненти на цялата система (които преди това са били тествани като модул и интеграция) и след това тествани като цяло. Това тестване е изброено в метода за тестване в черната кутия, където софтуерът се проверява за очаквани от потребителя сценарии, потенциални изключения и крайни условия. Споменати специални категории тестване:

• Тестване, предизвикано от събитие: Иницииран от определени събития или промени в състоянието в живота на хардуерния продукт (напр. Стартиране, нулиране, изключване). Целта му е да открие трайни неизправности.
• Тестване, предизвикано от времето: Иницииран в предварително конфигурирани моменти в нормалната работа на системата, периодично се прави за откриване на постоянни повреди. Полезен е в системи, работещи за дълги периоди, където не се случват значителни събития, задействащи теста. Задействаното от времето тестване е полезно и за откриване на периодични повреди.

Приемане на продукти на хардуер с вграден софтуер

Стойност на продукта за хардуерни продукти с вграден софтуер обикновено се валидира след стъпката за приемане на продукта в методологията water-scrum-fall. Хардуерът с вградена софтуерна екосистема трябва да дава приоритет на хардуера пред софтуера за валидиране и приемане. Както беше посочено по-рано, хардуерните промени са по-трудни и скъпи за изпълнение. Често се случва продуктовите мениджъри да създават иновативни решения, необходими за решаване на проблеми с приемането или коригиране на стойността, като вземат предвид ограничението, че не могат да променят хардуера и предпочитат допълнителни повторения в областта на разработката на софтуер.

Отличните продуктови мениджъри притежават продуктовия нюх и голямата сила на зрението при прогнозиране на хардуерните нужди и приоритизиране на правилните включими функции, така че бизнес моделът да е стабилен, приемането да е стабилно и потребителите да се радват да използват продукта. Като се има предвид вградения софтуер, „украсата“ на хардуера не би трябвало да е изненадваща, тъй като той трябва да следва правилата и ограниченията, движени от процесите на разработване на хардуер, процедурите за сертифициране, производствените предизвикателства и приемането на пазара.

Разработката на хардуер изисква управлявана гъвкавост

Agile завладя света на разработката на софтуер и сега започна да се прокрадва в хардуерното пространство. Условията на хардуерния продукт с вградена разработка на софтуер водят до различни предизвикателства:

• Липса на специализиран талант
• Системи за контрол на версиите, които не са адаптирани за хардуер
• Делокализирани производствени мощности
• Промени, които се правят по-трудно в сравнение със софтуера
• Изисквания за сертифициране и регулиране, които налагат пречки пред планирането

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

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

Разбиране на основите

Може ли да се използва пъргав за разработване на хардуер?

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

Какво прави инженерът по разработване на хардуер?

Инженер за разработване на хардуер е отговорен за действителното създаване и тестване на хардуерните компоненти като платки, процесори, устройства с памет и т.н.

Каква е разликата между софтуерното и хардуерното инженерство?

Основната разлика между софтуерното и хардуерното инженерство е физическият елемент. Софтуерните инженери работят само с код на компютър, докато хардуерните инженери работят с физически продукти като процесори, платки или устройства с памет.

Какво се разбира под вградена система?

Вградените системи са софтуерни компоненти, които работят в рамките на хардуерен продукт. Те се наричат ​​вградени, защото са адаптирани само за работа на този конкретен хардуер.