SCRUM, Product Owner e a Parábola do Taxista

Vamos começar com uma pequena história, que pode muito bem ter acontecido com qualquer um de nós. Nesta história seu diretor está a caminho do aeroporto para uma viagem onde irá fechar um importante contrato em que a empresa está negociando há um bom tempo para que isso aconteça.

Seu diretor liga para você e diz: “Esqueci os contratos em minha mesa e já estou no aeroporto de Congonhas, você poderia trazê-los para mim? Ficarei aguardando por você no saguão do aeroporto!”. Você está na região da Av. Paulista e precisa chegar o quanto antes no aeroporto. Decide então pegar um táxi e chama o Seu Manuel, taxista conhecido da empresa: “Seu Manuel, daqui para o Aeroporto de Congonhas quanto tempo levaria e qual seria o valor aproximado da corrida?”. Seu Manuel, de acordo com sua experiência, lhe dá uma estimava: “Olha, nesse horário creio que em 30 minutos estejamos por lá e sairá em torno de R$35″. Você acha a estimativa satisfatória e decide ir com seu Manuel até o aeroporto. Ao entrar na 9 de Julho você percebe que o trânsito está completamente parado até mesmo para ir pelo corredor de ônibus. Seu Manuel lhe sugere um atalho que corta sentido a Av. Tiradentes e que economizaria tempo. Como se trata de uma situação urgente você decide ir pelo atalho sugerido.

Algum tempo após ir pelo atalho sugerido começa a chover muito em São Paulo e além de o trânsito ficar complicado há alguns metros é possível ver que uma árvore caiu na pista, impossibilitando a passagem de qualquer veículo. Preocupado, você pergunta novamente a Seu Manuel se há alguma maneira de contornar este caminho e encontrar outra saída. Seu Manuel diz que se voltarem um pouco o caminho feito e tentarem ir por dentro do Centro é possível que não se atrasem tanto. Você aceita novamente a proposta de Seu Manuel, pois vocês realmente tiveram problemas durante todo o percurso.

Finalmente vocês conseguem chegar ao aeroporto, porém, você percebe que o táxi levou 90 minutos para chegar até o destino, e ao invés de custar R$ 35 (como previsto), custou R$ 130. O que você faria? Ficaria irritado? Nunca mais utilizaria os serviços prestados por Seu Manuel? Mas veja, você estava dentro do táxi o tempo todo e percebeu que ele fez o possível para chegar a tempo, e realmente se esforçou lhe oferecendo diversas opções, as quais você aceitou, pois percebeu que realmente eram situações de dificuldade. Você viu que o trânsito estava ruim, que a chuva complicou ainda mais e que um grave acidente no meio do caminho piorou as coisas. Você viu que quando isso aconteceu Seu Manuel tentou pegar outro caminho para fugir do trânsito e, por mais que a estratégia tenha sido boa, não foi suficiente para chegar a tempo. O que você fará? Há uma probabilidade muito grande de você, mesmo chateado, pagar o taxista e entender o lado dele, afinal você viu o quanto ele se esforçou.

Agora, no mesmo cenário, imagine que, ao invés de ir no táxi, você apenas contrata o Seu Manuel para levar os documentos para o aeroporto. Ele lhe deu a mesma estimativa de tempo e custo. No entanto, 90 minutos depois ele lhe liga e diz: “Olha, o trânsito estava muito complicado e só cheguei agora, o custo foi R$ 130 ao invés de R$ 35″. Qual será sua reação agora? O que você pensará?

Provavelmente você pensaria que Seu Manuel estava te enrolando, abusando de sua confiança, pois você não estava presente em cada uma das mesmas situações que iriam ocorrer se você estivesse com ele no táxi.

Uma situação como essa nos mostra a grande diferença entre “estar dentro do táxi” e “estar fora dele”, e esse é um dos grandes diferenciais que o Scrum pode agregar ao seu time tendo o P.O (Product Owner) presente em cada uma das evoluções do projeto, sentindo na pele as dificuldades junto com seu time e decidindo sobre o que deverá ser feito, pois o ele é o dono do projeto e o mais interessado em sua realização.

Devemos não apenas nos colocar no lugar do cliente, mas devemos colocá-los dentro do táxi! Fazer com que ele realmente sinta que estamos comprometidos e que realmente estamos juntos para que haja sucesso em seu projeto.

Marvin Ferreira

Mais artigos deste autor »

Sou mestrando em Engenharia da Computação pela Escola Politécnica da Universidade de São Paulo (POLI-USP), Bacharel em Ciência da Computação pela Pontifícia Universidade Católica de São Paulo (PUC-SP), possuo as certificações Microsoft Certified Trainer, Microsoft Certified Professional Developer e Microsoft Certified Technology Specialist. Atualmente sou Engenheiro de Software na ClearSale S/A, instrutor de treinamentos oficiais Microsoft e pesquisador do Laboratório de Engenharia do Conhecimento (KNOMA) da Escola Politécnica da USP.

17 Comentários

Frederico Augusto de Camargo
1

Legal a parábola Marvin. O problema é como trazer o seu Product Owner para dentro de sua equipe, visto que os clientes em geral encaram equipes de desenvolvimento como meros prestadores de serviços, no mais clássico modelo “insumo-processo-resultado”. Um PO com disponibilidade é difícil de se encontrar.

Transformar “galinhas” em “porcos” não é tarefa fácil. Acredito que o trabalho maior seja de mostrar ao cliente as vantagens de acompanhar de perto a equipe e dar visibilidade ao processo, e aí sim, evitar que as surpresas desagradáveis ocorram, e que passemos ao cliente a sensação de estarmos enganando.

Por isso é importante que o PO participe das Sprint Review Meetings, seja ouvinte nas Sprint Retrospectives e que seu feedback realmente valha de algo na melhoria contínua da equipe.

Marvin Ferreira
2

Muito bom seu comentário Frederico, realmente encontrar um PO com disponibilidade é complicado mas para que o Scrum seja aplicado de maneira correta isso é necessário e decisivo na maioria das fases do processo.

Aderir ao Scrum requer uma reformulação no PENSAMENTO e na CULTURA de todos, desde o time até o cliente que precisa tomar conhecimento de todas as vantagens que serão proporcionadas a ele!

É isso aí!
Obrigado por seu comentário!

Marvin Ferreira

Gabriel
3

Manolo,

Pra isso funcionar o processo seletivo deve ser 100% eficiente, pq a falta de skill na hora H em scrum pode comprometer o projeto por inteiro… Ou seja, n temos enroladores

Marvin Ferreira
4

Concordo com você Campeão!

Devemos conhecer MUITO bem nosso time e em todas Sprint Planning Meeting todos envolvidos devem ser sinceros com relação a suas capacidades de modo que possamos mensurar até que ponto de complexidade o time pode atacar no geral.

A melhor parte é o fato de não ter enroladores, se olhar para o Kanban estará TUDO lá para qualquer pessoa ver, no começo pode ser que intimide um pouco ou até cause constrangimento mas com o tempo todos se acostumam e percebem o valor que tudo isso agrega!

Obrigado pelo comentário!

Marvin Ferreira

Flavio Horita
5

Marvin,

Excelente parabola para explicar está importância do P.O durante todo o processo !
Pegando um gancho nas duvidas dos colegas acima, e quando este P. O. não pode estar disponível, qual a atividade ideal (ou processo, açoes) para evitar que os problemas citados no texto aconteceçam!?

Parabéns pelo artigo.

Abracos,
Flavio Horita

marcos
6

Bom… vejo esse texto de duas maneiras diferentes.

Primeiro: todo mundo é capaz de entender o esforço a mais do taxista e pagar por isso, por que andar no trânsito é, bem ou mal, uma experiência que todo mundo já teve, mas será que todo mundo entende de desenvolvimento de software?

Por outro lado, veja bem, eu perdi 1h30 do meu tempo e ainda paguei 4 vezes mais caro… às vezes é mais fácil pagar R$ 100 ao taxista e ter certeza que seu pacote vai chegar lá (em 5min ou em 1h30), no “mais clássico modelo insumo-processo-resultado”. São modelos de negócio diferentes, apenas isso, nenhum é necessariamente melhor que o outro. Perceba também que o segundo caso pode ser benéfico pro taxista, é só saber gerenciar ;).

SCRUM é uma excelente ferramenta de redução de riscos, mas é a velha lei do mercado: quanto menos risco, menos ganho ;).

Marvin Ferreira
7

Flavio,

Tratando-se do Scrum é imprescindível que o P.O esteja presente em todas as etapas que ele deve definir coisas como concepção da visão, definição do product backlog, criação das users stories, sprint planning meeting e principalmente na review que é o momento em que o P.O vê um pedaço do seu produto entregue. O P.O não ficará colado ao time a todo momento mas ele deve se mostrar presente pois tudo é conduzido de acordo com seus interesses de modo que haja um aumento do R.O.l (Return on investment).
A participação do P.O no Scrum representa alguns de seus princípios que são: indivíduos e interações entre eles mais do que processos e ferramentas, e colaboração com o cliente mais que negociação de contratos. É papel do Scrum Master fazer com que o processo seja aplicado da maneira correta, não existe Scrum ‘nas coxas’ se for usar algo do framework esse algo deve ser usado da maneira correta.
Em um cenário onde não é utilizado Scrum prevalece a ética e comprometimento com o cliente, devemos de alguma maneira mantê-lo ciente do que está acontecendo com o seu projeto/investimento.

Espero ter respondido sua pergunta!
Obrigado por seu comentário!

Marvin Ferreira

Kallyl
8

Parabéns Marvin !!!

Embora eu seja um leigo no assunto e preferir não comentar nada em questão.
Admiro a sua capacidade e vejo de longe o seu sucesso. É de se orgulhar quando se trata de uma pessoa que cresceu ao seu lado!

Abraços.

Ítalo
9

Caro Marvin,
É uma parábola interessante, que parte da premissa do histórico do “seu Manuel”: taxista conhecido pela sua “competência”. Dentro do táxi, confiamos no conhecimento do seu Manuel e pensamos: “ele conhece a cidade mais do que eu” (ou algo parecido, pois aceitamos todas as suas sugestões). Mas, e se pegássemos o “seu Pedro”, de quem nunca ouvimos falar e, além disso, não tivéssemos a mínima ideia de como chegar da Paulista até o aeroporto? Se o seu Pedro é um “recém-taxista”, que tipo de “processo” iríamos observar na sua parábola? Acho que um Scrum “infantil”, do tipo “tentativa-e-erro”, parecido com carrinhos bate-bate de parques de diversão. Portanto, precisamos do “seu Manuel” de desenvolvimento. Nesse sentido, o processo de engenharia (não o processo de gerência, Scrum) acaba sendo predominado pelo trabalho artesanal do engenheiro de software. Problema: processo de gestão versus processo de engenharia, como resolver esta equação?

Parabéns pelo texto. Obrigou-me a alguma reflexões que compatilho com você.
Um grande abraço,
Ítalo

José Carréra
10

Muito interessante a parábola, de fato mostra como sua percepção é afetada pela forma que você se envolve com a situação.
Na prática acho que o que acontece bastante é o PO ausente ou que na melhor das hipóteses está sempre em contato com o taxista pelo telefone. A participação direta e eficaz é bastante difícil.
Mas, com certeza a colaboração é o caminho.

Maria Lucia
12

Apesar de eu também ser leiga no assunto, ao me colocar como personagem desta parábola teria duas visões diferentes, levando em consideração a segunda situação da história: sendo o Sr. Manuel conhecido da empresa por já ter prestado serviços a ela, acredito que isto seria um ponto a seu favor, o que, talvez, amenizasse a desconfiança que passasse em minha mente! Se toda vez que ele prestasse serviço à empresa deixasse uma boa impressão, ajudaria mais ainda para que a desconfiança não ocorresse. Agora, se ele estivesse prestando serviço pela primeira vez… com toda certeza do mundo, eu não acreditaria na versão dele. Conclusão: enquanto cliente, seja de qual produto for, quando conhecemos a qualidade do serviço prestado, cria-se um elo de confiança entre a empresa e o cliente. A meu ver, este elo é mais importante do que qualquer valor financeiro.

Miguel
13

Parabens Marvin, lendo sua parabola e vendo a conclusao de estar ou nao no taxi , bom seu chefe pediu para voce levar entao nao seria conveniente mandar o taxisita e nos dias de hoje seria bem mais eficiente mandar um motoboy, rs. Parabens !!!

Marvin Ferreira
14

Fala Miguel!
Obrigado pelo comentário, você pegou um dos sentidos da coisa, o fato de estar dentro ou fora é para perceber o valor que agrega acompanhar o projeto ou não. Usar um motoboy é outro fator de risco, porque podem acontecer outras coisas e nesse caso você deve aumentar a confiabilidade em quem desenvolve o seu projeto sobre o valor do risco apresentado!

Valeu campeão!
Abraços,
Marvin Ferreria

Ítalo Chesley
15

Cara, seu texto é excelente.

Acredito que sirva tanto ao time iniciante no SCRUM, que vive cheio de incertezas principalmente relacionadas ao P.O, como de argumento para que o P.O reconheça o valor de sua participação no projeto.

Parabéns!

Marcos Habib Bistene
16

Marvin… muito bom este post.
Realmente, as colocações acima, deixam dúvidas quanto a dificuldade da presença do P.O.
Concordo também com o comentário da Maria Lucia…

Confiança não se compra, é conquistada.
E se você tem confiança em sua equipe, a falta do P.O. pode ser menor, mas não implica que este profissional não deva existir.

Projeto bem dirigido, Equipe unida, sucesso garantido.

abs

Deixe seu comentário

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


quatro − = 2

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>