Profissionais TI - Pra quem respira informação

Quando 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:

Obrigado, mestre Yoda! 🙂

Abraço, pessoal!