Já tive minha startup, já passei por várias e também trabalhei para grandes empresas. Mas uma coisa é comum em quase todos os lugares por onde passei: o trabalho não-planejado. E o trabalho não-planejado é algo que cria estresse, sobrecarrega e diminui a agilidade do seu time de desenvolvimento.
Planejar não é frescura
Se você acha que planejar é fazer o “sprint planning”, a resposta é não. O famoso sprint planning também faz parte do planejamento, mas planejar é algo muito mais amplo do que apenas decidir o que fazer em um sprint.
Quando estamos falando de um projeto, estamos falando de algo muito mais amplo do que só o desenvolvimento do produto. Na verdade, fazer o produto faz parte da operação e não é o todo. Você precisa vender o produto, ter ações de marketing para captar clientes, fazer pré e pós-venda, acompanhar a performance dos seus clientes e do seu produto junto aos mesmos, etc.
Durante o sprint planning, o PO precisa alinhar-se com outras coisas acontecendo na empresa. Na prática, cada setor da empresa trabalha separadamente, como se fosses empresas separadas. Quem nunca viu a briga do desenvolvimento com o marketing ou com vendas? Quem nunca viveu aquele projeto no qual venderam algo que nem projetado foi? Se o PO não tiver visibilidade de outras ações acontecendo na empresa, não será capaz de priorizar corretamente o que precisa ser feito.
Claro, não dá para planejar detalhatamente os próximos 5 anos, mas dá para planejar as próximas duas semanas. Além disso, dá para criar um “roadmap” com fases do seu projeto para que isso sirva de guia, o mapa que indica qual caminho tomar para chegar ao final dessa estrada.
Enfim, o planejamento permite que toda a equipe da empresa trabalhe em conjunto com o mesmo objetivo evitando-se, com isso, atropelos. Assim, vendas não vai vender o que não tem, marketing não vai anunciar o que não existe e todo o projeto flui de forma natural e ágil.
Porém, quem está na área sabe que não é assim.
O tal trabalho não-planejado
Chega o CEO, faz uma reunião com o desenvolvimento e prioriza uma tarefa que precisa ser feita anteontem. Todo mundo corre para enfiar no meio do sprint e lá vamos fazer a tarefa. Já viu esse filme? Pois bem: sempre que alguém atropela o planejamento dessa forma, traz trabalho não-planejado. Gente vai ter de parar o que está fazendo para dedicar-se à nova tarefa, tudo o que havia sido planejado para o sprint vai por água abaixo.
Alguém vai ter de especificar isso, modelar, escrever o código, testar, fazer o deploy. E tudo isso na correria. O que acontece na prática é que isso não é analisado direito, dada a urgência, não é documentado e especificado direito e será mais uma dívida técnica adquirida na sua base de código.
Mesmo que seu processo seja altamente automatizado, com AI gerando o código, essa é uma forma péssima de trabalhar pois aumenta a incerteza, atropela o processo e joga a qualidade literalmente na merda. Esta nova adição será uma fonte infindável de bugs não porque as pessoas escreveram ou geraram código errado, mas porque as especificações foram feitas às pressas.
E sempre que trabalho não-planejado aparece em um sprint, costuma acontecer das pessoas trabalharem mais horas para poder cumprir o que foi combinado no sprint planning além daquilo que caiu de pára-quedas. O resultado é invariável: equipe exaurida, sobrecarregada. Com o passar do tempo, a equipe para de entregar com agilidade, a dívida técnica aumenta e o custo de manutenções evolutiva e corretiva, naturalmente aumentam.
Como evitar trabalho não-planejado?
A solução que eu vejo para isso é simples: dizer não. Não vai ser feito agora e será agendado para o próximo ciclo. Ponto final. Ou é assim ou não é. Ah, mas é urgente. Foda-se que é urgente. Via de regra esse tipo de urgência é fruto da falta de planejamento adequado, o que faz com que algo que deveria ter sido feito há mais tempo torne-se urgente.
Por outro lado, muitas das “urgências” não agregam valor ao negócio e são criadas artificialmente, novamente devido à falta de planejamento.
O trabalho não-planejado é particularmente danoso em startups. Sim, uma startup precisa iterar rapidamente. Mas, mesmo neste cenário, é importante que cada iteração seja devidamente planejada. Ao atropelar o processo, o resultado pode ser fatal. Uma startup não tem recursos suficientes para aguentar o aumento do custo de manutenção. E isso pode inviabilizar o negócio completamente. Não é incomum ver startups fechando as portas por falta de planejamento adequado.