Ler em inglês

Partilhar via


Planear e priorizar

Saiba como identificar objetivos para os seus esforços de engenharia de plataforma, percorrer cenários comuns e procurar formas de medir o sucesso. Pode medir o sucesso ao definir o âmbito dos seus objetivos para objetivos empresariais.

Identificar objetivos e cenários-chave

Como uma líder de engenharia de plataforma disse uma vez, "Não faço nada pela engenharia da plataforma até ter algo que possa ganhar com ele." – Peter, líder de engenharia de plataformas, Multinacional Tech Company

Em vez de olhar para uma lista de verificação de capacidades ou funcionalidades, comece por identificar os objetivos dos seus esforços de engenharia de plataforma. Pode planear e atualizar continuamente os objetivos ao longo do tempo. No entanto, ser claro sobre o que quer ganhar com o investimento na sua jornada de engenharia de plataforma pode ajudar a criar suporte organizacional.

À medida que pensa nos seus objetivos, defina-os para objetivos empresariais relacionados com o seu esforço de engenharia de plataforma, em vez das especificidades de uma determinada equipa de desenvolvimento. Por exemplo, seguem-se alguns objetivos comuns de engenharia de plataforma de alto nível:

  • Aumente a qualidade da aplicação, reduza erros e problemas durante a versão.
  • Melhorar a segurança, reduzir o número de incidentes de segurança ou CVEs detetados uma vez na produção.
  • Diminuir o risco através de uma melhor conformidade em áreas como licenciamento, acessibilidade, privacidade ou regulação governamental.
  • Acelere o valor time-to-business ao reduzir a complexidade, a sobrecarga e a promoção da partilha de código através de práticas de origem interna .
  • Reduza os custos de desenvolvimento ou operações, minimize a duplicação e melhore a automatização.

Embora todos estes objetivos possam ser objetivos a longo prazo, escolher o seu objetivo principal é fundamental, uma vez que isto motiva a forma como pensa sobre a sua atribuição de prioridades.

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

Cenários e tarefas a realizar

Depois de identificar os seus objetivos, identifique os principais cenários que irá utilizar para eliminar o registo de tarefas pendentes e o mapa de objetivos. Por exemplo, veja estes cenários e tarefas a realizar.

Cenário: começar a criar uma nova aplicação

  • Compreender e aplicar melhores práticas e políticas organizacionais
  • Criar um novo repositório
  • Ferramentas de aprovisionamento
  • Aprovisionar infraestrutura comum
  • Conceder acesso aos membros da equipa
  • Estabelecer pipelines de CI/CD
  • Aprovisionar infraestrutura de desenvolvimento
  • Implementação inicial para testar "pipes"

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

  • Atualizar o acesso a ferramentas, serviços
  • Configurar o computador do programador
  • Aumentar o membro da equipa nas aplicações
  • Criar um ambiente de sandbox de aplicação
  • Criar e rever primeiro PR

Cenário: Adicionar/atualizar a infraestrutura para a aplicação existente

  • Compreender as melhores práticas organizacionais, as opções disponíveis
  • Atualizar/adicionar infraestrutura como artefactos de código
  • Criar um ambiente de sandbox de aplicação
  • Verificar atualizações
  • Implementar alterações a outros ambientes

Cenário: Adicionar/atualizar ferramenta para a equipa existente

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

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

  • Descobrir APIs disponíveis, SDK, serviços
  • Avaliar se satisfaz as necessidades
  • Ligue-se à equipa proprietária para dúvidas
  • Adotar para a aplicação

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

  • Notificação de um problema
  • Avaliar se o código da aplicação ou a infraestrutura está relacionado (ou ambos)
  • Criar um ambiente de sandbox que espelha o prod (se diferente)
  • Fazer alterações, testar, lançamento fora de banda

Cenário: Remediar rapidamente o incidente de segurança/Aviso de Vulnerabilidades e Exposições Comuns (CVE)

  • Notificação de um problema
  • Avaliar a amplitude dos problemas (que sistemas)
  • Compreender se os clientes são diretamente afetados
  • Criar um ambiente de sandbox que espelha o prod (se diferente)
  • Fazer alterações, testar, lançamento fora de banda
  • Comunicar com qualquer pessoa afetada

Cenário: Descontinuar a ferramenta

  • Compreender a utilização de ferramentas
  • Notificar os utilizadores da preterição
  • (Opcional) Migração de Coordenação de utilizadores para nova ferramenta

Cenário: Definir/lançar um novo modelo/arquitetura de aplicações

  • Arquitetura proposta pelo piloto
  • Ajustar com base nos resultados piloto
  • Atualizar a documentação de melhores práticas
  • Criar modelos, atualizar automatização, políticas, governação

Auditar a conformidade das aplicações (RGPD, acessibilidade, normas de infraestrutura)

  • Compreender as regras de conformidade atuais
  • Verificar se a aplicação cumpre as regras
  • Estabelecer prazo para correções de desvios
  • Efetuar alterações, testar, lançar

Muitos cenários aplicam-se a mais do que uma função, pelo que também vai querer pensar nas métricas para saber o quanto os seus cenários melhoram.

De problemas a conceitos

Em seguida, recomendamos que procure compreender os maiores problemas que os seus programadores e outras funções enfrentam com os cenários e trabalhos que identificou. Pode ser tentador começar a investigar novos produtos para preencher lacunas percebidas, mas se estes produtos não resolverem um grande ponto de dor, é improvável que sejam adoptados ou apreciados.

Existem várias abordagens que podem ajudá-lo a realizar este tipo de investigação. Uma delas é a Arquitetura de Progressão de Hipóteses. Mesmo que não utilize um processo formalizado como o Framework de Progressão de Hipóteses, pode ganhar muito ao entrevistar programadores sobre um trabalho a ser feito para analisar o debate e, em seguida, identificar os seus maiores problemas na realização do seu trabalho. Assim que tiver uma boa noção do que são estes problemas, pode avançar para a criação de conceitos para resolvê-los. Isto ajuda a garantir que irá criar funcionalidades que os programadores pretendem utilizar.

Para poder repetir rapidamente este processo, deverá identificar alguém que possa representar a voz do cliente diretamente na sua equipa interna da plataforma de programadores. Normalmente, esta função é denominada gestor de produtos (mesmo que tenham um cargo diferente) e, à medida que os seus conhecimentos aumentam, poderão prever com precisão os resultados para decisões mais pequenas e determinar quando precisa de fazer mais entrevistas. Isto mantém a agilidade ao mesmo tempo que garante que está focado em fornecer valor aos seus clientes internos.

Defender os seus investimentos iniciais

Assim que tiver um conjunto de problemas e conceitos validados, estará em boa posição para fazer um argumento para investir. No entanto, tenha em atenção o nível de investimento inicial e de manutenção a longo prazo necessário. A solução de esforço mais baixa que pode resolver o problema tende a ser a mais adequada 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 do seu percurso, a menos que realmente precise.

Depois de identificar a sua plataforma mais fina e viável (TVP) ( um MVP para a sua plataforma), pode pilotá-la com um conjunto de equipas de desenvolvimento que estão dispostas a fornecer feedback. Se a sua solução piloto resolver problemas que estas equipas estão a enfrentar, não deve ter problemas em encontrar alguém interessado em envolver-se.

Deve capturar algumas métricas-chave à medida que pilota uma nova capacidade ou alterações para que possa medir se o conceito foi bem-sucedido antes de o implementar.

Medir o sucesso e o valor de prova

Independentemente de estar a fazer o seu primeiro investimento ou não, medir o seu sucesso é uma parte importante de uma mentalidade de produto. Não só o ajuda a saber se alcançou os seus objetivos, como mesmo pequenos sucessos com investimentos modestos podem lançar as bases para investimentos maiores para construir.

Por exemplo, pode ser difícil garantir o financiamento ou a entrada para os esforços de conformidade, uma vez que podem ser vistos como um imposto operacional para as equipas de desenvolvimento que estão a fornecer valor comercial. Uma mentalidade de produto pode mudar essa percepção. Com uma mentalidade de produto, está a tentar garantir que os clientes da sua plataforma de programadores internos estão satisfeitos e que os objetivos empresariais dos intervenientes são cumpridos. As métricas colocam-no em posição de utilizar factos para provar que está a fornecer valor comercial. Definir OKRs pode ajudar, especialmente se tiver métricas que pode utilizar para ajudar a remover o preconceito subjetivo. Mesmo que não esteja a medir nada aplicável hoje, pode definir um OKR de aprendizagem para definir uma linha de base que irá refinar depois de esta linha de base ser conhecida.

Seguem-se exemplos de métricas conhecidas que pode medir para determinar se as equipas com quem está a trabalhar estão a obter valor do que está a criar. Zero nas pessoas que o ajudam a medir se você, e os seus clientes da equipa de desenvolvimento, estão a atingir os seus objetivos. Por exemplo, o seguinte é um conjunto de métricas que o ajudam a avaliar se a sua plataforma está a contribuir para uma organização de engenharia eficaz:

  • Velocidade/tempo para o valor comercial: Dias medianos para concluir o primeiro pedido Pull (inclusão), minutos medianos para processos de compilação e teste (por exemplo: CI), tempo mediano para intercalar o pedido Pull.
  • Qualidade do software: incidentes (problemas) criados por mês por dev(contagem normalizada para o número de devs), tempo médio para remediar (MTTR), tempo médio para investigar e remediar o problema 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 inquiridas: "Estou capacitado para fazer o meu melhor trabalho", "a maioria dos dias sou energizado pelo trabalho que faço", "o trabalho que faço é significativo para mim."

Em seguida, pode dividir estas métricas por organização, equipa ou projeto. Para começar, terá de medir algumas linhas de base, mas pode, em seguida, watch estas métricas forem alteradas à medida que melhora a plataforma.

Outras métricas que o utilizador ou os seus patrocinadores poderão estar interessados em medir incluem:

Área Métricas de exemplo
Desempenho da entrega de software DevOps Research and Assessment (DORA): Alterar o tempo de execução, a frequência de implementação, a taxa de falha de alteração, o tempo para restaurar o serviço (MTTR)
Operações DORA (MTTR), tempo médio entre falha (MTBF), tempo médio a reconhecer, disponibilidade do cliente final, latência, métricas de débito, custo por equipa, custo por implementação
Métricas de adoção da capacidade da plataforma Número de equipas ou programadores que utilizam uma ferramenta ou funcionalidade ao longo do tempo, percentagem de repositórios com a plataforma, modelos, pipelines, etc. mais populares.

Recolher métricas requer tempo e esforço, pelo que é importante concentrarmo-nos em métricas críticas para os objetivos principais que identificou, especialmente aqueles que alimentam as suas OKRs. Os produtos baseados em OpenTelemetry, como o Application Insights, podem ajudar. Independentemente disso, certifique-se de que mede a facilidade de utilização e o levantamento da plataforma de que tem regularmente um ecossistema próspero. Estas métricas são muitas vezes perdidas para sistemas internos e são um indicador principal sobre se irá cumprir os seus objetivos empresariais mais amplos, uma vez que a participação envolvida é fundamental para o sucesso. Também o ajuda a saber se está na altura de continuar a desenvolver o cliente para saber para onde ir a seguir.

Outras sugestões

Independentemente de como começar, tenha em atenção as seguintes diretrizes.

Planear a alteração

A plataforma de aplicações de destino irá evoluir ao longo do tempo e poderá não conseguir migrar todos os seus investimentos existentes de uma só vez. É provável que queira pensar em como pode suportar mais do que uma variação ao longo do tempo e planear a alteração.

Validar ideias com aplicações mais recentes

Geralmente, é melhor começar com novas aplicações com um tamanho razoável quando estiver a testar as suas novas capacidades de plataforma ou plataforma. Isto também lhe dará experiência na gestão da sua plataforma como um produto. Afaste-se da reinscrição de projetos para começar, uma vez que aprenderá à medida que avança, e as grandes aplicações existentes têm muitas vezes necessidades únicas que só são descobertas durante o esforço de replataformação propriamente dito. Por isso, acoplar o seu sucesso a este tipo de esforços pode resultar em incompatibilidades de expectativas ou problemas de quebras tardios. Começar com algo mais recente pode dar-lhe confiança na sua direção do valor que fornece. Isso reduz o risco de enfrentar estes esforços maiores. Dito de outra forma, se estiveres confiante que as pessoas podem começar bem e manter-te à direita, então torna-se mais fácil conduzir uma campanha certa com o que aprendes com a experiência. Se esta abordagem não for possível, vai querer fazer uma análise cuidadosa, definir expectativas e avançar incrementalmente em vez de tentar mudar tudo de uma só vez.

Foco nos centros de gravidade existentes para experiências dos utilizadores antes de criar novos

Os programadores são mais propensos a adotar e manter novas capacidades quando são apresentados em algo que já gostam e utilizam. À medida que está a avaliar conceitos para fornecer novas capacidades, certifique-se de que investiga as opções que assumem "centros de gravidade" existentes. Por exemplo, editores/IDEs (Visual Studio, VS Code), conjuntos de aplicações DevOps (GitHub, Azure DevOps), CLIs existentes ou um portal interno existente podem ser mais eficazes do que um portal totalmente novo ou outro UX. Veja experiências de utilizador para saber mais.

Assumir o princípio do menor privilégio

Suponha que os programadores têm acesso limitado a sistemas a jusante para aspetos como a infraestrutura de aprovisionamento. Precisará de uma forma controlada de ativar este acesso para experiências self-service.

Planear a experimentação controlada

Experimente antes de implementar alterações importantes ou arriscadas. Nem tudo tem de ser totalmente automatizado para começar. Um fluxo de trabalho manual acionado automaticamente pode ser uma excelente forma de testar ideias.

Minimizar a personalização da Plataforma de Aplicações

Tente evitar a criação personalizada de capacidades da plataforma de aplicações que possam ser eclipsadas pela versão de fornecedores de software de capacidades ao longo do tempo. Por exemplo, alojamento em runtime, malhas de serviço, sistemas de identidade, etc. Se encontrar uma necessidade urgente numa área que suspeita ser semelhante a esta, planeie várias opções de implementação dada a manutenção a longo prazo provavelmente fará com que mude ao longo do tempo.