Planejando Projetos de Engenharia de Forma Eficaz
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Planejando um projeto juntos (MidJourney)
Resolver um problema do cliente com software é uma atividade complexa. Vai desde entender o problema até identificar possíveis soluções para melhorar a situação e então entregá-la: planejar e executar a iniciativa para criar o software.
Dentro de planejamento e execução, uma atividade que geralmente cai sob a responsabilidade dos Engineering Managers (EMs) é a quebra do trabalho. Nessa situação, quebrar significa pegar uma visão de produto como input e dividi-la em tarefas que o time (principalmente os engenheiros) possa executar.
Infelizmente, os times geralmente não dedicam atenção suficiente a essa atividade. O que é visto como uma simples tarefa de dividir o trabalho em partes menores influencia como o time trabalha, como engenheiros colaboram, como performam e, mais importante, o resultado da iniciativa. Como esperado, a falta de atenção leva a resultados abaixo do ideal.
Quebrando a Colaboração
O primeiro desafio com a ideia de engenheiros serem responsáveis pela quebra do trabalho é que pensar nisso como uma atividade exclusiva de engenharia já é um problema.
Times multifuncionais existem na entrega de software para que produto, design, engenharia (e todas as outras disciplinas que possam estar envolvidas) trabalhem juntos, não em um processo mini-waterfall. Nesse caso, planejar como o time vai executar o projeto deve envolver todas as disciplinas.
Processo mini waterfall
Isso porque essas perspectivas devem influenciar umas às outras. Por exemplo, o que um time precisa construir vai impactar como engenharia estrutura o trabalho. E as restrições de engenharia em qualquer projeto devem afetar o que será construído. Por conta disso, essa conversa não pode ser um pipeline de trabalho que vai de pesquisa para planejamento para entrega. Em vez disso, tem que ser uma série de iterações que vão de um conceito abstrato à feature concreta que vai resolvê-lo.
Resolvendo Juntos
Uma conversa de escopo melhor considera o todo, não os aspectos de produto, design e engenharia, um de cada vez. De uma visão de alto nível, o time quer resolver um problema do cliente o mais rápido possível e fazê-lo de uma forma de alta qualidade da perspectiva de todos, incluindo engenharia.
A partir daí, times de engenharia devem guiar como o trabalho é planejado e dividido. Mas devem abordá-lo do problema do cliente para baixo, e não da arquitetura planejada para cima. A pergunta principal deve ser Como podemos resolver esse problema da forma mais simples?, e não Como construímos a parte um dessa solução complexa que temos em mente? Iterativo e incremental.
Na prática, isso significa focar o time em pensar em iterações como camadas de qualidade, onde cada milestone torna a solução melhor, mas cada milestone também é uma solução completa. E isso só pode acontecer se engenheiros trabalharem com o restante do time para definir o caminho adiante.
“Quando usar desenvolvimento iterativo? Você deve usar desenvolvimento iterativo apenas em projetos que quer que tenham sucesso.” — Martin Fowler
Por exemplo, em um time que gerenciei, costumávamos ter um processo de design, pesquisa e planejamento de produto de vários meses. Um engenheiro estava envolvido nele, mas como um participante passivo, dando feedback sobre ideias apresentadas. Ao final, produto e design compartilhavam o projeto com todo o time de engenharia para ser dividido em épicos e tickets para executar. O tempo desde o início até recebermos feedback real de usuários usando a feature era frequentemente de 6+ meses.
Para reduzir o ciclo de feedback, focamos em um processo no qual todas as disciplinas planejavam juntas, com o time de engenharia envolvido como participante pleno desde o início. Como resultado, reduzimos o tempo de ciclo de ideia a produção para 1 mês, tendo o time entregando o projeto em múltiplos milestones. E isso só foi possível porque o trabalho não foi quebrado por engenharia, mas sim moldado pelo time inteiro.
Esses são conceitos familiares, e há excelente material disponível sobre como abordá-los de uma perspectiva de produto. No entanto, EMs também devem priorizar um planejamento e escopo mais colaborativos, pois:
- Reduz o risco de entrega. Focar em milestones mais curtos reduz o risco de entrega, já que o software será lançado e usado mais cedo, e quaisquer desafios imprevistos serão visíveis mais cedo no projeto.
- Proporciona melhores trade-offs de entrega. Com o time entregando múltiplos milestones curtos e completos, há um risco muito menor de um aperto na entrega, onde tudo precisa se juntar no último minuto. Qualquer pressão por atrasos também é diminuída, já que os clientes sempre terão uma solução para contornar o problema.
- Entrega tecnologia mais simples. O time naturalmente focará em uma arquitetura mais simples ao focar em iterações de qualidade, já que soluções menores requerem menos complexidade. Por causa disso, a complexidade tecnológica pode evoluir com o produto, conforme as necessidades do cliente, e não ser inserida nele desde o início da iniciativa.
- Fomenta melhor colaboração. Com todo o time colaborando no planejamento, engenheiros entenderão melhor o problema e a solução, facilitando a discussão entre disciplinas e dentro de engenharia.
Os Obstáculos Comuns
No entanto, planejamento e entrega iterativos são mais fáceis de falar do que de fazer. Há muitas objeções práticas que um EM pode encontrar ao tentar mover seu time nessa direção. Aqui estão alguns exemplos comuns que já vi no passado.
“Não é eficiente” — o ponto de atrito mais comum ao iterar no planejamento e execução (tanto no nível do projeto quanto da story) é que é ineficiente do ponto de vista de engenharia. Engenheiros frequentemente sentem que entregar em iterações levará a retrabalho, e estão certos. No entanto, EMs devem destacar que o trade-off será um projeto de menor risco do ponto de vista de engenharia e produto.
“O plano pode mudar” — Outra preocupação é que se os planos são iterativos, eles serão executados antes de serem totalmente pensados. Por exemplo, engenheiros podem ter um problema com uma decisão de produto que muda mais adiante no projeto, o que também é uma preocupação válida. Já vi PMs (ou designers) sendo criticados por times de engenharia por isso. No entanto, execução iterativa significa que a mudança se torna mais gerenciável, então focar nisso vai melhorar como o time a percebe.
“Reduz o impacto individual” — se uma empresa foca em avaliar impacto individual, engenheiros podem pensar que vão perder pontos a menos que planejem a execução do projeto sozinhos. No entanto, EMs devem garantir que o time entenda que impacto individual ainda pode ser observado em um ambiente altamente colaborativo.
“Não permite uma boa arquitetura” — como um time cria uma arquitetura sólida se constrói uma peça de cada vez? Embora haja nuances nisso, ter uma arquitetura evolutiva não significa não ter uma visão de como a arquitetura deve ser. Em vez disso, líderes técnicos devem se esforçar para guiar o time através de uma ideia arquitetural enquanto ainda a constroem iterativamente.
“Vai gerar tempo ocioso” — ter todas as disciplinas trabalhando juntas levantará preocupações de que o time de engenharia pode ficar ocioso, já que há um lead time do planejamento até ter trabalho pronto para ser executado. Como vamos alimentar a máquina? A resposta aqui é que está tudo bem se a máquina tiver um pequeno descanso. O tempo ocioso de engenharia será compensado pela eficiência da execução depois.
Abordando da Forma Certa
No final das contas, mover-se em direção a um planejamento de execução mais iterativo em software requer uma perspectiva holística e alguma convicção para ser feito com sucesso. Um desafio comum é ter times implementando um passo específico (ou seja, devemos ter milestones ou tickets menores) sem mudar como abordam o problema. Infelizmente, isso geralmente leva a resultados malsucedidos, frustração e hábitos ainda mais enraizados contra isso.
Para ter sucesso, EMs (e seus pares de produto/design) devem ter em mente o objetivo geral de resolver um problema do cliente da forma mais simples possível, guiando seu planejamento e execução a partir disso.
Mais concretamente, aqui estão alguns princípios que os times precisam ter em mente:
O foco de engenharia (junto com o restante do time) deve ser planejar uma solução, não quebrar trabalho.
Planejar a execução de software deve ser parte de uma conversa única que vai do problema à implementação da solução e permite ciclos rápidos de feedback. Um exemplo típico desse ciclo é o time concordando em um milestone (Como usuário, quero poder pagar minha conta online) que é então escopado por engenharia de uma perspectiva centrada no cliente (Quero poder pagar minha conta com cartão de crédito e quero poder pagar minha conta com bitcoin), o que leva a uma redefinição do milestone (devemos lançar o pagamento por cartão de crédito isoladamente).
Essa conversa só é possível se todas as disciplinas trabalharem juntas no problema e em como ele será resolvido em termos de produto, design e engenharia.
O problema do cliente é o foco principal para todos.
Embora qualquer organização tenha restrições, como o stack tecnológico para um time de engenharia, atividades de planejamento devem focar no problema do cliente e evitar ideias preconcebidas sobre como as coisas devem ser feitas. É um desafio comum que as pessoas naturalmente tragam experiência passada para qualquer projeto (por exemplo, eu sempre quis refatorar essa parte do código) e retroajustem o plano do projeto às suas necessidades percebidas.
Embora os times devam considerar essas ideias com base em seus méritos, o ponto de alinhamento para o time precisa ser o valor ao cliente que estão proporcionando.
O pensamento de engenharia deve vir depois que o problema é definido, não antes.
Engenheiros devem dar tempo primeiro para entender o problema e a solução propostos e depois pensar em como construí-la. Embora o pensamento arquitetural seja crítico, ele deve facilitar a criação de uma solução para o cliente, e não o contrário. Se eu ganhasse um centavo por cada projeto que vi tendo uma ótima solução técnica (construída ao longo de muito tempo) e falhando no primeiro contato com o cliente, eu teria pelo menos um punhado de centavos.
Esse desafio não é exclusivo de engenharia e também se aplica ao pensamento de design e produto. Embora o planejamento deva permitir que as pessoas tragam sua experiência e pesquisa, o time precisa se sentir confortável questionando esse conhecimento prévio ao alinhar a nova solução.
Sinta-se confortável iterando. No trabalho e no processo.
Por último, iteração significa que haverá algum retrabalho. Iterar se aplica ao código, que vai mudar conforme novos tickets, épicos e milestones são entregues. Também se aplica ao processo, pois o time vai aprender o que funcionou bem ou não a cada iteração. Um dos principais desafios de se afastar do grande planejamento antecipado é que o planejamento de longo prazo dá às pessoas certeza.
Mover-se para uma mentalidade de planejamento e execução mais iterativa significa aceitar que lições serão aprendidas com mais frequência, à medida que erros e oportunidades de melhoria são percebidos mais vezes. Embora isso seja às vezes desconfortável, é um trade-off positivo, e vai levar a um resultado melhor no final.
No final das contas, quebrar trabalho é planejar e deve ser feito de forma colaborativa. Quanto mais esse silo não existir entre produto, design e engenharia, melhores serão os resultados de um time de engenharia.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.