palestraPauloFurtado_AgileBR2013Ainda na onda do Agile Brazil 2013, no post de hoje eu vou falar um pouquinho sobre o que vi por lá. Como aconteceu nas outras edições, o conteúdo do evento foi muito rico e o networking com a galera presente foi bem legal. Assisti cerca de 13 palestras, mas algumas me chamaram bastante atenção, dentre elas uma sobre Team Guiders. Hoje eu quero falar um pouco mais sobre esse tal conceito de Team Guider, já ouviu falar? Então vamos lá…

A palestra "Como capacitar clientes: Introdução ao conceito de Team Guiders" foi apresentada pelo Paulo Furtado, logo no primeiro dia do evento, e o que achei mais interessante nesta apresentação foi a visão diferenciada sobre um problema que a maioria dos softwares possui: a falta de comprometimento do cliente durante a fase de construção do produto.

Esse é um problema antigo na área de software e todos os envolvidos, de uma forma ou de outra, sofrem com esta questão. No entanto, o interessante e diferente desta palestra foi a visão apresentada sobre o problema. Já parou para observar que alguém que compra um apartamento faz questão de acompanhar o andamento da obra e se preocupa se tudo está correndo bem durante a construção? Então por que será que quando gastamos a mesma quantia na construção de um software não nos interessamos pela construção do mesmo e só queremos saber do resultado que virá meses ou anos depois?

Esse foi o questionamento proposto pelo Paulo logo no início da palestra e acredito que a resposta para esta diferença de comportamento está justamente no valor dado ao produto que está sendo comprado. Quando compramos um apartamento ou um carro, sabemos exatamente o impacto que esta aquisição terá no nosso dia a dia. Digamos, por exemplo, que você acabou de comprar um apartamento na planta e vai se casar. Além de prazo e custo, faz diferença para você saber a qualidade com que o empreendimento será construído e quantos quartos terá o apartamento. Se você pretende ter filhos, ter uma área especial no prédio para crianças pode contar muito, mas se não pretende, isso pode não representar um diferencial para você. A questão deste exemplo é que está claro para quem está comprando o contexto desta compra e por isso é mais fácil tomar a decisão sobre quais requisitos são de fato importantes, qual o objetivo da compra e o que se espera.

Nem sempre isso acontece no caso de um produto de software. O processo costuma ser muito mais obscuro para quem está comprando e o real impacto só será visto no fim do desenvolvimento do produto. Por isso, é preciso que quem produz o software não esqueça de ver o cliente como um cliente realmente, como alguém que está pagando por aquele produto que está sendo fabricado. Este cliente tem expectativas como aquele que acabou de comprar um carro, mas talvez ele não saiba exatamente o que realmente espera e, em vez de vê-lo como um fator impeditivo, é importante trabalhar junto para entender o seu contexto e os fatores envolvidos para construir a melhor solução possível.

No fim de tudo, um Team Guider nada mais é que um cliente e, portanto, um PO. O ideal é que ele entenda o contexto do problema para que ele possa saber quais requisitos são de fato importantes e devem ser priorizados. Ele deve saber estabelecer o nível de qualidade esperado e saber mostrar o que ele espera para sua equipe. Ele deve ter o poder de decidir o que é melhor para o seu produto e, mais do que nunca, ele deve ser tratado como um cliente, como alguém que possui uma expectativa e está recorrendo a você para supri-la.

Ok que é possível que o seu PO ainda não seja um Team Guider, mas aí está a oportunidade de ajudá-lo a entender o valor do produto que está sendo adquirido, melhorando a comunicação entre vocês e buscando realmente entender o problema que seu software deve atender. Só assim será possível produzir uma solução de qualidade e que realmente atenda a expectativa do seu cliente.

E aí, o que acharam? Visão interessante, não é verdade?