Hardware ágil com desenvolvimento de software incorporado

Construir ecossistemas complexos de hardware e software que encontrem ajuste de produto/mercado é uma tarefa difícil. Embora a maioria das startups de hardware falhem porque ficam sem dinheiro, de acordo com um relatório da CB Insights, a maior razão subjacente é, na verdade, a falta de demanda por seus produtos. Isso apenas ressalta a importância de quão crítico é o papel do gerente de produto para startups de hardware, pois seu objetivo principal é descobrir as necessidades do cliente e os pontos problemáticos para entregar um produto de sucesso.

A última empresa que administrei criou um ecossistema de aplicativos de software da Web, móveis, incorporados e dispositivos de hardware para o setor de estacionamento. A estratégia de produtos de hardware fazia parte do meu trabalho diário, o que me levou a experimentar 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 no 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 uma estrutura ágil, as condições exclusivas no desenvolvimento de dispositivos de hardware e software incorporados tornam muito mais difícil aplicar os princípios ágeis. Nesta primeira seção, abordaremos 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 específicas de desenvolvimento de hardware, que serão abordadas na próxima seção.

Talento técnico especializado é difícil de encontrar localmente

Criar novos produtos de hardware é significativamente mais difícil do que iterar nos existentes. Envolve muita criatividade e experiência em prototipagem, o que raramente é ensinado nas universidades. Algumas universidades nem sequer têm instalações de prototipagem ou ferramentas necessárias para desenvolver essas habilidades e essa experiência é adquirida quase exclusivamente em grandes corporações de hardware que possuem 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 precisando 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 são otimizados para serem usados ​​em VCSs. CADLAB é uma tentativa relativamente nova de criar um VCS compatível com hardware e esperamos que haja mais ferramentas como esta em um futuro próximo.

As 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 fabricante de hardware e o fabricante precisa de consideração especial e é a chave para a entrega bem-sucedida do produto. Uma comunicação bem-sucedida requer um enquadramento mais estratégico para garantir a qualidade do produto e 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 de 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, pois elas podem ficar desatualizadas rapidamente.

As alterações 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 startups 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 de hardware, é uma tendência infeliz nesse campo, pois é muito mais difícil fazer e implantar alterações de hardware. Os custos de desenvolvimento compensam o valor obtido por meio de lançamentos rápidos e frequentes, portanto, na verdade, é uma estratégia muito mais desejável investir mais na fase de design para criar arquiteturas de hardware sólidas.

A armadilha do financiamento coletivo

Muitas startups estão presas à ideia de que lançar uma campanha de financiamento coletivo de hardware bem-sucedida é equivalente à validação de mercado. O crowdfunding 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 visa validar seu produto em escala, mas sim uma forma democrática de financiar o desenvolvimento de produtos em estágio inicial. A triste realidade é que muitas empresas com campanhas de crowdfunding bem-sucedidas posteriormente acharam difícil ou quase impossível escalar sua produção, pois 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 retroceder condicionalmente à fase inicial. Em vez disso, os gerentes de produto podem analisar cuidadosamente as regulamentações, dependências e gateways de decisão estratégica do plano de produto em uma abordagem mais semelhante a uma cascata.

Oportunidades para gerenciamento de produtos de hardware

Agora que abordamos alguns dos desafios existentes no campo de hardware com software embarcado, vamos agora ver como tornar o processo de desenvolvimento mais ágil e previsível para 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 incorporado que tenta explorar uma oportunidade de mercado criada por novos desenvolvimentos tecnológicos. Eles aprendem a equilibrar a aceleração do tempo de lançamento no mercado sem comprometer a probabilidade de sucesso do produto desde o estágio de planejamento. Na maioria das vezes, isso toma forma por meio de uma abordagem de queda de água.

A fase de idealização do produto expande os princípios do produto, objetivos e recursos de alto nível com o máximo de detalhes possível. Grandes gerentes de produto passam mais tempo refinando os resultados desta fase: visão, missão, avaliação de oportunidades, objetivos do produto de hardware e recursos. Esta é a estrela 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 bem documentados e especificações funcionais 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, não incentivadas uma vez que sejam aprovadas por toda a equipe.

Uma metodologia scrum padrão pode ser usada ao desenvolver software embarcado. É menos dispendioso em termos de tempo e dinheiro ajustar e refinar a implementação de 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 de cascata. Nesta fase, 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.

Incorpore o Agile no Desenvolvimento de Software Embarcado

A construção de produtos de hardware complexos com software incorporado afeta a forma como as metodologias tradicionais de desenvolvimento de software são aplicadas. Muitos sistemas usados ​​para produzir software que rodam em um computador pessoal não são apropriados para o desenvolvimento de software embarcado, porque existem restrições em 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 Design de Software Baseada em Plataforma para Sistemas de Controle Embarcados: Um Kit de Ferramentas Ágeis . Essa metodologia incorpora princípios ágeis 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 a descrição completa antes de aplicá-la em sua prática.

Os papéis envolvidos 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 recursos – Responsável por gerenciar projetos de subsistemas e acompanhar o progresso da entrega de recursos
• 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 das plataformas de arquitetura e API de uma biblioteca de plataforma e os customiza para satisfazer as restrições da aplicação 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 divididas 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. O grupo de processos de gerenciamento de produtos monitora e controla os parâmetros de escopo, tempo, qualidade e custo do produto. As abordagens sugeridas consistem principalmente nas práticas promovidas pelo método Scrum Agile, bem como pelos padrões ágeis.

Criar um programa de desenvolvimento de hardware

A estruturação de um programa de desenvolvimento de hardware em estágio inicial possibilitou às empresas fornecer um pivô rápido ou um plano B. Do ponto de vista comercial, 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 capacidades tecnológicas avançadas.

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

Teste bem-sucedido de hardware com software incorporado

O teste é um componente crucial do gerenciamento de produtos de hardware porque, diferentemente dos testes ágeis de software, a maioria dos bugs de hardware só podem ser corrigidos com a produção de um novo lote de produtos. Os dispositivos Samsung Galaxy Note 7 que estavam pegando fogo são um ótimo exemplo de por que o teste de hardware deve ser uma prioridade para todos os gerentes de produto.

Os testes funcionais são o principal objetivo da validação técnica de hardware com produtos de software incorporados. A complexidade desses procedimentos vem do fato de que os erros podem vir de qualquer parte do sistema.

O 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 e não produzirem nenhum resultado.

O 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 cerebral montado na cabeça durante atividades ao ar livre, as condições de teste devem considerar essas particularidades.

O teste do sistema envolve testar todo o sistema quanto a erros e bugs. Este teste é realizado através da interface dos componentes de hardware e software de todo o sistema (que foram previamente testados de unidade e integração) e, em seguida, testados como um todo. Esse teste é listado no método de teste de caixa preta, onde o software é verificado quanto a cenários esperados pelo usuário, possíveis exceções e condições de casos extremos. Categorias especiais mencionáveis ​​de testes:

• Testes acionados por eventos: Iniciados por eventos específicos ou mudanças de estado na vida útil do produto de hardware (por exemplo, inicialização, reinicialização, desligamento). Seu objetivo é detectar falhas permanentes.
• Teste acionado por tempo: Iniciado em tempos pré-configurados na operação normal do sistema, feito periodicamente para detectar falhas permanentes. É útil em sistemas executados por longos períodos, onde não ocorrem eventos significativos de acionamento de teste. O teste acionado por tempo também é útil para detectar falhas intermitentes.

Aceitação do Produto de Hardware com Software Incorporado

O valor do produto para produtos de hardware com software incorporado é normalmente validado após a etapa de aceitação do produto na metodologia de queda de água. O hardware com ecossistema de software incorporado deve priorizar o hardware sobre o software para validação e aceitação. Como dito anteriormente, as alterações de hardware são mais difíceis e caras de executar. É 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 poder alterar o hardware e favorecer iterações extras na área de desenvolvimento de software.

Excelentes gerentes de produto têm a perspicácia do produto e o grande poder de visão para prever as necessidades de hardware e priorizar os recursos inclusivos certos para que o modelo de negócios seja sólido, a aceitação seja sólida e os usuários gostem de usar o produto. Considerando o software embarcado, a “decoração” do hardware não deve surpreender, pois 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

O Agile conquistou o mundo do desenvolvimento de software 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 embarcado acarretam 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
• Alterações que são mais difíceis de fazer em comparação com o software
• Requisitos de certificação e regulamentação que impõem obstáculos ao planejamento

Esses desafios dificultam a aplicação dos princípios ágeis da mesma forma que as empresas de software.

Para combater esses desafios, é necessária uma abordagem de agilidade gerenciada na forma de queda de água. O desenvolvimento de software embarcado é criado seguindo os procedimentos padrão do scrum, enquanto outras etapas como ideação, criação de especificações e testes são implementados em uma configuração em cascata. Isso permite que as empresas de hardware obtenham as recompensas que o Agile oferece, mantendo uma abordagem de gerenciamento de produto funcional que deve considerar as várias restrições listadas acima. Essa abordagem de agilidade gerenciada fornece um caminho bem-sucedido no contexto de condições de mercado em rápida mudança e melhorias tecnológicas constantes.