Você provavelmente não sabe o que é um iPaaS, essa dúvida é comum para a maioria das pessoas, até mesmo as que trabalham com desenvolvimento de softwares.

Um iPaaS (Integration Plataform As A Service), como o nome já diz, é uma plataforma de integrações disponibilizada como serviço, fazendo integrações entre softwares dentro de um ecossistema.

Em resumo, a maioria das empresas desenvolve suas integrações internamente, gastando muito esforço, técnico e principalmente intelectual com desenvolvimento e sustentação dessas integrações.

Segundo Gartner, até 2019, iPaaS será a plataforma de integração escolhida para novos projetos de integração. Ultrapassando as plataformas de software tradicionais pela primeira vez.

Como nasceu o LinkApi e qual seu propósito

O LinkApi nasceu em 2017 para resolver o trauma de criar integrações de software. Nosso CEO Thiago Lima, fala sobre esse trauma em seu artigo “Software Integrations são um Trauma. Aqui está o porquê.“.

Nosso propósito é revolucionar a experiência de quem cria e de quem consome integrações de software.

Acabamos de lançar uma nova versão da nossa plataforma. Essa versão foi fruto das nossas experiências no dia-a-dia da operação e dos feedbacks evolutivos de diversos clientes.

Agora vou contar para você em detalhes como nosso time de produto é formado. E como projetamos, e construímos uma plataforma para resolver esse trauma.

Nosso ciclo de entregas

Trabalhamos somente em alta performance, nossos ciclos de entregas são de duas semanas.

Inicialmente experimentamos um ciclo de uma semana, porém percebemos que com esse formato não tínhamos o tempo necessário para desenvolvermos e testarmos nossas entregas como deveríamos.

Separamos nossas entregas por ciclo em dois tipos:

  • Grandes entregas: grandes recursos ou coisas que provavelmente levarão as duas semanas completas para serem concluídas. Normalmente, realizamos um projeto deste tipo em um ciclo de duas semanas.
  • Pequenas entregas: coisas menores, ajustes, ajustes menores e adições fáceis que devem levar de um dia a uma semana para serem concluídos.

Normalmente, realizamos entre 4 e 8 projetos de pequenos lotes em um ciclo de duas semanas.

Criamos um roadmap e adicionamos as tarefas a serem entregues referentes a nova plataforma. Separamos os todo’s por telas e criamos etiquetas para identificar se a tarefa era da Plataforma, API, Engine, etc., pois nesse momento fazia mais sentido que separarmos por features.

Se alguma entrega do nosso roadmap ultrapasse o ciclo nós a quebramos em pequenas entregas, seguindo o conceito de MVP (Mínimo produto viável).

Quem faz o trabalho

Nosso time de produto é composto por quatro pessoas, divido em três Desenvolvedores Full-Stack e um UX Designer. Temos a intenção de aumentar nosso time, porém sem inflá-lo demais, culturalmente acreditamos no poder de times pequenos e talentosos.

Atacamos as tarefas em dois formatos:

  • Singular: em pequenas entregas, uma ou duas pessoas do time atuam de forma isolada.
  • Em bloco: em grandes entregas, com prazos extremamente agressivos ou correções de bugs que estão prejudicando nossa operação, o time todo é acionado.

No futuro, pretendemos dividir nosso time de produtos em squads de 3 a 4 pessoas, acreditamos que esse é um número ideal para isso, se aumentarmos o time mais, corremos o risco de aumentar exponencialmente a complexidade de nosso trabalho.

user-experience-e-as-integrações

Como decidimos o que íamos fazer

A primeira coisa que fizemos foi utilizar da metodologia Design Thinking para identificar quais eram as personas que utilizam nosso serviço. E também quais suas principais dores em relação ao dia-a-dia com integrações em seus respectivos trabalhos.

Após uma imersão em profundidade identificamos duas personas:

LinkApi-integrações de software

Usuário Técnico: trabalha com desenvolvimento em Software Houses, Consultorias, SaaS’s e Fábricas de Software, constrói integrações de software e as distribui, possui proficiência em desenvolvimento de softwares, conhecimento de nomenclaturas técnicas, facilidade na utilização de ferramentas digitais e análise de código.

Usuário Não Técnico: trabalha com operação de empresas, consome integrações de software, não possui conhecimento de nomenclaturas técnicas, alto interesse e conhecimento por assuntos relacionados ao seu business, dependente de pessoas técnicas para assuntos relacionados aos softwares da sua empresa.

Principais dores apontadas por estas personas:

  • Possuir uma visão holística das integrações e o que acontece nelas
  • Complexidade de criar uma integração
  • Manter uma integração
  • Visualização de erros de uma integração
  • Complexidade de distribuir integrações

Depois de identificada as personas e suas dores, desenhamos o que acreditamos ser a jornada ideal. Tanto para quem cria, como para quem consome integrações de software. Essa jornada é constituída por 3 etapas.

integrações de software-saas

Jornada das Integrações de Software

Build: Construção das integrações, o usuário vê as aplicações disponíveis para integrar, ele mesmo constrói seu fluxo de integração dentro da nossa plataforma.

Magic Distribution: Após criar suas integrações o usuário pode distribuí-las para seus clientes, seja por meio de nossas APIs, nosso SDK ou da nossa Integration Store.

Advanced Monitoring: Depois de distribuí-las, tanto o usuário técnico como o não técnico, tem controle de todas as integrações que possui, por meio de logs gerados a cada execução de uma integração. Para usuários técnicos, gera-se um log em JSON com o descritivo completo do retorno da integração. Para os usuários não técnicos é gerado um log amigável somente com a mensagem de sucesso ou erro retornada.

Como projetamos a plataforma

Sabíamos que a mudança seria drástica na nova plataforma, tanto em questão de funcionamento como em tecnologia. Tudo seguindo nosso objetivo de otimizar ao máximo nosso trabalho e mitigar possíveis erros.

Para isso, prototipamos todas a interfaces antes de desenvolvermos, boa prática comum em times ágeis de desenvolvimento de software. Assim, pudemos fazer validação de hipóteses rapidamente, ter maior assertividade do que deve ser feito e mais objetividade no desenvolvimento.

Neste processo de prototipação eliminamos diversas telas presentes na plataforma antiga que não eram utilizadas. Seja porque não eram necessárias, ou então porque os clientes não entendiam seu objetivo.

Para sermos mais assertivos e coletarmos feedbacks em tempo real, disponibilizamos para nosso time de vendas e CS um ambiente de demonstração para que eles apresentassem a nova plataforma para clientes e prospects.

Decidindo como íamos construir a plataforma

Para aumentarmos nossa velocidade de entrega, optamos por usar frameworks que o time dominava tecnicamente. Para o front-end utilizamos Angular 5 com SCSS como pré-processador de CSS e o framework CSS Bootstrap 4, para o back-end utilizamos NodeJS.

O portal anterior utilizava Angular 2 como framework JS e como framework de CSS utilizava-se o Materialize. Optamos pela mudança de framework CSS porque o Bootstrap possui uma gama muito maior de componentes disponíveis que são compatíveis com o Angular 5.

O que vem a seguir

Participamos como patrocinadores de diversos eventos, como: ERP Summit, VTEX Day e Superlógica Xperience. Apresentando nossa nova plataforma e features.

Ficamos muito animados com os feedbacks de clientes e prospects recebidos até o momento. Mas sempre dizemos que estamos só começando.

Nossos próximos releases estimados são:

  • Trial do portal (se você não quiser esperar o lançamento você pode entrar no nosso site e solicitar uma demo)
  • Gerenciamento de time e usuários
  • Integration Store Embedada
  • Integration Store CMS
  • Integration Store pagamento online
  • Otimização da documentação da nossa API

Se você quiser ver em detalhes a nova plataforma, entre no nosso site e solicite uma demonstração.

Nos próximos artigos vou detalhar o processo de como projetamos e desenvolvemos as principais features da nossa plataforma.

(Visited 164 times, 1 visits today)

Posts Relacionados

Compartilhe!
Bitnami