Planejar e priorizar

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

Identificar metas e cenários-chave

Para começar, primeiro avalie onde sua organização está hoje usando o Modelo de Funcionalidade de Engenharia de Plataforma. Use o modelo para mapear onde sua organização está em seis principais funcionalidades de engenharia de plataforma: investimento, adoção, governança, provisionamento e gerenciamento, interfaces e medição e comentários. Todas as organizações são mais avançadas em algumas funcionalidades do que em outras. Depois de saber onde sua organização está hoje, você pode escolher quais capacidades gostaria de desenvolver. Para saber mais, confira 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ê deseja ganhar investindo em sua jornada de engenharia de plataforma pode ajudar a criar suporte organizacional.

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

Ao pensar em suas metas, faça o escopo delas para objetivos de negócios relacionados ao seu esforço de engenharia de plataforma, em vez das especificidades de uma equipe de desenvolvimento específica. As metas comuns de engenharia de plataforma de alto nível incluem:

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

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

Melhor ainda, concordar com os objetivos e os principais resultados (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 terão 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, pois remove a subjetividade.

Cenários e trabalhos a serem feitos

Depois de identificar suas metas, escolha os principais cenários para desenvolver seu backlog e roadmap. Por exemplo, consulte os cenários a seguir e os trabalhos associados a serem feitos.

Cenário: começar a criar um novo aplicativo

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

Cenário: adicionar ou remover um novo membro a uma equipe existente

• Atualizar o acesso a ferramentas e serviços
• Configurar um computador desenvolvedor
• Treinar o membro da equipe para usar os aplicativos
• Criar um ambiente de área restrita do aplicativo
• Crie e revise primeiro a solicitação de pull

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

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

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

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

Cenário: localizar ou reutilizar a API, o SDK ou o serviço existentes

• Descobrir APIs, SDK ou serviços disponíveis
• Avaliar se ele atende às necessidades
• Conectar-se com a equipe proprietária para quaisquer dúvidas.
• Adotar para aplicação

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

• Notificação de um problema
• Avaliar se o código do aplicativo ou a infraestrutura é relacionada (ou ambos)
• Criar um ambiente de área restrita que espelha o prod (se diferente)
• Fazer alterações, testar, 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 afetados
• Criar um ambiente sandbox que espelha o ambiente de produção (caso seja diferente)
• Realizar alterações, testar, lançamento fora de banda
• Comunicar-se com qualquer pessoa afetada

Cenário: Descontinuar ferramenta

• Entender 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 proposta pelo piloto
• Ajustar com base nos resultados do piloto
• Atualizar documentação de práticas recomendadas
• Criar modelos, atualizar automação, políticas e governança

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

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

Muitos cenários se aplicam a mais de uma função. Pense nas métricas de como você medirá a melhoria.

De problemas a 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 de dor, é improvável que sejam adotados ou apreciados.

Há várias abordagens que podem ajudá-lo a fazer esse tipo de investigação, como a Estrutura de Progressão de Hipótese. Mesmo que você não use um processo formalizado como o Hypothesis Progress Framework, você deve entrevistar os 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. Depois de ter uma boa noção do que são esses problemas, siga em frente para 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 em sua equipe interna da plataforma de desenvolvedores. Essa função normalmente é chamada de gerente de produto (mesmo que tenha 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 em alta, garantindo que você esteja focado na entrega de valor para seus clientes internos.

Apresente os argumentos para os seus investimentos iniciais

Depois de ter um conjunto de problemas e conceitos validados, você estará em uma boa posição para decidir onde investir. No entanto, considere o investimento inicial e a manutenção de 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 seu investimento é bem-sucedido.

Dito de outra forma, não crie soluções direcionadas a estágios posteriores de sua jornada, a menos que você realmente precise.

Depois de identificar sua plataforma viável mínima (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 importantes enquanto pilota uma nova funcionalidade ou alterações para poder medir se o conceito foi bem-sucedido antes de implantá-lo.

Medir o êxito e comprovar o valor

Medir seu sucesso é uma parte importante de uma mentalidade de produto. Mesmo pequenos sucessos com investimentos modestos podem estabelecer as bases para que investimentos maiores se desenvolvam.

Por exemplo, pode ser difícil garantir o financiamento ou a adesão aos esforços de conformidade, pois eles podem ser percebidos como um imposto operacional para as equipes de desenvolvimento que estão entregando valor de negócio. Uma mentalidade de produto pode mudar essa percepção. Com uma mentalidade de produto, você está tentando garantir que os clientes de sua plataforma de desenvolvedor interno estejam felizes e que as metas de negócios dos stakeholders sejam atendidas. 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 pode usar para ajudar a remover o viés subjetivo. Mesmo que você não esteja medindo nada aplicável hoje, você pode definir um OKR de aprendizado para definir uma linha de base que você refinará depois que essa linha de base for conhecida.

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

• Velocidade/tempo para o valor comercial: mediana de dias para concluir o primeiro pull request (integração), mediana de minutos para processos de build e teste (exemplo: CI), tempo mediano para mesclar o pull request.
• Qualidade do software: incidentes (problemas) criados por mês por desenvolvimento (contagem normalizada em número de devs), mttr (tempo médio de recuperação) e tempo médio para investigar e corrigir o problema de segurança.
• Facilidade de uso da plataforma: NSAT (satisfação líquida do usuário)
• Ecossistema próspero: Pontuação média para cada uma das seguintes perguntas pesquisadas: "Estou capacitado a 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 você pode ver essas métricas mudarem à medida que aprimora sua plataforma.

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

Coletar métricas requer tempo e esforço, portanto, é importante se concentrar em métricas críticas para as principais metas que você identificou, especialmente aquelas 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 verificar regularmente que você tem um ecossistema próspero. Essas métricas geralmente são perdidas para sistemas internos e são um indicador principal sobre se você atende às 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 ao cliente para entender para onde ir a seguir.

Outras dicas

Independentemente de como você começa, tenha em mente que você deve planejar a alteração, começar com novos aplicativos para pilotos, focar no aprimoramento das experiências de usuário existentes, adotar o princípio de privilégios mínimos, planejar a experimentação controlada e minimizar a personalização.

Plano para alteração

Sua plataforma de aplicativo de destino evoluirá ao longo do tempo e talvez você não consiga migrar todos os seus investimentos existentes ao mesmo tempo. Pense em como você pode dar suporte a mais de uma variação ao longo do tempo e planejar a alteração.

Validar ideias com aplicativos mais recentes

Comece com novas aplicações de um tamanho razoável quando estiver pilotando suas novas funcionalidades ou capacidades de plataforma. Isso também oferece experiência no gerenciamento de sua plataforma como um produto. Evite iniciar projetos de replatformação, já que se aprende à medida que se avança, e grandes aplicativos existentes geralmente têm necessidades exclusivas que só são descobertas durante o próprio esforço de replatformação. Por isso, vincular seu sucesso a esses tipos de esforços pode resultar em incompatibilidades de expectativas ou problemas que surgem tardiamente. Começar com algo mais recente pode lhe dar confiança em sua direção e no valor que ele fornece. Isso reduz o risco de enfrentar esses esforços maiores. Dito de outra forma, se você está confiante de que as pessoas podem começar bem e manter-se no caminho certo, então torna-se mais fácil conduzir uma campanha certa com o que você aprende com a experiência. Se essa abordagem não for possível, você deseja 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

Os desenvolvedores são mais propensos a adotar e manter novos recursos quando eles são exibidos em algo que eles já gostam e usam. À medida que você avalia os conceitos para fornecer novos recursos, certifique-se de investigar as opções que exigem a extensão dos centros de gravidade existentes. Por exemplo, editores/IDEs (Visual Studio, VS Code), pacotes DevOps (GitHub, Azure DevOps), CLIs existentes ou um portal interno existente podem ser mais eficazes do que um portal totalmente novo ou outro UX. Para saber mais, confira as experiências do usuário.

Assumir o princípio do privilégio mínimo

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

Planejar experimentação controlada

Experimente antes de distribuir alterações importantes ou arriscadas. Nem tudo precisa ser totalmente automatizado para começar. Um fluxo de trabalho manual acionado automaticamente pode ser uma ótima maneira de testar ideias.

Minimizar a personalização da plataforma de aplicativo

Evite a criação personalizada de recursos da plataforma de aplicativos que podem ser eclipsadas por recursos que os fornecedores de software liberam ao longo do tempo. Por exemplo, hospedagem de runtime, malhas de serviço, sistemas de identidade e assim por diante. Caso você encontre uma necessidade urgente em uma área que suspeita ter essas características, planeje várias opções de implementação, considerando que a manutenção a longo prazo provavelmente exigirá mudanças ao longo do tempo.

Conteúdo relacionado

• Aplicar sistemas de engenharia de software