A nossa resposta foi tratar IA na engenharia como um produto de plataforma, com um framework que o time inteiro usa, a Ada. Este post é sobre o que a Ada é, as decisões de arquitetura que a sustentam e onde estamos na adoção.

De onde vem o nome

Ada é sigla de Alice Development Approach, a forma como a Alice desenvolve software. O nome também homenageia Ada Lovelace, que escreveu o primeiro algoritmo da história em 1843, descrevendo um fluxo para uma máquina executar. É exatamente o que a plataforma sistematiza hoje: a forma como descrevemos trabalho para o Claude Code (ou qualquer outro coding agent) executar.

O que é a Ada

Desde o início do ano, o time de engenharia não escreve mais código à mão: descreve o que precisa, revisa e decide, e quem escreve o código é o Claude Code. A Ada é um plugin do Claude Code, no marketplace privado da Alice, que distribui para o time um conjunto de fluxos de trabalho versionados. Todos os desenvolvedores instalam com um comando, rodam os mesmos comandos sobre as mesmas regras, e recebem atualizações de forma centralizada.

A Ada cobre o ciclo de desenvolvimento de ponta a ponta, onde uma feature passa por uma sequência de etapas bem definidas. Há fluxos paralelos para investigação de bugs com análise de causa raiz, revisão de Pull Request e correções pequenas que não justificam a cerimônia completa.

O que importa aqui é menos em cada comando isolado e mais o fato de que todo o time roda os mesmos. Quando refinamos o fluxo de review, ele melhora para todo mundo na próxima atualização do plugin. Quando um padrão de teste se firma, ele entra no /execute e deixa de depender de quem está codando. É isso que transforma um conjunto de prompts num produto: a melhoria fica centralizada e a distribuição acontece de forma automática.

O que a Ada faz

A Ada organiza o trabalho em comandos. Cada um cobre uma etapa, e /feature costura o caminho completo de ponta a ponta. Por baixo, os comandos acionam subagentes especialistas (mapeamento de módulo, revisores por dimensão, detecção de squad), mas o dev interage só com os comandos abaixo.

Ciclo de desenvolvimento de uma feature

• /feature orquestra o caminho completo, com um gate entre cada etapa.
• /spec transforma um brief em especificação, com user stories, critérios de aceite e requisitos. É o início de qualquer trabalho novo.
• /plan lê a spec, gera um plano de implementação e todas as tasks que o agente deverá executar.
• /execute implementa o plano com TDD, atualiza as tasks conforme avança e verifica a cada fase.
• /verify roda lint, typecheck, testes e build no escopo do que mudou, e devolve aprovado ou rejeitado.
• /deploy-dev verifica e sobe a branch para os ambientes de dev para validação.
• /ship gera a descrição do PR a partir da spec e do plano, abre o PR e dispara o review.

Gates opcionais, quando a feature ainda tem incerteza

• /brainstorm explora o problema e propõe abordagens quando a ideia ainda está vaga. Roda antes da spec.
• /research dispara pesquisa em paralelo sobre APIs, exemplos e padrões do código quando a feature mexe com algo desconhecido. Roda antes do plano.
• /discuss varre a spec atrás de ambiguidade, edge cases e integrações indefinidas, e faz perguntas ao desenvolvedor para melhorar a spec. Roda entre a spec e o plano.

Bugs e suporte

• /bug investiga um ticket de suporte de ponta a ponta: define a squad responsável, faz a análise da causa raiz, valida as hipóteses contra os dados no Metabase e devolve um veredito.

Review de PR

• /review roda o review canônico da Alice, com classificação simples ou complexo, revisores especialistas em paralelo, calibração de severidade e um veredito explícito. É o que sustenta o auto review.
• /pr-review-digest resume os comentários de review (Ada, PR-Agent e pessoas) numa tabela do que ainda está em aberto.

Atalho e apoio

• /quick é o fast-track para mudanças triviais, um fix pequeno ou um ajuste de config, que não justificam a cerimônia de spec e plan.
• /feedback registra fricção na sessão com o usuário ou capacidade faltante da própria Ada, abre automaticamente um issue no github que alimenta o roadmap das próximas versões.
• /scan-pii adiciona uma camada extra de verificação de dados pessoais nos dados de avaliação de um PR.

Onde mora cada regra

É mais difícil decidir onde cada regra deve viver do que escolher o que automatizar. Uma instrução escrita no lugar errado ou vira ruído (aparece em contextos onde não se aplica) ou vira lixo (ninguém a encontra quando precisa).

A Ada resolve isso por meio de duas perguntas:

1. A regra é específica a um repositório? Se sim, ela mora no próprio repositório, num arquivo de convenções local. A Ada lê esse arquivo quando trabalha ali. Exemplo: a convenção de nomenclatura de migrations de um repositório backend não tem por que estar no plugin, ela pertence ao repositório backend.
2. A regra é agnóstica de repositório e envolve código executável? Se sim, ela mora na Ada como capacidade compartilhada. Senão, vai pra camada de helpers genéricos.

Essa separação é o que mantém a Ada enxuta. O plugin carrega o que é genuinamente transversal, como revisar um PR ou estruturar uma spec, e delega ao repositório tudo que é local àquele código. Cada repo continua dono das suas próprias regras, e a Ada não tenta saber tudo sobre todos.

Há uma consequência de design importante aqui: a Ada é stack-aware. A Alice tem backend em Kotlin e vários frontends em Vue e React. O mesmo comando /spec ou /verify funciona nos dois mundos porque a Ada resolve a stack ativa a partir de um registro e aplica os comandos de verificação certos pra cada uma. O dev não precisa saber qual mecanismo roda por baixo. Ele roda /verify e a Ada sabe se chama o build do backend, frontend, mobile ou outras stacks.

Como construímos

Em vez de adotar um framework fechado, combinamos o que funcionava melhor de seis referências do mercado numa abordagem própria, desenhada pro nosso contexto.

A Ada não tem uma squad dedicada. Ela é construída por um grupo transversal de staff engineers e engineering managers que não saem das próprias squads, e isso funcionou melhor do que concentrar tudo num time só pra isso. Quem desenha os fluxos é quem sente a dor deles entregando produto todo dia.

A Ada captura fricção do próprio uso, com um feedback loop embutido. Quando um fluxo falha ou frustra, isso vira um registro estruturado via github issue que alimenta a próxima iteração do plugin. O produto melhora a partir de como ele é usado de verdade.

Onde estamos

Acompanhamos a adoção por três indicadores.

• Código escrito com o Claude Code: 100%. O time de engenharia não escreve mais código à mão. Todos os devs têm commits feitos com o Claude Code, e essa é a forma padrão de trabalhar.
• Adoção da Ada: 90%. A maioria dos devs já roda os fluxos da Ada, além do Claude Code padrão. Os restantes são os que codam em alguma stack que a Ada ainda não reconhece.
• Review automático de PR. Um agente revisa os PRs, acelerando o processo de code review para evitar gargalos, dado o maior volume de código sendo produzido.

Chegar a 100% de uso de IA é relativamente fácil quando a ferramenta está disponível. Chegar a 90% de uso de um produto de plataforma, com fluxos versionados e compartilhados, é o sinal de um ganho organizacional, que circula pelo time inteiro em vez de ficar concentrado em alguns devs.

Remote Agents

Além disso, construímos agentes que atuam diretamente no fluxo de pull requests e bug report. Um revisa cada PR automaticamente. O outro avalia se a mudança está apta a ir pro ar. Outro investiga e resolve bugs reportados.

Auto Review

Assim que um PR é aberto, a Ada lê o código inteiro e devolve uma revisão estruturada em cerca de quatro minutos. Classifica a complexidade da mudança, sinaliza o que é crítico e sugere melhorias, com o código pronto para corrigir em cada ponto. São recomendações, e o autor decide o que aplicar. O ganho está em toda PR receber esse olhar, sempre. Hoje o auto review roda em 100% dos PRs de backend, frontend e mobile.

Auto-merge

O auto-merge é uma camada mais rígida, voltada para a segurança. Ele roda uma checklist de doze critérios antes de dizer se a PR pode ser mergeado: não ser rascunho, apontar pra main, não ter migração de banco, mudanças restritas a um único domínio, revisão aprovada, autor é codeowner, e assim por diante. O sinal verde só aparece quando todos passam e o PR é mergeado. Estamos sendo bem conservadores nesse primeiro momento, a maioria das nossas mudanças ainda pedem o olhar de uma pessoa antes do merge.

Bug-triage

O bug-triage é o primeiro a olhar um ticket de suporte. Ele lê o que foi reportado, identifica qual squad é responsável e consulta a base de conhecimento daquela squad pra entender se aquilo já apareceu antes. No fim, classifica o ticket em uma de cinco categorias: bug conhecido, bug novo, dúvida, não pertinente ou inconclusivo. É essa decisão que define o que acontece a seguir. O resultado da triagem são dois comentários no próprio ticket: um técnico, escrito para a squad responsável, e outro em português claro para a pessoa que reportou com a explicação que ela precisa. Se for um bug já conhecido, o usuário recebe o workaround na mesma hora. Se for algo que precisa de mais contexto, o agente pergunta. O ganho é que o ticket deixa de esperar dias até alguém de engenharia ter tempo de olhar — a primeira resposta sai em minutos.

Bug-solver

O bug-solver entra só quando o bug-triage diz que é um bug novo. A ideia é simples: se o bug é genuíno, não é necessário esperar um agente humano começar a investigar. Ele clona o repositório certo, lê as convenções daquele código e investiga a causa do bug vasculhando arquivos, procurando padrões, montando uma hipótese. Quando chega a uma conclusão, propõe a correção em forma de pull request, com a explicação do que mudou e por quê. Antes de o PR ir pro ar, passa pelo review automático da Ada e por uma checagem de dados sensíveis. Só depois disso o PR aparece no GitHub, pronto para o squad revisar, testar e decidir o que fazer.

Ada como remote agent. Esses agentes rodam como remote agents: o próprio evento de abertura do PR dispara a Ada remotamente, sem ninguém precisar iniciar nada. Alertas no Datadog e tickets de report de bugs no JIRA disparam os agentes de bug. Além de viver como plugin no terminal de cada dev, a Ada opera de forma autônoma dentro do fluxo de código, no momento exato em que o trabalho acontece. É o tipo de automação de IA em produção que aumenta drasticamente a capacidade de entrega do time de engenharia da Alice.

Como medimos o uso

Os números de adoção vêm de três fontes: os commits e PRs no GitHub, incluindo os trailers que marcam quando o Claude Code ou a Ada participaram de cada mudança; e o volume por dev. Isso dá uma leitura confiável, mas depende de coleta manual e de juntar as fontes a cada rodada.

O próximo passo é tornar essa medição contínua. Estamos construindo o ada-mcp, um servidor interno de Developer Experience que funciona como ponto único de entrada para métricas geradas por qualquer coding agent. Ele cobre duas frentes:

• Telemetria de uso. Cada vez que alguém roda um fluxo da Ada, o evento vai pro ada-mcp, que encaminha pro Datadog, sem depender de coleta manual.
• Métricas do próprio dev. Cada pessoa consulta o que rodou, por exemplo quantos /spec fez na semana.

Tem um detalhe que fecha o ciclo: o ada-mcp está sendo construído com a própria Ada, passando por /spec, /plan, /execute, /verify e /ship. Ada constrói Ada.

O que isso significa

Tratar IA como produto de engenharia significa assumir que o trabalho não acaba quando a ferramenta está disponível. Ele apenas começa. As decisões de onde cada regra mora, de quem constrói, e de como medimos uso real são o que separa “ter IA” de “fazer engenharia com IA”. É isso que a Ada é pra Alice, e seguimos construindo.

O post Ada: IA como produto da engenharia na 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.

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.

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.

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.