Finalizando a sequência que iniciamos alguns artigos atrás além de itens sobre coisas que o cliente pode te pedir – mas que você não tem obrigação de fazer – vou escrever sobre o modo como devemos implementar ideias novas oferecidas por nossos clientes: melhorando-as.

Se você perdeu os antigos anteriores, confira o conteúdo já publicado:

• Não faça tudo o que o seu cliente pedir – Parte 01: Ética
• Não faça tudo o que o seu cliente pedir – Parte 02: Firula

Atendendo pedidos

Entenda que quando o seu cliente pede alguma modificação, na maioria das vezes, ele está apresentando sempre duas coisas:

1. Uma nova forma de fazer algo, ou simplesmente algo realmente novo (O que é muito bom).
2. O ponto de vista DELE sobre aquele algo (O que pode ser muito ruim).

É óbvio que o problema de se desenvolver algo sob o ponto de vista de apenas um cliente tem mais chances de ocorrer quando você desenvolve/vende/dá suporte a um produto.

Mas, na minha opinião, é uma ótima prática desenvolver sempre pensando em ter vários clientes daquele determinado sistema, mesmo que atualmente só se tenha um. Dessa forma, você estará preparado para clientes futuros desde já.

Criando soluções úteis

Voltando ao assunto deste artigo, a questão é que o cliente conhece o problema para o qual a nova solução se destina somente do ponto de vista próprio. Raros (bem raros mesmo) são os clientes que têm uma visão do todo ou que pensam em uma forma que outras pessoas poderiam adotar.

E você precisa lembrar que aquela solução pode não ser útil somente a este cliente que te solicitou, mas sim a todos os outros clientes que utilizam o seu produto. Ou pode ser que esta nova ‘coisa’ dificulte a vida dos demais clientes se for implementada da forma original.

Se optar por desenvolver o solicitado pelo cliente, faça a análise antes do desenvolvimento e também antes de passar um orçamento, verificando de que forma você poderia adaptar a nova funcionalidade aos demais clientes.

Entre em contato com eles, explicando o que você está se propondo a fazer, coletando mais e mais informações com o objetivo de que a sua implementação saia o mais generalizada possível.

Coletando dados e explicando os objetivos ao cliente

Durante este contato, tenha cuidado para não falar ‘Eu tive uma ideia…’ ou ‘Fulano de tal (seu outro cliente que teve a ideia original) propôs..’. Na primeira situação, pode ser que o cliente que você está contatando conheça o cliente original e você será acusado de estar se apropriando da solução.

No segundo caso, pode ser que este outro cliente seja um concorrente do cliente original e não gostaria nem de ouvir falar o nome dele, muito menos ouvir ideias dele. Ainda há a possibilidade de o cliente achar que você passa informações de um para o outro.

Mude os pontos que achar necessários. Se for o caso, altere o fluxo das ações e, principalmente, traduza os termos usados pelo seu cliente para que possam ser entendidos por qualquer pessoa e não somente por aquele cliente específico, ou clientes de sua cidade/região. Vale lembrar que pessoas de locais diferentes usam termos diferentes mesmo que todos falem português e a área de trabalho seja a mesma.

Adaptando o projeto à prática

Outro ponto importante é adaptar a novidade àquilo que a sua tecnologia/linguagem de programação, framework ou ambiente permitem. Se você não consegue realizar o que é pedido em apenas um passo, mas sim em três, faça isso.

Mas esteja pronto para explicar o porquê para o cliente (mesmo que ele não compreenda completamente) para que ele não se sinta enrolado e ache que você não está valorizando suficientemente.

Para citar um exemplo: se você precisa exportar dados da sua aplicação para o MS-Word, você pode fazer tudo via uma simples API do Windows e um clique bastará para que você exporte os dados e já abra o editor.

Já se você precisa exportar e abrir os dados para xxx Office (Open ou Libre), possivelmente você terá de exportar dados primeiro para um XML e depois realizar uma chamada direta para a aplicação. A aplicação talvez não permitirá tratar mensagens de erro e ainda vai exigir outros cliques do usuário, bem como tratamento dos dados exportados.

Claro que existem ‘n’ formas de fazer esta ação, mas como disse no começo deste parágrafo isto foi apenas um exemplo.

Benefícios e consequências

De toda forma, evite desenvolver apenas para um cliente. Se conseguir fazer com que a funcionalidade tenha aplicação ampla, você obtém vários benefícios como:

• Ter realmente agregado valor ao seu produto;
• Conseguir uma maior visibilidade da implementação, do suor e do valor gasto naquele desenvolvimento;
• Talvez possa cobrar pela implementação não só de um, mas de vários clientes;
• Pelo motivo acima, poderá cobrar menos do cliente que propôs a ideia, já que agora poderá partilhar custos. Isso fará com que aumente as chances de ele concordar em pagar pelo seu desenvolvimento. Esse fator também torna mais fácil o convencimento para que boas ideias não sejam cortadas por falta de financiamento.

Cuidado em implementar agora, e talvez até de graça, algo idêntico ao que foi negado para outro cliente no passado. Mesmo que tenha sido passado um orçamento e ele é que não tenha aceitado pagar.

Na primeira oportunidade que tiver, quando você for passar um novo orçamento para desenvolver outra coisa, o cliente que teve a solicitação negada, não aprovada ou que não aprovou o custo, poderá fazer brincadeirinhas de mal gosto sobre a recusa para bancar determinada implementação porque “sabe” que é só um outro cliente mais importante pedir que você acabará fazendo de graça. Ou seja, pode minar sua relação com este outro cliente.

Para finalizarmos esta série, volto à uma recomendação que já foi dada no segundo artigo: Cuidado para que boas ideias não sejam cortadas.