Aprenda a dizer “Não” para o Product Owner

Aprenda a dizer "Não" para o Product OwnerQuando trabalhamos com Desenvolvimento Ágil, nós, desenvolvedores, assumimos uma postura diferente. O perfil do “desenvolvedor ágil” exige mais comprometimento, comunicação e colaboração de acordo com as diretrizes da metodologia. Porém, isso não significa que somos obrigados, por exemplo, a concordar com todas as solicitações do Product Owner. Não é fazer cara feia. É simplesmente ser profissional.

 

O assunto de hoje é relacionado com os verbos “tentar” e “achar”. Muitos desenvolvedores, na tentativa de mostrar serviço, se comprometem a entregar um “zilhão” de funcionalidades do Product Backlog, mesmo sabendo que será custoso, cansativo e que, talvez, não será possível. Isso é grave…
Assim como já destaquei em outros artigos, no contexto de desenvolvimento de software, ser ágil não se traduz em ser mais rápido, energético e implementar o dobro de funcionalidades selecionadas. Já vou dizendo: concordar com tudo não é ser profissional.

O motivo é simples. Quando uma equipe ágil se compromete a implementar funcionalidades além da própria capacidade, ela estará automaticamente conduzindo a Sprint para o atraso. Esse comprometimento inviável é fomentado quando a equipe diz que “vai tentar” ou “acha que vai conseguir”. Ao ouvir essas afirmações, os gestores assumem que todos os requisitos serão entregues no final da Sprint e já saem fazendo promessas para o cliente. Para eles, “tentar” e “achar” são sinônimos de “sim” e demonstram confiança. Resultado? Quando terminar a timeline da Sprint e houver funcionalidades ainda não implementadas, começarão os conflitos, busca pelos culpados e a temporada de horas extras. Isso é correto?

Desenvolvedores ágeis devem desconhecer estes dois verbos. Ou a equipe faz ou não faz. Para isso, desenvolvedores devem estabelecer a autonomia de dizer “não” quando identificarem que não é possível entregar as user stories designadas pelo Product Owner.
É justamente aqui que mora o problema. Muitas equipes sentem receio de contestar as solicitações do Product Owner por pensarem que esse comportamento é antiético ou inadequado no contexto corporativo. Para elas, quanto maior o número de funcionalidades implementadas, melhor será a visibilidade conquistada na empresa. Não é assim que funciona! Se uma das funcionalidades já não for entregue, por menor que seja, a equipe transmitirá uma impressão de ineficiência ou, no pior dos casos, irresponsabilidade por prometer uma entrega que não foi concluída. A consequência é a inversão da imagem: ao invés de serem reconhecidos, serão difamados.

Desenvolvedores ágeis dizem “não”. Sabe porque isso é ser profissional?
O Product Owner e os gestores de projeto esperam que desenvolvedores sejam realistas, e não otimistas. Eles esperam que a equipe tenha a coragem de recusar as demandas e apresentar os motivos, encarando a realidade do trabalho a ser realizado. Ser otimista, mais uma vez, nos leva aos dois verbos mencionados acima.

Alguns Product Owners insistirão, claro, na implementação das funcionalidades, e se irritarão quando a equipe contestar. Deixem ficar irritados. É muito mais digno declarar que não será possível entregar uma funcionalidade (por falta de recursos, tempo ou outra condição), do que prometê-la e ter que se desdobrar para conseguir finalizá-la. É assim que uma equipe ágil ganha confiança da gerência. Nas próximas Sprints, os gestores já compreenderão que, quando a equipe diz “não”, é não mesmo!

Olhem só o diálogo abaixo:
Product Owner: “Vamos incluir também essa funcionalidade para gerar gráficos de vendas mensais na nossa Sprint.”
Equipe: Não, não será possível.”
Product Owner: “Como assim? Isso é importante para o cliente! Precisamos implementá-la.”
Equipe: Não. Essa user story não se encaixará no nosso Sprint Backlog, pois já temos atividades suficientes.”
Product Owner: “E se fizermos algumas horas extras no final de semana?”
Equipe: Não. Dessa forma estaremos trabalhando além da nossa competência, logo, não garantiremos a conclusão.”
Product Owner: “Mas o cliente está esperando essa funcionalidade nessa versão. Vamos tentar, pelo menos?”
Equipe: Não. Há uma possibilidade de tentar e não conseguir. Não gostaríamos de nos arriscar e comprometer a entrega.”
Product Owner: “Preciso disso. O que vocês sugerem?”
Equipe: “Remova uma user story da Sprint para que possamos encaixá-la, ou negocie a disponibilização dessa funcionalidade com o cliente para a próxima versão.”

 

O segredo é “bater o pé”, pessoal. No final dessa reunião de planejamento, garanto que os desenvolvedores sairão mais confiáveis. Novamente: não é fazer “corpo mole”. É simplesmente saber trabalhar.

Dizer “não” envolve mais do que confiança. O Product Owner e a gerência serão mais assertivos nas próximas decisões com o cliente e apresentarão uma negociação mais realista, melhorando o orçamento do projeto e o ROI. O cliente, por sua vez, sentirá mais segurança nos compromissos da empresa em relação às entregas.

Para fechar, deixo uma mensagem do Mestre Yoda que se encaixa perfeitamente nesse artigo:

Do or Do Not. There is no try.
Faça ou não faça. Não existe “tentar”

 

Obrigado, mestre Yoda! 🙂
Abraço, pessoal!


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

3 comentários

  1. Sabias palavras André. Dizer Sim para tudo dá um desgaste enorme. Saber dizer Não na hora certa nos livra de futuras dores de cabeça .

  2. Processos como Ágile, Scrum, SAFe são essenciais para o bom desenvolvimento de uma equipe. Eles garantem que o time tenha ciência do que deverá ser feito e de quanto tempo cada um tem para desempenhar suas atividades. Porém por vezes temos Gerentes / Coordenadores / Product Owners que ‘enfiam goela abaixo’ novas atividades ou reprovações de funcionalidades tornando cada vez mais estressante a rotina diária dos desenvolvedores. Pessoas que estão à frente desta gestão precisam entender que tudo é negociável, desde que seja favorável para ambas as partes. Se uma nova funcionalidade não cabe, que seja retirada ou adiada da sprint. Se um erro retorna e precisa ser corrigido o time não terá carga para atender toda a demanda, logo a atividade menos importante que agregue menos valor de negócio deve ser retirada da sprint.
    Outro ponto importante é que a medição histórica de erros do time através do indicador IET (Índice de Erros Total) pode ajudar o Gerente de Projetos a incluir uma margem extra em seu planejamento de Gerenciamento de Riscos.
    Traçar metas para a redução do IET a cada sprint ou projeto também ajuda o time a tornar-se mais maduro e reduzir retrabalho, criando mais tempo para atuar em novas atividades.

    1. Fala, grande Marcos! Mais uma vez agregando um enorme valor ao artigo!
      Você tocou em um assunto no qual considero bastante relevante, porém, infelizmente é negligenciado nas empresas: a Engenharia de Valor. Tenho notado uma desorientação notável de muitos Products Owners em relação ao valor de negócio que cada funcionalidade traz para o cliente. Por conta disso, várias entregas de maior valor são desconsideradas em função da falta de recursos, prazo ou justamente pelo excesso de alocação de itens de menor valor. Essa desorientação desencadeia uma série de consequências que impactam diretamente na motivação e produtividade da equipe. Se a Engenharia de Valor fosse empregada nesse cenário, provavelmente não seria necessário dizer “Não” para o Product Owner. 🙂
      Também concordo com você a respeito do IET, principalmente pela redução de retrabalho. Na minha opinião, esse é um dos fatores que mais gera desperdício de tempo e orçamento nas empresas.

      Obrigado, Marcos!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.