Planejamento de sprints é das primeiras etapas que parecem sobrar quando um processo fica pesado. Eu vi essa tentação de perto, revisando com o time os modelos de processo de uma operação de desenvolvimento de software. A conversa era sobre o que estava sobrando e podia sair.
A gente tem um template para cada projeto de software que entra, do briefing à entrega. Cada etapa vira tarefa, com responsável. A revisão era para enxugar, e enxugar é bom. Só que tem etapa que, se sai do papel, aparece de novo no meio da execução.
Planejamento de sprints: quem faz o quê
Antes de riscar qualquer coisa, perguntei para o time: “Você não acha que o gestor tem que planejar os sprints? Quem vai fazer o quê? Quem ele vai alocar? Compartilhar um cronograma de entregas com o cliente? Você não acha?”
Tem projeto em que o planejamento já nasce antes, em uma conversa anterior. Então emendei: “Depois do briefing você já vai ter um planejamento. Então, de repente, o planejamento pode estar antes, entendeu? É só você tirar. Se você já tem um planejamento, você tira essa etapa. Se você precisa fazer, você deixa ela.”
E completei: “A ideia quando você pega um template é você adaptar com o projeto atual. Tem coisa que vai ser imutável e que é processo nosso, mas tem coisa que vai ser dinâmica de acordo com cada projeto.”
O que não pode é o planejamento sumir dos dois lugares. Aí ninguém sabe quem pega cada tarefa e o cliente não sabe quando recebe. E a confusão que a gente tirou do papel volta no meio da execução.
Onboarding separado, à vista do gestor
A conversa passou para o onboarding do cliente.
Eu disse: “O onboarding é fundamental ser bem feito. E independente se ele seja um projeto ou se ele esteja como tarefa, ele tem que ser executado, como a gente definiu. O gestor tem que se apresentar, a gente tem que mandar todo o contexto, tem que formalizar. O onboarding tem começo, meio e fim. Ele é só no início. Por isso chama onboarding.”
Depois mudei de ângulo: “Agora vou falar na visão do gestor de operações. Para ele é interessante ver o onboarding separado, porque o onboarding é uma das nossas premissas. Se o onboarding falhar, a primeira impressão nossa com o cliente ficou zoada.”
“Então, se ele tiver isso desmembrado, a gente vai conseguir ver que o onboarding do projeto de um cliente já está quase concluído, só batendo o olho ali. Eu não vou precisar entrar no projeto de desenvolvimento, ver o histórico da tarefa de onboarding. Nessa questão é praticidade.”
Já escrevi aqui sobre como as primeiras semanas de onboarding decidem se o cliente fica. Em software vale o mesmo. E tem uma etapa que quase ninguém coloca no fluxo.
Falei: “Eu acho que cabe um tipo de etapa que cabe em muitos contextos, que é comunicação com o cliente. A gente vai usar ela em várias etapas. Por exemplo, depois de uma produção, tem a comunicação com o cliente.”
“E comunicação com o cliente é uma etapa que não dá para apontar tempo, e aí a gente vai contar com que os nossos colaboradores coloquem o tempo subjetivo, e isso tem que colocar. Essa é uma etapa que a gente vai conseguir ver nos relatórios: quanto tempo as pessoas estão gastando com a comunicação com o cliente.”
Template com tudo, projeto personalizado
O template só ajuda se a tarefa explicar o passo a passo.
Expliquei assim: “Na descrição de cada tarefa, você vai ter que colocar o detalhamento do processo das etapas. Por exemplo, na descrição vai estar assim: um, fazer tal coisa; dois, e assim por diante. Para a solicitação de acesso, você precisa entrar em contato com o cliente, encontrar o contato com quem você precisa falar e usar o seguinte script.”
Na mesma conversa, dei o exemplo: “Aí a gente pode deixar uma mensagem pré-definida: ‘Olá, cliente, estou entrando em contato para solicitar acesso das contas X, Y, Z para que a gente possa continuar com o desenvolvimento do seu software.’”
E ressalvei: “E lembrando que coleta de acesso não é necessária em todo projeto de desenvolvimento de software. Pode ser que o cliente não tenha nada para passar. Isso vai sendo atualizado conforme o cliente vai evoluindo. Então, no template a gente conta com todas as possibilidades e depois o gestor de projetos tem que personalizar.”
Comentário em toda tarefa concluída
O planejamento da sprint diz o que vai acontecer. O comentário registra o que aconteceu. Sem ele, o processo depende da memória de alguém.
Sobre o acompanhamento semanal, falei: “Monitoramento é tarefa de gestão. A gente tem que entender que é como se nós estivéssemos falando assim para o gestor: ‘Gestor, para toda semana e revisa esse projeto. Está tudo certo?’ E aí nós vamos reforçar cada vez mais.”
E fui bem direto sobre o registro: “‘Olha, está tudo certo, nada a declarar.’ ‘Olha, estou analisando tal e tal situação.’ Mesmo se tiver tudo certo, deixa comentado que está tudo certo, entendeu? Não pode mais finalizar e seguir a etapa sem deixar comentário. Passou a etapa, concluiu a tarefa, deixa comentado, nem que seja oi. Deixa um emoji, eu quero um comentário.”
Na mesma conversa, emendei: “Não basta fazer, tem que falar que fez, e é assim que funciona, entendeu?”
Eu sei que parece muita etapa para quem está começando. Fechei aquela revisão assim: “Dá trabalho. Por isso que as empresas são desorganizadas. Dá muito trabalho organizar. Só que a hora que você faz uma vez, já era. A gente já está colhendo muito fruto de processo. Dá muito trampo, mas a hora que funciona vai liso. É top.”
Se a sua operação ainda não tem isso, comece pequeno. No meio da revisão, também falei: “Vamos tentar soltar uma versão mínima. E vamos testar, gente. Pode melhorar depois.” Esse tipo de arrumação é parte do que a gente faz quando um negócio precisa acelerar.
No seu processo, quem planeja a sprint hoje?
