Гибкое оборудование с разработкой встроенного программного обеспечения

Создание сложных аппаратных и программных экосистем, которые соответствуют продукту и рынку, — сложная задача. Хотя большинство аппаратных стартапов в конечном итоге терпят неудачу из-за того, что у них заканчиваются деньги, согласно отчету CB Insights, основной причиной является отсутствие спроса на их продукты. Это только подчеркивает важность роли продакт-менеджера для аппаратных стартапов, поскольку их основная цель — выяснить потребности клиентов и болевые точки, чтобы предоставить успешный продукт.

Последняя компания, которой я руководил, создала экосистему веб-сайтов, мобильных приложений, встроенных программных приложений и аппаратных устройств для индустрии парковки. Стратегия аппаратного продукта была частью моей повседневной работы, что привело меня к экспериментам с различными рабочими процессами разработки аппаратного продукта. Несмотря на то, что я работал с аппаратными продуктами в течение 10 лет и имел степень бакалавра в области электроники и телекоммуникаций, мне еще предстояло многому научиться на работе. Я создал приведенное ниже руководство в надежде, что вы сможете быстрее, чем я, освоить управление продуктами на оборудовании со встроенным программным пространством.

Проблемы управления аппаратными продуктами

В то время как SaaS и мобильные приложения могут быть легко разработаны с использованием гибкой среды, уникальные условия разработки встроенного программного обеспечения и аппаратных устройств значительно усложняют применение принципов гибкой разработки. В этом первом разделе мы рассмотрим характеристики разработки аппаратного обеспечения, которые создают сложность. Не все из них имеют простые решения, но есть способы уменьшить сложность, используя определенные стратегии разработки оборудования, которые будут рассмотрены в следующем разделе.

Специализированные технические таланты трудно найти на месте

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

Системы контроля версий не адаптированы к аппаратному обеспечению

Большинство систем контроля версий (СКВ) ориентированы на поддержку текстового формата, так как были созданы для совместной работы по разработке программного обеспечения. В проектах, связанных с разработкой аппаратного обеспечения, информация вместо этого упаковывается в файлы проекта, созданные с помощью специальных инструментов, таких как OrCAD. И некоторые из этих инструментов поддерживают только бинарные файлы, которые даже не оптимизированы для использования в СКВ. CADLAB — это относительно новая попытка создания аппаратно-совместимой системы контроля версий, и мы надеемся, что в ближайшем будущем таких инструментов станет больше.

Производство оборудования делокализовано

Производство оборудования часто находится в другом регионе, стране или континенте. Связь между производителем оборудования и производителем требует особого внимания и является ключом к успешной доставке продукта. Успешная коммуникация требует более стратегической разработки, чтобы гарантировать качество продукта и гарантировать, что он может справиться с изменениями на этапе динамической проверки продукта на рынке. Для этого производитель оборудования должен создать множество подробных спецификаций, отправленных производителю. Структура совместной работы должна обеспечивать быструю доставку информации и управление жизненным циклом спецификаций, поскольку они могут быстро устареть.

Аппаратные изменения менее гибкие

Популярная операционная модель стартапов программного обеспечения жертвует качеством ради скорости на ранних стадиях. Даже Facebook довольно долго отстаивал мантру «Двигайся быстро и ломай вещи». Еще один знакомый подход — «притворяйся, пока не сделаешь». Это работает для стартапов программного обеспечения из-за дешевых затрат на инфраструктуру и оптимизированных сред программирования, которые позволяют разработчикам ежедневно развертывать обновления кода.

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

Подводный камень краудфандинга

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

Сертификаты, правила и разрешения

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

Возможности для управления оборудованием

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

Внедрение Agile в разработку оборудования

Опытные менеджеры по продуктам знают о проблемах, связанных с созданием аппаратных продуктов со встроенным программным обеспечением, которое пытается использовать рыночные возможности, созданные новыми технологическими разработками. Они учатся балансировать, ускоряя время выхода на рынок, не ставя под угрозу вероятность успеха продукта на этапе планирования. В большинстве случаев это принимает форму с помощью подхода «вода-схватка-падение».

На этапе создания идеи продукта принципы продукта, цели и высокоуровневые функции раскрываются настолько подробно, насколько это возможно. Лучшие продакт-менеджеры тратят больше времени на уточнение результатов этого этапа: видения, миссии, оценки возможностей, целей аппаратного продукта и функций. Это северная звезда продукта, которая должна быть достаточно ясной, прежде чем начинать работу над любым прототипом оборудования, поэтому рекомендуется каскадный подход.

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

При разработке встраиваемого программного обеспечения можно использовать стандартную методологию scrum. Настройка и доработка реализации программного обеспечения для работы с предопределенной аппаратной архитектурой обходится дешевле с точки зрения времени и денег, чем наоборот.

Окончательное интеграционное тестирование и пользовательское приемочное тестирование должны выполняться в каскадных условиях. На этом этапе фаза разработки завершена, и новые функции и отсутствующие функции регистрируются как дополнительные рабочие запросы на следующий период планирования.

Внедрение Agile в разработку встраиваемого программного обеспечения

Создание сложных аппаратных продуктов со встроенным программным обеспечением влияет на то, как применяются традиционные методологии разработки программного обеспечения. Многие системы, используемые для создания программного обеспечения, работающего на персональном компьютере, не подходят для разработки встраиваемого программного обеспечения, поскольку существуют ограничения, связанные с нехваткой ресурсов и гораздо более длительным жизненным циклом разработки.

Группа ученых и профессионалов из Бразилии предложила потенциальное решение: методология разработки программного обеспечения на основе платформы для встроенных систем управления: гибкий инструментарий . Эта методология включает принципы Agile в разработку встраиваемого программного обеспечения. Ниже приводится краткое изложение методологии, но менеджерам по аппаратным продуктам настоятельно рекомендуется прочитать полное описание, прежде чем применять ее в своей практике.

Роли, задействованные в этой методологии:

• Владелец платформы — отвечает за определение качества, планирования и целевых показателей затрат.
• Лидер продукта — отвечает за внедрение, интеграцию и тестирование продукта.
• Руководитель функции — отвечает за управление проектами подсистем и отслеживание хода выполнения функции.
• Команда разработчиков – Работа над разработкой продукта

Методология разделяет разработку встроенного программного обеспечения на три группы процессов:

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

Создайте программу разработки оборудования

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

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

Успешное тестирование оборудования с помощью встроенного программного обеспечения

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

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

Модульное тестирование обычно происходит в смоделированной среде после каждого спринта, поскольку смоделированное оборудование дает преимущество в том, что оно полностью управляемо. Тестовые сценарии могут быть автоматизированы, могут контролировать выполнение и уничтожать тесты, которые, как кажется, потерпели крах, не дав никаких результатов.

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

Системное тестирование включает тестирование всей системы на наличие ошибок и багов. Этот тест выполняется путем сопряжения аппаратных и программных компонентов всей системы (которые ранее были протестированы на единицу и интеграцию), а затем тестируется в целом. Это тестирование относится к методу тестирования черного ящика, при котором программное обеспечение проверяется на наличие ожидаемых пользователем сценариев, потенциальных исключений и крайних случаев. Упомянутые специальные категории тестирования:

• Тестирование, инициируемое событием: инициируется определенными событиями или изменениями состояния в течение срока службы аппаратного продукта (например, запуск, сброс, завершение работы). Его целью является обнаружение постоянных неисправностей.
• Тестирование с запуском по времени: инициируется в заранее заданное время при нормальной работе системы, периодически проводится для обнаружения постоянных сбоев. Это полезно в системах, работающих в течение длительного времени, когда не происходит значительных событий, запускающих тест. Тестирование с запуском по времени также полезно для обнаружения прерывистых сбоев.

Приемка оборудования со встроенным программным обеспечением

Ценность продукта для продуктов аппаратного обеспечения со встроенным программным обеспечением обычно проверяется после этапа приемки продукта в методологии «вода-схватка-падение». Экосистема аппаратного обеспечения со встроенным программным обеспечением должна отдавать предпочтение аппаратному обеспечению над программным обеспечением для проверки и принятия. Как указывалось ранее, аппаратные изменения выполнить сложнее и дороже. Менеджеры по продуктам обычно придумывают инновационные решения, необходимые для решения проблем приемки или корректировки стоимости, учитывая ограничения, связанные с невозможностью изменить аппаратное обеспечение и отдавая предпочтение дополнительным итерациям в области разработки программного обеспечения.

Отличные продакт-менеджеры обладают проницательностью в области продуктов и огромной силой видения в прогнозировании потребностей в оборудовании и расстановке приоритетов для нужных включаемых функций, чтобы бизнес-модель была надежной, принятие было прочным, а пользователи получали удовольствие от использования продукта. Что касается встраиваемого программного обеспечения, «украшение» аппаратного обеспечения не должно вызывать удивления, поскольку оно должно соответствовать правилам и ограничениям, определяемым процессами разработки аппаратного обеспечения, процедурами сертификации, производственными проблемами и признанием на рынке.

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

Agile штурмом захватил мир разработки программного обеспечения и теперь начал проникать в аппаратное пространство. Однако условия разработки аппаратного продукта со встроенным программным обеспечением влекут за собой различные проблемы:

• Отсутствие специализированных талантов
• Системы контроля версий, не адаптированные для аппаратного обеспечения
• Делокализованные производственные мощности
• Изменения, которые сложнее сделать по сравнению с программным обеспечением
• Сертификация и нормативные требования, затрудняющие планирование

Эти проблемы затрудняют применение гибких принципов так же, как это делают компании-разработчики программного обеспечения.

Чтобы справиться с этими проблемами, необходим управляемый подход к маневренности в форме «вода-схватка-падение». Разработка встроенного программного обеспечения создается в соответствии со стандартными процедурами scrum, в то время как другие этапы, такие как создание идей, создание спецификаций и тестирование, реализуются в каскадной настройке. Это позволяет компаниям, производящим оборудование, пожинать плоды, которые предлагает Agile, сохраняя при этом функционирующий подход к управлению продуктом, который должен учитывать различные ограничения, перечисленные выше. Этот подход к управляемой гибкости обеспечивает успешный путь вперед в контексте быстро меняющихся рыночных условий и постоянных технологических усовершенствований.