O Verdadeiro Time dos Sonhos

O Verdadeiro Time dos Sonhos

Pense num time de desenvolvimento super eficiente. Um time ágil, rodando Scrum, por exemplo. Pode ser aquele time de uma empresa que você sonha trabalhar e que todo mundo fala deles. Os caras são bons demais! Qualquer projeto que chega os caras tiram de letra e entregam voando. Eles se comunicam bem, tem bom entrosamento, são feras na tecnologia que usam. Usam as tecnologias mais produtivas, teste automatizado, integração contínua e continuous delivery de dar inveja…

Então, tá com ele na cabeça aí, né?

Aí chega um cliente novo e fala assim:

Estou com um problema aqui. Meu produto está vendendo pouco. É um sistema web que fornece um serviço para o Brasil todo, mas a tecnologia está obsoleta, a gente não consegue escalar fácil, e o layout está feio e isso tem atrapalhado as vendas. Preciso de uma nova versão com tudo que tem ali, só que melhor e mais bonito.

Você percebe que é um ótimo projeto para o seu time. Vai mantê-lo ocupado por um bom tempo e o cliente tem dinheiro para bancar o time. Então, você decide que vai tocar o projeto.

Você faz uma reunião com o time, explica tudo e já deixou marcado o dia e o horário para o time conhecer o cliente e também o sistema antigo dele. Também, já para começar o detalhamento das funcionalidades do novo sistema.

Logo após as reuniões iniciais, onde vocês criaram uma big picture do projeto, você e seu time conseguem passar uma estimativa inicial para o cliente:

Vamos levar 7 meses segundo o nosso histórico de velocidade, mas isso pode variar um pouco pra mais ou pra menos. Conforme formos conhecendo melhor o seu caso e nosso histórico se ajustar melhor teremos uma ideia melhor do prazo.

Seu time segue no ritmo de detalhar, desenvolver, validar, colocar em produção. Alguns bugs aparecem. E como é um time ágil, isto não é um grande problema, os defeitos são poucos e o time é muito eficiente para resolvê-los e garantir que não voltem a aparecer.

Depois de 2 meses de trabalho e mostrando resultado para o cliente a cada duas semanas, as estimativas indicam agora que vocês vão levar cerca de 7,5 ou 8 meses para concluir a nova versão.

Seu cliente acha razoável, afinal vocês estão mostrando um progresso a cada duas semanas e ele já confia em vocês.

E a vida segue… o desenvolvimento segue.

Depois de 9 meses o produto está concluído, quase tudo já está em produção. Os usuários precisam ser treinados… Uma campanha de divulgação precisa ser feita e por aí vai…

Termina a história desse time e desse projeto.

Dream Team… Será?

Aí eu te pergunto:

O que poderia ser feito diferente nesse cenário?
Esse time cometeu algum erro? Se cometeu, onde?

É o seguinte… O time (analistas de requisitos, desenvolvedores e o Product Owner) se esqueceu de um detalhe bem lá no início. E isso pode ser crucial para todo o projeto.

No final do projeto, o cliente vai ter o que ele pediu lá no início? Vai ter uma versão nova do sistema?

Sem dúvida! O time é fera, usa as melhores práticas e tal…

O cliente vai estar satisfeito no final do projeto?

Provavelmente sim. O time entregou o que ele pediu.

Só que depois de entrar totalmente em produção, será que o sistema novo vai ter resolvido o problema do cliente? Será que terá ajudado a aumentar as vendas?

Bom aí eu não tenho tanta certeza…

O que faltou lá no início foi investigar um pouco mais o que realmente estava gerando poucas vendas. O time assumiu que o cliente já tinha uma resposta para isso, aceitou a versão do cliente de que o tecnologia obsoleta e o layout feio eram as causas das baixas vendas.

E qual é o custo disso? Para o cliente é investir 9 meses em um projeto que ele não tinha a menor ideia se iria resolver o problema dele? Sim, o cliente tem parte da responsabilidade disso também. Mas é nosso dever como profissionais não assumir que o cliente sabe fazer o diagnóstico certo do problema dele.

É aquela história do médico. Se você chegar no médico assim: “Doutor, estou sentindo uma dor aqui do lado esquerdo do peito e vou precisar do remédio Xulambs pra melhorar meu coração.” É claro, que o médico não vai te receitar o Xulambs de cara. Ele vai fazer o diagnóstico dele antes.

O Verdadeiro Dream Team

Investigar a causa raiz do problema do cliente é fazer o diagnóstico. É encontrar o problema real por trás das poucas vendas. Será que ele fez uma pesquisa com os usuários para saber a opinião deles? Será que o problema é realmente a tecnologia obsoleta? Será que o layout é realmente ruim para os usuários dele? Será que todo o sistema é ruim ou é só parte dele?

Quando começamos a fazer perguntas e, principalmente, a perguntar os porquês, começamos a descobrir o problema real, a causa raiz. Tem até uma técnica para isso chamada de 5 Porquês (ou 5 Whys). Onde se pergunta o porquê seguidamente até se encontrar a causa raiz. Um exemplo:

O carro não liga (o problema)
Por quê? – A bateria acabou. (Primeiro porque)
Por quê? – O alternador não está funcionando. (Segundo porque)
Por quê? – A correia do alternador está quebrada. (Terceiro porque)
Por quê? – A correia do alternador foi bem além de sua vida útil e não foi substituída. (Quarto porque)
Por quê? – Não foram feitas as revisões periódicas conforme recomendado. (Quinto porque, uma causa raiz)
Fonte: https://en.wikipedia.org/wiki/5_Whys

É claro, que nem sempre é fácil responder aos porquês. Às vezes vamos precisar fazer alguma investigação, conseguir números e métricas, fazer algumas pesquisa com usuários, entre outras coisas.

O importante é resolver o problema certo. É ser eficaz. Afinal, como dizia o Peter Drucker:

“Não há nada tão inútil quanto fazer eficientemente o que não deveria ser feito”.

Ser muito eficiente (o time ágil é muito eficiente) fazendo o que não deveria ser feito (resolvendo o problema errado) é inútil.

Vamos voltar ao nosso exemplo. O cliente que estava satisfeito com o time durante o projeto, tem grandes chances de voltar a ter o mesmo problema pouco tempo depois do projeto terminar. E ficar insatisfeito novamente. Por que tem grandes chances do problema de poucas vendas não ter sido resolvido e voltar a aparecer por que a causa raiz não foi encontrada e tratada.

Caso o time tivesse feito um diagnóstico do problema, se tivesse tentado encontrar a raiz do problema, ao invés de ir imediatamente para a solução, é muito provável que este time teria resolvido o problema em menos tempo e com uma solução melhor. Gastando menos dinheiro do cliente. E ainda deixado o cliente realmente satisfeito.

3 Grandes Erros

Você viu o primeiro de 3 Grandes Erros no desenvolvimento de software. Para conhecer outros dois muito comuns, baixe o eBook – 3 Grandes Erros no Desenvolvimento de Software. O segundo tem a ver com a interação entre as pessoas e o terceiro…  Melhor deixar você mesmo descobrir… Clica aí embaixo e faça o download do eBook.

Clique aqui e baixe o eBook.

%d blogueiros gostam disto: