Quando o cliente nos deve algo

Em um dos meus últimos artigos, busquei explicar a necessidade que possuímos, como empresas e desenvolvedores de soluções em TI, de buscar a fidelidade de nosso cliente, além de alguns passos a serem seguidos por nós para que possamos alcançar esse nível de relação.

Como já abordei anteriormente, não somos somente nós que devemos fornecer ‘coisas’ aos nossos clientes: eles também possuem obrigações conosco. Vamos discutir aqui quais são esses pontos que não devem ficar em aberto.

 Veja abaixo os itens que podemos cobrar de nosso cliente:

1. Responsabilidade por seus dados: Um dos principais problemas que as empresas desenvolvedoras de software encontram é o cliente que não possui pessoal dedicado para cuidar de sua infraestrutura de TI. Às vezes, até nos colocamos à disposição do cliente para instalar o serviço de banco de dados, para que ele enfim possa utilizar nosso sistema, mas temos de saber a hora de ‘abandonarmos’ essa responsabilidade. Afinal, se o backup não funcionar algum dia, e foi você quem configurou a rotina a ser executada no servidor, a culpa irá cair em cima da sua empresa (mesmo que não seja de fato).
2. Manter uma estrutura de rede adequada: Montar uma rede não é simplesmente passar cabos, ligar switches e instalar o sistema operacional de rede. Os cabos devem ser de boa qualidade, conectores bem grimpados e o switch deve estar apto a suportar grande carga de utilização. Evite emendas e cuidado com interferências que podem surgir pelo fato de os cabos de rede serem passados na mesma tubulação de cabos de energia. Em relação a esse ponto, devemos pensar que se a rede, por algum motivo, cai ou fica lenta, nosso usuário final sempre dirá que ‘O sistema está lento’ ou ‘O sistema está fora do ar’, nunca a rede. E aí parece que o software é que foi mal feito.
3. Planejar quantos e quais servidores serão necessários: Se são poucos usuários e acessos, tudo bem compartilhar em um mesmo servidor várias funções (tipo servidor de domínio e do SQL na mesma máquina). Mas se o seu sistema possuir vários acessos ao mesmo tempo, já deve ser considerada pelo menos a utilização de um servidor exclusivo para o banco de dados. Servidores de aplicações e páginas Web também são bastante exigidos e deve ser analisada a ideia de um servidor exclusivo para essa função também. É importante notar que se o site do cliente cai, e consequentemente sua aplicação, a identidade do cliente deixa temporariamente de existir para o público que talvez não terá tempo para uma segunda tentativa.
4. Não mexer naquilo que não deve: As informações que estão hospedadas no banco de dados do nosso cliente pertencem a ele próprio, independentemente de sermos nós os desenvolvedores da aplicação e até mesmo os responsáveis pela gestão do banco de dados. Não é por causa disso que o usuário, muitas vezes conhecedor do tipo de banco de dados que usamos, pode sair alterando informações ou apagando dados por fora da aplicação. Inserir, apagar ou mesmo alterar dados pode disparar triggers que destruam todo um cadastro ou procedimento. Ele deve ser conhecedor da estrutura e das consequências do seu banco de dados. Essa informação só pode ser passada por nós desenvolvedores da aplicação (ele não deve ficar brincando com os dados para aprender sua estrutura).
5. Fornecer acesso a dados para manutenção, se necessário: Em alguns momentos, necessitamos realizar manutenção diretamente no banco de dados de nossa aplicação. O cliente precisa fornecer acesso aos seus dados, mesmo que não totalmente atuais, mas o mais próximo possível disso para que possamos escrever o procedimento de ajuste. De nossa parte, é importante escrevermos o procedimento de ajuste de forma que pegue também dados que não estavam presentes na base que foi fornecida, bem como não afete dados benignos que foram criados depois.
6. Validar alterações quando for isso solicitado em um tempo determinado: O cliente solicitou um novo recurso. Você desenvolveu e o devolveu ao seu cliente para testes. Pronto, agora ele deve testar e verificar se o desenvolvimento ficou da forma que ele pretendia e dar o retorno. Parece lógico, mas nem todos os clientes nos dão retorno sobre aquilo que pedimos que ele validasse. Se necessário, fixe um prazo para obter a resposta, após o qual, no caso de não obtenção de posição, o procedimento será considerado validado e funcionando. Se o item necessitar de manutenção após esse tempo, ele não receberá prioridade, sendo tratatado como os demais itens que necessitarem de ajustes. Use isso com moderação.
7. Liberar portas e criar rotas em sua rede: Nossos clientes necessitam que suas redes sejam seguras. Porém, eles têm de estar cientes de que para algumas aplicações funcionarem, determinadas portas e mapeamentos necessitam ser feitos. Forneça a eles a lista de portas e caminhos a liberar. Quando os dados necessitam passar por plataformas diferentes, o cuidado é maior. Por exemplo, certa vez tive muito trabalho para colocar um sistema com SQL Server para rodar passando por servidor firewall Unix até descobrir que não era só criar as rotas, mas apontar o servidor Unix para SQL Server e também este para o Unix via arquivo Hosts, ignorando totalmente qualquer DNS que estivesse no meio do caminho (que acabava por desviar o pacote). O pior: na época não tinha a internet plenamente à minha disposição para procura da solução.
8. Liberar acesso a site ou ftp de atualização de nossas aplicações: Se você instalou no cliente um serviço de atualização automática da sua aplicação e depois, com uma mudança no ambiente de rede, ele bloqueia o acesso do servidor ao seu serviço de atualização, o próprio cliente será prejudicado, pois não contará sempre com a versão mais atual. Informe a ele de que forma se dá o seu processo de atualização automática e solicite a liberação do acesso ao webservice, site ou ftp. Se o cliente não deseja que o sistema seja atualizado diretamente, mas sim passar por um processo de validação interna primeiro, não tem problema. Mas lembre a ele que a validação necessita ser feita rapidamente, pois os demais usuários estarão esperando pela atualização.
9. Relatar os erros de forma correta: É difícil corrigir um erro se a informação não é completa. Se o cliente quer a correção de algo no menor tempo possível, deverá fornecer todas as informações necessárias para a reprodução do erro. Caso contrário, corremos o risco de até mesmo sermos enganados por um teste mal feito devido à falta de informações.

Claro que, além desses itens descritos acima, o nosso cliente também necessita cumprir com suas obrigações financeiras conosco. Mas isso já é tão implícito na relação desenvolvedor X cliente, que não me dei ao trabalho de explanar aqui.

É importante abordar pontos que às vezes não estão claros e que, muitas vezes, o cliente joga a responsabilidade para cima de nós, desenvolvedores, equipes de suporte e implantadores, seja por total desconhecimento ou não.

Necessitamos de atenção para colocarmos as responsabilidades nas mãos de quem é seu dono de fato e não sermos prejudicados por um acúmulo das que não nos pertencem, mas estão nas nossas costas.