- …vai entregar no prazo?
- …quantos porcento já entregamos?
São as perguntas que costumamos ouvir quando estamos envolvidos no desenvolvimento de software.
No primeiro momento parece ser uma pergunta inofensiva, mas ao observar os comportamentos gerados nas pessoas, pode ser um desincentivo na geração de impacto e valor que as organizações tanto buscam.
Em cenários como este é comum observar muito tempo e dinheiro sendo gastos sem expectativas de impacto significativo sobre a estratégia da empresa e até mesmo sobre as necessidades dos clientes.
Quando questionado sobre a não entrega, as equipes encontram maneiras de justificar os maus resultados com “só precisamos de mais tempo” ou “da nossa parte está tudo ok, só falta…”, adiando qualquer decisão para entrega de valor e onerando ainda mais o orçamento da empresa.
Observando algumas organizações neste cenário, identificamos alguns problemas em comum:
- custo alto de coordenação: vivendo no caos: e-mails intermináveis, prazos estourados, reuniões para marcar reuniões, ou seja, passamos maior parte do tempo trabalhando para justificar a não entrega do que de fato trabalhando para entregar;
- perda de aprendizado: como o foco é entregar coisas em um prazo determinado, as pessoas não sabem qual problema estão tentando resolver e qual o impacto para o negócio, gerando uma visão míope de propósito e consequentemente times reativos (esperam sempre decisões dos seus superiores);
- ROI ausente: sensação de completude com base em atividades concluídas e não em entregas de valor para os clientes, sem valor entregue para os clientes não há ROI;
- software estocado: funcionalidades construídas não estão em produção. Não há uso, sem uso não há feedback, sem feedback não sabemos se estamos no caminho certo.
E se a eficiência do time não fosse um problema? Se tivéssemos o melhor time do mundo, estaríamos entregando valor para o cliente? Há apenas uma forma de validar isso: entregando e coletando feedback em ciclos curtos.
“O uso define o produto” (Rafael Sabbagh)
Seguindo esse raciocínio, fica claro que o problema não está na eficiência do time e sim na eficácia das suas entregas, ou seja, entregar algo de valor e impacto para o cliente, dessa forma, ele utiliza o produto e só então consegue dar feedback sobre o quão próximo ou distante estamos de resolver seus problemas.
Theodore Sturgeon, escritor de ficção científica disse que “90% de tudo é lixo”. Isso faz total sentido para o processo de desenvolvimento de produtos de software. Quanto tempo e dinheiro desperdiçados na construção de produtos que ninguém precisa. Para eliminar ou minimizar esse cenário, precisamos urgentemente mudar a abordagem tradicional de desenvolvimento, focar nos 10% relevantes e gerar impacto para o cliente:
Love the problem, not the solution
Compreenda o problema que está tentando resolver: o que é, quem sente, quando acontece… Não se perca em soluções maravilhosas de problemas que ninguém vive.
Faça algo útil
Conhecendo o problema profundamente, pense em uma solução simples e rápida, que não precisa atender todos os critérios, apenas a causa raiz do problema. Pode até ser uma solução temporária mas teste o uso com o usuário e peça feedback.
Meça o progresso com base no valor entregue
Sucesso não é marcar uma caixinha
Sucesso é ter impacto.
Se você completa todas as tarefas e nada melhora, isso não é sucesso.
@cwodtke
O que 90% de algo que não funciona significa? NADA, absolutamente NADA. A saída é focar em algo tangível, que gere impacto nos negócios e na vida dos clientes.
Descubra mais nos nossos posts:
“Quando fica pronto?” não é a pergunta mais importante
Radar do produto: Nosso time está atingindo os objetivos de negócio
Tanque de Decantação: um canvas como solução
True Agile – O que a K21 Acredita
Curtiu e se identificou com as dicas? Deixe seu comentário ;D
