Planejar e priorizar

Saiba como identificar metas para seus esforços de engenharia de plataforma, percorrer cenários comuns e procurar maneiras de medir o sucesso. Você pode medir o sucesso fazendo o escopo de suas metas para os objetivos de negócios.

Identificar metas e cenários-chave

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

Em vez de examinar uma lista de verificação rote de recursos ou funcionalidades, comece identificando as metas dos esforços de engenharia da plataforma. Você pode planejar e atualizar continuamente as metas ao longo do tempo. No entanto, ser claro sobre o que você deseja ganhar com o investimento em sua jornada de engenharia de plataforma pode ajudar a criar suporte organizacional.

À medida que você está pensando em seus objetivos, o escopo deles 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. Por exemplo, aqui estão algumas metas comuns de engenharia de plataforma de alto nível:

• Aumente a qualidade do aplicativo, reduza bugs e problemas durante a versão.
• Melhore a segurança, reduza o número de incidentes de segurança ou detecte CVEs uma vez 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 de tempo para negócios reduzindo a complexidade, a sobrecarga e promovendo o compartilhamento de código por meio de práticas internas de origem .
• Reduza os custos de desenvolvimento ou operações, minimize a duplicação e melhore a automação.

Embora todos esses objetivos possam ser metas de longo prazo, escolher sua meta principal é fundamental, pois isso impulsiona a forma como você pensa sobre sua priorização.

Melhor ainda, concordar com objetivos e OKRs (resultados-chave) com sua liderança e parceiros internos pode ajudá-lo 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, identifique os principais cenários que você usará para expulsar a lista de pendências e o roteiro. Por exemplo, consulte esses cenários e trabalhos 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 repositório
• Provisionar ferramentas
• Provisionar infraestrutura comum
• Conceder acesso aos membros da equipe
• Estabelecer pipelines de CI/CD
• Provisionar infraestrutura de desenvolvimento
• Implantação inicial para testar "pipes"

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

• Atualizar o acesso a ferramentas, serviços
• Configurar o computador do desenvolvedor
• Aumentar o membro da equipe em aplicativos
• Criar ambiente de área restrita do aplicativo
• Criar e examinar a primeira PR

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

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

Cenário: adicionar/atualizar ferramenta para a equipe existente

• Entender as práticas recomendadas organizacionais, as opções disponíveis
• Solicitar o uso da 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/reutilizar a API, o SDK ou o serviço existentes

• Descobrir APIs disponíveis, SDK, serviços
• Avaliar se ele atende às necessidades
• Conecte-se com a equipe proprietária para perguntas
• Adotar para o aplicativo

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

• Notificação de um problema
• Avaliar se o código do aplicativo ou infra relacionado (ou ambos)
• Criar ambiente de área restrita que espelha prod (se diferente)
• Fazer alterações, testar, liberar fora de banda

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

• Notificação de um problema
• Avaliar a amplitude dos problemas (quais sistemas)
• Entender se os clientes são diretamente afetados
• Criar ambiente de área restrita que espelha prod (se diferente)
• Fazer alterações, testar, liberar fora de banda
• Comunicar-se com qualquer pessoa afetada

Cenário: descontinuar ferramenta

• Entender o uso da ferramenta
• Notificar os usuários sobre a substituição
• (Opcional) Migração de coordenação de usuários para a nova ferramenta

Cenário: Definir/distribuir novo modelo/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, governança

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

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

Muitos cenários se aplicam a mais de uma função, portanto, você também vai querer pensar sobre as métricas de como você entenderá o quanto seus cenários melhoram.

De problemas a conceitos

Em seguida, recomendamos buscar 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 lacunas percebidas, mas se esses produtos não resolve 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. Uma delas é a Estrutura de Progressão de Hipótese. Mesmo que você não use um processo formalizado como o Framework de Progressão de Hipótese, poderá ganhar muito entrevistando 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, você pode passar a criar conceitos para resolvê-los. Isso ajuda a garantir que você crie recursos que os desenvolvedores desejam usar.

Para poder repetir rapidamente esse processo, você desejará identificar 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 poderão prever com precisão os resultados para decisões menores e determinar quando você precisa fazer mais entrevistas. Isso mantém sua agilidade ativa enquanto ainda garante que você esteja focado em fornecer valor aos seus clientes internos.

Faça o caso de seus investimentos iniciais

Depois de ter um conjunto de problemas e conceitos validados, você estará em uma boa posição para fazer um argumento para investir. No entanto, tenha em mente o nível de investimento antecipado e a manutenção de longo prazo necessárias. 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 que se destinem a estágios posteriores da sua jornada, a menos que você realmente precise.

Depois de identificar sua TVP (plataforma viável) mais fina ( um MVP para sua plataforma), você poderá pilotá-la com um conjunto de equipes de desenvolvimento que estão dispostas a fornecer comentários. 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 ao testar uma nova funcionalidade ou alterações para que possa medir se o conceito foi bem-sucedido antes de implantá-lo.

Medir o sucesso e o valor de prova

Independentemente de você estar fazendo seu primeiro investimento ou não, medir o quão bem-sucedido você é é uma parte importante de uma mentalidade de produto. Isso não só ajuda você a saber se você atingiu suas metas, mas mesmo pequenos sucessos com investimentos modestos podem estabelecer as bases para investimentos maiores para construir.

Por exemplo, pode ser difícil garantir financiamento ou compra para esforços de conformidade porque eles podem ser percebidos como um imposto operacional para equipes de desenvolvimento que estão fornecendo 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 de desenvolvedor interna 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 aprendizagem 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. Zero em relação àqueles que ajudam você a medir se você e seus clientes da 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: dias medianos para concluir a primeira solicitação de pull (integração), minutos medianos para processos de build e teste (exemplo: CI), tempo médio para mesclar solicitação de pull.
• Qualidade do software: incidentes (problemas) criados por mês por desenvolvimento (contagem normalizada para número de devs), tempo médio para correção (MTTR), tempo médio para investigar e corrigir o problema de segurança.
• Facilidade de uso da plataforma: NSAT (satisfação do usuário líquido)
• 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. Para começar, você precisará medir algumas linhas de base, mas poderá watch essas métricas mudar à medida que melhorar 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	DevOps Research and Assessment (DORA): alterar o tempo de entrega, 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 falha (MTBF), tempo médio para reconhecer, 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 da funcionalidade da plataforma	Número de equipes ou desenvolvedores que usam uma ferramenta ou recurso ao longo do tempo, percentual de repositórios usando a plataforma, modelos mais populares, pipelines etc.

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. Independentemente disso, certifique-se de medir a facilidade de uso e a pesquisa da plataforma de que você tem um ecossistema próspero regularmente. Essas métricas geralmente são perdidas para sistemas internos e são um indicador importante sobre se você cumprirá 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 as diretrizes a seguir.

Planejar a 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 de uma só vez. Você provavelmente desejará pensar 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

Geralmente, é melhor começar com novos aplicativos de um tamanho razoável quando você está pilotando suas novas funcionalidades de plataforma ou plataforma. Isso também lhe dará experiência para gerenciar sua plataforma como um produto. Afaste-se dos projetos de nova plataforma para começar, pois você aprenderá à medida que avança, e grandes aplicativos existentes geralmente têm necessidades exclusivas que só são descobertas durante o esforço de replacação em si. Por isso, acoplar seu sucesso a esses tipos de esforços pode resultar em incompatibilidades de expectativas ou problemas de interrupção tardia. Começar com algo mais recente pode lhe dar confiança em sua direção o 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 direito e ficar certos, então torna-se mais fácil conduzir uma campanha get right com o que você aprende com a experiência. Se essa abordagem não for possível, você desejará fazer uma análise cuidadosa, definir expectativas e intervir incrementalmente em vez de tentar alterar 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. Enquanto você está avaliando conceitos para fornecer novas funcionalidades, 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 de DevOps (GitHub, Azure DevOps), CLIs existentes ou um portal interno existente podem ser mais eficazes do que um portal totalmente novo ou outro UX. Confira experiências do usuário para saber mais.

Assumir o princípio de privilégios mínimos

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

Planejar a 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 disparado automaticamente pode ser uma ótima maneira de testar ideias.

Minimizar a personalização da Plataforma de Aplicativo

Tente evitar a criação personalizada de recursos da plataforma de aplicativos que podem ser eclipsados por recursos que os fornecedores de software lançam ao longo do tempo. Por exemplo, hospedagem de runtime, malhas de serviço, sistemas de identidade e assim por diante. Se você encontrar uma necessidade urgente em uma área suspeita que possa ser assim, planeje várias opções de implementação, dado que a manutenção de longo prazo provavelmente fará com que você mude ao longo do tempo.

Aplicar sistemas de engenharia de software