Plataforma Web - Gestão de Contas Correntes

Hoje em dia, com tantos softwares e plataformas disponíveis no mercado, criar uma plataforma web para gerir as contas correntes de uma empresa, não é uma decisão que deva ser tomada de ânimo leve. Têm que existir razões objectivas e muito fortes para o fazer.

No entanto, este é um caso real de uma empresa que opera num nicho de mercado, com necessidades específicas, que não encontrou no mercado softwares que lhe permitisse gerir as contas correntes de forma eficaz.

Aconselho sempre os clientes a gastarem tempo e recursos à procura de uma solução disponível no mercado.

Mas acima de tudo, definir muito bem quais as necessidades reais da empresa, para definir com clareza as especificações da solução. A fase de análise, deve envolver todos os futuros utilizadores da plataforma, O compromisso de todos é a palavra de ordem. 

Uma plataforma deste género, desenvolvida à medida e de raíz tem um custo elevado, tempo e no final deve ser uma aposta ganha para a empresa.

Solução Antes da Nossa Solução

A empresa geria as contas correntes dos clientes com recurso a ficheiros microsoft excel,  Uma gestão muito manual, que na prática não impunha regras nem constrangimentos. Uma gestão possível se estivermos a falar de poucas transacções, mas um pesadelo, se estivermos a falar de centenas de transacções por mês, como é o caso presente.

Uma solução que obrigava a uma grande disciplina, grande margem para cometer erros e ainda por cima, dada a complexidade, não era fácil no dia a dia, integrar outros membros na equipa para ajudar a gerir as contas correntes (risco elevado).

Para além do mais, os envios de emails de pagamentos, e de pagamentos em atraso, eram efectuados de forma manual. Como estamos a falar de centenas de transações por mês, podemos facilmente perceber que estamos perante um sistema complexo de gerir e de fraca controlabilidade.

Solução Implementada

Optou-se por criar uma plataforma web específica que integrasse as regras e especificidades do negócio.

Desde o início que houve uma grande preocupação em criar uma interface muito simples e de grande usabilidade. Paralelamente apostou-se na criação de relatórios verdadeiramente úteis e de um sistema de pesquisa transversal à plataforma.

A pesquisa mostrou-se uma ferramenta essencial. Todas as pessoas que trabalham com softwares de facturação e contas correntes, muitas vezes para encontrarem o que pretendem tendem a usar muitos cliques. Um verdadeiro pesadelo, para uma utilização quotidiana e intensa. A pesquisa que implementamos, para além de procurar de forma transversal, nas várias entidades que compõem a plataforma (documento, clientes, pagamentos etc), permite pesquisar por valor (muito útil).

As plataformas/softwares podem ter uma infinidade de funcionalidades e ecrãs, mas nas aplicações transaccionais, é fundamental que o utilizador tenha uma sensação de controlabilidade. Isso só é possível alcançar com  uma boa interface, que organicamente permita ao utilizador gerir e usar a plataforma como uma ferramenta ao serviço do negócio.

Um facto importante no desenvolvimento desta plataforma, prendia-se com um prazo muito apertado. Era essencial ser pragmático e muito eficiente.

Processo e Metodologias de Desenvolvimento

Tudo começou com uma conversa telefónica e o envio de um email com as especificações gerais. É relevante referir, que há um longo historial de colaboração com este cliente.

O mais importante no início é tentar perceber o negócio, os fluxos de informação, os problemas que a solução atual apresenta e acima de tudo, colocarmo-nos no papel do cliente.

Com a informação disponível, criamos um protótipo não funcional com o desenho dos ecrãs mais importantes. Para isso, usamos o Bootstrap sobre uma plataforma genérica, criada pela BETACODE para projetos web.    

Os protótipos são uma ferramenta muito poderosa para delinear as especificações do projeto, esclarecer ambiguidades, amadurecer conceitos, adicionar novas ideias e abandonar algumas. Um verdadeiro laboratório vivo.

É também nesta fase que é importante que todos os intervenientes chamem as várias entidades (fornecedor, cliente, etc) pelo mesmo nome. Um aspecto que tem repercurssões em toda a estrutura de programação. É muito mau sinal, quando a meio do projecto os vários intervenientes, dão nomes diferentes para definir a mesma entidade/conceito. Pessoalmente acho que, o nome a dar a cada elemento é de máxima importância e de grande dificuldade. À medida que o tempo passa e são adicionadas novas funcionalidades e ligações entre as várias entidades da aplicação, ter os nomes correctos, é uma grande mais valia.

Também relevante,  a BETACODE apenas comunicou com um elemento do lado do cliente. Este por sua vez era o porta voz de todo o feedback da empresa. Desta forma, foi possível manter uma comunicação estremamente clara, eficaz e centralizada.

Um à parte, mas que não posso deixar de referir. O uso correto do email em processos que envolvem muita troca de informação é crucial. Quando o mesmo email é aproveitado para vários assuntos (reply), quando o email é usado como um chat entre vários intervenientes, quando cada email tem um encadeamento "infinito", pode tornar-se num verdadeiro pesadelo. Toda a comunicação deve ser pautada por uma grande assertividade e objetividade.

Segunda Fase: Desenvolvimento

À medida que o protótipo não funcional foi evoluindo, com toda a informação e clarificação que o mesmo fornececeu, passou-se à fase de desenvolvimento de software (sobre o protótipo não funcional). Isto é, passou de um protótipo meramente visual, para um protótipo funcional. Todo o trabalho de css/html foi aproveitado e melhorado.

É crítico não passar à fase de desenvolvimento cedo demais. Porque na fase inicial de desenvolvimento do software, é a fase da estruturação das várias camadas de software, classes de programação, esquema da base de dados.

Qualquer passo em falso nesta fase, pode representar um aumento exponencial de tempo perdido (custos) e atraso no projecto, ou pior, obrigar a uma série de remendos no futuro.

Começamos por desenvolver as funcionalidades mais simples, de modo a criar o mote e coerência e ir ganhando confiança nas especificações iniciais.

Sempre que foi implementada uma funcionalidade, enviamos um vídeo a explicar o que foi feito. O cliente acedia à plataforma, validava com a sua equipa, detectava erros e enviava sugestões.

Também criamos uma rotina, para fazer o reset da base de dados, para ser mais fácil testar funcionalidades sem ruído de dados antigos.

Para cumprir com o prazo apertado, foi essencial que por cada nova implementação, o cliente rapidamente testasse e validasse. Confesso que houve muitas situações de alterações quase em tempo real. 

Terceira Fase: Testar, Testar, Testar

O desenvolvimento de uma plataforma deste género, que "mexe com o dinheiro" dos clientes, pela sua responsabilidade, não pode ter erros ou induzir o operador a erros.

Para além dos testes conduzidos ao longo de todo o processo de desenvolvimento, optou-se por testar já com a plataforma terminada, com a participação de todos os utilizadores.

Ao contrário do que se possa imaginar, testar um software é uma tarefa difícil e complicada. Quem participa no desenvolvimento/programação, e naturalmente testa, acaba por conduzir os testes de forma viciada.

Cabe ao cliente, estar motivado para testar, com dados reais e testar com cenários menos comuns, para tentar detectar erros e incoerências.

Já com uma visão completa da plataforma e dos fluxos de trabalho necessários, foram introduzidos links e informação contextual em vários ecrãs. Fundamental, para criar um ambiente de grande usabilidade. A utilização diária de plataformas com problemas de usabilidade, é um fator de fadiga e de baixa produtividade.

No mundo real do desenvolvimento de software, acontece muitas vezes, a introdução de novas funcionalidades, provoca erros em módulos já testados e funcionais. Por isso, testar software é um autêntico carrossel.

Quarta Fase: Live, a Prova de Fogo

Entrada em funcionamento da plataforma e estar preparado para resolver rapidamente os erros que surgem. É preciso não dar razões de rejeição para algum utilizador mais relutante na mudança. O homem como animal de hábitos é muitas vezes avesso à mudança. Com frequência a implementação de novos processos ou softwares falha, não por questões tecnológicas, mas sim, relacionadas com o factor humano.

Esta aplicação não fugiu à regra,  no momento que foi para o ar, com dados reais, por coincidência no primeiro dia, apareceu uma situação nova e que não tinha sido testada. É mesmo assim, depois de tantos testes, acontece.

De qualquer forma, esta plataforma passou com distinção a prova de fogo com a entrada em funcionamento e o desligar da "aplicação" anterior.

Relatórios e Dashboards

Uma das maiores dificuldades em sistemas transacionais prende-se com a questão dos relatórios/dashboards. Quais os relatórios verdadeiramente importantes para os utilizadores desempenharem as suas funções com eficiência ?

O problema agrava-se quando os softwares/plataformas permitem com facilidade a criação de relatórios todos bonitos, mas que depois no dia a dia, não têm grande utilidade.

A nossa abordagem passou por criar apenas os relatórios/dashboards estritamente necessários, e esperar que com a utilização do dia a dia, nos traga informação para implementar novos relatórios ou para alterar os já existentes.

A grande angústia, é saber  quais os relatórios que não foram implementados, mas que seriam de grande utilidade. Muitas vezes, com o passar dos dias, os utilizadores , habituam-se às plataforma/softwares, por pior que sejam ao nível da qualidade de informação e usabilidade. Se não existir um sentido crítico, os problemas podem-se eternizar.

Os relatórios não são abstrações com gráficos, tabelas, mas são uma ferramenta essencial de informação para gerir a empresa.

Novas especificações a meio do processo

Num ambiente de grande confiança, estabilidade e fair play, foram introduzidas novas funcionalidades e especificações a meio do projecto.

Uma coisa é ter um problema e apontar uma solução. Outra é depois a sua concretização. Só num processo "work in progress" é que é possível chegar ao fim com um sistema que sirva os interesses reais da empresa e tenha uma validação real por parte dos actores a quem se destina (utilizadores).

A pior coisa, é quando a "política" e burocracia tomam conta de um projecto. No final, ninguém fica feliz.

Interface e Usabilidade

Procuramos desenvolver uma aplicação do ponto de vista visual o mais simples possível, com recurso ao Bootstrap, sem grandes "floreados".

O mais importante foi desenvolver com clareza os ecrãs ao nível da informação,  criar uma lógica e hierarquia, criar as ligações pertinentes entre os ecrãs e associar a cada ecrã a informação relacionada de forma lógica e útil.

Foi dado grande ênfase à pesquisa, de modo a encontrar com grande precisão a informação. Por exemplo, um dos requisitos, depois da plataforma entrar no ar, foi pesquisar por clientes que tenham um dado valor a débito. 

Outro aspecto a que demos importância, foi criar uma grande coerência visual e funcional entre os vários ecrãs. Por isso, os primeiros ecrãs implementados assumiram grande importância em todo o desenvolvimento.

Algumas Funcionalidades da Plataforma

• Importação e consolidação dos clientes a partir de uma outra plataforma web do cliente.
• Importação de dados diversos necessários ao funcionamento da plataforma, armazenados em Google Sheets
• Exportação dos relatórios e dos dados, de alguns ecrãs, para Microsoft Excel (para manipulação de dados e/ou envio aos clientes)
• Automação do envio de emails para o cliente de acordo com a situação/contexto. Alguns exemplos: email de pagamento efetuado, email de pagamentos em atraso, etc.
• Criação e edição de documentos, clientes, etc

Devo confessar que a implementação de algumas regras do negócio, foram um desafio interessante.

Futuro e Novos Desenvolvimentos

Uma aplicação como esta naturalmente que vai sofrer alterações, melhorias e a incorporação de novas funcionalidades.

Por isso, é muito importante, dar grande importância e gastar energia com uma programação/arquitetura bem estruturada, coerente, flexível e  fácil de entender. É importante, quando for necessário alterar alguma coisa, que a equipa de desenvolvimento, rapidamente, se sinta num ambiente familiar e coerente. 

Uma área de novos desenvolvimentos, que achamos que esta plataforma vai precisar,  é ao nível dos dashboards de performance e indicadores.

Conclusão

Considero o desenvolvimento desta plataforma web um sucesso a todos os níveis. O prazo, as especificações e as expectativas do cliente foram alcançadas.

Podemos estar a falar de processos que envolvem tecnologia, mas o mais importante para alcançar o sucesso, são as pessoas. É uma frase já gasta, mas na minha longa experiência de programador, cada vez mais penso assim.

Também penso que a maior vantagem na criação deste software, foi termos optado por um desenvolvimento "work in progress", com um cliente que sabia muito bem o que queria e que se empenhou em todas as fases, para criar uma ferramenta que além de útil é crítica ao negócio.

Como nota final, não apresentamos qualquer screenshot da plataforma web desenvolvida, porque o cliente achou por bem não o fazer. O Segredo é a alma do negócio.