Gerenciamento de projetos - O abismo entre a entrega e o entendimento

uma reflexão sobre processos

Ao longo dos meus curtos cinco anos de carreira como desenvolvedor, sempre me interessei muito pouco pela gestão. No início, eu não me importava com a forma como as tarefas chegavam até mim; na minha cabeça, eu era capaz de entregar qualquer demanda. E, de fato, eu entregava. Mas não demorou muito para eu perceber que não estava exatamente "entregando" o que era esperado; eu estava entregando apenas o meu entendimento — que, muitas vezes, era raso, insuficiente e gerava retrabalho.

A princípio, esse retrabalho vinha acompanhado de uma certa graça por conta dos mal-entendidos. Com o tempo e o ganho de experiência, o cenário mudou: os alinhamentos ficaram mais ásperos e os feedbacks negativos começaram a me incomodar. Como todo programador com síndrome do impostor, que tem a tendência a se achar insuficiente, eu internalizei aquilo como minha culpa e incompetência. Continuei estudando, me esforçando e absorvendo cada vez mais os projetos. Eventualmente, as demandas genéricas com pouca informação pararam de ser um problema, porque eu já dominava o negócio e sabia exatamente o que precisava ser feito. Voltei a me sentir confiante e habilidoso.

Até que troquei de empresa.

Ao me envolver em um projeto completamente novo, a crise voltou antes mesmo de eu entregar a primeira tarefa. Senti-me inseguro por assumir um cargo acima do anterior, com expectativas mais altas, e o medo de "não ser suficiente" me dominou enquanto eu tentava aprender o novo sistema. Mas, para minha surpresa, isso não aconteceu. Minhas entregas foram sólidas desde o primeiro momento. Eu cumpria prazos e mantinha a qualidade. O que mudou? Minha experiência finalmente tinha se tornado efetiva? O sistema era mais simples?

De fato, a experiência ajudou na transição, mas os projetos não eram simples. Pelo contrário: possuíam uma complexidade alta e exigiam muito cuidado. O que realmente me ajudou a ganhar confiança foi o processo de gestão.

Na minha primeira experiência, as demandas vinham diretamente do cliente: ele reclamava ou solicitava algo, e um card era jogado no meu backlog. Sem análise, sem discussão, apenas a pergunta: "Quanto tempo você leva para fazer isso?".

Já na segunda empresa, a organização era outra. Todas as tarefas passavam por um fluxo rigoroso (com exceção dos bugs, que tinham um caminho próprio):

Análise de Negócio: Descrevia-se a necessidade e o motivo dela existir.

Análise Funcional: Pessoas que entendiam profundamente o sistema traduziam a necessidade para a realidade técnica. Mockups genéricos davam lugar a desenhos baseados na identidade do produto, e as funções perdiam descrições vagas. O resultado eram detalhes claros: o que cada botão faria, como os registros seriam persistidos, restrições e exemplos de resultados esperados.

Só depois disso entrávamos em cena. Nas plannings, usávamos o famoso Planning Poker para votar os prazos. Com base na nossa própria estimativa, os gestores definiam o que entraria na sprint.

Quando o trabalho começava, ainda havia a análise técnica: nós escrevíamos o que precisávamos alterar para atender à demanda. Não com 100% de clareza — afinal, é difícil prever cada linha de código —, mas descrevíamos quais partes do sistema seriam modificadas e por quê. Dependendo da complexidade, fazíamos uma revisão técnica para garantir que não estávamos "alucinando". Só então partíamos para o desenvolvimento, seguido de testes e homologação.

Eu não havia notado que esse processo "mastigava" tanta informação para mim. Ele engessava um pouco da criatividade e limitava o espaço para inovações, sim, mas garantia que eu tivesse exatamente o que precisava para trabalhar. Minhas frustrações não eram mais com a minha capacidade técnica, mas com a arquitetura — por ser um projeto legado, eu, como todo iniciante emocionado, só queria saber de mexer com tecnologias modernas.

Moral da história: se o seu time está atrasando as entregas com frequência, antes de duvidar da capacidade técnica deles, revise o processo. Será que não está burocrático demais? Ou o oposto: será que não está genérico demais? As informações estão chegando ao desenvolvedor com a clareza necessária?

Seniores, geralmente, conseguem navegar na ambiguidade, mas juniores e plenos precisam de chão para caminhar. Às vezes, o sucesso do time não depende de mais código, mas de uma descrição funcional bem feita. ;]