- …vai entregar no prazo?
- …quantos por cento 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 à geração de impacto e de valor que as organizações tanto buscam.
Em cenários como estes, é comum observar que muito tempo e dinheiro são gastos sem expectativas de impacto significativo sobre a estratégia da empresa e até mesmo sobre as necessidades dos clientes.
Quando questionadas 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 sobre a 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 ao 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 de suas entregas, ou seja, em 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 no processo de desenvolvimento de produtos de software. Quanto tempo e dinheiro desperdiçados na construção de produtos de 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 para 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 a todos os critérios, apenas à 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 significa 90% de algo que não funciona? 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
Os 9 princípios do Usage-Driven Development (UDD)
Curtiu e se identificou com as dicas? Deixe seu comentário ;D
