Planejar 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 definindo o escopo de suas metas para os objetivos de negócios.
Identifique metas e cenários-chave
Para começar, primeiro avalie onde sua organização está hoje com o Modelo de Capacidade de Engenharia de Plataforma. Use o modelo para traçar onde sua organização está em seis recursos principais 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 alguns recursos do que em outros. Depois de saber onde sua organização está hoje, você pode escolher quais recursos deseja desenvolver. Para saber mais, confira como usar o modelo.
Você pode planejar e atualizar continuamente suas metas de engenharia de plataforma ao longo do tempo. Ser claro sobre o que você deseja ganhar ao investir em sua jornada de engenharia de plataforma pode ajudar muito a criar suporte organizacional.
Como um líder de engenharia de plataforma disse uma vez: "Eu não faço algo para 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, defina 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. Os objetivos comuns de engenharia de plataforma de alto nível incluem:
- Aumente a qualidade do aplicativo, reduza bugs e problemas durante o lançamento.
- Melhore a segurança, reduza o número de incidentes de segurança ou detecte vulnerabilidades e exposições comuns (CVEs) quando estiver em produção.
- Diminua o risco por meio de uma melhor conformidade em áreas como licenciamento, acessibilidade, privacidade ou regulamentação governamental.
- Acelere o valor do tempo de negócios reduzindo a complexidade, a sobrecarga e promovendo o compartilhamento de código por meio de práticas de origem interna.
- Reduza os custos de desenvolvimento ou operações, minimize a duplicação e melhore a automação.
Escolher seu principal objetivo é fundamental, pois seu objetivo determina como você pensa sobre sua priorização.
Melhor ainda, concordar com objetivos e resultados-chave (OKRs) com sua liderança e parceiros internos leva ao estabelecimento de 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, pois remove a subjetividade.
Cenários e trabalhos a serem feitos
Depois de identificar seus objetivos, escolha os principais cenários para eliminar sua lista de pendências e roteiro. Por exemplo, veja esses cenários e os trabalhos associados a serem feitos.
Cenário: Iniciar a criação de um novo aplicativo
- Compreender e aplicar as melhores práticas e políticas organizacionais
- Criar um repositório
- Ferramentas de provisionamento
- Provisionar infraestrutura comum
- Dê acesso aos membros da equipe
- Estabelecer pipelines de CI/CD
- Infraestrutura de desenvolvimento de provisões
- Implantação inicial para testar "pipes"
Cenário: Adicionar ou remover um novo membro de uma equipe existente
- Atualizar o acesso a ferramentas e serviços
- Configurar a máquina do desenvolvedor
- Aumente o membro da equipe nas inscrições
- Criar ambiente de sandbox de aplicativo
- Criar e revisar a primeira PR
Cenário: Adicionar ou atualizar a infraestrutura para o aplicativo existente
- Entenda as melhores práticas organizacionais, opções disponíveis
- Atualizar/adicionar infraestrutura como artefatos de código
- Criar ambiente de sandbox de aplicativo
- Verificar atualizações
- Implementar alterações em outros ambientes
Cenário: Adicionar ou atualizar ferramenta para equipe existente
- Entenda as melhores práticas organizacionais, opções disponíveis
- Solicite o uso da 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, serviços disponíveis
- Avalie se atende às necessidades
- Conecte-se com a equipe proprietária para qualquer dúvida
- Adote para aplicação
Cenário: Responder a um incidente de operações
- Notificação de um problema
- Avalie se o código do aplicativo ou a infraestrutura estão relacionados (ou ambos)
- Crie um ambiente de sandbox que espelhe o produto (se diferente)
- Faça alterações, teste, liberação fora de banda
Cenário: Corrigir rapidamente o incidente de segurança
- Notificação de um problema
- Avaliar a amplitude dos problemas (quais sistemas)
- Entenda se os clientes são diretamente afetados
- Crie um ambiente de sandbox que espelhe o produto (se diferente)
- Faça alterações, teste, liberação fora de banda
- Comunique-se com qualquer pessoa afetada
Cenário: Ferramenta de descontinuação
- Entenda o uso da ferramenta
- Notificar os usuários sobre a substituição
- (Opcional) Coordenação da migração de usuários para nova ferramenta
Cenário: Distribuição de um novo modelo de aplicativo de arquitetura
- Arquitetura proposta piloto
- Ajuste com base nos resultados do piloto
- Atualizar a documentação de práticas recomendadas
- Criar modelos, atualizar automação, políticas, governança
Auditar a conformidade do aplicativo (GDPR, acessibilidade, padrões de infraestrutura)
- Entenda as regras de conformidade atuais
- Verifique se o aplicativo atende às regras
- Estabeleça prazo para correções de desvios
- Faça alterações, teste, libere
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, procure entender os maiores problemas que seus desenvolvedores e outras funções enfrentam com os cenários e trabalhos que você identificou. Pode ser tentador começar a investigar novos produtos para preencher as 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. Um deles é a Estrutura de Progressão de Hipóteses. Mesmo que você não use um processo formalizado como o Hypothesis Progression 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 de quais são esses problemas, passe a elaborar 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 de decisões menores e determinar quando você precisa fazer mais entrevistas. Isso mantém sua agilidade alta e, ao mesmo tempo, garante que você esteja focado em agregar valor aos seus clientes internos.
Defenda 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 de longo prazo necessários ao avaliar as 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 decide se o seu investimento é bem-sucedido.
Dito de outra forma, não crie soluções que visem estágios posteriores de sua jornada, a menos que você realmente precise.
Depois de identificar sua plataforma viável mais fina (TVP) (um MVP para sua plataforma), pilote-a com um conjunto de equipes de desenvolvimento dispostas a fornecer feedback. Se sua solução piloto resolver problemas que essas equipes estão enfrentando, você não deverá ter problemas para encontrar alguém interessado em se envolver.
Você deve capturar algumas métricas importantes ao pilotar um novo recurso ou alterações para poder 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 esforços de conformidade porque eles podem ser percebidos como um imposto operacional para equipes de desenvolvimento que estão agregando valor comercial. Uma mentalidade de produto pode mudar essa percepção. Com uma mentalidade de produto, você está tentando garantir que os clientes de sua plataforma interna de desenvolvedor estejam satisfeitos e que as metas de negócios das partes interessadas sejam atendidas. As métricas colocam você em posição de usar fatos para provar que está fornecendo valor comercial. Definir OKRs pode ajudar, principalmente se você tiver métricas que possa 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á construindo. Concentre-se naqueles que ajudam a medir se você e os clientes de sua equipe de desenvolvimento estão atingindo seus objetivos. 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 para o valor comercial: mediana de dias para concluir a primeira solicitação de pull (integração), mediana de minutos para processos de build e teste (exemplo: CI), mediana
- Qualidade do software: incidentes (problemas) criados por mês por desenvolvedor (contagem normalizada para o número de desenvolvedores), tempo médio de correção (MTTR), tempo médio para investigar e corrigir o problema de segurança.
- Facilidade de uso da plataforma: Satisfação líquida do usuário (NSAT)
- Ecossistema próspero: Pontuação média para cada uma das seguintes perguntas pesquisadas: "Tenho o poder de fazer o 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. Para começar, você precisa medir algumas linhas de base, mas pode observar essas métricas mudarem à medida que melhora sua plataforma.
Outras métricas que você ou seus patrocinadores podem estar interessados em medir incluem:
| Área | Métricas de exemplo |
|---|---|
| Desempenho de entrega de software | Pesquisa e avaliação de DevOps (DORA): alterar o tempo de espera, a frequência de implantação, a taxa de falha de alteração, o tempo de restauração do serviço (MTTR) |
| Operações | DORA (MTTR), tempo médio entre falhas (MTBF), tempo médio de confirmação, disponibilidade do cliente final, latência, métricas de taxa de transferência, custo por equipe, custo por implantação |
| Métricas de adoção de recursos da plataforma | Número de equipes ou desenvolvedores usando uma ferramenta ou recurso ao longo do tempo, porcentagem de repositórios usando a plataforma, modelos mais populares, pipelines, etc. |
A coleta de métricas requer tempo e esforço, por isso é importante se concentrar em métricas críticas para os objetivos principais que você identificou – especialmente aqueles que alimentam seus OKRs. Os produtos baseados em OpenTelemetry , como o Application Insights , podem ajudar. Independentemente disso, certifique-se de medir a facilidade de uso da plataforma e pesquisar se você tem um ecossistema próspero regularmente. Essas métricas geralmente são perdidas para sistemas internos e são um indicador importante para saber se você atinge suas metas de negócios mais amplas, pois a participação engajada é fundamental para o sucesso. Também ajuda você a saber se é hora de fazer mais desenvolvimento do cliente para entender para onde ir em seguida.
Outras dicas
Independentemente de como você começa, lembre-se de que você deve planejar a mudança, começar com novos aplicativos para pilotos, concentrar-se em aprimorar as experiências de usuário existentes, adotar o princípio do privilégio mínimo, planejar a experimentação controlada e minimizar a personalização.
Plano para 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 aplicativos mais recentes
Comece com novos aplicativos de tamanho razoável quando estiver pilotando sua nova plataforma ou recursos de plataforma. Isso também lhe dará experiência no gerenciamento de sua plataforma como um produto. Evite começar os projetos de replataforma, pois você aprende à medida que avança, e grandes aplicativos existentes geralmente têm necessidades exclusivas que só são descobertas durante o próprio esforço de replataforma. Por causa disso, acoplar seu sucesso a esses tipos de esforços pode resultar em incompatibilidades de expectativa ou problemas de última hora. Começar com algo mais novo pode dar a você confiança em sua direção do valor que ela oferece. 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 permanecer certas, fica mais fácil conduzir uma campanha de acerto com o que você aprende com a experiência. Se essa abordagem não for possível, você deve fazer uma análise cuidadosa, definir expectativas e intervir de forma incremental, em vez de tentar mudar tudo de uma vez.
Concentre-se nos centros de gravidade existentes para as experiências do usuário antes de criar novos
Os desenvolvedores são mais propensos a adotar e manter novos recursos quando são exibidos em algo que já gostam e usam. Ao avaliar conceitos para fornecer novos recursos, certifique-se de investigar as opções que estendem 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 experiência do usuário. Consulte as experiências do usuário para saber mais.
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.
Planejar a experimentação controlada
Experimente antes de implementar mudanças 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 pilotar ideias.
Minimizar a personalização da plataforma de aplicativos
Evite criar recursos personalizados da plataforma de aplicativos que podem ser eclipsados pelos recursos que os fornecedores de software lançam ao longo do tempo. Por exemplo, hospedagem de tempo de execução, malhas de serviço, sistemas de identidade e assim por diante. Se você encontrar uma necessidade urgente em uma área que suspeita ser assim, planeje várias opções de implementação, pois a manutenção de longo prazo provavelmente fará com que você mude com o tempo.