Aprendendo com o inesperado: A integração mais desafiadora de Vitor Aquiles
28 de abril de 2021
No papel o projeto parecia simples, mas muitas surpresas surgiram na prática. Junto com o desgaste inevitável, houve muito aprendizado para todos os envolvidos.

No papel o projeto parecia simples, mas muitas surpresas surgiram na prática. Junto com o desgaste inevitável, houve muito aprendizado para todos os envolvidos.

Vitor Aquiles*

 

Sabe aquele projeto em que tudo dá certo? O planejamento engloba todos os requerimentos; a execução ocorre sem problemas; a entrega, consequentemente, é feita antes do previsto. É o sonho de todos nós. Bem, o projeto que eu vou relatar não foi assim. Aliás, aconteceu praticamente o contrário. Mas, mesmo desgastante, ele agregou muito conhecimento para mim e para a Digibee. 

Eu aprendi demais, tanto tecnicamente quanto no contato com o cliente. Para a Digibee, ele também serviu como aprendizado intenso numa época em que isso era muito necessário – a empresa crescia muito, ganhava clientes e precisava de feedback sobre as áreas que deveriam ser aperfeiçoadas. E nos deparamos com esse projeto que funcionou como uma aula magna preciosa para todos nós porque, apesar de todos os obstáculos, foi muito bem-sucedido.

Os obstáculos nos sistemas

Em meados de 2019, quando eu tinha sete meses de Digibee, embarquei em uma missão, que já estava em andamento, envolvendo a integração de dados entre bases Oracle e Salesforce de uma rede de hotéis. Segundo o briefing, era um projeto aparentemente simples, com três fluxos de integração, e conclusão prevista dentro de poucas semanas.

Ao longo das primeiras reuniões, entretanto, esses três fluxos de integração se transformaram em sete: cadastros de clientes, hóspedes, reservas, contratos, tarifas, estatísticas e eventos. E os desafios se estenderam aos sistemas, também. Eu logo descobri que não poderia simplesmente enviar o dado para o Salesforce, porque ele não confirmava a integração como concluída. Como eu não tinha visão completa de tudo que estava sendo integrado, precisei criar um fluxo específico para isso.

Essa questão do Salesforce trouxe um outro problema quando estávamos construindo o fluxo de integração de eventos, que demandava acesso a diferentes bases de dados. Além de eu precisar atualizar, no banco da Oracle, tudo que estava sendo integrado, eu também precisei montar um arquivo CSV para enviar à Salesforce, porque o sistema exigia esse formato específico. Os dias seguintes foram dedicados a tentar fazer uma chamada para a Salesforce e entender por que o sistema não estava aceitando o que eu enviava. Me juntei ao nosso time de produto até conseguir compreender exatamente esse cenário de erro.

Houve um outro contratempo relevante. Nosso objetivo era subir todos os fluxos ao mesmo tempo, consumindo o mínimo de recursos. Mas, antes de concluir a integração da base Oracle com a Salesforce, descobri que precisaríamos de uma carga de dados, preparando o pipeline, e fazer muitas adaptações. Nada disso estava previsto.

Problemas acumulados

O que aconteceu, em resumo, foi que demoramos um tempo para entender o verdadeiro cenário do cliente. A integração, que na superfície parecia simples, se revelou complexa à medida que mergulhávamos nos bastidores dos sistemas.

Além de tudo, houve as três integrações que viraram sete. Foi um acúmulo de coisas que precisaram ser resolvidas ao mesmo tempo. Mesmo depois de acertarmos boa parte desses problemas de sistema – em um mês de projeto, mais ou menos –, ainda levamos noventa dias para finalizar os ajustes. O processo de integração se repetiu diversas vezes.  

É nesse ponto que entra a palavra “desgaste”, que eu usei lá em cima. Foram várias reuniões com o cliente para entender por que os erros aconteciam, e o que deveríamos fazer para ajustá-los. Houve também muitos pedidos diferentes do cliente sobre o que deveria ser integrado, redefinindo as regras de negócio. Por fim, conseguimos acertar tudo e fazer os sistemas conversarem. Mas esse projeto de algumas semanas que se transformaram em quatro meses me causou uma inquietação. 

Além da demanda técnica, havia a necessidade de estar em contato permanente com o cliente  (reuniões, mensagens, e-mail, todas essas coisas) o que acabava tomando todo o meu tempo e me exigindo um foco exclusivo naquele projeto. É claro que essa situação também foi observada – e debatida – dentro da Digibee, que não podia me utilizar, como ela pretendia, em outros projetos simultâneos. Ficou evidente que precisávamos evitar aquele tipo de cenário no futuro.

Quebrando paradigmas do cliente

Depois de todos os contratempos, posso dizer, com alegria, que o projeto foi bem-sucedido. As integrações, inclusive, estão ativas neste exato momento. Resolvemos o problema de negócio do cliente, que obviamente ficou muito satisfeito. Para ele, ficou claro que as pendências estavam relacionadas aos sistemas e não ao nosso trabalho. Resolvemos tudo o mais rápido possível, e o cliente reconheceu isso ao nos dar feedback.

Nossa relação, no geral, foi muito boa durante todo o processo. A equipe da rede de hotéis não era expert em TI, mas foi muito acolhedora e receptiva. Nos deram liberdade e estabeleceram um bom diálogo para solucionarmos, juntos, todas aquelas questões. E tenho certeza de que também tiraram aprendizados importantes sobre a relevância e a necessidade de ter o “terreno preparado” internamente, em termos de tecnologia, antes de iniciar um projeto como aquele. 

O legado

Para mim, pessoalmente, a principal lição foi afinar o meu senso crítico e perceber um problema ainda quando ele está prestes a surgir – claro que contando com a ajuda das pessoas e áreas necessárias. Saí com a certeza de que havia crescido como profissional, com mais conhecimento técnico e habilidade na lida com o cliente. E também pude trazer esse feedback à Digibee para ajudar a empresa em seu processo de aperfeiçoamento.

Internamente, percebemos a necessidade de ter mais gente no time de entrega. Quanto mais crescia o volume de trabalho, mais precisávamos de braços, e muita gente foi contratada com o foco na resolução de problemas. Também ficou claro que precisávamos de um analista funcional durante todas as fases de um projeto. A ideia era que ele nos ajudasse no contato com o cliente, liberando o profissional mais técnico para focar exclusivamente na integração em si e evitar o acúmulo de tarefas.

Outro aprendizado importante foi a necessidade de entender os bastidores do sistema e alinhar tudo com o cliente desde o início, sem deixar lacunas ou definições para serem feitas no meio do caminho. A lida com situações como essas nos permite, hoje, uma comunicação inicial mais fácil com o cliente, alertando sobre os problemas que podem acontecer por causa de um planejamento mal feito. 

A tônica dessa experiência foi o amadurecimento. Em um mundo que exige cada vez mais tecnologia, precisamos estar 100% preparados para executar grandes projetos de transformação digital sem os traumas que enfrentamos no passado.

*Vitor Aquiles é engenheiro de software na Digibee

 

** Este conteúdo faz parte da série Bastidores da Integração de Sistemas. Acompanhe os próximos!

 

Leia também

Salvando o sistema: como Marcos Arruda impediu a paralisação do negócio

Sob os holofotes: Marcos Moraes e a integração que inaugurou o primeiro aeroporto industrial do Brasil

Atravessando a Muralha da China: Luiz Emmerich e a integração que ligou dois continentes

Share This