Pensar como dono do problema, não como dono do cronograma

Quinta-feira à noite, véspera da entrega. Você abre a tela da nova funcionalidade de aprovação de reembolsos e faz o teste que a equipe de qualidade não fez: tenta usar como uma analista de verdade usaria, com uma pilha de pedidos para aprovar. Cada aprovação exige sete cliques e três telas. Hoje, na planilha antiga, são dois.

A especificação foi cumprida à risca. O cronograma está verde. A entrega vai sair amanhã, conforme combinado. E você tem quase certeza de que, em duas semanas, as analistas vão voltar para a planilha.

O que você faz?

Duas lealdades que às vezes brigam

Todo gerente de projetos carrega duas lealdades. Uma é com o plano: o compromisso assumido, a data prometida, a linha de base aprovada. A outra é com o problema: a razão pela qual alguém decidiu gastar dinheiro e tempo naquele projeto.

Na maior parte do tempo, as duas andam juntas. O plano foi feito para resolver o problema, e cumpri-lo é a melhor forma de chegar lá. Mas há momentos em que elas se separam. O contexto muda, uma premissa se revela errada, a solução desenhada não funciona na prática. É nesses momentos que se revela de qual dos dois o GP se sente dono.

Ser dono do cronograma é medir sucesso pela aderência à linha de base. Ser dono do problema é medir sucesso pelo que muda para quem recebe a entrega.

O que nos prende ao plano

Seria fácil dizer que o GP que segue o plano cegamente é acomodado. Quase nunca é isso. Existem motivos legítimos e humanos para se agarrar ao cronograma.

O plano é seguro. Ele foi aprovado por alguém com autoridade. Se você cumpre e dá errado, a responsabilidade está distribuída. Se você muda e dá errado, ela é sua.

O plano é visível. A empresa mede prazo, custo e entregas porque são coisas fáceis de medir. O problema resolvido aparece mais tarde e de forma difusa. O incentivo empurra para o que é visível.

O plano tem histórico. Meses de esforço, negociações, compromissos com outras áreas. Mudar parece desperdiçar tudo isso. É o mecanismo conhecido como custo afundado: o que já foi investido pesa mais do que deveria na decisão sobre o que fazer agora.

E o plano poupa conversas difíceis. Dizer ao sponsor que a funcionalidade, do jeito especificado, não vai resolver é desconfortável. Pode soar como admissão de erro, como crítica a quem especificou, como fuga do prazo. Entregar e deixar o problema aparecer depois parece mais leve, ao menos no curto prazo.

Nenhum desses motivos é tolo. Mas, somados, eles produzem projetos entregues no prazo que ninguém usa.

O outro extremo também falha

Existe um erro simétrico, e ele merece atenção. É o GP que, em nome do problema, muda tudo por conta própria. Decide sozinho que a especificação está errada, refaz o desenho com a equipe, atrasa a entrega sem avisar e apresenta a solução nova como fato consumado.

Isso não é ser dono do problema. É tomar para si uma decisão que não é só sua. Mesmo quando a intuição está certa, o modo como a mudança acontece destrói confiança. O sponsor descobre que perdeu o controle do projeto, as áreas que dependiam da data são surpreendidas, e a próxima vez que você levantar um alerta, ele será recebido com desconfiança.

Ser dono do problema é enxergar, nomear e propor. A decisão continua com quem tem a autoridade para tomá-la.

Como agir quando o plano e o problema se separam

Voltemos à quinta-feira à noite. Há alguns caminhos, e o certo depende do que você encontra ao investigar um pouco mais.

Se a distância entre o plano e o problema é pequena e pode ser corrigida rapidamente, entregue e ajuste logo depois. Avise o sponsor e a área usuária que haverá uma melhoria em seguida, e por quê. Isso preserva o compromisso e trata o problema.

Se a distância é grande, e entregar como está vai gerar retrabalho, rejeição ou risco, leve o alerta antes da entrega. Na mesma noite ou logo cedo. Com evidência concreta (o teste que você fez, a conversa com uma usuária) e com opções: entregar como está e corrigir depois, adiar alguns dias para ajustar, entregar parte e ajustar o resto.

Se você não tem certeza de que o problema é real, busque evidência antes de alarmar. Peça a uma pessoa da área usuária para testar com você. Às vezes o incômodo é seu, não de quem vai usar.

Se o sponsor ouve e decide entregar como está, respeite a decisão, registre o alerta e acompanhe o que acontece. Ter levantado o ponto no momento certo já cumpriu o seu papel. Esse é um daqueles momentos em que vale pensar sobre ter razão ou ter resultado.

E se a mudança que você percebe não é na funcionalidade, mas no próprio motivo do projeto, o caminho é outro, mais amplo. O artigo sobre quando a estratégia muda no meio do projeto trata desse cenário.

Palavras para levar o alerta sem dramatizar

Para o sponsor, na véspera:

"A entrega está pronta conforme a especificação, mas fiz um teste usando como a analista vai usar e fiquei preocupado. São sete cliques por aprovação, contra dois na planilha. Acho que elas vão voltar para a planilha. Posso te mostrar em cinco minutos e trazer duas opções?"

Para a equipe, quando você decide puxar o freio:

"O que vocês fizeram está certo pelo que foi pedido. O que eu quero entender agora é se o que foi pedido resolve o problema das analistas. Vamos olhar juntos antes de soltar."

Quando a decisão do sponsor é seguir:

"Entendido, a gente entrega amanhã. Vou registrar esse ponto e acompanhar o uso nas duas primeiras semanas. Se aparecer resistência, já tenho a proposta de ajuste pronta."

Como perceber se você está mais perto de um ou de outro

Algumas perguntas ajudam a fazer um autodiagnóstico honesto.

Quando você fala do projeto, fala primeiro do prazo ou do que vai mudar para alguém? Nas últimas semanas, quantas vezes você conversou com quem vai usar a entrega? Quando uma premissa se revelou errada, você levou o assunto ao sponsor ou contornou em silêncio? Se o projeto fosse cancelado amanhã, você saberia explicar o que a empresa deixaria de ganhar?

Não há resposta certa absoluta. Mas, se todas as respostas puxam para o cronograma, talvez o seu olhar esteja estreito demais.

Na relação com os outros, os sinais também aparecem. Um GP visto como dono do problema é procurado pela área de negócio para conversar antes das decisões. Recebe alertas da equipe com mais frequência, porque as pessoas sabem que ele vai ouvir. É consultado quando o contexto muda.

Uma véspera de entrega diferente

Exemplo ilustrativo (situação fictícia): Camila coordenava a nova funcionalidade de aprovação de reembolsos em uma empresa de seguros. Na véspera da entrega, fez o teste que descrevemos e percebeu o problema.

Em vez de entregar e torcer, mandou uma mensagem curta para o sponsor, o gerente de sinistros, Paulo, pedindo dez minutos às oito da manhã. Levou uma gravação da tela mostrando o fluxo e duas opções: entregar na data e ajustar em duas semanas, ou segurar três dias para simplificar o fluxo de aprovação em lote.

Paulo escolheu segurar os três dias. Avisou ele mesmo a diretoria. Camila explicou a mudança para a equipe deixando claro que o trabalho deles estava correto conforme especificado. A entrega saiu com o atraso combinado, e as analistas abandonaram a planilha.

O que ficou para Paulo não foi o atraso. Foi a lembrança de que Camila percebeu o problema antes dele.

O que essa escolha diz sobre a sua carreira

Pensar como dono do problema é uma das marcas mais nítidas da maturidade de um GP. Ela aparece nas pequenas escolhas: um teste a mais, uma pergunta incômoda, um alerta levado na hora certa. E é um dos pilares da visão estratégica para gerentes de projetos.

Ela também tem um custo. Às vezes você vai levantar alertas que não serão ouvidos. Às vezes vai errar a avaliação. Mas um histórico de alertas bem fundamentados, feitos com respeito à autoridade de quem decide, constrói uma reputação que nenhum cronograma verde consegue construir sozinho.

Checklist para a véspera de cada entrega

• Sei dizer qual problema esta entrega deveria resolver.
• Testei a entrega do ponto de vista de quem vai usá-la.
• Conversei com pelo menos uma pessoa da área usuária nas últimas semanas.
• Se vejo distância entre plano e problema, tenho evidência concreta.
• Levo o alerta com opções, não só com o problema.
• Respeito a decisão de quem tem autoridade e registro o ponto.

Uma pergunta para levar esta semana

Escolha a próxima entrega do seu projeto e faça a si mesmo a pergunta da quinta-feira à noite: se ela sair exatamente como está planejada, resolve o problema de quem vai usar? Se a resposta for "não sei", marque uma conversa de quinze minutos com um futuro usuário antes da data. Essa conversa é o primeiro gesto de quem é dono do problema.