Construindo plataformas melhores com descoberta contínua

Toda equipe de plataforma tem uma história de guerra sobre uma ferramenta que passou meses construindo que acabou subutilizada, incompreendida ou abandonada. Não porque foi mal projetado, mas porque não se encaixava naturalmente em como os desenvolvedores de produtos funcionavam ou porque resolveu um problema que ninguém realmente tinha. Vi isso acontecer mais de uma vez. Não se trata de más intenções ou falta de rigor técnico. É que a descoberta foi ignorada. Descoberta significa entender como os engenheiros realmente funcionam – seus fluxos de trabalho, pontos problemáticos e os problemas que realmente os diminuem – antes de construir soluções. Sem ele, as equipes da plataforma acabam resolvendo problemas que parecem importantes do lado de fora, mas não correspondem à realidade do trabalho diário de desenvolvimento. E quando falta a descoberta, o trabalho da plataforma começa a cair de seu objetivo real, que deveria estar capacitando os engenheiros a implantar software de trabalho mais rápido e com confiança. É por isso que estou empolgado com algo que estamos fazendo na equipe de engenharia da plataforma em pilha com o toucting: uma prática emprestada a partir do gerenciamento de produtos chamado de descoberta contínua. risco nas decisões do produto. É uma maneira estruturada de ficar perto das pessoas que você está construindo para que você não esteja adivinhando. A idéia é tornar o processo de descoberta mais ágil e receptivo, em vez de confiar em uma fase de pesquisa pesada e pouco frequente. Em equipes de produtos, isso é uma segunda natureza. Mas no trabalho da plataforma? É menos comum. As equipes da plataforma geralmente padrão pensam na solução usando experiência anterior e heurística, não problemas de usuário. Escalamos a criação de infraestrutura confiável, automatizando processos e frete as ferramentas do DevOps. Mas nem sempre validamos se essas ferramentas resolvem problemas reais. Isso pode levar, a soluções que ficam sem uso, acumulam dívidas técnicas e eventualmente apodrecem porque nunca encontraram adoção genuína. É por isso que a descoberta contínua se tornou uma estrutura útil para nós. As equipes da plataforma atendem a desenvolvedores internos, o que nos torna ambos construtores e facilitadores. Mas os desenvolvedores internos ainda são clientes, por isso aprendemos a tratar a plataforma como um produto. E em organizações em movimento rápido, onde a inovação é constante e as interrupções são comuns, as necessidades do desenvolvedor evoluem com a mesma rapidez. Novas arquiteturas, prioridades de mudança e ferramentas emergentes mudam como é “bom”. A descoberta contínua nos ajuda a acompanhar. Ele nos permite: evitar a construção da coisa errada. Discover, problemas reais escondidos por trás de solicitações ruidosas. Faça apostas mais inteligentes com tempo e recursos limitados. Aumentação de aumento, criando ferramentas que se encaixam. Aqui está a aparência do conceito na prática na equipe de engenharia de plataforma da Stack Overflow: tratamos equipes internas como clientes, não apenas partes interessadas. Passamos tempo entendendo seu contexto antes de escrever o código. Enquanto planejamos trimestralmente, nos concentramos nos resultados e envolvemos as equipes de parceiros cedo, começando com os problemas que eles enfrentam, não apenas as soluções que eles pedem – o que Teresa Torres liga focando em oportunidades, em vez de pular direto para soluções. A partir daí, exploramos várias maneiras de resolver esses problemas, pesando trocas antes de cometermos. Isso nos ajuda a evitar o bloqueio da primeira idéia e nos dá espaço para descobrir o que é mais impactante, não apenas mais solicitado. Verificamos regularmente nossas suposições com equipes parceiras, em vez de construir isoladamente – o que Torres chama de mapeamento e teste de suposição. Há muita colaboração com equipes parceiras durante todo o processo; Eles não são apenas informados após o fato. A cultura de transparência facilita a superfície das incertezas precocemente, desafiam as suposições e a identificação de lacunas antes que elas se tornem problemas reais. Também gera confiança; portanto, quando fazemos trocas, as equipes entendem o porquê, não apenas o quê. Essa visibilidade contínua também facilita a obtenção de feedback à medida que construímos; portanto, se precisarmos girar, podemos fazê -lo com confiança e contexto. A adoção é a métrica principal, mas o atrito também – os pequenos momentos de confusão, etapas extras ou soluções alternativas que sinalizam uma ferramenta não se encaixam bastante nos fluxos de trabalho dos desenvolvedores. Procuramos sinais como: as pessoas precisam pedir ajuda para usar recursos básicos? Eles estão construindo soluções alternativas em vez de usar nossa ferramenta diretamente? Quanta troca de contexto nossa solução exige? Os usuários estão alcançando novas idéias ou apenas reclamações? Se nossa plataforma for invisível da melhor maneira (libertando o tempo e a redução do trabalho), sabemos que estamos fazendo algo certo. Uma boa plataforma parece infraestrutura – os desenvolvedores a usam sem pensar nisso, lida com a complexidade nos bastidores e torna os fluxos de trabalho existentes dos desenvolvidos mais rapidamente, em vez de exigir que eles aprendam novos. Uma plataforma não otimizada, por outro lado, se torna conhecida por atrito constante: os desenvolvedores precisam se lembrar de comandos especiais, contornar as limitações ou gastar tempo descobrindo como fazê-lo atender às suas necessidades. Alta adoção com baixos sinais de atrito, construímos algo que realmente melhora a experiência do desenvolvedor, enquanto a alta adoção com alto atrito pode significar que as pessoas são forçadas a usar uma ferramenta que não funcione para eles. Para obter clareza sobre nossa eficácia, reunimos dados; Os dados nos permitem entender o mundo. Rastreamos o número de desenvolvedores pedindo ajuda com coisas que assumimos que tínhamos resolvido e lideramos o tempo para alterações de código – eles nos falam sobre o atrito antes que se torne um problema de adoção maior. Monitoramos padrões de uso para ver se as ferramentas estão se tornando parte de fluxos de trabalho diários ou apenas necessidades ocasionais. Também prestamos atenção ao que não estamos medindo – as entrevistas de desenvolvedores nos ajudam a entender o lado qualitativo de que as métricas de uso puro podem perder. Quando esses sinais se alinham – indicadores de atrito, alto uso orgânico e feedback positivo do desenvolvedor – sabemos que atingimos a marca. Quando não o fazem, essa é a nossa sugestão para se aprofundar e iterar. A descoberta não é única. As equipes evoluem. O mesmo deve nossa compreensão de suas necessidades. O que funcionou para uma equipe há seis meses pode não se encaixar em suas prioridades atuais. Os check-ins regulares nos ajudam a permanecer alinhados com a maneira como as práticas de desenvolvimento e os pontos de morte das equipes mudam ao longo do tempo. Às vezes, o que as pessoas pedem não é o que precisam. Cavar mais fundo. Em vez de apenas aceitar solicitações de recursos pelo valor nominal, pedimos aos desenvolvedores que nos contem uma história sobre a última vez que encontraram o problema que eles querem que resolvamos-o que Torres chama de entrevistas baseadas em histórias. Isso revela o contexto real por trás da solicitação, geralmente nos mostrando que a necessidade real é diferente da pergunta inicial. A escovação rápida é ótima. O envio certo é melhor. A descoberta nos ajuda a fazer os dois. As equipes da plataforma são frequentemente julgadas por estabilidade, não por criatividade. Equilibrar a descoberta com tempo de atividade e confiabilidade exige esforço. O mesmo acontece com o ciclo de “ingressos e entrega” para explorar os problemas a montante. Mas as equipes que o administram? Eles criam plataformas que as pessoas desejam usar, não apenas precisam usar. Comece bloqueando o tempo para a descoberta em seu planejamento de sprint, medindo as métricas de adoção e atrito e, o mais importante, conversando com seus usuários periodicamente, em vez de esperar que eles venham até você com problemas. Mudanças culturais como esse levam tempo porque você não está apenas mudando o processo; Você está mudando o que as pessoas acreditam ser aceitável ou esperado. Esse tipo de mudança não acontece apenas porque a liderança diz que deveria, ou porque um gerente adiciona uma nova agenda às reuniões de planejamento. Ele permanece quando os ICs se sentem inspirados e seguros o suficiente para trabalhar de maneira diferente e quando os gerentes fazem backup com suporte e consistência. Às vezes, um campeão de suítes C ajuda a definir o tom, mas, no dia-a-dia, são os gerentes intermediários e os ICs seniores que fazem o trabalho lento e constante de normalizar novos comportamentos. Você precisa de uma prova repetida de que não há problema em fazer uma pausa e perguntar por que, para explorar, admitir incerteza. Sem essa segurança psicológica, as pessoas apenas voltam ao que sabem: entregas e prazos. A cultura não muda porque alguém diz que deveria; Ele muda quando pessoas suficientes começam a acreditar que uma maneira diferente de trabalhar não é apenas permitida, mas valorizada. Quando começamos a nos inclinar para a descoberta contínua, não foi uma iniciativa formal – começou com algumas entrevistas focadas nas equipes internas que apoiamos. Já conhecíamos nosso objetivo: ajude -os a enviar mais rápido e de maneira mais confiável. Mas precisávamos esclarecer como poderíamos realizar. Então, em vez de assumir o que nossas equipes internas precisavam, pedimos. Queríamos ter certeza de que estávamos resolvendo problemas que eles realmente tinham, não apenas aqueles que pensávamos que tínhamos. Mantivíamos isso simples – concorda, não pesquisas. Perguntamos sobre atrito, bloqueadores e soluções alternativas. Ouvimos os momentos que tornaram seu trabalho mais difícil do que precisava ser. Essas entrevistas nos ajudaram a cavar solicitações no nível da superfície e a entender as restrições reais que moldam sua experiência. Documentamos o que aprendemos e o usamos para moldar nosso roteiro. Não como uma lista de desejos, mas como um reflexo do que as equipes estavam realmente lutando. Antes de investir plenamente em qualquer solução, testamos idéias com algumas equipes. Às vezes isso significava construir um protótipo. Outras vezes, estava apenas passando por uma mudança proposta e recebendo feedback. Esse loop leve (ouça, testar, ajustar) nos deu a confiança para avançar e deu a nossas equipes parceiras a confiança de que estávamos construindo com eles, não apenas para eles. No final do dia, a engenharia da plataforma é sobre resultados, não saídas. As melhores plataformas são as que os desenvolvedores mal notam porque funcionam, se encaixam e evoluem ao lado de seus usuários. A descoberta contínua nos dá uma maneira de chegar lá, resolvendo gargalos que não são código. É uma prática que estou animada para continuar me aprofundando com minha equipe, uma conversa de cada vez.

Fonte