Foco e follow-through são o verdadeiro fosso de engenharia

O problema é escolher e terminar

Em uma startup de alto crescimento, há mais trabalho do que pessoas. A equipe do autor, formada por quatro integrantes, recebe cerca de 50 novas ideias para triagem a cada sprint, mantém cinco ou seis projetos principais em andamento, cuida dos sistemas de produção e ainda atende a pequenas funcionalidades e correções. Nesse contexto, começar novos trabalhos é fácil, mas concluí-los é difícil: o desenvolvimento “prioritário” tende a deixar uma sequência de tarefas parcialmente acabadas.

O autor sustenta que foco e capacidade de levar o trabalho até o fim são uma vantagem mais importante do que uma pontuação perfeita de sprint. A equipe costuma concluir cerca de 70% do sprint e realizar aproximadamente 30 pontos por pessoa, mas esses números só são úteis porque refletem um processo de escolha e execução relativamente consistente. Não é possível atender a todos os pedidos. Cada tarefa representa algo importante para alguém - uma ferramenta de trabalho, uma página usada diariamente, uma correção esperada ou uma funcionalidade ligada à receita -, mas dedicar tempo a uma coisa significa deixar outra de lado. Por isso, a prioridade deve considerar impacto, esforço, retorno, tempo de espera, urgência, desbloqueios e o momento de aproveitar um trabalho que já ganhou impulso.

Transformar disputa em colaboração

Para alinhar expectativas, a equipe se reúne regularmente com as áreas interessadas. O encontro serve para mostrar o que foi entregue, discutir o que está em andamento e revisar prioridades. Segundo o autor, demonstrar o que foi concluído é essencial: as pessoas nem sempre percebem que um problema deixou de ocorrer ou que uma nova ferramenta passou a existir. Se a engenharia só falar sobre o trabalho futuro, pode parecer que nada está sendo feito.

A recomendação é manter uma classificação manual das demandas, ordenada por prioridade, e revisar essa lista com os stakeholders. Novas sugestões entram no quadro e podem alterar a ordem até que todos concordem com ela. Assim, a engenharia deixa de simplesmente rejeitar pedidos e passa a facilitar uma decisão compartilhada sobre o que será feito primeiro.

Planejar o sprint a partir do topo

O autor organiza backlogs separados para cada área interessada e também para projetos de prazo mais longo. Esses últimos precisam receber tempo deliberadamente, pois objetivos trimestrais raramente parecem urgentes. Com as listas previamente priorizadas, o planejamento do sprint segue uma distribuição alternada: a equipe retira algumas tarefas do topo de cada projeto e de cada grupo de stakeholders.

A capacidade conhecida é de 30 a 40 pontos por pessoa, mas o escopo costuma crescer 20% durante o sprint, porque surgem urgências, tarefas são divididas ou trabalhos se mostram mais difíceis. Idealmente, toda nova demanda incluída deve retirar outra. O que não for urgente vai para a triagem, onde será direcionado ao sprint ou a um backlog para priorização posterior.

Por fim, a equipe verifica se o sprint está equilibrado e compartilha com cada área uma visão do que deve ser feito. Isso permite objeções antecipadas e mantém os stakeholders informados. Para o autor, uma lista clara ajuda a preservar o foco, concluir o iniciado e fazer a engenharia parecer uma parceira previsível, não uma força caótica que muda ferramentas e prioridades sem explicação.