Construir ecossistemas complexos de hardware e software que encontrem o produto / mercado adequado é uma tarefa difícil. Embora a maioria das startups de hardware falhe por falta de dinheiro, de acordo com um relatório da CB Insights, o maior motivo subjacente é na verdade a falta de demanda por seus produtos. Isso apenas ressalta a importância de quão crítica é a função do gerente de produto para startups de hardware, já que seu objetivo principal é descobrir as necessidades do cliente e os pontos fracos para entregar um produto de sucesso.

A última empresa que dirigi criou um ecossistema de web, mobile, aplicativos de software embutidos e dispositivos de hardware para a indústria de estacionamento. A estratégia de produtos de hardware fazia parte do meu trabalho diário, o que me levou a experiências com vários fluxos de trabalho de desenvolvimento de produtos de hardware. Apesar de trabalhar com produtos de hardware por 10 anos e ser bacharel em Eletrônica e Telecomunicações, ainda tinha muito a aprender no trabalho. Eu criei o guia abaixo na esperança de que você possa se atualizar no gerenciamento de produtos dentro do hardware com espaço de software incorporado mais rápido do que eu.

Desafios do gerenciamento de produtos de hardware

Embora SaaS e aplicativos móveis possam ser facilmente desenvolvidos usando um framework ágil , as condições exclusivas no software embarcado e no desenvolvimento de dispositivos de hardware tornam muito mais difícil a aplicação de princípios ágeis. Nesta primeira seção, cobriremos as características do desenvolvimento de hardware que criam complexidade. Nem todos eles têm soluções diretas, mas existem maneiras de reduzir a dificuldade empregando estratégias de desenvolvimento de hardware específicas, que serão abordadas na próxima seção.

É difícil encontrar talentos técnicos especializados localmente

Criar novos produtos de hardware é significativamente mais difícil do que iterar nos existentes. Envolve muita criatividade e experiência em prototipagem, que raramente é ensinada nas universidades. Algumas universidades nem mesmo têm instalações de prototipagem ou ferramentas necessárias para desenvolver essas habilidades e tal experiência é quase exclusivamente adquirida em grandes corporações de hardware que têm centros de P&D. Encontrar profissionais locais com experiência relevante pode, portanto, ser muito difícil, resultando em muitos fundadores de startups de hardware que precisam expandir seu pool de talentos contratando remotamente.

Os sistemas de controle de versão não são adaptados ao design de hardware

A maioria dos sistemas de controle de versão (VCS) são orientados no suporte ao formato textual, pois foram criados para o trabalho colaborativo de desenvolvimento de software. Em projetos que envolvem desenvolvimento de hardware, as informações são agrupadas em arquivos de design criados com a ajuda de ferramentas especiais como o OrCAD. E algumas dessas ferramentas suportam apenas arquivos binários que nem mesmo são otimizados para serem usados ​​em VCSs. CADLAB é uma tentativa relativamente nova de criar um VCS compatível com hardware e, com sorte, haverá mais ferramentas como esta em um futuro próximo.

Instalações de produção de hardware são deslocalizadas

As instalações de produção de hardware geralmente estão localizadas em outra região, país ou continente. A comunicação entre o produtor de hardware e o fabricante precisa de consideração especial e é a chave para uma entrega bem-sucedida do produto. Uma comunicação bem-sucedida requer um enquadramento mais estratégico para garantir a qualidade do produto e para garantir que ele possa lidar com as mudanças no estágio dinâmico de validação do produto-mercado. Para conseguir isso, o produtor do hardware precisa criar muitas especificações detalhadas enviadas ao fabricante. A estrutura de colaboração deve garantir a entrega rápida de informações e o gerenciamento do ciclo de vida das especificações, uma vez que podem facilmente ficar desatualizadas rapidamente.

Mudanças de hardware são menos flexíveis

Um modelo operacional popular em startups de software sacrifica a qualidade pela velocidade nos estágios iniciais. Até o Facebook defendeu o mantra “mova-se rápido e quebre as coisas” por algum tempo. Outra abordagem familiar é 'fingir até conseguir'. Isso funciona para inicializações de software por causa dos custos de infraestrutura baratos e estruturas de programação simplificadas que permitem que os desenvolvedores implantem atualizações de código diariamente.

Embora essa abordagem de desenvolvimento tenha se infiltrado lentamente no espaço do hardware, é uma tendência infeliz neste campo, pois é muito mais difícil fazer e implantar alterações de hardware. Os custos de desenvolvimento compensam o valor ganho por meio de lançamentos rápidos e frequentes, então é realmente uma estratégia muito mais desejável investir mais na fase de design para criar arquiteturas de hardware de som.

A armadilha do financiamento coletivo

Muitas startups estão presas na ideia de que o lançamento de um crowdfunding de hardware campanha é equivalente à validação de mercado. O financiamento coletivo tende a ser mais bem-sucedido para produtos que envolvem um componente de hardware, principalmente devido ao nosso desejo inconsciente de propriedade relacionado ao objeto físico. No entanto, o crowdfunding não tem como objetivo validar seu produto em escala, mas sim uma forma democrática de financiar o desenvolvimento do produto em estágio inicial. A triste realidade é que muitas empresas com campanhas de crowdfunding bem-sucedidas, subsequentemente, acharam difícil ou quase impossível dimensionar sua produção, uma vez que não validaram seu mercado em escala.

Certificações, regulamentos e aprovações

Todos os produtos de hardware requerem algum tipo de certificação para serem vendidos. É uma das etapas mais negligenciadas nos estágios iniciais de trazer produtos de hardware para o mercado. Como a restrição de certificação afetará o plano do produto e a estrutura aplicada para o desenvolvimento? Não é incomum planejar as fases iniciais do projeto com certificação e outras aprovações como um marco do projeto, só então voltar condicionalmente à fase inicial. Em vez disso, os gerentes de produto podem analisar cuidadosamente os regulamentos, dependências e gateways de decisão estratégica do plano de produto em uma abordagem mais semelhante a uma cachoeira.

Oportunidades para gerenciamento de produtos de hardware

Agora que cobrimos alguns dos desafios existentes no campo do hardware com software incorporado, vamos ver como tornar o processo de desenvolvimento mais simplificado e previsível, a fim de compensar as dificuldades inerentes ao desenvolvimento de hardware.

Incorporar Agile no desenvolvimento de hardware

Gerentes de produto experientes estão cientes dos desafios por trás da construção de produtos de hardware com software embutido que tenta explorar uma oportunidade de mercado criada por novos desenvolvimentos tecnológicos. Eles aprendem a equilibrar a aceleração do tempo de chegada ao mercado sem comprometer a probabilidade de sucesso do produto desde o estágio de planejamento. Na maioria das vezes, isso ocorre por meio de um queda d'água abordagem.

A fase de idealização do produto expande os princípios, objetivos e recursos de alto nível do produto com o máximo de detalhes possível. Grandes gerentes de produto gastam mais tempo refinando os resultados desta fase: visão, missão, avaliação de oportunidades, objetivos de produtos de hardware e recursos. Esta é a estrela do norte do produto que precisa ser clara o suficiente antes de começar a trabalhar em qualquer tipo de protótipo de hardware, portanto, uma abordagem em cascata é recomendada.

É fundamental ter requisitos e especificações funcionais bem documentados para produtos de hardware, bem como uma boa arquitetura técnica para o software embarcado que conduz o produto de hardware. Mudanças nos requisitos e especificações devem ser penalizadas, e não incentivadas, uma vez que são aprovadas por toda a equipe.

Uma metodologia scrum padrão pode ser usada ao desenvolver software embarcado. É mais barato em termos de tempo e dinheiro ajustar e refinar a implementação do software para trabalhar com a arquitetura de hardware predefinida do que vice-versa.

O teste final de integração e o teste de aceitação do usuário devem ser realizados em condições em cascata. Nesse estágio, a fase de desenvolvimento é concluída e novas funcionalidades e recursos ausentes são registrados como solicitações de trabalho adicionais para o próximo período de planejamento.

Incorporar Agile no desenvolvimento de software integrado

Construir produtos de hardware complexos com software embutido impacta como as metodologias tradicionais de desenvolvimento de software são aplicadas. Muitos sistemas usados ​​para produzir software que roda em um computador pessoal não são apropriados para o desenvolvimento de software embarcado, porque há restrições com relação à escassez de recursos e ciclos de vida de desenvolvimento muito mais longos.

Um grupo de acadêmicos e profissionais do Brasil ofereceu uma solução potencial: Metodologia de projeto de software baseado em plataforma para sistemas de controle incorporados: um kit de ferramentas ágil . Esta metodologia incorpora ágil princípios no desenvolvimento de software embarcado. Abaixo está um breve resumo da metodologia, mas os gerentes de produto de hardware são fortemente aconselhados a ler o descrição completa antes de aplicá-lo em sua prática.

As funções envolvidas nesta metodologia são:

• Proprietário da plataforma - Responsável por definir metas de qualidade, planejamento e custo
• Líder de produto - Responsável pela implementação, integração e teste do produto
• Líder de recurso - Responsável por gerenciar projetos de subsistema e acompanhar o progresso do produto final
• Equipe de desenvolvimento - Trabalhando no desenvolvimento do produto

A metodologia divide o desenvolvimento de software embarcado em três grupos de processos:

1. Grupo de processos da plataforma do sistema. Um sistema escolhe os componentes do sistema que farão parte da arquitetura e das plataformas API de uma biblioteca de plataforma e os customiza para satisfazer as restrições do aplicativo em questão. O processo de customização é realizado em ciclos iterativos, programando os processadores configuráveis ​​pelo designer e a lógica reconfigurável em tempo de execução integrada à plataforma.
2. Grupo de processos de desenvolvimento de produtos. As funcionalidades que compõem o produto são particionadas em elementos de hardware ou software da plataforma. A metodologia fornece algoritmos de particionamento para levar em consideração o consumo de energia, o tempo de execução e o tamanho da memória dos componentes do aplicativo.
3. Grupo de processos de gestão de produtos monitora e controla o escopo do produto, tempo, qualidade e parâmetros de custo. As abordagens sugeridas consistem principalmente nas práticas promovidas pelo método Agile Scrum e também nos padrões ágeis.

Crie um programa de desenvolvimento de hardware

Estruturar um programa de desenvolvimento de hardware em estágio inicial permitiu que as empresas fornecessem pivotamento rápido ou um plano B. Do ponto de vista do negócio, pode diminuir as margens financeiras, mas no final, fornece a agilidade necessária para lidar com o mercado em constante mudança condições em termos de produtos lançados pela concorrência e avanço das capacidades tecnológicas.

Suponha que uma empresa execute uma campanha de crowdfunding bem-sucedida para seu produto de hardware com software integrado. Eles funcionam muito bem para o primeiro lote de produtos, até que uma grande empresa estabelecida anuncie algo semelhante. Versatilidade e tempo de lançamento no mercado são os mais importantes, e uma resposta pragmática e ágil a essa situação aumenta a probabilidade de um produto bem-sucedido. Por ter um programa de desenvolvimento de hardware implantado, a empresa pode se adaptar rapidamente e colocar em destaque uma versão mais rica do produto como resposta aos concorrentes.

Teste de Hardware com Sucesso com Software Embarcado

O teste é um componente crucial do gerenciamento de produtos de hardware porque, ao contrário de teste ágil de software , a maioria dos bugs de hardware só pode ser corrigida com a produção de um novo lote de produtos. Os dispositivos Samsung Galaxy Note 7 que foram pegando fogo é um ótimo exemplo de por que o teste de hardware deve ser uma prioridade para todos os gerentes de produto.

Testes funcionais são o principal objetivo da validação técnica para hardware com produtos de software integrados. A complexidade desses procedimentos vem do fato de que os erros provavelmente vêm de qualquer parte do sistema.

Teste de unidade geralmente acontece em um ambiente simulado após cada sprint, pois o hardware simulado oferece a vantagem de ser perfeitamente controlável. Os scripts de teste podem ser automatizados, podem supervisionar a execução e eliminar os testes que parecem ter travado, deixando de produzir quaisquer resultados.

Teste de integração deve levar em consideração as operações online e offline e a submissão do produto de hardware às condições operacionais da vida real. Por exemplo, se a empresa desenvolve um sistema de monitoramento do cérebro montado na cabeça durante atividades ao ar livre, as condições de teste devem considerar essas particularidades.

Teste de sistema envolve testar todo o sistema em busca de erros e bugs. Este teste é realizado através da interface dos componentes de hardware e software de todo o sistema (que foram previamente testados na unidade e integração) e depois testados como um todo. Este teste é listado no método de teste de caixa preta, onde o software é verificado para cenários esperados pelo usuário, exceções potenciais e condições de casos extremos. Categorias especiais de teste mencionáveis:

• Teste acionado por evento: Iniciado por eventos específicos ou mudanças de estado na vida do produto de hardware (por exemplo, inicialização, reinicialização, desligamento). Seu objetivo é detectar falhas permanentes.
• Teste acionado por tempo: Iniciado em horários pré-configurados no funcionamento normal do sistema, feito periodicamente para detectar falhas permanentes. É útil em sistemas em execução por longos períodos, onde nenhum evento de acionamento de teste significativo ocorre. O teste disparado por tempo também é útil para detectar falhas intermitentes.

Aceitação do produto de hardware com software integrado

Valor do produto para produtos de hardware com software embutido é tipicamente validado após a etapa de aceitação do produto na metodologia water-scrum-fall. O hardware com ecossistema de software integrado deve priorizar o hardware sobre o software para validação e aceitação. Conforme afirmado anteriormente, as alterações de hardware são mais difíceis e caras de realizar. É comum que os gerentes de produto concebam soluções inovadoras, necessárias para resolver problemas de aceitação ou ajustar o valor considerando a restrição de não ser capaz de alterar o hardware e favorecer iterações extras no campo de desenvolvimento de software.

Excelentes gerentes de produto têm perspicácia para o produto e grande poder de visão para prever as necessidades de hardware e priorizar os recursos incluídos corretos para que o modelo de negócios seja sólido, a aceitação seja sólida e os usuários aproveitem o produto. Considerando o software embarcado, a “decoração” do hardware não deve ser surpreendente, pois ele precisa seguir regras e restrições, impulsionadas por processos de desenvolvimento de hardware, procedimentos de certificação, desafios de produção e aceitação do mercado.

O desenvolvimento de hardware requer agilidade gerenciada

Agile tomou o mundo do desenvolvimento de software como uma tempestade e agora começou a se infiltrar no espaço do hardware. No entanto, as condições do produto de hardware com desenvolvimento de software embutido acarreta vários desafios:

• Falta de talento especializado
• Sistemas de controle de versão que não são adaptados para hardware
• Instalações de produção deslocalizadas
• Mudanças que são mais difíceis de fazer em comparação com software
• Requisitos de certificação e regulamentação que impõem obstáculos de planejamento

Esses desafios tornam mais difícil aplicar os princípios ágeis da mesma forma que as empresas de software.

Para combater esses desafios, uma abordagem de agilidade gerenciada é necessária na forma de queda d'água. O desenvolvimento de software embarcado é criado seguindo os procedimentos padrão do scrum, enquanto outras etapas, como idealização, criação de especificações e teste, são implementadas em uma configuração em cascata. Isso permite que as empresas de hardware colham as recompensas que o Agile oferece, ao mesmo tempo em que mantém uma abordagem de gerenciamento de produto funcional que deve considerar as várias restrições listadas acima. Esta abordagem de agilidade gerenciada fornece um caminho de sucesso no contexto de condições de mercado em rápida mudança e melhorias tecnológicas constantes.

Compreender o básico

O Agile pode ser usado para desenvolvimento de hardware?

A abordagem water-scrum-fall é recomendada para o desenvolvimento ágil de hardware. O desenvolvimento de software embarcado é criado seguindo os procedimentos padrão do scrum, enquanto outras etapas, como idealização, criação de especificações e teste, são implementadas em uma configuração em cascata.

O que um engenheiro de desenvolvimento de hardware faz?

Um engenheiro de desenvolvimento de hardware é responsável por realmente criar e testar os componentes de hardware, como placas de circuito, processadores, dispositivos de memória, etc.

Qual é a diferença entre engenharia de software e hardware?

A principal diferença entre engenharia de software e hardware é o elemento físico. Os engenheiros de software trabalham apenas com código em um computador, enquanto os engenheiros de hardware trabalham com produtos físicos, como processadores, placas de circuito ou dispositivos de memória.

O que significa sistema embarcado?

Os sistemas incorporados são componentes de software executados em um produto de hardware. Eles são chamados de incorporados porque só são adaptados para funcionar naquele hardware específico.