Planear e priorizar

Saiba como identificar metas para seus esforços de engenharia de plataforma com base no Modelo de Capacidade de Engenharia de Plataforma, percorrer cenários comuns e procurar maneiras de medir o sucesso. Meça o sucesso alinhando suas metas aos objetivos empresariais.

Identificar metas e cenários-chave

Para começar, primeiro avalie onde sua organização está hoje usando o Modelo de Capacidade de Engenharia de Plataforma. Use o modelo para mapear onde sua organização está em seis recursos principais de engenharia de plataforma: investimento, adoção, governança, provisionamento e gerenciamento, interfaces, medição e feedback. Todas as organizações são mais avançadas em alguns recursos do que em outros. Depois de saber onde a sua organização se encontra hoje, pode escolher quais capacidades gostaria de desenvolver. Para saber mais, consulte Avaliar suas práticas atuais e definir metas futuras.

Você pode planejar e atualizar continuamente suas metas de engenharia de plataforma ao longo do tempo. Ser claro sobre o que você quer ganhar investindo em sua jornada de engenharia de plataforma pode ajudar muito a construir suporte organizacional.

Como um líder de engenharia de plataforma disse uma vez, "Eu não faço algo pela engenharia de plataforma até que eu tenha algo que eu possa ganhar com isso." – Peter, líder de engenharia de plataforma, empresa multinacional de tecnologia

Ao pensar sobre suas metas, estenda-as para os objetivos de negócios relacionados ao seu esforço de engenharia de plataforma, em vez das especificidades de uma equipe de desenvolvimento específica. Os objetivos comuns de engenharia de plataforma de alto nível incluem:

• Aumente a qualidade do aplicativo e reduza bugs e problemas durante o lançamento.
• Melhore a segurança e reduza o número de incidentes de segurança ou vulnerabilidades e exposições comuns detetadas (CVEs), uma vez em produção.
• Diminua o risco através de uma melhor conformidade em áreas como licenciamento, acessibilidade, privacidade ou regulamentação governamental.
• Acelere o tempo para valor empresarial, reduzindo a complexidade, os custos indiretos e promovendo o compartilhamento de código por meio das práticas de inner source.
• Reduza os custos de desenvolvimento ou operações, minimize a duplicação e melhore a automação.

Escolher seu objetivo principal é fundamental, pois seu objetivo orienta como você pensa sobre sua priorização.

Melhor ainda, concordar com objetivos e resultados-chave (OKRs) com sua liderança e parceiros internos ajuda a estabelecer metas mensuráveis para a fase atual de seus investimentos. (Outras abordagens de planejamento têm conceitos semelhantes se sua organização usar outra coisa.) Os melhores OKRs são aqueles que você pode definir com base em uma medida concreta, uma vez que remove a subjetividade.

Cenários e trabalhos a serem realizados

Depois de identificar suas metas, escolha os principais cenários para eliminar sua lista de pendências e roteiro. Por exemplo, consulte os cenários a seguir e os trabalhos associados a serem feitos.

Cenário: Comece a criar um novo aplicativo

• Compreender e aplicar as melhores práticas e políticas organizacionais
• Criar um novo repositório
• Ferramentas de provisionamento
• Oferta de infraestrutura comum
• Dê acesso aos membros da equipe
• Estabelecer pipelines de CI/CD
• Provisão de infraestrutura de desenvolvimento
• Implantação inicial para testar "tubos"

Cenário: Adicionar ou remover um novo membro a uma equipa existente

• Atualizar o acesso a ferramentas e serviços
• Configurar uma máquina de desenvolvedor
• Aumente o número de membros da equipe em aplicativos
• Criar um ambiente de área restrita do aplicativo
• Crie e analise primeiro a solicitação pull

Cenário: Adicionar ou atualizar a infraestrutura para o aplicativo existente

• Compreender as melhores práticas organizacionais, as opções disponíveis
• Atualizar ou adicionar infraestrutura como artefatos de código
• Criar ambiente de área restrita de aplicativos
• Verificar atualizações
• Implementar alterações em outros ambientes

Cenário: Adicionar ou atualizar ferramenta para a equipe existente

• Compreender as melhores práticas organizacionais, as opções disponíveis
• Solicitar o uso de uma nova ferramenta
• Atualizar o acesso dos membros da equipe às ferramentas
• (Se aplicável) Integre a ferramenta em clientes ou pipelines de CI/CD

Cenário: Localizar ou reutilizar API, SDK ou serviço existente

• Descubra APIs, SDK ou serviços disponíveis
• Avaliar se ele atende às necessidades
• Entre em contato com a equipa responsável para qualquer dúvida
• Adotar para aplicação

Cenário: Responder a um incidente de operações

• Notificação de um problema
• Avalie se o código da aplicação ou a infraestrutura está relacionado (ou ambos)
• Crie um ambiente de teste que espelhe o ambiente de produção (se diferente)
• Faça alterações, teste, lançamento fora de banda

Cenário: Corrigir rapidamente o incidente de segurança

• Notificação de um problema
• Avaliar a amplitude dos problemas (quais sistemas)
• Entender se os clientes são diretamente impactados
• Crie um ambiente de área restrita que espelhe o prod (se diferente)
• Faça alterações, teste, lançamento fora da banda
• Comunique-se com qualquer pessoa afetada

Cenário: Ferramenta em descontinuação

• Compreender o uso da ferramenta
• Notificar os usuários sobre a descontinuação
• (Opcional) Coordenar a migração de usuários para uma nova ferramenta

Cenário: Implantação do novo modelo de arquitetura de aplicativo

• Arquitetura piloto proposta
• Ajuste com base nos resultados do piloto
• Atualizar a documentação de práticas recomendadas
• Crie modelos, atualize a automação, as políticas e a governança

Auditar a conformidade do aplicativo (GDPR, acessibilidade, padrões de infraestrutura)

• Compreender as regras de conformidade atuais
• Verificar se o aplicativo atende às regras
• Estabeleça prazo para correções de desvios
• Fazer alterações, testar, liberar

Muitos cenários se aplicam a mais de uma função. Pense em métricas para medir a melhoria.

Dos problemas aos conceitos

Em seguida, entenda os maiores problemas que seus desenvolvedores e outras funções enfrentam com os cenários e trabalhos identificados. Pode ser tentador começar a investigar novos produtos para preencher lacunas percebidas, mas se esses produtos não resolverem um grande ponto problemático, é improvável que sejam adotados ou apreciados.

Existem várias abordagens que podem ajudá-lo a fazer esse tipo de investigação, como o Quadro de Progressão de Hipóteses. Mesmo que você não use um processo formalizado como o Hypothesis Progression Framework, você deve entrevistar desenvolvedores sobre um trabalho a ser feito para definir o escopo da discussão e, em seguida, identificar seus maiores problemas na realização de seu trabalho. Uma vez que você tenha uma boa noção de quais são esses problemas, passe a criar planos para resolvê-los. Isso ajuda a garantir que você crie recursos que os desenvolvedores desejam usar.

Para poder repetir rapidamente esse processo, identifique alguém que possa representar a voz do cliente diretamente na sua equipe interna da plataforma de desenvolvedores. Essa função é normalmente chamada de gerente de produto (mesmo que eles tenham um cargo diferente) e, à medida que seu conhecimento cresce, eles são capazes de prever com precisão os resultados para decisões menores e determinar quando você precisa fazer mais entrevistas. Isso mantém sua agilidade enquanto garante que você esteja focado em entregar valor aos seus clientes internos.

Defenda os seus investimentos iniciais

Depois de ter um conjunto de problemas e conceitos validados, você está em uma boa posição para decidir onde investir. No entanto, considere o investimento inicial e a manutenção a longo prazo necessários ao avaliar soluções. A solução de menor esforço que pode resolver o problema tende a ser a certa para começar, mas muitas vezes é o trabalho de manutenção que, em última análise, decide se o seu investimento é bem-sucedido.

Dito de outra forma, não crie soluções que visem fases posteriores da sua jornada, a menos que você realmente precise.

Depois de identificar sua plataforma viável mais fina (TVP) (como um produto mínimo viável para sua plataforma), pilote-a com um conjunto de equipes de desenvolvimento que estão dispostas a fornecer feedback. Se sua solução piloto resolver problemas que essas equipes estão enfrentando, você não deve ter problemas para encontrar alguém interessado em se envolver.

Você deve capturar algumas métricas-chave enquanto pilota um novo recurso ou alterações para que possa medir se o conceito foi bem-sucedido antes de implementá-lo.

Meça o sucesso e comprove o valor

Medir o seu sucesso é uma parte importante da mentalidade de um produto. Mesmo pequenos sucessos com investimentos modestos podem lançar as bases para investimentos maiores.

Por exemplo, pode ser difícil garantir financiamento ou adesão para os esforços de conformidade, porque eles podem ser percebidos como um imposto operacional para as equipes de desenvolvimento que estão entregando valor comercial. Uma mentalidade de produto pode mudar essa perceção. Com uma mentalidade de produto, você está tentando garantir que os clientes da sua plataforma de desenvolvedor interno estejam felizes e que os objetivos de negócios das partes interessadas sejam atingidos. As métricas colocam você em posição de usar fatos para provar que você está fornecendo valor comercial. Definir OKRs pode ajudar, especialmente se você tiver métricas que possa usar para ajudar a remover vieses subjetivos. Mesmo que você não esteja medindo nada aplicável hoje, você pode definir um OKR de aprendizagem para definir uma linha de base que será refinada depois que essa linha de base for conhecida.

A seguir estão exemplos de métricas bem conhecidas que você pode medir para determinar se as equipes com as quais você está trabalhando estão obtendo valor do que você está construindo. Concentre-se naqueles que ajudam você a medir se você e os clientes da sua equipe de desenvolvimento estão atingindo suas metas. Por exemplo, a seguir está um conjunto de métricas que ajudam você a avaliar se sua plataforma está contribuindo para uma organização de engenharia eficaz:

• Velocidade/tempo até ao valor comercial: Dias medianos para concluir a primeira solicitação de pull (integração inicial), minutos medianos para os processos de compilação e teste (exemplo: CI), tempo mediano para mesclar solicitações de pull.
• Qualidade de software: Incidentes (problemas) criados por mês por dev (contagem normalizada para o número de devs), tempo médio de recuperação (MTTR), tempo médio para investigar e remediar problemas de segurança.
• Facilidade de utilização da plataforma: Satisfação líquida do utilizador (NSAT)
• Ecossistema próspero: Pontuação média para cada uma das seguintes perguntas pesquisadas: "Estou capacitado para fazer meu melhor trabalho", "na maioria dos dias estou energizado pelo trabalho que faço", "o trabalho que faço é significativo para mim".

Em seguida, você pode dividir essas métricas por organização, equipe ou projeto. Você precisa medir algumas linhas de base para começar, mas pode observar essas métricas mudarem à medida que você melhora sua plataforma.

Outras métricas que você ou seus patrocinadores podem estar interessados em medir incluem:

Coletar métricas requer tempo e esforço, por isso é importante se concentrar em métricas críticas para os objetivos principais que você identificou, particularmente aqueles que alimentam seus OKRs. Produtos baseados em OpenTelemetry, como o Application Insights, podem ajudar.

Certifique-se de medir a facilidade de uso da plataforma e pesquisar se você tem um ecossistema próspero regularmente. Essas métricas muitas vezes são perdidas para os sistemas internos e são um indicador importante para saber se você atinge suas metas de negócios mais amplas, uma vez que a participação engajada é fundamental para o sucesso. Ele também ajuda você a saber se é hora de fazer mais desenvolvimento do cliente para entender onde ir em seguida.

Outras dicas

Independentemente de como você começa, tenha em mente que você deve planejar a mudança, começar com novos aplicativos para pilotos, concentrar-se em melhorar as experiências de usuário existentes, adotar o princípio do menor privilégio, planejar a experimentação controlada e minimizar a personalização.

Plano de alteração

Sua plataforma de aplicativo de destino evoluirá com o tempo, e talvez você não consiga migrar todos os seus investimentos existentes de uma só vez. Pense em como você pode suportar mais de uma variação ao longo do tempo e planeje a mudança.

Valide ideias com aplicações mais recentes

Comece com novos aplicativos de tamanho razoável quando estiver testando sua nova plataforma ou recursos de plataforma. Isso também lhe dá experiência no gerenciamento de sua plataforma como um produto. Evite projetos de replataforma para começar, uma vez que você aprende à medida que avança, e grandes aplicativos existentes geralmente têm necessidades exclusivas que só são descobertas durante o esforço de replataforma em si. Por isso, associar o seu sucesso a esses tipos de esforços pode resultar em desalinhamento de expectativas ou problemas de última hora. Começar com algo mais novo pode dar-lhe confiança na sua direção e no valor que ela proporciona. Isso reduz o risco de fazer face a estes esforços maiores. Dito de outra forma, se tiveres confiança de que as pessoas podem começar de forma certeira e continuar no caminho certo, então torna-se mais fácil conduzir uma campanha para acertar com o que aprendes com a experiência. Se essa abordagem não for possível, você quer fazer uma análise cuidadosa, definir expectativas e intervir incrementalmente, em vez de tentar mudar tudo de uma vez.

Concentre-se nos centros de gravidade existentes para experiências do usuário antes de criar novos centros

Os desenvolvedores são mais propensos a adotar e manter novos recursos quando eles são apresentados em algo que já gostam e usam. Ao avaliar conceitos para fornecer novos recursos, certifique-se de investigar as opções que levam a estender os centros de gravidade existentes. Por exemplo, editores/IDEs (Visual Studio, VS Code), pacotes de DevOps (GitHub, Azure DevOps), CLIs existentes ou um portal interno existente podem ser mais eficazes do que um portal totalmente novo ou outra UX. Para saber mais, consulte Experiências do usuário.

Assuma o princípio do menor privilégio

Suponha que os desenvolvedores tenham acesso limitado a sistemas downstream para coisas como provisionamento de infraestrutura. Você precisará de uma maneira controlada de habilitar esse acesso para experiências de autoatendimento.

Plano de experimentação controlada

Experimente antes de implementar mudanças importantes ou arriscadas. Nem tudo tem de ser totalmente automatizado para começar. Um fluxo de trabalho manual acionado automaticamente pode ser uma ótima maneira de pilotar ideias.

Minimizar a personalização da plataforma de aplicativos

Evite a criação personalizada de recursos de plataforma de aplicativos que podem ser eclipsados por recursos que os fornecedores de software lançam ao longo do tempo. Por exemplo, hospedagem em tempo de execução, malhas de serviço, sistemas de identidade e assim por diante. Se encontrar uma necessidade urgente numa área que suspeite ser assim, planeie várias opções de implementação, dado que a manutenção de longo prazo provavelmente levará a mudanças ao longo do tempo.

Conteúdo relacionado

• Aplicar sistemas de engenharia de software