Táticas de Liderança em Engenharia: Cuide do Input
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Ao falar sobre Liderança Sistêmica para times de software, uma pergunta que surge com frequência é como aplicá-la na prática. Sim, pensamento sistêmico faz sentido, mas como um engineering manager (EM) usa isso no dia a dia?
Um aspecto frequentemente negligenciado é a importância da qualidade do input do time. Em outras palavras, a forma como enquadramos o trabalho impacta diretamente a performance do time.
Em particular, dois casos se aplicam comumente ao desenvolvimento de software: definição de projetos e user stories.
Inputs Importam
Embora a execução possa definir o papel de um Engineering Manager (EM), o que o time está entregando pode ser a alavanca de melhoria mais poderosa que ele tem.
“A vantagem está nos inputs. A pessoa que consome de fontes melhores tem pensamentos melhores. A pessoa que faz perguntas melhores obtém respostas melhores. A pessoa que constrói hábitos melhores obtém resultados melhores. Não são os resultados. São os inputs.”
James Clear
Pode parecer óbvio na teoria. No entanto, é natural que as pessoas foquem na tarefa imediata à sua frente. Isso vale para engenheiros que às vezes executam o que está no ticket sem questioná-lo. E também para EMs, gerenciando sem tempo para entender por que aquele trabalho está sendo feito em primeiro lugar.
Perspectiva sistêmica
Se um EM olhar para seu time de uma perspectiva sistêmica, vai perceber que tudo é influenciado pela forma como o trabalho é definido. E há dois aspectos que considero críticos ao gerenciar times de software:
Envolver engenharia na definição dos projetos — A unidade de trabalho de um time pode variar. Pode ser um projeto, uma feature, uma iniciativa ou uma pesquisa. Independentemente de como a organização define isso, engenharia precisa estar envolvida em algum grau do início ao fim, garantindo que o trabalho esteja bem enquadrado quando chegar à fase de desenvolvimento.
Ter alinhamento e visibilidade sobre os itens de trabalho — Por outro lado, a unidade de trabalho de um engenheiro geralmente é um ticket (ou user story, entre outros formatos). O time inteiro, incluindo produto e design, deve estar alinhado, entender e ser capaz de discutir cada item de trabalho.
O Problema na Prática
As afirmações acima são abstratas, então você pode se perguntar se isso realmente faz diferença. Vou ilustrar esse problema com dois casos (de muitos) em times que gerenciei.
Definição de Projeto que Deu Errado
Nessa situação, eu supervisionava um time construindo uma nova feature em uma plataforma de consumo. E o diretor de produto me disse um dia: “Precisamos lançar essa feature em duas semanas. A demanda veio do CEO e não há margem para mudar o prazo”.
Para contextualizar, nossa estimativa original para um lançamento completo ao cliente era de 4 a 6 semanas. Quando ouvi aquela frase, já conseguia imaginar a conversa que deveria ter com os engenheiros: Entreguem mais rápido, trabalhem mais, hora de apertar. Felizmente, antes de seguir esse caminho, decidi perguntar por quê. Por que isso é importante? Por que o prazo existe? Isso levou a uma discussão sobre as perspectivas mais amplas do produto e, por fim, à percepção de que a demanda do CEO vinha da necessidade de reportar uma métrica específica de adoção que a nova feature aumentaria.
Essa percepção me deu um novo grau de alavancagem. Em vez de pedir ao time que trabalhasse mais, discutimos como aumentar a métrica. Isso significou que pudemos ter uma conversa empoderadora sobre o assunto, o que levou à repriorização e redesign do trabalho. No final, durante aquele período, todos trabalharam (em um ritmo sustentável) em direção a um objetivo específico. Como resultado, entregamos nossa melhor tentativa de impulsionar a adoção, e embora não tenhamos atingido o número que esperávamos, foi positivo o suficiente para ser considerado um excelente resultado pela empresa.
Embora o caso acima tenha sido extremo, esse problema pode acontecer de várias formas. Alguns exemplos:
- Projetos são definidos com base nos tickets que serão entregues. Sucesso significa limpar o backlog.
- Iniciativas onde o resultado é binário: ou o time entregou X, ou foi um fracasso.
- Trabalho planejado sem envolvimento de engenharia, levando a expectativas irrealistas.
Falta de Alinhamento nos Itens de Trabalho
Neste caso, entrei em um time pequeno construindo um produto voltado ao cliente. Logo após entrar, percebi que os engenheiros eram competentes e trabalhavam duro. No entanto, o resultado das entregas poderia ser mais eficaz, e melhorar isso era uma das minhas principais tarefas ao entrar na empresa.
Trabalhando com o time, ficou claro que estávamos executando o processo ágil padrão com stand-ups, sprints e retrospectivas. Ainda assim, havia pouco alinhamento e visibilidade sobre os itens de trabalho reais. Os tickets no nosso board eram predominantemente técnicos, dificultando que pessoas de produto entendessem o que significavam. Eles também eram divididos por fronteiras técnicas, tornando difícil verificar o trabalho após sua conclusão. E dependiam uns dos outros, levando engenheiros a ficarem frequentemente bloqueados por outra pessoa.
Na prática, enquanto cards se moviam pelo board diariamente, operávamos sem visibilidade fora de engenharia. Só conseguíamos verificar o resultado do nosso trabalho depois de entregar o projeto inteiro. Como resultado, lançamentos eram frequentemente atrasados e continham muitos problemas que só descobríamos no final. E melhoramos drasticamente nossos resultados mudando uma coisa: como escrevíamos user stories.
Como definir requisitos é um assunto longo, mas há alguns sinais de alerta comuns que já vi:
- Tickets que são tecnicamente focados e que apenas pessoas dentro do time de engenharia conseguem entender.
- Tickets que são difíceis de verificar independentemente, criando incerteza sobre seu resultado.
- Tickets que dependem uns dos outros, levando ao acúmulo de risco.
A essa altura, já vi esse problema tantas vezes que tenho uma perspectiva forte sobre ele. Itens de trabalho mal definidos vão levar a desafios de performance individual. É apenas uma questão de tempo até que o ambiente incerto faça um engenheiro não entregar de forma eficaz.
Como Melhorar?
Você já sabe essa parte se leu algum dos meus outros artigos. A maior alavancagem que um EM pode ter é entender profundamente e agir intencionalmente sobre os sistemas ao redor do seu time.
Ao analisar seus projetos, entenda como as iniciativas são priorizadas. Quem está tomando as decisões? Como os engenheiros estão envolvidos na definição? Um time deve buscar um processo onde:
- As iniciativas se concentrem em problemas do cliente ao invés de soluções específicas. Embora um time possa entregar uma feature, quanto mais todos entenderem o problema que estão tentando resolver, melhor. Objetivos mais amplos levam a mais oportunidades de trade-off e melhores chances de sucesso.
- Engenharia participe do planejamento à entrega. A participação deve variar em diferentes fases, com mais envolvimento na execução e menos no planejamento. Mas sempre deve haver algum.
- Prazos podem existir, mas devem ser em torno de resultados (ou problemas do cliente) e não de output de entrega. Quanto menos centrado em output o trabalho for, mais opções o EM (e o time) terá para abordá-lo, reduzindo as chances de fracasso.
Ao olhar para os itens de trabalho, eles devem ser fáceis de entender, acordados entre todos e verificáveis. Uma ótima forma de analisar esse aspecto é observar com que frequência tickets transitam entre produto, design e engenharia. Embora a colaboração entre disciplinas para realizar o trabalho seja saudável e essencial, tickets sendo passados de um lado para outro entre elas não é.
Um time deve buscar o seguinte:
- Itens escritos da perspectiva do cliente, de modo que todos os entendam. PMs e Designers devem ser capazes de ler um ticket e saber o que significa ele estar concluído.
- Itens que possam ser executados e verificados independentemente. Quanto mais fácil for para produto e design verificar cada ticket independentemente, menor será o risco em qualquer iniciativa.
- Itens pequenos. Embora as restrições variem, quanto mais tempo levarem para executar, maior o risco que o time de engenharia está assumindo.
Em ambas as áreas, se você quiser pesquisar mais, ainda considero o livro User Story Mapping como o melhor da categoria. Siga-o e você estará no caminho certo.
Por fim, lembre-se de que inputs importam. Melhore-os e o trabalho de todos vai melhorar.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.