O uso define o produto | K21

Compartilhe

O uso define o produto

20/04/18 - 3 minutos de leitura

  • …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

Compartilhe

Escrito por

Magno De Santana

Agile Expert e Trainer na K21


Apaixonado por inovação, com experiência em desenvolvimento de produtos digitais utilizando práticas de Design Thinking, Lean Startup e Desenvolvimento Ágil
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Qual a diferença entre critérios de aceitação e Definição de Pronto (Definition of Done)?
20/03/24
4 minutos de leitura
A agilidade morreu mesmo? Como será o futuro do trabalhador do conhecimento com a Inteligência Artificial?
22/02/24
3 minutos de leitura
Cemitério Mexicano: Comemorando os produtos que não fizemos
07/02/24
10 minutos de leitura
5 Tipos de Vieses Cognitivos (Cognitive Bias) comuns no desenvolvimento de produtos
09/10/23
8 minutos de leitura

    Receba mais conteúdos K21

    Deixe seu nome e email que nós te deixamos por dentro de tudo que rola por aqui.

    Ao informar meus dados, eu concordo com a Política de Privacidade.