Quer fazer bons produtos, saiba quem são os seus clientes

Olá pessoal, tudo certo?

Você já tentou responder quem são os seus clientes e o que eles realmente esperam de seus produtos e/ou serviços?!

Esta pergunta não é tão fácil de responder quanto possa parecer inicialmente. Provavelmente, nem todos em sua organização sabem claramente quem são os seus clientes. Talvez, você mesmo ignore parte importante dessa resposta.

Como você pretende montar boas arquiteturas ignorando quem são seus clientes?

Quem são seus clientes?!

Um cliente é qualquer um que:

1. Pague por seus produtos;
2. Use os seus produtos;
3. Ofereça suporte (técnico ou não) para os seus produtos;
4. Extraia algum valor (direta ou indiretamente) de seus produtos.

Além disso, considere:

Se você está trabalhando em um subsistema (parte de um sistema maior). Então, todos os outros envolvidos com os demais subsistemas também são seus clientes.

Aqueles que pagam…

Frequentemente, os primeiros “clientes” que lembramos são aqueles que pagam por nossos sistemas. Os famosos sponsors.

Agora, proponho um desafio. Pergunte-se:

1. Por que alguém está disposto a pagar pelos seus produtos e/ou serviços?!
2. Que problema eles querem resolver?
3. Quais são as suas principais restrições e/ou considerações?

Considere:

Os sponsors normalmente não dão muita importância para os detalhes de um produto, desde que seus objetivos principais estejam sendo atendidos.

É importante identificar e entender quais são esses objetivos.

Considere manter foco “especial” para os objetivos do sponsor, preferencialmente, de forma independente dos demais detalhes de implementação.

Aqueles que usam o sistema …

Geralmente, as pessoas que usam nossos produtos não são aquelas que pagam por eles. Ainda mais comum é que os objetivos dessas pessoas também sejam diferentes.

Lembre-se:

os usuários são pessoas que têm um trabalho a ser feito, e eles esperam que nossos produtos os ajudem a fazer esse trabalho de forma mais efetiva e cômoda.

Mais importante:

Os usuários têm o poder de “boicotar” a implantação de um produto. Deixe-os insatisfeitos e conquiste poderosas resistências.

Naturalmente, buscamos subordinar os “desejos” de nossos usuários as vontades dos sponsors. Mais uma vez, lembre-se que é raro encontrar um sponsor com interesse no operacional.

Aqueles que fazem tudo funcionar…

O “deploy” de um produto costuma ser apenas “o início efetivo de sua história”.

Você sabe quanto tempo é necessário, e com que facilidade, os produtos que você desenvolve começam a gerar resultado?!

Você considera o tempo necessário para instalar seus produtos? E para treinar os usuários? Aliás, quanto treinamento é necessário para que “aqueles que usam” possam fazer algo útil em seu sistema.

Para pensar, você considera:

• quantas vezes seu produto “caí” em ambiente de produção?
• quanto tempo e esforço é necessário para colocar tudo “no ar” novamente?
• quanto tempo e esforço são necessários para identificar e eliminar causas de falhas?
• o custo das falhas de seus sistemas para seus clientes?

O custo de manter um sistema, devido a sua (aparente) perpetuidade sempre será maior que aquele para o desenvolver.

Perceba que:

a manutenabilidade de um sistema não deverá ser medida apenas pela dificuldade em alterar código. É importante considerar os demais envolvidos.

Geralmente, é inteligente assumir um custo maior de desenvolvimento do que postergar “dívidas técnicas” que causem transtorno para o futuro.

Aqueles que extraem valor de seus produtos ….

Em termos claros:

• Quanto dinheiro novo seu produto ajuda a gerar?
• Quanto disperdício seu produto ajuda a evitar?

De forma resumida, essas são as duas considerações mais importantes que todos deveriam fazer durante o desenvolvimento (ou evolução de um produto).

Você pode potencializar seus produtos considerando que está atendendo não apenas a um “ponto” isolado, mas toda a cadeia de suprimentos relacionada a seus clientes.

Enfim…

Conhecer os clientes. Sem manter “foco nos clientes”, mas desenvolvendo o “foco dos clientes” é a forma mais efetiva de identificar o que é (ou não) importante em um sistema.

Nossos clientes não nos contratam para desenvolver software. Eles nos contratam para resolver problemas.

Conhecer os clientes é passo fundamental para montar a estratégia de desenvolvimento. Em outras palavras, é fundamental para definir um padrão coerente para tomada de decisão que é base para uma boa arquitetura.

Por hoje, era isso