Produto & UXARTIGO

Quando o seu produto só atrapalha

Vitória, capital do Espírito Santo, assim como tantas outras cidades possui um serviço que fornece ao cidadão, via internet e tendo como base GPS instalado nos ônibus, a informação do tempo que falta para que o próximo ônibus de cada linha passe no ponto de ônibus escolhido.

O objetivo principal, conforme divulgado pela prefeitura, é evitar que o usuário fique esperando muito tempo no ponto de ônibus: ele só sairia do seu serviço ou residência instantes antes de o ônibus realmente passar.

O serviço foi lançado oficialmente em outubro de 2010. Porém, ao final do mês seguinte, quando a população já estava começando a se acostumar com o mesmo, motoristas e cobradores de ônibus da capital e cidades vizinhas entraram em greve. Estavam legalmente protegidos, pois avisaram com vários dias de antecedência e mantiveram 50% dos ônibus rodando

No mesmo dia do início do movimento, meu carro apresentou um problema e eu tive de pegar carona para ir ao trabalho. Na volta pegaria ônibus, mesmo tendo de esperar mais, mas verificaria o horário que o ônibus iria passar pelo serviço descrito acima.

Eis então que, próximo ao horário de fim da jornada de trabalho, entrei no site do serviço e, para minha infeliz surpresa, o site apresentava apenas a mensagem \’Serviço indisponível durante a greve\’.

Na mesma hora, ainda com o choque e a sensação de incredulidade, pus-me a monitorar o termo do nome do serviço no Twitter e percebi que a indignação não era só minha: a todo segundo pipocavam tweets de pessoas que estavam contando com o serviço para retornarem às suas casas, e agora se viam obrigadas a esperar por tempo indeterminado o seu ônibus. Frustrados.

Tudo bem que nas greves passadas esse serviço ainda não existia e o usuário tinha que esperar, mas desde o momento que começou a funcionar, a população passou a confiar e, na verdade, até a depender dele. E aquele momento era a hora em que todos mais necessitavam do mesmo.

Todo desenvolvedor deve estar ciente de que existem horas em que o seu produto NÃO PODE falhar. Devemos estar atentos desde o momento da concepção de nosso produto até o da manutenção.

Abaixo veremos quatro supostas causas de o serviço citado no começo deste artigo não estar disponível e o porquê de termos de saber lidar com as mesmas:

  • O serviço ou produto foi mal feito porque exige recursos que não existem na totalidade

Procurei apurar sobre a ausência do serviço com pessoas ligadas à área de TI e com \’contatos\’. Me disseram que o motivo real de o serviço sair do ar foi porque nem todos os ônibus possuíam de fato GPS instalado, e para os ônibus que não possuíam era feito um cálculo que utilizava como base a informação obtida dos que o tinham. Para tentar diminuir seus custos, as empresas de ônibus apenas teriam colocado para rodar os ônibus antigos, sem o equipamento.

O erro aqui é contar com algo, no caso informação, que nem todos os seus alimentadores de informação (no caso os ônibus) poderão fornecer. Se o seu sistema encontra-se nessa situação, na verdade ele não deveria entrar no ar até este requisito ser plenamente preenchido. Do jeito que está hoje, a informação para os ônibus sem GPS é até mesmo incorreta.

  • O produto estabelece muitas regras que nem sempre poderão de fato ser seguidas

A prefeitura da cidade publicou em seu site a informação de que a previsão não poderia ser feita durante a greve porque o horário dos ônibus era calculado sempre tendo como base o horário inicial previsto de saída do ponto final, o qual não seria cumprido pelos grevistas.

Todo sistema deve considerar a hipótese de que os seus dados venham em uma ordem ou a partir de um procedimento que não foi inicialmente previsto. É imprescindível estar pronto para tratar isso de alguma forma sem que deixe de funcionar.

No exemplo do serviço de horários de ônibus, se a causa realmente foi a defendida pela prefeitura, o serviço também não poderia estar no ar, pois é muito fácil que a regra de o ônibus sair do ponto inicial no horário correto não seja cumprida. E não é necessária uma greve, e sim qualquer atraso ou retenção no trânsito que o impeça de chegar no ponto de início (nesse caso, um ponto final) a tempo de iniciar a próxima viagem na hora certa.

  • O sistema não foi feito tendo como base aquilo que o cliente buscava

O que o usuário final, cidadão e cliente do serviço de informação sobre horário de ônibus desejava? Simples, saber apenas a que horas passaria o seu ônibus.

O cliente não quer saber de que forma você obterá uma determinada informação. Ele apenas quer tê-la, e você é pago para que desenvolva como fornecer esses dados. Agora, a partir do momento em que você disser para ele que o sistema está gerando a informação, ele passará a cobrar para que sempre possa obtê-la. E que ela esteja correta.

No caso do exemplo deste artigo, o serviço foi feito para atender apenas aquilo que a prefeitura queria (que o usuário, em dias normais, não gastasse tanto tempo nos pontos), mas não o que o seu usuário final realmente desejava.

Um detalhe importante: é preciso saber que nem sempre o seu cliente real é o seu cliente direto – aquele que contrata sua empresa para a criação de um produto. Muitas vezes, o cliente real é na verdade o cliente do seu cliente. No próprio exemplo do serviço, o cliente real da empresa desenvolvedora não era a prefeitura, que a contratou, mas sim os usuários do transporte coletivo.

  • Os interessados não foram informados de que o sistema sairia do ar a tempo

A prefeitura somente publicou em seu site (não para meios de comunicação em massa como sites jornalísticos), às 17:12 do primeiro dia em que a greve já estava ocorrendo, que o serviço estaria fora do ar. Esse é o horário em que muitas pessoas já começam a deixar seus postos de trabalho e já estavam então tentando usar o serviço. Se ela já sabia que o serviço não poderia funcionar na greve, por que não avisou às pessoas mais cedo, por meio da imprensa, para que talvez elas nem mesmo saíssem de casa?

Vai tirar o seu produto do ar por qualquer motivo? Planeje e divulgue que isso ocorrerá, para que o seu usuário final prepare-se para isso. Isso evitará que ele fique \’a pé\’, decepcionado com o produto, e talvez ainda contamine outras pessoas com a sua insatisfação.

é analista de implantação desde 2005. Já atuou como professor, administrador de redes, gerente e analista de suporte. Atualmente é Analista de Implantação da Qualidata, e também escreve no blog.qualidata.com.br.

Ver perfil