Uma entrevista da QE Unit que partilha a história da Lovys, de start-up para scale-up, onde a qualidade fez a diferença.
O João Macedo Pinto é o CTO da Lovys, uma empresa que revoluciona os seguros tradicionais oferecendo uma solução digital all-in-one em modelo de subscrição mensal.
Esta entrevista partilha as várias etapas de crescimento da prática de engenharia da Lovys, e como ela teve de suportar o crescimento da empresa, de start-up para scale-up.
A aposta em qualidade de software e o quality engineering permitiu a Lovys continuar o seu crescimento, mostrando o valor de um investimento em uma qualidade holística.
Junte-se à QE Unit para aceder a conteúdos exclusivos da comunidade.
Sobre o João Macedo Pinto
Dedicado ao alinhamento da tecnologia com as reais necessidades do negócio.
Na Lovys, estamos criando um novo conceito de seguro tudo-em-um, permitindo que as pessoas tenham uma interface simples para todas as suas necessidades de proteção, desde a integração até os sinistros, e paguem uma única assinatura mensal em vez da complicada combinação de apólices de hoje.
Co-fundou e desenvolveu o Prometheus na UpType, uma solução de gerenciamento online que organiza, compila e analisa automaticamente os dados de uma empresa praticamente sem custos de integração.
Experiência internacional em Business Intelligence, Data Warehousing / Engenharia e desenvolvimento de Software, bem como consultoria para a indústria de Telco, e-Commerce, GOV e Saúde (Angola, Nigéria, França, EUA) e gerenciamento de equipes / projetos.
Antoine: Pode começar por se apresentar?
Neste momento, estou CTO na Lovys, uma InsurTech que opera na área dos seguros. Para além do trabalho, sou pai de duas crianças com uma belíssima mulher que anda muito atarefada nesta altura do COVID!
Na Lovys sinto que fizemos um percurso interessante no domínio do QA (Quality Assurance). Para contextualizar, a Lovys não é uma seguradora tradicional: é uma empresa que tem por base a tecnologia para disponibilizar os seguros, fornecendo uma plataforma digital. A Lovys pretende fazer com os seguros o que os Neo Bank fizeram na área financeira há alguns anos atrás. Temos os exemplos dos Revolut, N26, Activobank que vieram trazer o modo 24/7 à indústria da banca, muito diferente do paradigma existente.
Estamos a mudar os hábitos tanto na parte de processos como na parte de digitalização. O nosso lema é precisamente “Digital Insurance for Everyone”, consumidos através do digital. Há dois fatores diferenciadores na Lovys: somos multiprodutos adaptado a oferta a geografia, e somos multi-países. De momento fornecemos quatros produtos core, sendo um adicional em França, e por exemplo o seguro de smartphone em Portugal. Esta lógica geográfica envolve uma expansão que vai acontecer nos próximos meses, ainda não posso dizer onde 🙂
Vendemos seguros num modelo de subscrição com um único pagamento mensal, independente do número de apólices e opções. Os clientes têm flexibilidade de ligar ou desligar serviços, e podem interagir com a Lovys a qualquer momento.
Antoine: Este modelo 100% digital cria uma forte pressão na disponibilidade da plataforma, e então no IT?
Todos os negócios digitais tem uma exposição 24/7 onde os serviços devem estar disponíveis. A temática do Business Continuity é um verdadeiro tema para nós; temos de garantir que estamos online 24/7, em todos os nossos canais e plataformas. Oferecemos contactos diretos para os nossos clientes: 2 website, 2 apps nativas, e 1 back-office.
A nossa oferta sendo muito em self-service, deixando o cliente interagir com o seu seguro sem ir num balcão, reforça a criticidade dos dispositivos. A app deve sempre funcionar, e não só a parte de front-end ou da montra, mas bem de todo o ecossistema. É um desafio gigante, em caso de falha a exposição é muito impactante, não afeta apenas uma rua.
Antoine: Quais são os elementos chaves da vossa arquitectura para fornecer essa plataforma digital?
Em primeiro, como a maioria das start-up e scale-up, utilizamos vários fornecedores de serviços Cloud. Estamos presentes na Google, como na Azure, ou na AWS, para necessidades diferentes. A Google Cloud Platform é mais na vertente de Data & Analytics, a AWS para R&D, enquanto a Azure suporta 90% do core dos serviços.
Do ponto de vista da arquitectura, iniciamos com um monolito que está a caminho da modularização. A separação segue uma abordagem por Domínio, em Domain Driven Design (DDD), onde identificamos as áreas do monolítico associado ao negócio. O objetivo desta evolução é de permitir escalar o processo de desenvolvimento e as equipes. Uma base de código tem um limite de números de developers que podem colaborar ao mesmo tempo. É aí que a segregação permite alocar mais equipes por diferentes bases de código.
Em termos de tecnologias, usamos bastante a stack da Microsoft, nomeadamente .NET Core. Na parte do Front-end, utilizamos Vue JS, Angular, Swift, ou Kotlin para criar experiências adequadas. Temos várias equipas de desenvolvimento com um mix de expertise, de experiência e de localização que acaba por criar partilhas interessantes. Muitas melhorias estruturantes vieram de pontos de vista divergentes, sinto muito isso.
Antoine: Mencionava um percurso interessante de QA na Lovys, onde que se insere?
Na realidade quando começamos, foi sem uma qualidade oficialmente formalizada. Tínhamos uma grande pressão de criar o produto onde os developers eram os principais contribuidores. Depois desta primeira fase, apareceu um primeiro layering entre o front e o back-end. A Lovys tal como opera em vários mercados, tem escritórios em vários países, está no nosso ADN.
Tínhamos o back-end em Leiria, o front-end completamente remoto na Ucrânia, foi nesta altura que me juntei à empresa, já sentia a necessidade de QA. Fizemos salto grande em maturidade da organização; passamos a ter full-stack squads, com unidades pequenas tendo todas as competências necessárias. Houve uma fase onde a equipa de Produto não era integrada, que acabamos por rapidamente recuperar. Estamos agora no que chamamos de nível 4 de maturidade, com Talent Pool por cada tipo de posição que juntamos por missões. É o modelo de organização que até agora nos permitiu responder melhor às necessidades e projetos.
Antoine: Percebi que fizeram um investimento em QA; normalmente investimos o nosso dinheiro para resolver um problema. Qual era o vosso?
O QA surgiu como um balde de água fria: o número de bugs estava a aumentar drasticamente. No Q3 do ano passado, tínhamos 74 defeitos registrados no sistema, e no Q4 já eram 170, um aumento de um factor de 2.5. Aconteceu não tanto por piorar a qualidade dos desenvolvimentos, mas pela aceleração forte que tivemos. Os bugs cresceram da mesma forma que a nossa base de funcionalidades, código e equipas.
Os nossos ciclos de release contavam um período de estabilização post-release equivalente a tempo de desenvolvimento. Tínhamos de agir. Cada release tinha impacto em serviços que precisam de correções live, impactando o desenvolvimento das próximas funcionalidades. As equipas deviam concentrar-se na estabilização, não era fácil fazer deploy ou rollback, envolvia alterações de códigos.
“Não queríamos um batalhão de testers no final da cadeia; tínhamos de resolver os problemas raízes, desde o início.”
João Macedo Pinto
Fomos confrontados a várias questões aqui para resolver essa da qualidade. Não estivemos apenas focados na qualidade no fim da cadeia, queríamos uma qualidade presente desde o início. Por causa disso, não fomos para uma batalhão de testers para verificar em ambiente de staging o produto; não ia resolver as causas raízes, mantendo uma limitação ao crescimento da empresa. Queríamos incluir a qualidade nas várias etapas do processo dentro do nosso contexto Agile, o mais cedo possível.
Estávamos a crescer a equipas de desenvolvimento sem conseguir escalar o desenvolvimento, devido aos vários rollbacks e reworks.
Antoine: Estavam mesmo a sentirem-se confrontados com os factores limitantes do vosso sistema de desenvolvimento?
Claramente, não conseguimos acompanhar o crescimento, a mais de não fornecer a User Experience (UX) ou Business Continuity ambicionadas.
O grande desafio é que não tínhamos competências internas em QA, não podíamos fazer o setup sozinho de QA. Ao mesmo tempo, estávamos imersos num backlog grande de projetos. Sendo uma start-up a procura de Venture Capital (VC), o produto devia estar pronto e dinâmico. O tempo médio de entrega de uma feature é uma métrica bastante importante neste contexto de investimento. Nesta altura precisávamos de 1 mês e meio a 2 meses para estabilizar o site, não era sustentável.
Foi esse meu exercício de reflexão que me levou a “chamar um amigo”. A maioria da equipa de engenheira estava em Leiria e optamos por uma solução de proximidade com a empresa atale.io, por acaso localizada no mesmo espaço de escritórios.
“O grande desafio em capacitar a empresa com QA era não ter competências internas e um backlog mais que cheio.”
João Macedo Pinto
Confiamos toda a estruturação dos assuntos de qualidade de forma a capacitar a nossa empresa, das fundações até a aceleração tão procurada. Atuamos em muitas áreas, revendo os processos de desenvolvimento de software para incluir a qualidade desde o início; pedimos ajuda para encontrar, formar e acompanhar a criação da nossa equipa e prática de QA.
Houve um trabalho de evangelização com as equipas de desenvolvimento, a qualidade não começa nem acaba com os testes unitários. Apesar de termos uma boa cobertura, não resolve tudo, especialmente problemas de integração. Essa melhoria da awareness foi importante para os diversos actores que intervêm na cadeia de valor.
Montamos pipelines de Continuous Integration e de Continuous Deployment (CI/CD), até um ponto de maturidade que não estava à espera de conseguir. Temos padrões de quality gates, reviews, gradual deployment, rollback, e ligação às users-stories. Essas fundações e modelos ajudam na distribuição do sistema, já temos a receita pronta para novos desenvolvimentos.
Antoine: Incluir as equipas de QA dentro de processos, rituais e outros mecanismos de colaboração?
Sim, trabalhamos com cerimônias do Agile sem estar num puro modelo Scrum. A QA faz parte dos diferentes momentos de partilha entre as equipas. QA tem uma palavra a dizer em todas as etapas dos processos, não só na parte final. QA para de ser uma camada final para passar a ser uma peça integrada no resto dos processos.
“QA tem uma palavra a dizer em todas as etapas dos processos.”
João Macedo Pinto
Os nossos primeiros engenheiros de QA tiveram um foco particular em automação de forma a garantir a cobertura das várias áreas já presentes. Apostamos numa automação pensada para captar valor deste investimento inicial e contínuo em manutenção. Nós definimos as prioridades com base nas áreas do produto que são mais críticas, mais core-business. É o caso do funnel de conversão, da criação de conta, ou da subscrição em self-service, indispensáveis aos nossos clientes e muitas vezes alterados. Temos em benefício um grau de confiança grande da estabilidade desses serviços mesmo com alterações a serem feitas.
Antoine: Este ponto de confiança que mencionas é interessante; o valor da qualidade não é só técnico ou de dashboards. Existe bem uma parte humana ligada à confiança e ao relacionamento entre o Business e o IT?
Podemos ter todos os dashboards do mundo, KPIs, semáforos; há uma confiança que obtemos de toda essa supervisão. Essa relação de confiança é gradual. Começa com o “What you see”, um site que funciona, “Is What You Get”, no dashboard tudo verde. Se houver um semáforo verde e um site que não responde, temos um problema. É um ponto de atenção para nós, não exageramos na monitorização para limitar falsos negativos.
“A relação de confiança é gradual, mostrando o alinhamento entre negócio e IT.”
João Macedo Pinto
Usamos uma série de ferramentas diferentes para realizar isto. A ferramenta de automação de testes é o Katalon, num modo low-code. É bastante potente, permite-nos automatizar testes a plataformas web, mobile nativas, APIs, com flexibilidade de scripting. Podemos ter uma abordagem data-driven testing usando ficheiros de excel com os vários casos. O Katalon TestOps é o módulo onde temos os reportings disponíveis.
Temos uma integração com a nossa ferramenta de ticketing que é o Azure DevOps. De momento referenciamos os testes ligados às user-stories, conseguimos nas execuções de pipeline obter o estado das verificações. O Azure DevOps é mais do que uma gestão de backlog, é uma verticalização de ferramentas para suportar o processo de desenvolvimento. Disponibiliza o backlog, os repositórios, as pipelines de CI/CD, os testes cases e repositório de artefatos. Essa integração permite ter uma visão integrada entre requisitos, desenvolvimento e entregas. Em melhoria, queremos utilizar a noção de test case do Azure DevOps para uma melhor visibilidade.
Antoine: Qual é o balanço que podem tirar deste investimento, experiência e resultados? O problema inicial ficou resolvido?
Em poucas palavras, temos uma confiança muito grande na robustez das nossas soluções. O temos é válido tanto para a parte de quem recebe, o negócio, de quem produz, o IT. Hoje, o negócio sabe que vai receber algo estável, enquanto o IT sabe que pode detectar anomalias e corrigir em tempo e horas.
“Hoje temos confiança na robustez das nossas soluções.”
João Macedo Pinto
Todo esse investimento permitiu-nos entregar o site onde tínhamos reais dificuldades, foi um sucesso. Mais que isso, fazemos agora deploys a cada 3 dias. Isso acontece sem downtime e um números de defeitos muito reduzido. Se comparamos ao volume antigo, são mesmo residuais. Para nós, uma start-up que vira para uma scale-up, a aumentar sua capacidade de execução e de engenheira, é fundamental. Podemos andar rapidamente sem ter medo de partir o que existe.
Antoine: O objetivo acaba por poder sustentar o ritmo de transformação e de mudanças da empresa?
Exatamente, eu acabo por poder transformar a cara da empresa, o seu armazém, as suas operações com pouco risco de trazer defeitos até a produção. Digo isto com muita confiança mesmo, temos uma cobertura que permite isso.
Claro que o QA por si não chega. Há muitos processos interligados que contribuem para essa capacidade, a qualidade deve ser resolvida globalmente, numa perspectiva holística, integrada nos vários processos. Associo a noção de qualidade o facto de uma user-story ter acceptance criterias bem elaborados e claros. QA não é só automação, não é só escrever testes, deve trazer mais-valias para as outras áreas.
“Uma grande lição aprendida é de estar atento aos primeiros sinais.”
João Macedo Pinto
Detectar, decidir e agir rápido é fundamental, ainda mais neste ecossistema das start-ups onde o custo/oportunidade é importantíssimo. O tempo que podemos perder em rework, tem muito mais valor se aplicado às tarefas de maior valor acrescentado. De vez em quando, executar mais rápido pode ser necessário, sempre consciente que o custo da fatura vai ser muito mais alto a seguir.
Um conselho que dou é de incluir o QA desde o início.
Tal como identificamos é uma questão de trade-offs, neste contexto de start-ups não existe uma regra, é preciso escolher e adaptar consoante ao contexto. Manter uma transparência e comunicar os impactos das decisões que tomamos é muito importante. Ainda mais quando temos de fazer um atalho sem QA, o trade-off deve ficar visível.
O QA ajuda por acaso neste aspecto da comunicação, traz para a mesa uma série de elementos pela observabilidade que fornece. Isso suporta a melhoria dos processos.
Antoine: Esta comunicação permite atingir todos os stakeholders?
Podemos usar o exemplo de um novo botão na interface. Se só respondermos que demora uma semana na única perspectiva de desenvolvimento, a pessoa fica pensativa “Uma semana para por uma butão? Está a falar sério?”. A contextualizarmos que essa alteração envolve implementação em vários devices, plataformas, testes, gerir os vários casos nominais e de erros, a perspectiva muda. Ter abertura, criar um espaço de discussão com uma linguagem comum facilita a colaboração.
Antoine: Quais são as vossas perspectivas, prioridades e eixos de trabalho?
Fruto do investimento feito em consultoria para criar uma capacidade de qualidade, conseguimos atuar com uma equipa relativamente junior. A prioridade é complementar a nossa Talent Pool de QA com perfis mais sênior de forma a estender o modelo na organização e o seu impacto. Temos de acompanhar o crescimento, contamos duplicar o nosso headcount até o final do ano.
Uma parte importante do meu trabalho é o recrutamento; conseguir colaborar com os vários elementos de forma a traçar um caminho partilhado.
Agora, é uma questão de velocidade e de qualidade da execução, sem dar passos atrás.
Referências
Lovys, “The first insurance you’ll love”: https://www.lovys.com
Atale.io, empresa que apoiu a Lovys: https://atale.io
Katalon e Katalon TestOps: https://katalon.com ; https://www.katalon.com/testops/
Azure DevOps: https://azure.microsoft.com/en-us/services/devops/