Como destruir o produto perfeito.

Uma idéia genial, que resolve problemas reais do cliente, depois de um período de desenvolvimento entra no mercado vende bem, tudo para dar certo! Mas que de repente dá errado! Por que?

A grande verdade que a abordagem de começar um produto e entregá-lo ao mercado o mais rápido possível, pode se tornar um pesadelo tanto para clientes quanto para as próprias empresas. E isso vale para qualquer indústria. Mas, neste artigo vamos tratar de questão relacionadas ao desenvolvimento de sistemas.

De uma boa idéia a um produto que entrega o que o cliente precisa.

Ter uma boa idéia não é garantia de ter um bom produto! O processo de validação deve ser respeitado. Ainda mais se você não é especialista no mercado que está atendendo. A fase de plannejamento muitas vezes é ignorada, simplesmente pela urgência do Time to Market, e veja bem não estou falando do planejamento do software, estou falando do planejamento do produto.

Sem um bom planejamento de produto o desenvolvimento começa míope e o empreendedor veste um cabestro para o mercado que deseja atender. Para tanto você pode usar um grande números de técnicas que discutiremos depois em outro artigo.

Planejar e arquiteturar sua solução!

Não importa se falamos de um sistema de informática, um software, ou o sistema de atendimento ao cliente de uma empresa, o fluxo de como o trabalho deve ser feito, e preciso se determinar a sequência de atividades, para podermos realizar duas coisas:

1. Ter pontos de controles claros
2. Detectar aonde as alterações devem ser feitas

Sim não basta entregar aonde o cliente quer, mas você tem de saber aonde e como mudar quando seu cliente tiver um problema, bem como ser capaz de se adaptar quando o seu cliente quiser algo difrente.

Matando o produto ideal, na ânsia de antender o cliente.

Diversas requisições, mudanças constantes de prioridades e falta de clareza, para quem trabalha com desenvolvimento de sistemas são a nossa realidade. A pior coisa que um profissional de produto pode querer fazer é desrespeitar o processo. Seja ele qual for, ao tentar gerar alterações mais rápidas, através de alterações rápidas diversos problemas são gerados:

1. Quebra de outras funcionalidades;
2. Perda de adaptabilidade do produto atual;
3. Aumento de custos de manutenção;
4. Desgaste da equipe

Tudo isso gerado por comportamentos que parecem ser pequenos, como mudar um sprint no meio, ou mandar fazer uma alteração rápida ao invés de demorar mais para respeitar a interface comum.

Lembre-se seu cliente pode ser muito importante para você agora, mas você pode matar a oportunidade de atender 10 outros no futuro na ânsia de atendê-lo agora!