Com avanços em IA surgindo diariamente, fica cada vez mais evidente o seu impacto disruptivo. A IA vai transformar indústrias, gerar novas oportunidades, impulsionar a produtividade ao longo de todos os setores e abrir as portas para uma nova era das empresas de tecnologia.

Enquanto startups que têm IA em seu DNA nascem todo dia, companhias de setores tradicionais precisam se adaptar rapidamente a esse novo contexto. É um desafio análogo ao nascimento dos primeiros computadores, e realizar uma mudança cultural tão importante exige um esforço imenso.

A Alice e IA

A Alice é um plano de saúde para empresas que permite que os seus membros (clientes) naveguem pelo sistema de saúde de forma coordenada entre os três diferentes níveis de atenção: primária, secundária e terciária. Fazemos isso direcionando os nossos membros aos agentes mais custo-efetivos do sistema de saúde – membros com condições simples podem ser tratados por enfermeiras e médicos de família, enquanto aqueles com sintomas graves deveriam rapidamente se consultar com os especialistas.

Abordagens baseadas em machine learning e dados sempre foram centrais para essa missão. Quando a Alice foi fundada, isso significava modelos proprietários construídos por nosso time interno de cientistas de dados, e um grande foco em análise de dados.

Mas a ascensão da IA generativa mudou isso. Em vez de depender de um time específico, a nova geração de produtos permite que todo funcionário da Alice faça uso de modelos no estado da arte. Seja incorporando modelos de terceiros diretamente em nossos produtos – para, por exemplo, resumir dados médicos baseados em transcrições de consultas em áudio – ou por aplicações de dia-a-dia que nos permitem reduzir burocracia, a IA deveria ter uma presença constante em como trabalhamos.

Um estudo recente mostrou que a adoção do ChatGPT foi ampla, mas desigual. Muitos funcionários precisam de treinamento e direcionamento para aproveitar completamente os aumentos de produtividade, e muitos são prejudicados por restrições das empresas em que trabalham.

Não cair nessas armadilhas exige uma mudança cultural importante. Product managers (PMs) e times operacionais deveriam enxergar a IA como a primeira solução para todo problema com que se deparam. Isso também significa que o uso de IA deveria ser tão simples quanto possível e não exigir expertise técnica.

Transformação cultural

Para fortalecer a ideia de que recorrer à IA é simples e esperado, organizamos eventos que chamamos de “AI Day”, envolvendo toda a empresa.

Durante todo um dia de trabalho, times de todas as áreas se reuniram em nosso escritório e trabalharam em implementar vários protótipos de aplicações de IA. Esses protótipos poderiam ser lançados no mesmo dia, ou poderiam ser um ponto de partida para um ciclo normal de desenvolvimento. Os times contaram com o apoio de membros de nossas equipes de engenharia e dados, assim como outros funcionários da Alice que já haviam adotado IA como uma ferramenta de trabalho cotidiano.

Antes desses eventos, os participantes levantaram ideias para vários protótipos em uma planilha comum, a serem validados por aqueles que lideraram a iniciativa. Esses projetos variavam dos mais simples, como classificar dados de exames com base em texto não estruturado, aos mais complexos, como gerar um banco de dados com uma ferramenta de busca usando todo o histórico médico de membros.

Fornecemos uma conta no ChatGPT aos participantes com acesso a assistants. No fim de cada dia, eles apresentaram seus projetos a todo mundo presente no evento.

Tivemos três objetivos com essa iniciativa: ensinar a todos como usar IA numa base cotidiana e incorporar essa possibilidade em seu raciocínio; aumentar o ritmo de geração de novas aplicações de IA; e identificar que ferramentas nosso time de engenharia deveria desenvolver para incentivar a adoção de IA.

Esses esforços foram em grande parte bem-sucedidos. Vários dos protótipos desenvolvidos em nosso primeiro AI Day se tornaram projetos completos, e muitos outros foram implementados imediatamente. Temos visto times que não são tradicionalmente de tech usando IA em seu dia a dia, e geramos um novo roadmap para o time de Foundation em engenharia com entregáveis claros que vão impulsionar a produtividade daqueles que trabalham com IA.

Com isso, vieram aprendizados importantes:

• Depois que a porteira está aberta, é difícil segurar a boiada. Um dos principais fatores que levam times fora de tecnologia a relutarem em usar IA é que eles precisam adaptar seu pensamento a uma nova ferramenta. Quebrar essa barreira rapidamente leva a um uso acelerado;
• Transicionar para um modelo em que IA é uma parte central de como trabalhamos exige quebrar dependências. Se funcionários da Alice precisam contatar os times de dado ou engenharias para usar IA, isso significa que estamos fazendo algo errado;
• IA pode ser transformador com produtos de larga escala, sim, mas uma parte importante do valor vem da soma de muitas aplicações pequenas. Aumentar eficiência em todos os lados da companhia pode ser tão impactante quanto desenvolver um novo produto de IA.

IA como plataforma

Nossa experiência com os AI Days nos fez dividir nossos esforços para facilitar o uso de IA em duas frentes: primeiro, precisávamos simplificar o teste de novas aplicações; segundo, precisávamos fazer com que lançar novos produtos de IA fosse tão fácil quanto possível, sem abrir mão de qualidade, controle de custo ou privacidade.

Na primeira frente, nosso time de Foundation em engenharia começou a desenvolver uma plataforma de testes que permitirá que nossos usuários cumpram várias tarefas que hoje são difíceis em um ambiente no-code:

• Rodar prompts de IA que são dinamicamente atrelados a dados de teste em batch. Por exemplo, um usuário pode subir um arquivo com comentários do NPS e pedir que a plataforma rode um prompt, atribuindo a cada um deles uma classificação;
• Otimizar prompts em escala comparando o resultado de diferentes prompts sobre um conjunto de arquivos; diferentes contextos sobre um único prompt; etc.
• Conectar diretamente a nossa camada analítica pelo Metabase, garantindo que usuários não precisam inserir manualmente dados de teste;
• Gerar workflows de diferentes modelos de IA. Por exemplo, transcrever um áudio e em seguida enviar essa transcrição a um modelo de texto;
• Controles de custo e acesso por meio de uma estrutura de times que atribui orçamentos específicos para cada unidade;
• Salvar e comentar em experimentos passados, permitindo que usuários mantenham um histórico dos últimos testes de seu time;
• Fazer uso de nossa infraestrutura de anonimização e privacidade para garantir que respeitemos nossas regras de governança.

Adotamos a estratégia de lançar iterações da plataforma rapidamente e testar com usuários. Representantes de produto, operações e até nossa equipe médica foram os clientes e tiveram a responsabilidade de validar nossos planos e evangelizar seus times.

Enquanto isso, também precisávamos facilitar o deploy de aplicações que se conectassem diretamente a nossos produtos. Por sorte, trabalhar com a nova geração de LLMs é simples, e nos concentramos em garantir que os dados inseridos e gerados por esses modelos passem pelos mesmos processos que nossos dados em produção.

O futuro

A Alice acredita que IA é o futuro, e que ocupamos uma posição única que nos permite nos beneficiar de novos desenvolvimentos. Como um payvidor que atua em toda a jornada de saúde e tem acesso a dados de fontes muito diversas, produtos de dados deveriam ser tão centrais para nós quanto nossa operação médica.

Em uma publicação futura, vamos explorar os detalhes da arquitetura descrita nas últimas sessões. Mas já demos passos largos em adotar uma cultura que coloca IA no centro com nossos esforços institucionais para educar os times e com o desenvolvimento rápido de ferramentas para incentivar a adoção. O futuro é animador e há muito mais a ser feito, tanto em termos dos planos da própria Alice quanto do desenvolvimento de LLMs como um todo.

How Alice is building a culture of ‘AI as a go-to solution’

Alice believes that AI should permeate every aspect of what we do. How do we make sure that this is the case? That’s the hard part.

As advances in AI technology pop up daily, claims of its transformative impact pile up. AI is set to disrupt established industries, foster new opportunities, drive up productivity across the board and usher in a new era for tech companies.

While startups that make AI as part of their DNA are born everyday, incumbents in traditional sectors have to quickly adapt to the new environment. That is a challenge analogous to the advent of the first computers, and bringing about such a major culture change requires major effort.

Alice and AI

Alice is a healthcare company that provides direct access to our own primary care physicians as well as third-party secondary and tertiary care. We do this by directing members to the most cost-effective agent in the healthcare chain – members with simple conditions can be treated by nurses and family doctors, while those with aggravated symptoms should be rapidly attended on by specialists.

Machine learning and data-based approaches have always been core to how we accomplish that mission. Back when we were founded, this meant proprietary models built by our in-house data scientists and a strong reliance on analytics.

But the ascent of generative AI has changed this. Instead of relying on a specific team, the new generation of products allows every single Alice employee to make use of state-of-the-art models. Whether it is by embedding third-party models directly into our products, such as by summarizing medical data based on consultation audio transcripts, or by day-to-day applications that allow us to reduce bureaucratic work, AI should play a constant role in how we work.

A recent paper showed that adoption of ChatGPT has been widespread, but has been unequal. Many workers require training and guidance to fully benefit from productivity increases, and many are hindered by company restrictions.

Not falling into those traps requires a major culture change. Product managers and operational teams should see AI as the number one go-to solution for every problem that arises. It also means that the use of AI should be as hassle-free as possible and does not require much technical expertise.

Culture change

In order to establish the idea that tapping into AI is easy and expected, we ran company-wide events known as “AI Days”.

For a whole working day, teams from across the company would gather in our office and work on implementing several POCs of AI applications that could either be rolled out on the same day or would kickstart a regular development cycle. They would be supported by members of the engineering and data teams, as well as other Alice employees who had already adopted AI as a day-to-day working tool.

Before those events, participants would brainstorm possible POCs in a common spreadsheet to be validated by those leading the initiative. These would range from the simplest, such as tagging exam data based on unstructured text, to the more complex, like generating a searchable database based on members’ full medical history.

Participants would be provided with a ChatGPT account that granted them access to assistants. At the end of each day, they would present their accomplishments to the whole event.

Our objectives with this initiative were threefold: teaching employees how to work with AI on a daily basis and ingraining that possibility into their thinking; increasing the pace of generation of new AI applications; and identifying what tools our engineering team should develop to ensure that AI adoption soars.

Those efforts were largely successful. Several of the POCs developed on our first AI Day event went on to become full-fledged projects, and many others were implemented from the get-go. We’ve seen teams that are not traditionally tech-savvy increasingly rely on AI in their day-to-day work. They also led to a new roadmap for our Engineering Foundation team with clear deliverables that will greatly boost the productivity of those working with AI applications.

All in all, the AI Day events led to significant learnings:

• Once the floodgates are open, the water is hard to stop. One of the main issues that prevent non-tech teams from using AI is that they have to adapt their thinking to a new tool. Breaching that barrier quickly leads to accelerated use;
• Successfully transitioning to a model where AI is a core part of how we work means breaking down dependencies. If Alice employees need to contact data or engineering to make use of AI, that means that there’s something wrong;
• AI can be transformative through large-scale products, yes, but a large swath of its value comes from the sum of a lot of tiny, day-to-day applications. Increasing efficiency across all levels of the company can be as impactful as developing one major new AI product.

AI as a platform

Our experience with AI Days led us to divide our efforts to ease use of AI in two fronts: first, we needed to facilitate testing of new applications throughout the company; second, we should make deploying new AI products as easy as possible while maintaining a high level of quality in our infrastructure, cost control and privacy policies.

In the first front, our Engineering Foundation team began development of a testing platform that will allow users to undertake several different tasks that are as of now hard to achieve in a no-code environment:

• Running AI prompts that are dynamically attached to testing data in batches. For instance, a user can upload a file with NPS comments and then request the platform run a prompt on them, asking it to classify each of the entries between a few different tags;
• Optimizing prompts at scale by comparing the results of different prompts over a single batch of files; different contexts over a single prompt; etc.
• Connecting directly to our analytical layer through Metabase, ensuring that users do not need to manually input testing data;
• Setting up workflows of different AI models. For example, by transcribing an audio, then sending that transcription to a text-based model;
• Access and cost controls through a team-based structure that carries specific budgets for each unit;
• Saving and commenting on past experiments and allowing users to keep a history of their team’s previous attempts;
• Using our own anonymization and privacy infrastructure to ensure that we are not breaching our rules of governance.

We adopted a strategy of rolling out quick iterations of the platform and testing it with users. With representatives of product, operations and even our medical staff as stakeholders, tasked with validating our roadmap and evangelizing their teams, development is running smoothly.

Meanwhile, we also needed to facilitate deployment for those applications that would connect directly with our products. Fortunately, the new generation of LLMs are easy to deal with and we were able to focus on ensuring that data inputted and outputted by those models go through the same processes as those of our production data.

The future

Alice believes that AI is the future, and that it is uniquely positioned to take advantage of new developments. Being a payvidor that acts on the whole healthcare journey and has access to data from a wide range of sources, data products should be as core to us as our medical operations.

In an upcoming post, we will explore the details of the architecture described in the previous sections. But we have taken long strides already in adopting an AI-centric culture by pursuing institutional efforts to educate our teams as well as quick development of tools that boost adoption. The future is bright and there is much more to be done both in terms of Alice’s efforts and the development of LLMs as a whole.

O post Cultura de IA: como a Alice inova no dia a dia apareceu primeiro em Blog da Alice Tech.

Pode até não parecer, mas eu fiz questão de deixar isso claro durante todo o meu processo de contratação, e o fato da Alice ter me dado esse voto de confiança já diz muito sobre a empresa: aqui, estamos mais interessados no brilho nos olhos e na vontade de aprender de cada um do que nas qualificações técnicas ou o conhecimento de ferramentas específicas.

Logo no começo da minha jornada por aqui, entrei para o squad de Privacidade que temos, que envolve pessoas das mais diversas áreas dentro da empresa {como Produto, Engenharia, Jurídico, TI, Financeiro…} e marquei conversas individuais com cada um como forma de entender um pouco sobre o que já tínhamos feito até o momento e qual a nossa visão para o futuro. Foi assim que tive dimensão do desafio e de sua importância para a Alice.

A importância da privacidade para a Alice

Aqui na Alice, a gente lida com dados muito sensíveis sobre a saúde dos nossos membros, o que inclui nossos funcionários e o que chamamos de membros “externos”, que são as pessoas que compraram nosso produto {e são apaixonadas por ele}.

Para uma empresa como a nossa, não preciso nem dizer o quão importante é conseguirmos garantir a segurança e a privacidade dos dados que coletamos.

Um possível ataque ou vazamento de dados, como vimos recentemente acontecer com o STJ {que teve seus sistemas criptografados por um ransomware} ou com o Ministério da Saúde {que acabou tendo a chave para acesso a dados de mais de 200 milhões de brasileiros divulgada} pode prejudicar não só a reputação e marca da Alice, como acarretar em multas e, pior, na perda da confiança dos nossos membros.

Para aumentar o tamanho do desafio {ainda bem, porque se fosse fácil eu nem estaria aqui pra contar essa história}, o produto oferecido pela Alice é um produto que depende do compartilhamento de dados de saúde entre diferentes profissionais e instituições.

Esse compartilhamento existe para que possamos fazer o que chamamos de “coordenação de cuidados”, que nada mais é que um termo bonito para dizer que, aqui, queremos que nossos membros tenham experiências mágicas, do tipo:

• Chegar numa consulta com um especialista que já te recebe pelo nome, sabe todo o seu histórico e o motivo do atendimento
• Depois da consulta, conversar com o seu Time de Saúde {o time de médicos, enfermeiros, preparadores físicos e nutricionistas que cuida de cada membro Alice} e perceber que eles já sabem o que foi discutido e quais foram as recomendações do especialista
• Ir ao laboratório fazer um exame e, ao se identificar {só com o CPF, nada de códigos e carteirinhas}, já ser atendido por alguém que tem todo o seu encaminhamento e contexto dos pedidos

Por esse motivo, desde a sua concepção, a Alice tem a privacidade dos membros como um dos seus pilares. Mas como fazemos isso quando dependemos tanto justamente do compartilhamento de informações sensíveis para entregarmos mais saúde aos nossos membros?

Cultura e tecnologia como ferramentas para entregar privacidade

A resposta para essa pergunta {como garantir privacidade em uma empresa cujo business model parte da premissa do compartilhamento de dados sensíveis?} passa por duas principais alavancas: a criação de uma forte cultura de segurança de dados e respeito à privacidade dos membros e a utilização da tecnologia como ferramenta viabilizadora para a execução de melhorias nos produtos e processos da empresa.

Cultura

Um dos conceitos mais importantes que temos como mantra aqui na Alice é o de Privacy by Design. De forma bem simplificada, Privacy by Design é uma forma de abordar e resolver desafios de privacidade logo na concepção de um produto, e não após o produto ser lançado e o risco ser identificado.

Isso significa, por exemplo, que os PMs {Product Managers} e desenvolvedores da Alice têm uma atuação proativa para entender a melhor forma de criar uma nova ferramenta que já nasça adequada à proteção da privacidade dos nossos membros. Não preciso nem dizer que essa forma de desenvolver produtos é muito mais eficiente e segura do que se, no futuro, tivéssemos que adaptar ferramentas já existentes para adequá-las do ponto de vista de privacidade.

Inclusive, para uma empresa que cresce de forma tão acelerada, como é o caso da Alice, lançando novos produtos e funcionalidades semanalmente, ter os conceitos de Privacy by Design embutidos na cultura dos times é essencial para garantir que não estejamos sempre correndo atrás do prejuízo e fazendo remendos em nossas ferramentas e produtos, e consigamos manter a agilidade necessária e esperada de uma startup com ambições tão grandes quanto as nossas.

Além dos princípios do Privacy by Design, uma forte cultura de privacidade ajuda a garantir que os funcionários da Alice sigam outras boas práticas de privacidade, como por exemplo:

• A não exposição de dados pessoais de membros em canais de comunicação internos com muitos colaboradores {por aqui, usamos o Slack}
• A utilização da mínima quantidade de dados pessoais possível em determinado processo ou fluxo de informações
• A garantia de que softwares utilizados para o tratamento de dados pessoais possuam determinados requisitos de segurança e proteção à privacidade {no caso de dados de saúde, temos também a exigência de que todos os softwares sejam HIPAA-compliant}

Ainda falando sobre a importância da cultura nesse processo, uma das principais virtudes que temos na Alice é a transparência com nossos membros, parceiros e também entre nossos times. A união da transparência com a cultura de privacidade da Alice resultou na Política de Privacidade mais incrível desse Brasilzão — nela, nossos membros podem tirar todas as suas dúvidas a respeito do que fazemos com seus dados e quais são seus direitos sobre eles.

Para se manter e fortalecer essa cultura de proteção à privacidade de dados, não existe atalho ou segredo: é muito importante que existam sessões de treinamento recorrentes, com o suporte das lideranças da empresa, e que o assunto seja sempre abordado em fóruns públicos em que todos poderão se educar e tirar suas dúvidas sobre o tema.

Tecnologia

A Alice é, antes de mais nada, uma healthtech. Aqui, acreditamos que a tecnologia é fundamental para conseguirmos entregar mais saúde aos nossos membros.

É graças a ela que conseguimos escalar soluções de coordenação de cuidados {como eu expliquei lá atrás}, realizar o contato proativo com os nossos membros exatamente nos momentos adequados ou garantir que estejamos sempre a um clique de distância através do Alice Agora {nossa ferramenta de chat instantâneo entre o membro e nossos Times de Saúde}.

Além de acreditarmos na tecnologia para a entrega de saúde, entendemos que ela é também peça essencial para a promoção da privacidade dos membros. Através dela, nós implementamos medidas como:

• A separação entre os dados de saúde {não identificados} e os dados pessoais dos nossos membros em duas estruturas de bases de dados separadas, com uma terceira base {guardada a sete chaves} funcionando como a chave para identificar os dados de saúde. Assim, protegemos a identidade dos nossos membros caso ocorra um possível vazamento {toc, toc, toc} da base com dados sensíveis
• A de-identificação dos dados dos nossos membros {o uso de um código interno nas nossas rotinas operacionais, ao invés de usarmos nomes ou CPFs}
• A automatização do envio e recebimento de dados de saúde para/dos nossos especialistas {lembra que, ao realizarem um atendimento, eles já têm todo o contexto e histórico médico de quem estão atendendo?}
• A disponibilização dos resultados de exames diretamente no nosso app {assim, os membros não precisam ficar enviando PDFs por e-mail para o seu Time de Saúde, que consegue acessar os resultados de forma automática}
• A restrição do acesso às nossas bases e sistemas apenas às pessoas essenciais

E agora? O que vem a seguir?

Apesar de já termos percorrido um bom caminho para chegarmos até aqui, sabemos que o trabalho de promoção da segurança e privacidade dos dados na Alice {e em qualquer empresa} é um que nunca acabará: sempre teremos novos fluxos de dados para serem mapeados {já contei que é muito importante termos um mapa de tudo o que acontece com os dados pessoais na empresa? só assim podemos priorizar o desenvolvimento de melhorias nos diferentes fluxos}, novos colaboradores com quem compartilharmos nossa visão de como executar privacidade {e aprendermos no processo!} e novas demandas de funcionalidades para quebrarmos a cabeça durante seu desenho {lembra do Privacy by Design?}.

Dito isso, tenho confiança de que a Alice já é, e será cada vez mais, referência na forma como pensamos em privacidade em saúde. E fico muito feliz de fazer parte de tudo isso.

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Privacidade em healthtechs: como a Alice garante segurança apareceu primeiro em Blog da Alice Tech.

Mas é claro, como quase tudo no mundo do frontend, as opções não param por ai. Dependendo do framework que você usa, também existem algumas alternativas diferentes para escrever CSS {como se já não fosse complexo o suficiente haha, mas vamos falar disso depois}.

Aqui na Alice, nós usamos o Vue e durante algumas semanas no nosso chapter de frontend, discutimos qual seria o padrão que iríamos adotar. Antes de tomar uma decisão, nós testamos as opções mais comuns e algumas obscuras que a comunidade ainda não está usando tanto. Como o nosso chapter de frontends não é muito grande, é importante para nós termos um padrão bem definido {já que cada pessoa está em um time diferente} e que seja fácil para quem não trabalha com frontend {já que nem todo time tem alguém com esse foco}.

No decorrer desse artigo, junto com os pontos que levantamos, tem algumas implementações básicas de um componente de botão {que chamei ele de base-button} que tem algumas propriedades: tamanho, ícone e loading que são as responsáveis por mudar o comportamento/CSS.

Então aperte o cinto que vamos seguir numa jornada do que nós encontramos em cada uma das possibilidades ✨

Mas antes, uma leve introdução ao vue file

Para quem nunca trabalhou com o Vue antes, é possível criar componentes usando arquivos .vue, que possuem o HTML dentro do <template>, o JS dentro de <script> e o CSS dentro de <style>.

Focando no assunto desse post, na parte de CSS nós temos algumas alternativas: escrever o CSS puro {assim como vemos da linha 16 a 18}, ou escrever com algum pré-processador.

Escolhendo a segunda o opção, tudo que nós precisamos fazer é adicionar um atributo lang na linha 15 com o nome da “linguagem” que queremos {Aqui na Alice nós usamos o SASS com a sintaxe scss, então a maioria dos exemplos daqui pra frente terão o CSS escrito dessa forma}.

Sabendo disso vamos começar falando de uma das nossas opções de escrever CSS, que não depende de estar usando ou não um pré-processador:

BEM

Acredito que essa seja uma das formas mais comum de escrever CSS. Por ser uma metodologia, não tem grandes segredos, mas não significa que seja fácil. Pensar no nome das coisas provavelmente é a parte mais difícil do desenvolvimento de software {risos}, e com o BEM é preciso pensar com carinho no nome das classes para que a estrutura faça sentido.

Para quem nunca trabalhou com a metodologia antes, vamos a uma explicação rápida:

Nós basicamente dividimos uma classe em três pedaços:

• O Block representa o bloco que vai ser estilizado {normalmente algum elemento que esteja envolvendo outros elementos/outras tags}.
• O Element é algum elemento ou tag que esteja dentro desse bloco, e para identificarmos ele facilmente, é separado por dois underscores.
• O Modifier significa que o estado daquele elemento mudou, o que significa que o nosso layout vai mudar graças; a separação dele é por dois dashes.

Isso significa que em uma classe eu posso ter dois elements? Ou dois modifiers? Não. A estrutura do BEM espera que você tenha um de cada, por isso para pessoas que não estão familiarizadas com a metologia, pode ser bem confuso como criar uma classe nova. {Nesse artigo tem uma explicação detalhada do uso do BEM e erros comuns, vale a leitura!}

De qualquer forma, se usado corretamente vários problemas de CSS são resolvidos, além de termos uma boa organização.

Agora vamos para a aplicação dessa metologia no Vue.

Começando pelas linhas 4, 5, 6, 7 — aqui nós temos classes condicionais baseadas em alguns atributos {que no nosso exemplo são props declaradas nas linhas 28 e 29}, uma coisa que podemos ver é que por serem condicionais, usamos o modifier para alterar visualmente o layout de cada uma delas {já que elas representam um estado do nosso botão}.

Na linha 12, temos uma classe com um element, pois esse componente de icone representa um elemento no nosso bloco {que nesse exemplo é o botão}.

Por fim, na linha 34 temos a declaração da lang, que como é importante dizer que só vai funcionar se o projeto está preparado para o pré-processador declarado. Se você começar um projeto usando o Vue CLI é uma das coisas que você pode ou não escolher. Se você quiser mudar o lang, na documentação do Vue tem um passo-a-passo.

Scoped CSS

Você pode se perguntar: por quê exatamente eu preciso do BEM? Não é só sair espalhando minhas classes por ai e tudo bem?

Conforme você vai escrevendo o seu CSS, no final das contas o Vue vai pegar o CSS de todos os componentes sendo usados naquela página e jogar ele no <head>. O que significa que qualquer componente vai ser afetado por qualquer regra definida em um componente. O BEM tenta resolver isso tendo classes especificas que não vão afetar outro componente tão facilmente.

É ai que entra o scoped CSS. Ele nos ajuda a resolver esse problema de escopo adicionando um atributo a mais nas nossas tags HTML para deixar as classes específicas para aquele componente.

Tudo o que precisamos para isso funcione é adicionar o atributo scoped à declaração de <style>, assim como na linha 34 do exemplo.

Para entender melhor vamos pegar a classe na linha 5.

O Vue vai transformar ela em algo como: .loading[data-v-763db97b]. Esse atributo novo sempre vai começar com data-v e vai terminar com uma hash aleatória, o que ajuda caso tenhamos classes iguais {elas não vão colidir graças ao hash} e impede que um componente distante seja afetado.

O problema dessa solução é que mesmo com esse atributo a mais na tag HTML, as regras afetam os componentes filhos. Olhando no exemplo ao lado, se o <base-icon> tivesse a classe “icon” e removêssemos a linha 12, as regras de CSS dessa classe afetariam o componente filho mesmo assim.

Podemos resolver isso facilmente evitando seletores iguais {até mesmo usando uma metologia como o BEM que vimos anteriomente}, para não correr o risco de herdar regras que não gostaríamos.

CSS Modules

Assim como a solução anterior, o CSS Modules tenta nos ajudar com esse problema de conflitar regras de CSS ou herdar regras que não gostariamos.

A diferença dele para o scoped, é que não teremos um atributo novo no HTML e sim uma classe gerada pelo Vue, composta pelo nome do componente + o nome da classe que nós colocamos no CSS + uma hash aleatória.

Para que essa solução funcione, precisamos adicionar o atributo module à declaração de <style>, assim como na linha 35 do exemplo.

Uma das coisas mais importantes aqui é que a sintaxe de declarar uma classe sempre vai ser :class=”$style.xpto” e com o nome da classe sempre em camelCase. E no caso de classes condicionais como na linha 5, 6 e 7, precisamos usar a classe dentro de colchetes.

Para entender melhor, vamos pegar a linha 5 de exemplo. No fim das contas o Vue vai gerar uma classe parecida com BaseButton_loading_1VuSe. Isso vai resolver o nosso problema de conflito de regras e não é algo que interfere nos filhos.

Mas e se você quisesse que isso acontecesse? Até agora pontuei que um componente filho herdar as regras do pai era uma coisa ruim, mas dependendo da situação é exatamente isso que nós queremos para não repetir código.

Nesse caso, você pode passar as classes como prop para o componente filho, ou usar mixins de um pré-processador e importar nos dois componentes.

Achou que tinha acabado?

Achou errado!

As três soluções que vimos até agora, são as formas oficiais do Vue de definir CSS, mas a partir daqui vamos entrar no mundo obscuro das formas alternativas.

Nós separamos duas para testar e ambas são frameworks CSS-in-JS, o que significa que nós escrevemos o CSS no JS e não precisamos mais da tag <style> nos nossos componentes.

Aphrodite

Começando pelo Aphrodite {que não tem muita coisa sobre o uso dele com o Vue na internet e eu usei esse artigo como referência para a minha implementação}.

Inicialmente, nós precisamos importar duas coisas do framework: o StyleSheet e o css {como vemos na linha 8}.

O StyleSheet vai ser o responsável por gerar as nossas regras de CSS baseado na estrutura de objeto com o nome da classe sendo a chave, e o valor sendo os atributos de CSS {linha 10 à 19}.

E para que nós possamos usar essas classes no HTML, primeiro precisamos expor elas no JS {como vemos da linha 22 à 24} e usamos o css na linha 2 {separando os nomes das classes por vírgula se necessário}.

Agora vamos voltar o mesmo componente de botão dos exemplos anteriores, mas dessa vez usando Aphrodite:

Temos algumas limitações com essa solução, e de cara o que mais me incomodou foi que por padrão todas as regras são geradas com !important. A linha 18 poderia estar importando só de ‘aphoridite’, mas para não ter o comportamento de !important, eu acabei importando as dependências necessárias de outro pacote.

Também não existe um jeito oficial de definir classes aninhados {ou seja, uma classe dentro de outra classe}, com isso precisamos ter classes diferentes para um estado específico de um elemento, como por exemplo na linha 27 e 28, onde o componente de ícone que nos exemplos anteriores só tinha uma classe, aqui nós precisamos de duas.

Com essa implementação, as classes geradas são completamente aleatórias {algo parecido com _w3twfb}, o que dificulta um pouco encontrar onde que essas regras foram definidas, mas tem a vantagem de serem nomes curtos.

Por fim, a implementação de exemplo não é a mais otimizada possível, dá para criar um plugin que importe o Aphrodite em todos os nossos componentes.

Styled Components

Por fim chegamos na última opção da nossa lista, o Styled Components, que nos permite criar componentes estilizados.

Na linha 22 e 33 temos dois componentes sendo definidos usando o styled importado do framework. O primeiro parâmetro é a tag HTML que vai ser renderizada, o segundo são as props daquele componente. A partir dai é possível retornar todas as regras de CSS necessárias {e condicionar elas dependendo de uma propriedade, o que nos dá muita liberdade}.

Por mais diferente que essa implementação seja, esses dois componentes são iguais a qualquer outro definido por um arquivo vue {claro, com as suas limitações, ele é um componente puramente visual, então não vamos ter métodos ou outros tipos de atributos nele} e precisa ser declarado como na linha 42 para ser usado pelo HTML.

Eles também não precisavam estar dentro do vue file {só coloquei aqui para facilitar o exemplo rs}. Por serem componentes normais, poderiam estar em arquivos separados para serem importados pelo base-button.

É uma solução simples para componentes básicos.

Conclusão

Depois de muita discussão e uni-duni-tê, nós escolhemos usar o CSS Modules como padrão aqui na Alice {pessoalmente, eu ainda prefiro usar o BEM, mas vamos manter isso entre eu e vc, blz? haha}.

Pelas nossas conversas, foi a opção que mais fez sentido para o nosso momento e para os nossos produtos, onde muitas pessoas precisam mexer. Mesmo sendo uma sintaxe diferente do normal, é algo rápido de aprender/entender e ganhamos uma certa liberdade com qual nome de classes vamos colocar {além de impedir certos problemas de herdar regras desnecessárias/ter seletores de tag HTML}.

Mas por que fizemos essa escolha? As outras opções são ruins?

Particularmente as soluções não oficiais não me agradam, pois é uma dependência a mais que precisamos colocar no projeto, temos uma curva de aprendizado para escrever o CSS dentro do JS, e do meu ponto de vista não é mais vantajoso do que usar uma solução oficial do Vue.

Porém, não existe solução perfeita, não tem uma forma melhor do que a outra, no fim das contas é necessário considerar o que mais faz sentido para o projeto e para as pessoas que vão dar manutenção no código.

Hoje o CSS Modules faz sentido pra gente, mas quem sabe daqui um tempo não faça mais. É importante ter a mente aberta para qualquer solução, e do meu ponto de vista, manter o mais simples possível. 🙂

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto! 🙂

O post Melhor forma de escrever CSS no Vue apareceu primeiro em Blog da Alice Tech.

Como padrão, no Javascript utilizamos o camelCase para nomenclatura de variáveis ​​e funções, e é possível encontrar essa definição nos principais guias de estilo de JS, como o standardjs ou o airbnb. E aqui na Alice, nós também seguimos esse padrão para os projetos de Front-end.

Uma das decisões que tomamos ao definir o padrão para nossas APIs é que usaríamos JSON com snake_case pois consideramos que para a leitura de logs por humanos, esse formato é mais legível do que camelCase. No nosso Back-end, feito em Kotlin, utilizamos a biblioteca em java, GSON. Ela transforma os objetos JAVA em uma representação em JSON e vice-versa. Para que a serialização/deserialização funcionasse com snake_case foi necessário passar o parâmetro FieldNamingPolicy com o valor LOWER_CASE_WITH_UNDERSCORES na configuração do client do GSON. (Imagem abaixo)

Dessa forma ficamos com o padrão snake_case no Back-end em todas as nossas APIs e camelCase em todos os projetos de Front-end, ou seja, o corpo de nossas requisições e respostas HTTP são formados por um JSON com padrão snake_case.

Com isso temos o seguinte problema: Como utilizar camelCase no Front-end, sendo que todas as solicitação para as nossas APIs HTTP teriam que ser feitas com snake_case?

A Solução

Para realizar nossas chamadas HTTP no Front-end, utilizamos a biblioteca ky ( ), que adiciona algumas funcionalidades da fetch API, entre elas, os hooks que permitem modificações da requisição e de seu payload durante o ciclo de vida dessa chamada.

Conseguimos então, resolver esse problema criando um conversor, antes das requisições e após as respostas, utilizando os hooks beforeRequest (que permite modificar a requisição antes dela ser enviada) e afterResponse (que permite alterar a resposta da requisição):

• beforeRequest: Vamos converter o corpo da nossa requisição de camelCase para snake_case.
• afterResponse: Vamos converter o corpo da nossa resposta de snake_case para camelCase.

O código JS ficaria da seguinte forma:

Esse código é open source

Criamos um pacote para permitir essa e outras alterações de case em nossas requisições, e decidimos abrir o código dessa solução:

alice-health/ky-hooks-change-case

Inclusive, esse pacote foi adicionado como biblioteca relacionada no repositório oficial do KY. Sinta-se a vontade para abrir pull requests com melhorias, correções ou mandar qualquer comentário. Já utilizou o ky e/ou hooks para outros casos de uso? Compartilhe com a gente aqui nos comentários quais  .

Kudos e agradecimentos à Diego Leme pela contribuição na biblioteca e início desse post.

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post JSON: integrando Back-end e Front-end na prática apareceu primeiro em Blog da Alice Tech.

Na Alice, temos a cultura de tomada de decisões em conjunto para assuntos que impactem a engenharia como um todo. Isso sendo desde a definição da tecnologia a ser usada para desenvolvimento mobile, até a arquitetura de processamento assíncrono dos serviços (spoiler: ela é baseada em Kafka).

Mas antes de contar como e porque escolhemos o Kafka, vale uma n̶ã̶o̶ ̶t̶ã̶o̶ breve introdução sobre ele.

O que é o Apache Kafka?

Resumidamente, o Kafka pode ser definido como um sistema de processamento de stream de dados em tempo real / um sistema de mensageria (messaging system) publish-subscribe distribuído.

Ele possui como principais características — se comparado com outros sistemas de mensageria — um alto throughput, clusterização no DNA (permitindo escalabilidade horizontal), ordenamento e persistência de mensagens com estrutura de disco O(1) (entraremos em mais detalhes sobre o que isto representa).

O que é um sistema de mensageria?

Um sistema de mensageria nada mais é do que uma forma de comunicação assíncrona entre duas (ou mais) aplicações. Neste conceito, as aplicações se comunicam através de uma fila (message queue), de forma totalmente desacoplada, onde o produtor da mensagem (producer) não tem conhecimento de quem a processará, assim como o consumidor (consumer) também não possui ciência de quem a produziu. Ambas as pontas apenas se preocupam com o conteúdo da mensagem.

Existem dois tipos de padrões de mensageria: ponta à ponta (point to point) e publish-subscribe (pub-sub).

Sistema de mensageria ponta à ponta

Um sistema de mensageria ponta à ponta é caracterizado pelo fato de que cada mensagem apenas poder ser consumida uma única vez. Neste sistema, a mensagem é persistida na fila e, a partir do momento que um consumidor lê esta mensagem, ela é automaticamente removida da fila. Exemplos de sistemas neste modelo temos o Amazon Simple Queue Service (SQS) e o Microsoft Message Queuing (MSMQ).

Sistema de mensageria publish-subscribe

No sistema de mensageria publish-subscribe assim como no de ponta à ponta, as mensagens são persistidas em uma fila através de um produtor (publisher). Porém, diferentemente do modelo anterior, os consumidores podem se inscrever/assinar (subscribe) à uma ou mais filas e consumir todas as mensagens destas filas. Neste modelo, todos os consumidores (subscribers) processam todas as mensagens de todas as filas no qual eles se inscreveram. Exemplos de sistemas neste modelo temos o RabbitMQ e o Apache Kafka.

Background

História

Tudo começou em meados de 2010, com uma necessidade do LinkedIn: integração massiva de dados. Um volume enorme de dados era gerado a todo tempo, porém, com as ferramentas existentes na época, não era possível integrar e centralizar estes dados da forma que gostariam e com a escala que precisavam.

Foi então que Jay Kreps e sua equipe surgiram com o conceito do Kafka.

Timeline

Em 2011 tornou-se um projeto open-source, sendo absolvido pela Apache Foundation em 2012.

Em 2014, os engenheiros do LinkedIn responsáveis pelo desenvolvimento do Kafka fundaram a Confluent, empresa com foco em Kafka.

Fun fact

Kafka é desenvolvido em Scala e Java, e seu nome é uma referência ao escritor alemão Franz Kafka. Jay diz que a escolha do nome se deu ao fato de que, devido o Kafka ser um sistema otimizado para escrita, faria sentido ter o nome de um escritor. Além de achar que soava bem para um projeto open source.

Mas por que utilizar Kafka?

Dentre as principais vantagens do Kafka, podemos destacar:

• Sistema de registros: após persistido, um registro (mensagem) nunca mais é mais removido do log (por padrão). Desta forma, é possível “voltar no tempo” e reprocessar todas as mensagens a partir de uma data específica.
• Ordenamento garantido: ao ser publicada a mensagem A (POST) e então a B (PUT), sempre serão retornadas e lidas nesta mesma ordem (FIFO).
• Centralização: uma mesma mensagem pode servir de input para uma operação SQL e para um registro em um Data Lake.
• Escalabilidade: Kafka é totalmente pensado em clusterização e escalabilidade horizontal.
• Pull over Push: diferentemente de outros sistemas de mensageria (e.g. RabbitMQ) e/ou sistemas de service bus, o Kafka trabalha com um modelo de pulling ao invés de pushing, no qual o consumidor tem de solicitar ativamente a leitura de novas mensagens. Isto possibilita a existência de consumers com velocidades de processamento distintas entre si.
• Performance: possui um alto throughput, comportando centenas de milhares de mensagens/seg até em hardwares mais modestos. Como citado anteriormente, possui persistência de mensagens com estrutura de disco O(1), ou seja, não importa a quantidade de mensagens existentes, a velocidade de escrita sempre se mantém a mesma.

Performance linear

Devido a arquitetura de distribuição que o Kafka implementa, é possível obtermos escalabilidade linear em nosso sistema. Desta forma, para cada nó (broker) adicionado ao cluster, teremos um aumento linear de throughput suportado pelo Kafka.

Use cases

Mesmo o Kafka sendo extremamente versátil, existem alguns casos de uso no qual acaba se destacando. Tais como:

• Hub de eventos: Kafka pode servir de um hub centralizador dos eventos da sua aplicação, permitindo que inputs de diversas fontes de dados sejam concentrados em um único ponto, para então serem potencialmente filtrados, transformados e processados de formas distintas.
• Data pipeline: um dado pode ser persistido no Kafka para então ser replicado para outros repositórios, tais como banco de dados.
• Entry point de Big Data: em casos de utilização de data lakes baseados em storages na nuvem (e.g. AWS S3), Kafka costuma servir como um “buffer” dos dados devido ao seu throughput, armazenando-os até serem transferidos para o storage final.

Semânticas

Registros

Os registros (records) são as mensagens persistidas em uma fila (tópico). Um registro é composto de três componentes: chave, valor e timestamp.

A chave (key) é o que define em qual partição este registro será armazenado (mais detalhes sobre particionamento abaixo). A chave não é obrigatória e, caso não seja fornecida, o Kafka se encarregará de definir a partição correta para este registro.

O valor (value) é o conteúdo do registro, o equivalente ao corpo de uma mensagem. O valor pode conter qualquer dado, desde uma simples string até um objeto serializado em JSON.

O timestamp é a data e hora no qual o registro foi persistido, sendo atribuído automaticamente pelo Kafka no momento da criação do registro.

O registro é sempre imutável e append-only, ou seja, somente é possível incluir novos registros. Uma vez incluído não pode mais ser modificado ou removido.

Os registros são sempre persistidos em disco, não havendo nenhum cache em memória, tanto para escrita quanto para leitura.

Producer e Consumer

O producer é quem será responsável por gerar registros em um tópico e o consumer por ler estes registros. Em ambos os casos, a comunicação é sempre feita com o broker (nó) líder do cluster.

Ao ler um registro, o consumer pode tanto solicitar o último não lido, quanto a partir de uma posição específica.

Tópicos

O tópico é a nomenclatura lógica para uma ou mais partições. Basicamente é onde os registros ficam armazenados, sendo equivalente à uma fila, porém considerando todas as partições do cluster.

Partições

As partições são as divisões “físicas” de um tópico. Cada partição representará o conjunto de registros de um tópico, em um broker (nó) no cluster.

As partições seguem o modelo de líder/seguidor (leader/follower), onde sempre há ao menos um broker com uma partição principal que recebe todas as operações de leitura e escrita, sendo replicado posteriormente para os demais brokers seguidores em forma de réplica.

No exemplo acima, temos quatro partições com duas réplicas cada. Cada partição ficará responsável por um conjunto de dados daquele tópico, onde estes mesmos dados serão replicados em cada um dos outros dois brokers seguidores.

O particionamento pode ser feito manualmente ou baseado em uma chave. No primeiro cenário, quem estiver produzindo e/ou consumindo as mensagens, fica responsável por indicar com qual partição deseja interfacear. Já no segundo caso, deve-se definir previamente qual o range de valores de uma chave que cada partição será responsável. Desta forma, ao publicar ou ler um registro, o Kafka ficará encarregado por atribuir a partição correspondente, baseado nas configurações previamente estabelecidas.

Grupos de consumo

Grupo de consumo (consumer group) é o nome lógico para um ou mais consumers. É através dele que se dá a escalabilidade do lado dos consumidores.

Cada grupo lê todas as mensagens de um tópico, dividindo as partições deste tópico por entre os integrantes do grupo.

Cada grupo vai representar um processamento específico (e distinto) dos registros de um tópico em relação ao outro grupo. Já cada integrante de um mesmo grupo representará uma instância de processamento (um processo, uma thread, um container, etc.) idêntica em relação aos consumers deste mesmo grupo.

No exemplo acima, temos um tópico dividido em quatro partições, e dois grupos de consumo: grupo A com dois integrantes e B com quatro.

Desta forma, tanto o grupo A quanto o grupo B processarão todas as mensagens de um determinado tópico. Devido ao grupo A possuir dois integrantes, cada integrante ficará responsável pelos registros de duas partições cada. Já no grupo B por possuir quatro integrantes, cada integrante ficará responsável pelas mensagens provenientes de uma única partição cada.

Com isto, é possível ter N processos distintos para um mesmo dado e paralelizar cada um destes processamentos em N instâncias conforme a necessidade, sem gerar concorrência entre si.

Offsets

Ao inserir um registro em um tópico, o Kafka automaticamente atribui um identificador único sequencial para ele, que consiste basicamente de um índice deste registro na partição daquele tópico.

O offset por sua vez, representa a posição de leitura de um grupo de consumo, em relação à uma partição de um tópico.

No exemplo acima, temos um tópico com três partições. As setas representando um grupo de consumo e os números destacados os offsets daquele grupo nas respectivos partições.

O objetivo do offset é definir qual foi o último registro lido por aquele grupo de consumo naquela partição, para que assim possa prosseguir com a leitura de onde parou.

O Kafka mantém o tracking dos offsets para que apenas retorne os registros ainda não lidos. Porém, como citado anteriormente, um consumer pode solicitar um registro em uma posição específica.

Conclusão

Conforme pudemos ver, o Kafka é uma excelente ferramenta para criação de sistemas distribuídos, mas assim como qualquer tecnologia, nasceu para resolver problemas específicos e não para ser uma “bala de prata” da persistência de dados.

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Descomplicando o Apache Kafka apareceu primeiro em Blog da Alice Tech.

Afinal, o que é um microbenchmark?

Um microbenchmark é um teste projetado para medir o desempenho de uma unidade muito pequena: o tempo para chamar um método sincronizado versus um método não sincronizado; a sobrecarga na criação de um encadeamento versus o uso de um conjunto de encadeamentos; o tempo para executar um algoritmo aritmético versus uma implementação alternativa; e assim por diante.

É uma forma bem interessante de verificar se algum fluxo que estamos fazemos está consumindo muito ou pouco tempo ou recursos (CPU, memória, rede, disco, etc). Porém deve ser feito com cautela.

Muitos fatores podem interferir na execução e aferição de um benchmark, como capacidade de processamento do computador, memória disponível, versão do framework, entre outros. Por conta disso, deve ser feito para testes isolados de unidades bem específicas.

Testando uso de reflections para nossos logs

Há alguns meses atrás, o time Alice estudou a necessidade do uso de Reflection para identificar a função e a classe exata de onde o log foi gerado.

Nossa hipótese era que a utilização de Reflection poderia aumentar o consumo de recursos da função, mas não sabíamos o quanto aumentaria e se isso impactaria de verdade nossas aplicações.

Importação de dependências

Usamos a biblioteca JMH (the Java Microbenchmark Harness) para fazer a comparação. Utilizamos tanto o JMH Core quanto JMH Annotation Processor.

plugins {
    kotlin("jvm") version "1.4.32"
    kotlin("kapt") version "1.4.32"
    id("me.champeau.gradle.jmh") version "0.5.2"
    id("io.morethan.jmhreport") version "0.9.0"
    application
}

No build.gradle.kts do projeto nós declaramos a task para rodar os testes de benchmark

task("benchmarks", type = JavaExec::class) {
  classpath = sourceSets.getByName("test").runtimeClasspath
  main = "br.com.alice.benchmarks.BenchmarksRunnerKt"
}

Além disso importamos a biblioteca orgs.slf4j.Logger para criar nossos logs. A lista de dependências ficou:

dependencies {
    kapt("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    implementation("org.openjdk.jmh:jmh-core:1.25")
    implementation("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    api("ch.qos.logback:logback-classic:1.2.3")
    implementation("net.logstash.logback:logstash-logback-encoder:6.4")

    annotationProcessor("org.openjdk.jmh:jmh-generator-annprocess:1.25")

    testImplementation(kotlin("test-junit"))
}

Criação da função de log

Para realizar o teste, criamos uma abstração para a biblioteca orgs.slf4j.Logger . Só possui uma simples função de logar info, simulando nossa biblioteca interna para logs.

Criando os casos de teste

JMH suporta diferentes tipos de benchmarks: Throughput, AverageTime, SampleTime, and SingleShotTime. São configurados via annotation @BenchmarkMode .

• Throughput: nesse modo, o teste é executado em um período pre determinado e é avaliado o número de vezes que o método em teste foi executado
• AverageTime: inverso ao Throughput, esse método é usado para se ter o tempo médio de cada chamada do método em teste.
• SampleTime: esse método também utiliza um tempo pré determinado, porém aqui algumas chamadas são selecionadas randomicamente e seu tempo avaliado.
• SingleShotTime: mede o tempo de uma única chamada.

Para o nosso caso, utilizamos AverageTime, dessa forma a gente simular os nossos micro-serviços utilizando os métodos de log diversas vezes e ver o quanto isso impactaria o tempo e os recursos dos mesmos.

Configuramos também a unidade de medida temporal para microsegundos, também via annotation @OutputTimeUnit .

Usamos a annotation @Benchmark para definir uma função como test case do benchmarking. Criamos 3 tipos de testes:

• Log sem nenhuma reflection
• Log utilizando reflection através do Throwable para receber os nomes de classe e método.
• Log utilizando reflection através da Thread para receber os nomes de classe e método.

Configuração final do benchmark

Para agrupar todos os testes, configurar saída do resultado e definir últimas configurações, nós criamos o arquivo BenchmarksRunner.kt, assim declarado no gradle.build.kts , mostrado no início do artigo.

As configurações utilizadas no OptionsBuilder:

• include adiciona o teste que vamos realizar. Nele indicamos qual a classe a ser executada, nesse caso o LogReflectionBenchmark .
• forks é o número de testes paralelos que vão ser executados em cada iteração. Utilizamos 2 forks.
• threads é o número de threads a ser utilizada para cada teste. Escolhemos duas threads. Dependendo do número de threads disponíveis na máquina, esse valor pode aumentar.
• warmupBatchSize é o tamanho o grupo de aquecimento. Utilizamos 2 batches.
• warmupIterations é o número de iterações a serem executadas antes de começar a contabilizar o tempo. Esse número é importante pois ajuda a contabilizar depois que a máquina já estiver rodando os testes. Um número muito alto pode impactar negativamente o teste, se o processo já tiver consumido bastante recurso da máquina.
• measurementIterations é o número de iterações, agora contabilizando o tempo de cada teste. O resultado final é montado a partir a média entre as diferentes iterações.

Além disso, definimos como arquivos output benchmark_output.log e benchmark_result.json . Eles vão conter as informações dos testes.

Hora de rodar os testes

Depois de toda a configuração, podemos rodar o BenchmarksRunner.main e aguardar os resultados. Após alguns minutos, o resultado foi mostrado no arquivo benchmark_output.log .

LogReflectionBenchmark.logWithReflectionThreadGetStackTrace     avgt    4  28.860 ± 7.172  us/op
LogReflectionBenchmark.logWithReflectionThrowableGetStackTrace  avgt    4  42.075 ± 11.087  us/op
LogReflectionBenchmark.logWithoutReflection                     avgt    4  0.36028 ±  0.00035  us/op

Como vocês podem ver, a utilização do log sem nenhum tipo de reflection foi cerca de 100x mais rápida do que com uso de qualquer reflection. Isso já foi necessário para que o nosso time decidisse não precisar logar o nome da função e nem da classe.

Teste você mesmo

Caso queira validar também em sua máquina, o código de exemplo está aberto. Você pode fazer o mesmo teste que nós fizemos, ou usar o exemplo para criar seus próprios microbenchmarks em Kotlin.

alice-health/kotlin-benchmark-example

No repositório tem a descrição de como executar os testes. E se você conseguiu testar outros use cases, compartilha aqui com a gente!

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Como fazemos microbenchmarks em Kotlin apareceu primeiro em Blog da Alice Tech.

About a year ago I arrived at Alice with the compromise to make the world healthier. We had less than 100 employees and living from series A, which means short money. A big challenge and a lot of work to do!

The first challenges

As a data engineer, my responsibility was to provide data for everybody. The team was very small (actually just me and half the time of my boss) and the systems were changing very fast.

Facing the situation, the plan needed to be as simple and direct as possible:

• Use a relational database as the data warehouse. We choose PostgreSQL hosted in AWS RDS. Easy to configure and maintain.
• Use a simple tool to schedule the ETL pipelines. The choice was Airflow since it’s a very stable, well know tool and we had experience with it (and we love Python).
• A visualization interface. Metabase was the winner for many motives: Free, previous experience with it, easy to install and configure, self-service, very stable and users usually like it.

OK…. That’s something we can make happen! I reused some previous code I wrote in the past to copy data from one place to another and data started to flow! Great! Mission accomplished!

Problems always happen!

BUT…. almost every day I had dags broken and had to add a table, fix some table structure, re-run dags, and deploy emergency PRs. The problem was for every new column, every modification in size or type, even the order of some selects could break something. How to solve it?

For every problem, a solution!

At that point, I started to work on an Airflow plugin for a smarter extractor which was baptized, given my total lack of imagination, “SmartTransfer”. The main idea was to check the existence and structure of the table in the destination stage area and automatically create or re-create as needed.

The intention was to be really easy to be called, with minimal parameters. Below is a real example of a very simple dag with it:

(all code is available at https://github.com/alice-health/airflow_plugins )

So, how does it work? No big secret, but there are some steps in the process.

First, we need to check the structure of the source table. We run a query and get one row from the source table and analyze the columns.

From the table, we can create build the ‘create table’ statement.

We used the ‘unlogged table’ PostgreSQL feature because it should be, in principle, faster. Unlogged tables are faster but not crash-free, so be careful! Since staging is just a copy of production, it’s not a problem to lose data. You can learn more about PostgreSQL here. We didn’t notice much difference but we have only a few gigabytes. We will benchmark again in the future as our database grows.

Everything set, the logic is quite straightforward:

• If the destination table doesn’t exist, create it
• If the destination table exists but the structure is different, drop it and recreate it
• If tables have the same structure, same primary keys, just keep the table

It’s important to remember in the case of (re)creating the destination table we need to do a full import, so we set the flag “need_full_import” to True

Finally, transfer the data. The first step is to know if we are going to do a full import or an incremental import:

and prepare the insert statements. The syntax is PostgreSQL specific, with “ON CONFLICT DO UPDATE” to create a mixed insert/update statement:

The main loop makes the data transfer. The most important part here is the grouper function: It lazily consumes the source_cursor, keeping in memory only the data will be sent in the current block

More details of installing, using, and testing SmartTransfer are in the README file in the official repository at https://github.com/alice-health/airflow_plugins.

Conclusion

I tried to cover the most important (and interesting) parts of the code and show how we solved the problem of moving, not hundred of terabytes with 100 people, but a couple of gigabytes with two people, in a way to automatize all table synchronization and copying process to minimize the data engineer manual work.

O post How we extract data for our DW apareceu primeiro em Blog da Alice Tech.

Certo dia fui surpreendida por um evento na minha agenda: “Café Legal.”

Era um convite de duas pessoas do Time de Legal da Alice para um café. Dentre outras coisas, elas queriam entender mais sobre a Área de Produto e como elas poderiam contribuir de forma ativa com as nossas tomadas de decisão.

Falamos sobre amenidades, eu expliquei um pouco sobre as Áreas de Produto e Tecnologia e quando me questionaram sobre como poderiam ser mais participativas nos nossos processos, eu inconscientemente respondi: “precisamos inserir vocês nos nossos discoveries.”

Falei isso com certa naturalidade e fiz uma pausa. Elas me olharam com cara de “quê?”. E então perguntei: vocês sabem o que é discovery?

Elas não sabiam. E isso, de forma alguma, é um demérito. Nós, que trabalhamos com produtos digitais, estamos muito acostumados com determinados termos, que acabamos utilizando com pessoas que não lidam diretamente com o nosso universo.

Expliquei para elas o que vou resumir aqui:

Discovery, como o nome já indica, é um processo de descoberta: existe um problema, existem hipóteses de como resolver esse problema e, baseado nessas hipóteses, existem as possíveis soluções.

No discovery, buscamos encontrar a melhor solução para um problema sob três pilares: usuário (UX), tecnologia (viabilidade) e negócios (alinhamento estratégico).

E, embora o discovery seja, muitas vezes, liderado por uma pessoa de produto (PM), ele é executado em conjunto com Product Designers e pessoas de desenvolvimento (tech), que têm papel fundamental para se obter um bom resultado.

Como estamos descobrindo a melhor forma de “descobrir” na Alice

Somos uma empresa early stage e sempre estamos descobrindo a melhor forma de fazer alguma coisa.

Uma das nossas virtudes é: “Subimos a barra, evoluímos todos os dias”. E para o processo de discovery não é diferente.

Iniciamos no melhor modelo free style.

Cada PM, com sua experiência e bagagem de aprendizados, iniciou e concluiu diversos processos de discovery. E os resultados, naturalmente, tiveram méritos, falhas e novos aprendizados.

Decidimos nos reunir para unificar esse processo, juntar nossas forças para preencher as lacunas de cada processo individualizado.

E chegamos a um framework que vou detalhar a seguir.

Framework de Discovery da Alice

Para apresentar o framework, vamos usar um suposto problema como exemplo:

Muitas pessoas do Time de Saúde estão reportando baixa adesão dos membros ao plano de ação.

Plano de ação é uma lista de tarefas que o Time de Saúde estabelece com o membro com o objetivo de tornar sua vida mais saudável. As tarefas podem variar entre: iniciar uma atividade física, realizar um exame, se consultar com um especialista, tomar um medicamento, fazer acompanhamento com Nutricionista, entre outras coisas.

Esse framework está dividido em 2 grandes etapas:

1. Entendimento do problema e levantamento de hipóteses;
2. Validação ou redução do grau de incerteza das hipóteses e proposta de solução;

Cada uma dessas etapas é marcada por um evento que reúne as pessoas envolvidas com o tema central do discovery.

1ª Etapa: entendimento do problema e levantamento de hipóteses

Ser PM é fazer escolhas, sempre — ser humano é fazer escolhas, sempre!

Como PM precisamos escolher qual problema resolver primeiro. Isso porque existem recursos limitados para desenvolver soluções. Essa etapa tem dois objetivos principais:

1. Responder se o problema é relevante (qual é o impacto dele) e se existe alinhamento estratégico para priorizar a solução desse problema;
2. Levantar hipóteses para solucionar esse problema;

É sempre importante frisar que hipóteses não são soluções. As hipóteses estão mais relacionadas a “o que deve ser feito” para se obter determinado resultado, enquanto as soluções estão relacionadas a “como isso deve ser feito”.

Eu sugiro escrever as hipóteses utilizando esse modelo: se [variável], então [resultado], porque [racional].

Utilizando o problema de exemplo: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames e aproximadamente 25% das pessoas não realizam o agendamento].

A hipótese aqui: as pessoas têm dificuldades para agendar exames.

A solução a gente deixa para a segunda etapa.

Nessa primeira etapa vamos a fundo no entendimento do problema. Entre outras coisas, fazemos entrevistas com as pessoas envolvidas, shadowings (passar um tempo acompanhando a rotina dessas pessoas ou, até mesmo, assumir esses papéis), análise de dados, análise da evolução do produto, etc…

Como resultado dessas ações, temos um documento contendo:

[x] Descrição do problema
[x] Descrição do impacto do problema
[x] Evidências (quali/quanti) do problema a ser resolvido
[x] Impacto no OKR
[x] Proposta de hipóteses

Essa etapa é marcada pelo evento Discovery Kick-off, onde reunimos os principais stakeholders para apresentar o problema e as hipóteses de solução. Nesse evento buscamos o buy-in dos envolvidos para seguir para próxima etapa.

Ou seja, baseado no que sabemos até aqui: podemos afirmar que o problema é relevante, e o desenvolvimento de uma solução — agora — está alinhado estrategicamente com a empresa?

Se sim, next (se não, re-prioriza)

2ª Etapa: validação das hipóteses e proposta de solução

Ótimo. Já conhecemos a fundo o problema e já temos em mãos algumas hipóteses de como solucioná-lo. Mas como saber se essas são hipóteses válidas? Existem algumas formas.

Vamos usar como exemplo a hipótese descrita na primeira etapa: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames, e aproximadamente 25% das pessoas não realizam o agendamento].

Aqui o problema é o baixo engajamento ao plano e a hipótese é que isso se deve à dificuldade de agendamento de exames.

Uma das formas de validar as hipóteses é entrevistar as pessoas que possuem baixa adesão ao plano. Nessas entrevistas, perguntamos a elas se aumentaria a probabilidade de adesão ao plano se houvesse uma forma mais fácil de agendar os exames.

Perguntamos também sobre outras hipóteses de solução a fim de entender quais são mais aderentes.

Outra forma complementar a essa, é simular um cenário onde enviamos um formulário para o membro para coletar informações sobre o melhor dia/horário de realização de exames e fazemos o agendamento pela pessoa.

Ao final desta simulação, comparamos se o engajamento ao plano dessas pessoas aumentou em comparação às demais.

Sim? Sinal de que estamos no caminho certo!
Entrevistas, cenários simulados e benchmarks são algumas formas de reduzir incertezas em relação às hipóteses.

Nesse momento algumas hipóteses serão validadas, outras terão seu grau de incerteza reduzido, e outras cairão.

Com base nas hipóteses validadas, partimos para o desenho da solução.

Utilizando o mesmo exemplo, o que fazemos aqui é propor qual é a melhor forma de facilitar o agendamento de exames.

Podemos ter como solução, uma funcionalidade de agendamento de exames no app da Alice. Sendo assim, criamos um protótipo dessa funcionalidade e selecionamos pessoas para testarem a solução.

Minha sugestão é, se possível, desenvolver protótipos navegáveis de alta fidelidade.

Isso ajuda muito a ter resultados de testes mais assertivos, e, não menos importante, é uma documentação bastante robusta para posterior alinhamento com todos os envolvidos.

Com o protótipo em mãos, partimos para os testes, e inicia-se o famoso ciclo — teste > feedback > iteração — até chegarmos à solução final.

Aqui na Alice usamos e abusamos do Maze para testes de usabilidade. É uma ferramenta incrível, que nos ajuda a ter mais alcance, e resultados mais estruturados.

Ah, e sabe o Time de Legal?

Então, esse é um ótimo momento para envolvê-lo se você entender que a solução proposta pode ter algum impacto jurídico.

Ou apenas para pegar a opinião deles, porque eles são “legal” — (tudumtss).

Ao final dessa etapa complementamos nosso documento de discovery com mais esse checklist preenchido.

[x] Descrição da solução (fluxograma, protótipo, casos de uso, etc.)
[x] Evidências de validação / invalidação das hipóteses
[x] Validação da solução com users
[x] Roadmap
[x] Métricas de sucesso
[ ] Alinhamento com stakeholders

Para coroar, convidamos os stakeholders envolvidos para um evento que chamamos de Discovery Sign-off, apresentamos a solução final e nos alinhamos sobre os próximos passos.

[x] Alinhamento com stakeholders

Para finalizar…

Todo esse framework pode dar, à primeira vista, a impressão de excesso de burocracia. Mas ele é só uma trilha, e não um trilho — parafraseando o Time de Saúde da Alice em relação aos protocolos de saúde. Cumprir todas essas etapas, ou apenas parte delas, depende da complexidade e impacto do problema e do grau de incerteza em relação às hipóteses.

O discovery ajuda a validar hipóteses, mas dificilmente será possível reduzir a zero o grau de incerteza em relação a elas.

Muitas vezes é importante arriscar. A verdade é que uma hipótese somente será 100% validada quando a solução derivada dela estiver em uso.

Muito embora o discovery seja uma importante ferramenta para evitar custos que são evitáveis com a implementação de uma solução que tem grandes chances de não funcionar, ele é, também, um processo que custa caro. É preciso escolher quais batalhas lutar!

O post Discovery: a forma de descobrir da Alice apareceu primeiro em Blog da Alice Tech.

Por isso, na Alice, além de construir nossas próprias ferramentas, utilizamos parceiros de mercado mega qualificados (e HIPAA compliant, claro) para nossa entrega de saúde. Um desses é o Braze, um CRM (customer relationship manager) focado em engajamento, que nos possibilita diversas oportunidades de contato com nossos membros, promovendo o cuidado e a saúde.

Nesse artigo, traremos alguns cases sobre como utilizamos o Braze para promover o engajamento dos nossos users com sua saúde.

Como a Alice funciona e qual o papel do aplicativo?

Antes de detalhar como usamos o Braze por aqui, um rápido recap do que é a Alice e como nosso app funciona: A Alice é uma gestora de saúde, ou seja, estamos com nossos membros não só quando eles estão doentes, mas também ajudando com que eles se tornem cada vez mais saudáveis.

Todo membro tem acesso ao app da Alice (já disponível em uma versão gratuita para qualquer pessoa na Apple Store ou Google Play), que é por onde ele se comunica com seu Time de Saúde, acessa o atendimento digital 24h, faz agendamentos de consulta, vê resultados de exames, entre várias outras coisas.

No entanto, nós não queremos que o nosso membro fique restrito a cuidar da sua saúde só em momentos em que ele esteja em consultas ou fazendo exame. Isso é apenas uma parte do cuidado. Nós queremos empoderar o membro para que ele realmente seja um agente ativo em melhorar sua qualidade de vida e possa fazer isso sozinho. E queremos que nosso app seja um verdadeiro parceiro nessa jornada. É aí que o Braze entra.

O que é o Braze e como nós usamos essa ferramenta no dia a dia?

O Braze é uma ferramenta de CRM focada em aumentar o engajamento dos usuários. Por meio do Braze é possível enviar campanhas de push, pop ups, cards no app e e-mail, utilizando-se de dados de interação do usuário — no nosso caso, usamos dados como agendamentos, cancelamentos, interação com campanhas enviadas, entre outros. Nosso objetivo é ajudar o membro a cuidar da sua saúde, assim nossas comunicações são sempre guiadas por isso (nada de cupons ou promoções, aqui o foco é em saúde mesmo).

Para garantir isso, restringimos o acesso ao Braze para algumas pessoas do time de produto e operações de saúde, e temos uma governança para garantir que não “floodamos” nossos usuários com excesso de notificações. Integramos o Braze com nosso app e construímos uma série de features que são “powered by Braze”. Dessa forma, temos uma máquina autônoma de comunicações com nossos membros, algo que hoje é normal e tem alto valor mas nem sempre foi assim.

Evolução do uso Braze dentro da Alice

Quando entrei na Alice, em janeiro de 2021, ainda usávamos o Braze de forma incipiente. Enviávamos campanhas esporádicas e manuais, como férias da médica do Time de Saúde ou campanhas de setembro amarelo. Nós não tínhamos réguas estruturadas e automatizadas para o envio de comunicações. Isso se devia, em parte, por que o Braze necessita de inputs de dados que dependem do time de Engenharia para estruturar e, também, por que nós ainda estávamos nos familiarizando com a ferramenta.

Ao longo do tempo, fomos explorando melhor o Braze e vimos um potencial muito grande na estruturação das campanhas automáticas, triggadas por eventos enviados diretamente à ferramenta pelo nosso back-end. Além de não pararmos alguém para enviar essas campanhas, poderíamos estruturar réguas de comunicação que fossem tailor made para o usuário, acompanhando de pertinho sua jornada na Alice. Assim, fizemos uma força tarefa para trazer esses dados de interação e status para o Braze.

Hoje conseguimos acompanhar de perto cada usuário e enviar comunicações como questionários de saúde pré consulta (onde as nutris e preparadores físicos conseguem conhecer o membro melhor e se preparar antes), CSAT e NPS, lembretes para realização de tarefas do Plano de Ação (ex: marcar consultas atrasadas) entre outros. Enxergamos essas comunicações como aliadas importantes na missão de tornar nossos membros mais saudáveis, já que gerir a própria saúde é algo complexo e que nem sempre lembramos no dia a dia.

Feita essa breve introdução, vamos detalhar três use cases do Braze que fizemos aqui na Alice: a criação do Notification Center, customização do envio das matérias das Pílulas de Saúde e os desafios de saúde promovidos.

Casos de uso do Braze aqui na Alice

1. Notification Center e comunicações rotineiras

O Notification Center foi a primeira grande entrega que fizemos usando o Braze. Mesmo depois de termos estruturado algumas réguas e comunicações automáticas, percebemos que o engajamento não havia aumentado substancialmente. Isso nos pareceu estranho já que estávamos garantindo que a comunicação fosse feita muito próxima ao evento (ex: um lembrete para uma consulta).

Nesse momento, tentamos modificar os textos das notificações e fazer testes A/B com horários distintos de envio, mas nada parecia aumentar o engajamento. Nesse meio tempo, era muito comum recebermos relatos de membros que perdiam as notificações. Não demorou muito para conectarmos os dois pontos.

A causa-raiz era que parte das comunicações eram enviadas por push notifications. E, apesar de ela ser boa por aparecer instantaneamente no celular do membro, é um tipo de comunicação perdida facilmente, dado que basta o usuário limpar as notificações do celular ou simplesmente não olhá-las. Vimos aí um grande gargalo na nossa estratégia: provavelmente nossos membros não estavam nem vendo as notificações, muito menos engajando com elas.

Dessa hipótese, surgiu a solução de criamos um Notification Center no app. Um repositório de todas as comunicações enviadas, que armazenasse isso para que o usuário consultasse a qualquer momento, evitando que o desengajamento fosse por perda da notificação. Mas como implementar isso? Como “guardar” as notificações por push enviadas?

Ao investigar opções, encontramos os Content Cards do Braze, um produto com cards customizáveis que ficam no aplicativo por até 30 dias. Uma das grandes vantagens é que os cards são entregues silenciosamente, ou seja, não há pop up ou push atrelados, evitando que se atrapalhe a experiência do usuário no app. Os principais usos, de acordo com o próprio Braze, são feed de notícias para aplicativos de jornais, repositório de notificações e central de descontos e promoções. Além disso, o processo de implementação seria simples, dado que já tínhamos o SDK do Braze integrado.

Em duas semanas, criamos um Notification Center no app operado via Content Cards. Cerca de um mês depois, comprovamos a nossa hipótese: Vimos nosso engajamento e taxa de conversão das campanhas dobrar, e o número de pedidos de reenvio de notificações cair substancialmente.

Hoje nosso Notification Center armazena todas as notificações que enviamos e se mostrou uma ótima ferramenta para ajudar na gestão de saúde do membro, já que reúne as pesquisas de NPS, CSAT de consulta, lembretes de tarefas de saúde em atraso, convite para rodas de conversa sobre temas de nutrição, e outros.

O Notification Center foi nossa primeira implementação dos cards. Em seguida, aproveitamos o recurso e passamos a utilizar os cards para mandar as pílulas de saúde aos nossos membros, como veremos a seguir.

2. Customização das Pílulas de Saúde com base nos interesses dos membros

Aqui na Alice a gente ama falar sobre saúde. Dessa vontade de contar pro mundo mais do que estudamos sobre bem estar e qualidade de vida, criamos o Portal Time de Saúde, com matérias bem legais e interessantes sobre corpo, mente, comportamento, sono e alimentação.

Além de informativas, as matérias geralmente trazem dicas práticas sobre o tema tratado, tendo um alto potencial de ajudar as pessoas a mudarem hábitos. Assim, fazia muito sentido introduzirmos esse conteúdo no app, visando principalmente fornecer materiais de qualidade e informativos aos nossos membros e, dessa forma, empoderá-los cada vez mais para cuidarem da sua saúde.

Para isso, utilizamos os Content Cards do Braze (o mesmo que utilizamos para o Notification Center) e passamos a fazer um envio semanal das novas matérias publicadas no blog. Geralmente enviávamos uma matéria de cada vertical do Portal, tentando contemplar todos os interesses.

Após cerca de 2 meses dessa rotina, paramos para analisar o engajamento e estava mais baixo do que esperávamos. Não tínhamos um benchmark específico para nos basear mas acreditávamos que havia um potencial de melhoria.

Nesse momento, em um fórum com o time de Design, levantou-se a hipótese que um maior engajamento estaria atrelado a uma possibilidade de customização dos conteúdos a serem recebidos. Se o membro pudesse escolher exatamente quais assuntos receber no app, possivelmente isso geraria um maior engajamento com as matérias e o aplicativo.

E como perguntar ao membro o que ele gostaria de ler?

Recentemente o Braze lançou uma feature de survey in app, que possibilita enviar questionários com uma pergunta de múltipla escolha e salvar as respostas do usuário como um atributo do mesmo. Posteriormente, é possível utilizar essas informações de atributos do usuário para triggar campanhas.

O que fizemos no caso das Pílulas de Saúde foi exatamente isso. Enviamos a campanha abaixo para perguntar para os nossos membros o que eles gostariam de ler sobre saúde e, ao responder, essas informações eram salvas como atributos deles

Depois da seleção dos interesses, os membros conseguem visualizar somente matérias dos assuntos que eles curtem. Enviamos os conteúdos semanalmente e, depois de 7 dias, paramos para analisar o resultado. E sabe qual foi?

Depois da customização, triplicamos o engajamento (medido pela taxa de clique) dos nossos membros com as Pílulas de Saúde. Ficamos muito felizes com o resultado, porque além de trazer uma melhor experiência aos usuários do app da Alice, também damos mais visibilidade a conteúdos de qualidade sobre saúde, gerando informação e conhecimento.

3. Desafios de Saúde

Aqui na Alice sabemos que mudar hábitos não é algo fácil. Seja introduzir água no seu dia a dia ou adotar estratégias para dormir melhor, a mudança de comportamento não é linear e requer muito foco.

Por isso, sempre queremos ajudar ao máximo os membros que estão passando por essa jornada. Mas como ficar perto do membro e criar um programa de incentivo à mudança de hábito?

Desse problema surgiu uma iniciativa de engajamento de realizar esse programa via surveys in app, push, pop ups e cards no Notification Center. Criamos dois desafios: beber mais água e dormir melhor, e fizemos o convite aos membros que quisessem participar. Com a ferramenta Canvas do Braze, que permite criar trilhas e réguas de envio de notificações, estruturamos caminhos altamente customizados que o membro poderia percorrer durante o desafio, a depender das respostas dele.

Durante o desafio, que dura cerca de 4–6 dias após o opt in do usuário, o membro recebe várias comunicações com dicas, conteúdo e lembretes. Um dos exemplos legais é uma notificação de push programada para às 17h, um horário comum para um cafezinho, explicando que a cafeína demora cerca de 7h para sair do corpo, o que pode prejudicar o sono. Outro exemplo é uma notificação enviada perto das 20h, explicando que não há problema em fazer atividades físicas antes de dormir, desde que haja um intervalo de 2h, para permitir o corpo voltar à temperatura normal.

Já no desafio de beber água, as comunicações centraram-se em dicas de como introduzir o hábito no dia a dia, seja criando “regras” (ex: toda vez que for à cozinha) ou misturando água com frutas para dar sabor. Ao final dos dois primeiros dias de desafio, 67% dos membros disseram estar conseguindo beber mais água do que de costume.

A implementação dos desafios foi 100% via Braze por parte do time de Produto, sem precisar de nenhum input por parte Engenharia. A criação do conteúdo foi feita em conjunto com o Time de Saúde, pensando em como trazer a melhor experiência ao membro. E, bom, podemos dizer que os resultados foram bem animadores.

De todos que participaram do desafio de dormir melhor, 37% afirmaram que a qualidade do sono melhorou depois do programa. Já no desafio de beber mais água, 58% disseram que a ingestão de fluídos está melhor que antes. Ficamos bem felizes com estes números, já que o bem estar está diretamente ligado com esses hábitos, e mesmo pequenas mudanças já podem ter grandes impactos.

Conclusão

Aqui na Alice continuamos sempre expandindo o uso do Braze para cada vez mais ser uma ferramenta que efetivamente ajude nossos membros a cuidarem da sua saúde. Trabalhamos conjuntamente — Produto, Engenharia, Operações e Time de Saúde — para sempre criar e entregar conteúdos relevantes ao usuário com a melhor experiência possível via aplicativo. Ficamos felizes de olhar para trás e ver nossa evolução utilizando o Braze, e esperamos que seu papel aqui na Alice só cresça.

Em tempo: Esse post apresenta a nossa opinião sobre a ferramenta e suas utilidades. Gostamos muito dela e acreditamos que boas ideias merecem ser compartilhadas 😉

Curtiu o conteúdo e também quer tornar o mundo mais saudável? Veja nossas vagas em aberto aqui.

O post Braze: como o CRM melhora a saúde dos membros apareceu primeiro em Blog da Alice Tech.

Alice é uma empresa de Tecnologia cujo o propósito é tornar o mundo mais saudável. E como tal, resolve seus principais problemas pensando primariamente em soluções baseadas em Tecnologia. Desde o início, além dos sistemas que alimentam diretamente nossos produtos, construímos ferramentas que poderiam ajudar o trabalho de pessoas engenheiras no geral.

Por exemplo, lá nos tempos primórdios da Alice, construímos o que chamamos de Data Layer, uma camada de abstração de acesso a dados que garante privacidade e segurança para todas as aplicações. Iniciamos a resolução de questões super importantes pro nosso contexto de saúde: privacidade e segurança. Esse e outros projetos foram criados de forma orgânica. Nós identificávamos um problema na Engenharia, e então pessoas se juntavam organicamente pra pensar numa solução, projetavam, implementavam e colocavam no ar.

Entretanto, com o crescimento acelerado da empresa e com a necessidade de subir a barra de qualidade de Engenharia no mesmo ritmo, essa estratégia começou a apresentar problemas.

1. Percebemos que nesse modelo não havia um time para dar manutenção a esses projetos ou iterarem de acordo com novos requisitos. As iniciativas eram interpretadas na perspectiva de projetos pontuais e não de produtos internos e suas complexidades (clientes, necessidades de evolução e de negócio).
2. Além disso, alterações macro eram difíceis de serem priorizadas, já que a cada dia ficavam mais complexas e necessitavam de grande esforço de pessoas que, dentro do contexto de seus times, precisavam negociar algum tempo extra para desenvolver novos projetos cross.
3. Com nossa nova escala, também aumentamos a complexidade dos sistemas e o número de novas pessoas engenheiras, tornando “conhecimento tribal” e qualidade mais difícil de se reproduzir.

Diante deste cenário de crescimento rápido pós Series C, percebemos que precisávamos dar o próximo passo na nossa organização de Engenharia para atacar nossos desafios: os times de Plataforma.

Como é Plataforma na Alice?

O que é um time de Plataforma?

Times de Plataforma são geralmente voltados para uma missão técnica de empoderar o time de Engenharia a ser consistentemente eficaz, construindo produtos que abstraem os detalhes técnicos (requisitos não funcionais) e que permitem o foco no negócio. Exemplos desses produtos aqui na Alice são:

1. Data Layer: como comentado anteriormente, uma aplicação que abstrai quesitos de privacidade e segurança na persistência de dados;
2. Design Systems: um ecossistema de repositórios de estilos, componentes e padrões predefinidos e reutilizáveis que ajuda os times a criarem experiências consistentes e escaláveis com mais velocidade e fica acessível por meio de código e ferramentas de design.

Mas como Plataforma resolve o nosso problema?

Com um time focado nas iniciativas cross Engenharia, conseguimos ter a especialização e tempo necessários para construir e evoluir produtos que potencializam os outros times de Tecnologia.

1. Somos essenciais para escalar rapidamente: sabemos que padrões e frameworks estabelecidos facilitam a escala de conhecimento e qualidade na Engenharia. Além disso, com um dono claro para requisitos não funcionais, que são críticas para o funcionamento de qualquer produto, conseguimos garantir que todas as equipes cumpram os mesmos requisitos consistentemente.
2. Melhoramos a eficiência organizacional: reduzimos a duplicação de trabalho e ajudamos na padronização de abordagens (nos casos onde a padronização é um benefício para a organização). Além disso, como donos dos produtos, construímos software mais manutenível e escalável.
3. Agilizamos a entrega de novos produtos: além de remover conflitos entre squads e fornecer serviços que agilizam o desenvolvimento, podemos ajudar quando as equipes de produto estão introduzindo uma nova tecnologia. A equipe da plataforma pode incubar essa nova tecnologia e, em seguida, ajudá-la a ser adotada por outros squads. {plataformização}

Um pouco mais sobre nós

Na Alice, a visão do nosso time é ser o alicerce para a construção de soluções de Tecnologia que aceleram a entrega de saúde no mundo. Para chegarmos a esse objetivo, temos quatro pilares estratégicos:

1. Construção de soluções de forma colaborativa com os times: entendemos que só conseguimos ser pertinentes construindo as ferramentas certas se estivermos muito próximos dos times de Tecnologia entendendo suas dores. Ao mesmo tempo, somos o alicerce para construção de Tecnologia com qualidade, então estamos sempre perto dos times para ajudá-los em suas demandas e entendermos como podemos subir a barra de Engenharia. Em um caso recente, por exemplo, de construção da nova arquitetura Mobile, entendemos junto a todos os times impactados quais casos de uso tinham dificuldades na arquitetura antiga e construímos em conjunto um diagnóstico dos problemas correntes.
2. Antecipação de problemas e pensamento de longo prazo: como um alicerce sólido, desenvolvemos soluções que são robustas no longo prazo. Para chegar a esse objetivo consistentemente, utilizamos um processo diligente de entendimento dos problemas futuros e tomada de decisão. Por exemplo, no caso da nova arquitetura Mobile, além do diagnóstico, projetamos prováveis casos de uso futuros (funcionalidades mais complexas, interações entre diferentes módulos ou até suporte a funções nativas mais recentes), dando insumos para decisões fundamentadas.
3. Abrangência na resolução de problemas priorizando padronização e plataformização: um problema só deve ser prioridade para o time de Plataforma se impactar o alicerce de Tecnologia. Portanto, focamos em soluções abrangentes que podem ser padronizadas ou plataformizadas para a utilização em diferentes contextos. Nosso backend, por exemplo, é bastante padronizado: a quase totalidade das aplicações segue a mesma arquitetura e tecnologia (Kotlin) num mesmo repositório (monorepo). Num caso onde precisamos melhorar a utilização de recursos de uma aplicação, conseguimos com pouco esforço estender essa melhoria para todas as outras as aplicações da empresa.
4. Inovação: para construir um alicerce que acelera a entrega de saúde no mundo precisamos buscar novas soluções, dado que queremos obter resultados diferentes do que já foi feito no passado. A inovação é o único caminho para chegar no nosso objetivo e temos trilhado essa estrada desde a criação do nosso Data Layer, que, diferente de outras soluções de mercado, torna controle de acesso a dados e identificação e de-identificação de dados, padrões em todos os sistemas da Alice.

Nosso time tem menos de 6 meses, mas já atuamos nas nossas três frentes principais: Development Experience, Shared Systems e Quality. Algumas de nossas iniciativas recentes:

• Design System: pensando em DevEx e na padronização de comportamentos, construímos o core do produto, desenvolvemos e aplicamos nossos primeiros componentes Mobile
• Ferramentas de Desenvolvimento local: pensando em DevEx, construímos uma nova forma muito fácil de desenvolver localmente na nossa arquitetura de microsserviços utilizando um ambiente remoto
• Sherlock: pensando em escalar Privacidade, construímos um sistema interno que permite, em casos específicos, acesso a dados PII com rastreabilidade
• Observabilidade no frontend: pensando em escalar estabilidade, integramos nossa plataforma de observabilidade (tracing, alertas, etc) com a ferramenta de monitoramento do Datadog
• Data Layer: estamos desenvolvendo novas funcionalidades no nosso sistema compartilhado (que não tínhamos tempo de evoluir no passado) com foco em estabilidade, performance e escala da aplicação
• Arquitetura Mobile: como foco em qualidade, estamos construindo uma nova arquitetura de software que prepare o nosso aplicativo Mobile para os próximos anos de Alice

E este é só o começo… temos planos ambiciosos de sermos este alicerce de Tecnologia em saúde mundial e ainda temos diversas áreas inexploradas (DevTools, Testes de alta complexidade, Microfrontends, etc.)

Que tal fazer parte desse time?

Estamos buscando pessoas que topem o desafio de transformar a saúde no Brasil através da tecnologia. Clica aqui para saber mais das vagas que temos em aberto!

O post Plataforma: como escalar qualidade em Tech apareceu primeiro em Blog da Alice Tech.