Capacitar a adoção com a invenção digital

O teste final da inovação é a reação do cliente à sua invenção. A hipótese provou ser verdadeira? Os clientes utilizam a solução? Dimensiona para satisfazer as necessidades da percentagem pretendida de utilizadores? O mais importante é que continuam a voltar? Nenhuma destas perguntas pode ser feita até que a solução de produto mínimo viável (MVP) tenha sido implementada.

Neste artigo, vamos concentrar-nos em capacitar a adoção com ferramentas de pipeline de integração contínua e implementação contínua (CI/CD). A integração contínua é a automatização de código múltiplas vezes por dia para ter um projeto único atualizado. A implementação contínua é a entrega automática dessas funções ao longo do dia.

Reduzir o atrito ci/CD que afeta a adoção

Alguns obstáculos à adoção podem ser minimizados através de uma combinação de tecnologia e processos. Para leitores com conhecimento dos processos de CI/CD ou DevOps, os seguintes processos de pipeline ci/CD serão familiares. Este artigo estabelece um ponto de partida para as equipas de adoção da cloud que alimentam ciclos de inovação e feedback. Este ponto de partida pode fomentar abordagens ci/CD ou DevOps mais robustas à medida que os produtos e as equipas amadurecem.

Conforme descrito em Medida para o impacto do cliente, a validação positiva de qualquer hipótese requer iteração e determinação. Este artigo de CI/CD visa minimizar os picos técnicos que retardam a inovação, ao mesmo tempo que garante que mantém as melhores práticas implementadas. Ao fazê-lo, irá ajudar a equipa a conceber o sucesso futuro e a cumprir as necessidades atuais do cliente.

Capacitar a adoção e a invenção digital: o modelo de maturidade

O principal objetivo da metodologia de Inovação é criar parcerias com clientes e acelerar os ciclos de feedback, o que leva a inovações no mercado. As seguintes imagens e secções descrevem as implementações iniciais que suportam esta metodologia.

Diagrama que mostra o modelo de maturidade de adoção capacitado.

  • Solução partilhada: estabeleça um repositório centralizado para todos os aspetos da solução.
  • Ciclos de comentários: certifique-se de que os ciclos de comentários podem ser geridos de forma consistente através de iterações.
  • Integração contínua: crie e consolide regularmente a solução.
  • Teste fiável: valide a qualidade da solução e as alterações esperadas para garantir a fiabilidade das métricas de teste.
  • Implementação de soluções: implemente soluções para que a equipa possa partilhar rapidamente as alterações com os clientes.
  • Medição integrada: adicione métricas de aprendizagem ao ciclo de comentários para uma análise clara por parte da equipa completa.

Para minimizar os picos técnicos, suponha que a maturidade será inicialmente baixa em todos estes princípios. Planeie com antecedência alinhando-se com ferramentas e processos que podem ser dimensionados à medida que as hipóteses se tornam mais detalhadas. No Azure, o GitHub e o Azure DevOps permitem que as equipas pequenas comecem com pouca fricção. Estas equipas podem crescer para incluir milhares de programadores que colaboram em soluções de escala e testam centenas de hipóteses de clientes. O resto deste artigo ilustra a abordagem "planear grande, começar pequeno" para capacitar a adoção através destes princípios.

Solução partilhada

Conforme descrito em Medida para o impacto do cliente, a validação positiva de qualquer hipótese requer iteração e determinação. Irá deparar-se com muito mais falhas do que ganha durante qualquer ciclo de inovação. Isto era esperado. No entanto, quando um cliente precisa, a hipótese e a solução se alinham à escala, o mundo muda rapidamente.

Quando está a dimensionar a invenção digital e a inovação, não existe uma ferramenta mais valiosa do que uma base de código partilhada para a solução. Infelizmente, não há nenhuma maneira fiável de prever qual iteração ou qual MVP irá produzir a combinação vencedora. É por isso que nunca é cedo para estabelecer uma base de código ou repositório partilhado. Este é o único pico técnico que não deve ser adiado. À medida que a equipa itera através de várias soluções MVP, um repositório partilhado permite uma colaboração fácil e um desenvolvimento acelerado. Quando as alterações à solução arrastam as métricas de aprendizagem, o controlo de versões permite reverter para uma versão anterior e mais eficaz da solução.

A ferramenta CI/CD mais amplamente adotada para gerir repositórios de código é o GitHub, que lhe permite criar um repositório de código partilhado em apenas alguns passos. Além disso, a funcionalidade Repositórios do Azure do Azure DevOps pode ser utilizada para criar um repositório Git ou TFVC .

Ciclos de comentários

Tornar o cliente parte da solução é a chave para criar parcerias com clientes durante os ciclos de inovação. Isto é conseguido, em parte, ao medir o impacto do cliente. Requer conversações e testes diretos com o cliente. Ambos geram comentários que têm de ser geridos de forma eficaz.

Cada ponto de feedback é uma solução potencial para as necessidades do cliente. Mais importante ainda, cada feedback direto dos clientes representa uma oportunidade para melhorar a parceria. Se o feedback o transformar numa solução MVP, celebre-o com o cliente. Mesmo que alguns comentários não sejam acionáveis, simplesmente ser transparente com a decisão de privar o feedback demonstra uma mentalidade de crescimento e um foco na aprendizagem contínua.

O Azure DevOps inclui formas de pedir, fornecer e gerir comentários. Estas ferramentas centralizam o feedback para que a equipa possa tomar medidas e dar seguimento ao serviço de um ciclo de feedback transparente.

Integração contínua

A integração contínua é a automatização de código múltiplas vezes por dia para ter um projeto único atualizado. À medida que as adoções se dimensionam e uma hipótese se aproxima da verdadeira inovação em escala, o número de hipóteses menores a testar tende a crescer rapidamente. Para ciclos de feedback precisos e processos de adoção suaves, é importante que essas hipóteses estejam integradas e apoiem a hipótese principal por detrás da inovação. Isto requer que se mova rapidamente para inovar e crescer, o que requer vários programadores para testar variações da hipótese principal. Para realizar mais tarde esforços de desenvolvimento, pode até precisar de várias equipas de programadores, cada uma a criar para uma solução partilhada. A integração contínua é o primeiro passo para a gestão de todas as partes móveis.

Na integração contínua, as alterações de código são frequentemente intercaladas no ramo principal. Os processos de compilação e teste automatizados garantem que o código no ramo principal é sempre a qualidade de produção. Isto garante que os programadores estão a trabalhar em conjunto para desenvolver soluções partilhadas que fornecem ciclos de comentários precisos e fiáveis.

O Azure DevOps e o Azure Pipelines fornecem capacidades de integração contínua com apenas alguns passos no GitHub ou noutros repositórios. Para obter mais informações, consulte O que é a integração contínua? ou experimente o laboratório prático de integração contínua. Estão disponíveis arquiteturas de soluções que podem acelerar a criação dos pipelines de CI/CD através do Azure DevOps.

Testes fiáveis

Os defeitos em qualquer solução podem criar falsos positivos ou falsos negativos. Erros inesperados podem facilmente levar a uma interpretação errada das métricas de adoção do utilizador. Também podem gerar feedback negativo de clientes que não representam com precisão o teste da sua hipótese.

Durante as iterações iniciais de uma solução MVP, são esperados defeitos. Os primeiros adotantes podem até encontrá-los cativantes. Nas versões iniciais, os testes de aceitação são normalmente inexistentes. No entanto, um aspecto da construção com empatia diz respeito à validação da necessidade e da hipótese. Ambos podem ser concluídos através de testes de unidades ao nível do código e testes de aceitação manual antes da implementação. Em conjunto, estes fornecem alguns meios de fiabilidade nos testes. Deve tentar automatizar uma série bem definida de testes de compilação, unidade e aceitação. Estas métricas irão garantir métricas fiáveis relacionadas com ajustes mais detalhados à hipótese e à solução resultante.

A funcionalidade Planos de Teste do Azure fornece ferramentas para desenvolver e operar planos de teste durante a execução de testes manual ou automatizada.

Implementação de solução

Talvez o aspeto mais significativo de capacitar a adoção seja a sua capacidade de controlar o lançamento de uma solução para os clientes. Ao fornecer um pipeline personalizado ou automatizado para lançar uma solução para os clientes, irá acelerar o ciclo de comentários. Ao permitir que os clientes interajam rapidamente com as alterações na solução, convida-os para o processo. Esta abordagem também desencadeia testes mais rápidos de hipóteses, reduzindo pressupostos e potenciais reformulações.

Existem vários métodos para a implementação de soluções. Os três mais comuns são:

  • A implementação contínua é o método mais avançado, uma vez que implementa automaticamente alterações de código na produção. Para equipas maduras que estão a testar hipóteses maduras, a implementação contínua pode ser extremamente valiosa.
  • Durante as fases iniciais de desenvolvimento, a entrega contínua pode ser mais adequada. Na entrega contínua, todas as alterações de código são implementadas automaticamente num ambiente de produção. Os programadores, os responsáveis pela tomada de decisões empresariais e outros membros da equipa podem utilizar este ambiente para verificar se o seu trabalho está pronto para produção. Também pode utilizar este método para testar uma hipótese com os clientes sem afetar as atividades empresariais em curso.
  • A implementação manual é a abordagem menos sofisticada para a gestão de versões. Como o nome sugere, alguém na equipa implementa manualmente as alterações de código mais recentes. Esta abordagem é propensa a erros, pouco fiável e considerada antipasta pela maioria dos engenheiros experientes.

Durante a primeira iteração de uma solução MVP, a implementação manual é comum, apesar da avaliação anterior. Quando a solução é extremamente fluida e o feedback dos clientes é desconhecido, existe um risco significativo na reposição de toda a solução (ou mesmo a hipótese principal). Eis a regra geral para a implementação manual: sem prova do cliente, sem automatização de implementação.

Investir cedo pode levar à perda de tempo. Mais importante ainda, pode criar dependências no pipeline de versão que tornam a equipa mais resistente a um pivô inicial. Após as primeiras iterações ou quando o feedback dos clientes sugere um potencial sucesso, deve ser rapidamente adotado um modelo de implementação mais avançado.

Em qualquer fase da validação de hipóteses, o Azure DevOps e os Pipelines do Azure fornecem capacidades de entrega contínua e implementação contínua. Saiba mais sobre a entrega contínua ou consulte o laboratório prático. A arquitetura de soluções também pode acelerar a criação dos pipelines de CI/CD através do Azure DevOps.

Medições integradas

Quando mede o impacto do cliente, é importante compreender como os clientes reagem às alterações na solução. Estes dados, conhecidos como telemetria, fornecem informações sobre as ações que um utilizador (ou coorte de utilizadores) realizou ao trabalhar com a solução. A partir destes dados, é fácil obter uma validação quantitativa da hipótese. Essas métricas podem então ser utilizadas para ajustar a solução e gerar hipóteses mais detalhadas. Essas alterações mais subtis ajudam a amadurecer a solução inicial em iterações posteriores, conduzindo, em última análise, a repetir a adoção em escala.

No Azure, o Azure Monitor fornece as ferramentas e a interface para recolher e rever dados de experiências de clientes. Pode aplicar essas observações e informações para refinar o atraso com os Quadros do Azure.

Passos seguintes

Depois de compreender as ferramentas e os processos de pipeline de CI/CD necessários para capacitar a adoção, está na altura de examinar uma disciplina de inovação mais avançada: interagir com dispositivos. Esta disciplina pode ajudar a reduzir as barreiras entre experiências físicas e digitais, tornando a sua solução ainda mais fácil de adotar.