O que o cliente paga é aquilo que recebe?

No final de semana passada passei um micro curso, talvez até mesmo um simples overview. Por incrível que pareça isso foi feito para meu cunhado que é fã do PMI, eheheh.

Passamos por todas as etapas de execução de um projeto, sempre com exemplos e tentando encaixar os conceitos no dia-a-dia dele de gerente de projetos. Bom.. conversa vai, conversa vem e lembrei de um desenho que representa um grande paradigma do desenvolvimento e gestão de projetos.

Este desenho é um espelho da realidade, vou passar meu ponto de vista para cada um dos quadros.

Como o cliente explicou: O cliente quando explica o que quer tenta passar uma visão de algo inovador, grande ou diferente, onde nem sempre condiz com a realidade ou com requisitos técnicos.

Como o líder de projeto entendeu: Uma única pessoa (líder) conversou com o cliente (etapa anterior), coisa que não ocorre com o Scrum onde toda a equipe vai conversar com o Product Owner. Bom um único entendimento e passado adiante, gera um ruído considerável.

Como o analista planejou: Quando o analista recebeu os requisitos do líder e tentou atender as especificações e limitações, ele acaba planejando algo em cima do que compreendeu, ou seja, mais ruído.

Como o programador codificou: O programador recebe do analista o que deve fazer, mas também tem sua interpretação e novamente ruídos. Então ele codifica com todos os requisitos levantados, porém pode ser que não funcione com o esperado.

O que os beta testers receberam: Os testadores das primeiras releases do sistema receberam algo que pouco condizia com o produto esperado e logo irão fazer testes em algo que não está funcionando corretamente, pelo menos não como deveria.

Como o consultor de negócios descreveu: O vendedor faz sempre o produto parecer mais do que é, muitas vezes passando uma falsa visão de como será o produto.

Valor que o cliente pagou: Quando um projeto é feito, sabemos os riscos e o quanto de trabalho teremos, logo conhecemos também as tradicionais falhas e tudo isso é levado em conta, sendo assim este valor é repassado ao cliente, onde muitas vezes ele paga muito mais do que seria realmente preciso. 
Como o projeto foi documentado: Lembre sempre, Agile não é ausência de documentação é sim ter somente a documentação que é necessária e agrega valor após o projeto.

O que a assistência técnica instalou: Se for instalar algo para o cliente, entregue algo funcional. É isso que diz a metodologia e o bom senso é claro, afinal ninguém quer ser enrrolado.

Quando foi entregue: Lógico que atrasos acontecem, mas estamos sempre tentando entregar em dia, muito atraso desgasta a equipe a a imagem da empresa com o cliente.

O que o cliente realmente necessitava: Sempre, eu repito SEMPRE, que o cliente especifica um produto o que ele realmente precisava era algo muito menor e mais simples.

Agora se tivéssemos usado um dos princípios básicos do Scrum que é levar toda a equipe para conversar e tirar as dúvidas com o cliente (product owner), não teríamos mais excessos ou deturpações de requisitos durante o processo de construção do produto. Se resolvêssemos esta parte já teríamos uma grande economia para o cliente, deixaríamos ele mais satisfeito e pouparíamos a equipe, podendo ainda receber novos projetos em um menor período de tempo.

Abraços!