Sou apaixonado por code review.

No mundo da engenharia de software, temos inúmeras cerimônias* que visam tornar o time mais unido, mais capacitado, mais ágil, mais coeso, mais eficiente, mais feliz, etc. Em geral, cada uma das cerimônias visam atacar 1 ou 2 desses pontos. Mas tem uma delas que ataca tudo isso e ela chama Code Review. ❤️

Porém, fazer code review por uma mera “burocracia” pode até tornar as coisas piores. Uma forma de garantir que isso não vai acontecer é CONVERSAR SOBRE CODE REVIEW, e é isso que esse artigo quer provocar. Nada do que esteja escrito aqui é lei, regra, o “certo” ou a verdade absoluta. É só o que funcionou para o nosso time e talvez funcione pra você.

*são técnicas, processos ou qualquer outro nome que você queira dar pros costumes que temos em times de engenharia

Vamos começar pela importância?

O code review é o momento onde garantimos que estamos escrevendo um código que atenda à necessidade do cliente e que esteja de acordo com os padrões de design e qualidade definidos pelo time.

O código, antes de tudo, deve atender a necessidade do cliente (aqui entenda-se por qualquer cliente… outro dev, outro time da empresa, o cliente final, etc). Se isso não for verdade, muito provavelmente não deveríamos ter escrito esse monte de instruções pra máquina.

Depois disso, é hora de ver se o código que foi escrito cumpre o que foi combinado pelo time em relação ao código escrito em si. Vamos entrar em mais detalhes daqui a pouco.

Se code review fosse só pra achar erro no código de outro programador, não precisaríamos dele.

Quem são os responsáveis?

Os reviewers do PR são tão responsáveis pelo código que está entrando quanto o autor do PR. Até aqui nenhuma novidade, né? Masss…

Não devia ser necessário ficar implorando review. O autor não é responsável por ficar te cobrando de fazer review do PR dele. Se sua foto apareceu no Pull Request, se organize, pare e faça.

Afinal, quais são as 8 coisas?

0 → O código funciona? Nada é mais importante do que ter a certeza de que o código funciona. Por isso, antes de se preocupar com nome de variável, clean code, tamanho do botão, garanta que o que está escrito funciona. Pra isso, veja os testes automatizados, o ambiente de homologação e o que mais for preciso pra garantir que funcione. Fique atento aos edge cases. Happy path não é feature funcionando, tá?

1 → Entenda o que está sendo resolvido. Sem entender o problema que está sendo resolvido, dificilmente você vai entender o design da solução criada e muito menos encontrar possíveis problemas. Caso você não conheça o que está sendo resolvido, converse com o autor antes de fazer o review

2 → Comece pelas alterações “principais”. A partir desse ponto, você provavelmente vai chegar em todos outros pontos alterados no PR e será mais fácil de entender o design da solução.

3 → Preste atenção no design da solução. Veja as classes, módulos, arquivos e métodos que foram criados e como eles interagem entre si. Os arquivos foram adicionados no lugar correto? Os métodos criados estão na classe correta?

4 → Busque melhoria ao invés de perfeição. O código que está entrando melhora o codebase ou piora? Caso ele melhore, é um forte indicativo que o PR está ok para ir para produção. Isso não quer dizer que você não deve comentar sugestões de melhorias, elas são sempre bem-vindas. Porém, em alguns casos, não devem travar o valor entregue no PR.

5 → Fatos e dados ao invés de opiniões e preferências pessoais. Caso alguma sugestão esteja conflitando entre o autor e o PR, é indicado buscar artigos, referências e/ou dados que comprovem uma solução melhor que a outra. Caso nenhuma das 2 se prove melhor, prevalece a solução do autor.

6 → Recorra ao autor e a outros devs sempre que necessário. Está levando muito tempo? Está mandando vários “wtf” na revisão da solução? Chame o autor do PR (ou outro dev) para revisar junto com você e aproveite o momento pra aprender sobre o conteúdo.

7 → Compartilhe conhecimento. Por favor, ensine! Compartilhe materiais que justifiquem o que você está falando ou que comprovem que o que foi feito está certo. É o momento perfeito pra você ajudar o time a crescer (falo isso por experiência própria, aprendi muitooo com 100 comentários no meu PR kkk).

8 → Elogie! ❤️ Viu algo que resolve algum problema antigo? Alguma solução elegante para um problema complexo? Algum edge case safado coberto nos testes? Manda um ❤️ 👏.

Como saber se o code review do meu time tá bom?

Essas informações vão te ajudar a responder essa pergunta.

1. Tem bug indo pra produção? Quanto?
2. Quanto tempo demora pra um PR ir para produção?
3. O time está satisfeito com a qualidade do codebase? (squad health check pode ajudar aqui)
4. Tem features que só um dev sabe mexer?

Conclusão

Use o momento do code review pra criar um laço de companheirismo com seu time. Deixe o ego de lado e ajude o time a crescer.

Ah… o autor do PR pode ajudar na eficiência desse processo também, tá? Mas, outro dia falo sobre isso.

Bônus: o GitHub pode ajudar

Se você estiver dentro de uma organização (e time) no github, essas coisas podem ajudar:

Code review assignment

O GitHub pode marcar os reviewers do PR pra você (e ainda dá pra escolher o algoritmo).

https://github.com/orgs/<org>/teams/<seu-time>/edit/review_assignment

PRs do time

Vocês usam slack? Ele também pode ficar mandando, no canal do seu time, todos os PRs e quem são os responsáveis (essa exposição funciona, acredite kkk).

https://github.com/orgs/<org>/teams/<seu-time>/settings/reminders

E por fim…

Não poderia deixar de agradecer os meus companheiros de time: Guilherme Lourenço, Henrique Santos, João Cruz, Marcos Toledo e Mateus Carneiro

8 coisas para talvez melhorar o code review do seu time was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como designers, somos confrontados o tempo todo com discussões sobre como fazer um Discovery ou até mesmo como provar o seu valor. De um lado, temos profissionais que lutam por espaço estratégico, do outro, empresas preocupadas com a eficiência dos seus times. Conquistar esse espaço vai muito além da abertura para realizar pesquisas, é preciso alinhamento com negócio e entrega de valor.

Como chegamos até aqui

Não tenho a intenção de abordar com detalhes o que é um Discovery em si, mas acredito que algumas informações são importantes para contextualizar melhor o momento que nos encontramos no mercado de tecnologia no geral.

No início do século XXI, o Manifesto Ágil[1][2] chegou como uma alternativa que revolucionou a forma como as empresas encaravam o fluxo de desenvolvimento de produtos, apresentando uma abordagem mais centrada no usuário formou o que chamamos hoje de Product Discovery. Essa metodologia busca trazer entendimento sobre o problema e uma visão mais clara da solução, garantindo alinhamento e validação da proposta. Essa mudança de abordagem foi muito importante, pois levou equipes a desenvolver de forma mais segura, garantindo que estavam resolvendo o problema certo com uma solução válida e bem sucedida.

Com a adesão de metodologias ágeis em alta e um mercado de startups com quase metade dos negócios falhando por falta de market-fit[3] (ajuste do produto ao mercado) o entendimento sobre a importância de criar soluções alinhadas com as necessidades do usuário foi se solidificando. Em meio a essa movimentação, as empresas passaram a buscar profissionais que pudessem atuar com mais clareza na definição de um problema, trazendo a experiência do usuário como pilar e, de certa forma, até influenciando na movimentação de profissionais de Produto e Design para áreas menos relacionadas à solução (User Interface — UI) e mais centradas no problema (User Experience — UX).

Com a disciplina de UX no seu auge, a aplicação do Discovery foi se integrando, cada vez mais, no processo de desenvolvimento dos produtos, chegando a ser considerada por alguns uma etapa indispensável na construção de qualquer solução. O que antes buscava trazer otimização na entrega, agora, por muitas vezes, tem gerado discussões sobre performance, falta de foco, e até mesmo se tornado o vilão para muitos stakeholders. Nos levando a pergunta: eu realmente preciso de um Discovery?

Antes que eu seja cancelado pelos mais fervorosos, quero deixar claro que o Discovery é sim uma das melhores formas de garantir o alinhamento e sucesso de um projeto. Assim como também precisamos reconhecer que o uso, por muitas vezes quase que religioso, desses processos não têm beneficiado nossa conquista pela tão sonhada posição estratégica.

Os fatores: cadência e adaptação

É comum encontrarmos profissionais muitas vezes até orgulhosos de toda metodologia aplicada em um Discovery ou do quanto as etapas dos processos foram respeitadas, segundo as diretrizes de frameworks como Design Sprint e Design Thinking, levando a uma cadência de entregas com prazos significativamente maiores, mas que seriam justificados pelo cumprimento de um cronograma e pela garantia de resultados melhores.

A polêmica discussão sobre cadência pode incomodar os mais metodológicos, ainda assim precisamos levar em conta a relevância e o impacto que o timing de uma entrega pode ter para o negócio, sendo listado em muitos estudos como um dos principais fatores de sucesso para uma empresa[4].

Entregar valor em tempo hábil é uma alavanca importante no crescimento de um negócio. Para isso, a flexibilidade como um todo de design/produto é essencial, com total adequação ao contexto do problema, tendo a qualidade de uma descoberta não baseada na aplicação de um grande volume de frameworks e metodologias hypadas, mas na capacidade dos profissionais de adequar cada etapa do processo para obter o aprendizado de forma otimizada.

Clareza e preparo

Logicamente, o discernimento depende de uma maior experiência e maturidade na aplicação dos processos. Com um nivelamento heterogêneo, garantir eficiência no amadurecimento, com esforços realmente orientados ao resultado, tem sido um dos meus principais desafios como gestor de design.

Para desassociar o sucesso de projetos do uso de determinadas metodologias, acelerando o ritmo de aprendizagem, criamos um plano de treinamento do time. Atrelamos um processo que pudesse permitir o acompanhamento de resultados, trazendo alinhamento sobre quando era necessário realizar determinadas etapas do processo de Discovery e, assim, garantir um padrão de qualidade nessa etapa.

Antes de definir um processo, entendemos o contexto do nosso time e os desafios existentes, considerando pontos como:

• Diferentes níveis de experiência e conhecimento do time;
• Alto custo para cenários de baixo impacto;
• Desalinhamento de expectativas entre líderes e stakeholders;
• Identificação de problemas durante a execução dos projetos.

A partir disso, estruturamos algumas perguntas/etapas para que cada designer ou gerente de produto tenha maior entendimento do seu cenário, buscando definir um racional padronizado que auxiliasse todo o time:

Quando fazer um discovery?

Oferecer critérios que auxiliem na definição de maturidade e risco de um projeto, para que assim seja determinado o que precisa ser descoberto.

O que fazer no discovery?

Tornar claro que tipo de pergunta deve ser respondida em cada variação de cenário, evitando que perguntas desnecessárias sejam respondidas e a performance seja prejudicada.

Como fazer um discovery?

Explicar como cada framework ou metodologia funciona e que tipo de respostas elas trazem, criando uma ligação clara entre as perguntas que seriam feitas e as possíveis formas de conseguir as respostas.

O que entregar no discovery?

Garantir o alinhamento das expectativas, principalmente com líderes e stakeholders, sobre os possíveis entregáveis de cada etapa.

Encontrando padrões

Após essa primeira fase definida, com o time entendendo se determinada iniciativa necessitava de Discovery, seguimos para a segunda parte. Definimos uma estrutura para as descobertas, de forma que o time mantivesse a padronização necessária para mensurar os resultados.

Definimos 3 formas de Discovery que poderiam ser realizadas. Elas se diferenciam na profundidade de entendimento necessário, que foi clarificado e alinhado na etapa anterior:

Planejamento da squad (Definindo cenários e estratégia):

Processo de descoberta no contexto macro da squad, realizado no início do semestre. Define-se os questionamentos e dores que precisam ser priorizados.

• O quê, quem e qual ( Exemplo: O que é o produto? Quem é o usuário?…)
• Impacto/Esforço
• Priorização

Discovery padrão (Aplicado a um cenário já definido):

No caso de um contexto com pouca informação, é necessário investigar o cenário, bem como entender e priorizar o problema.

• Entendimento
• Viabilidade
• Risco

Define (Maior entendimento sobre o cenário)

Quando já temos mais segurança sobre o cenário ou menor risco e precisamos alinhar o problema e já começar a convergir em uma solução.

• O quê
• Por quê
• Como

Definido o que vamos responder em cada etapa, conseguimos alinhar melhor os pontos de quebra no processo para garantir o pragmatismo necessário, assim, quando já temos as respostas podemos simplificar a definição e focar em solucionar o problema, utilizando o modelo de discovery mais robusto para cenários incertos ou de grande impacto, e uma definição mais objetiva para cenários de grande certeza ou pequeno impacto.

Adequando a rotina e documentação

Por fim, para garantir a execução e visualização/alinhamento, integramos a proposta com o processo de documentação no Jira (software que utilizamos para gestão de tarefas). Assim, organizamos modelos que, se preenchidos corretamente, oferecem para a liderança um acompanhamento simplificado da performance.

Cada uma das etapas pode conter tarefas de acordo com o contexto. Com esse modelo, conseguimos acompanhar informações sobre a performance do time em cada uma das fases e como uma variação de cenários afeta a execução do processo, auxiliando, dessa forma, a identificação de pessoas que necessitam de auxílio ou projetos que precisam de algum tipo de alinhamento estratégico.

Padrões vs Flexibilidade

Nesse processo, decidimos trabalhar com uma base em comum e, com ela, simplificar o aprendizado, a gestão e a metrificação. Esses padrões macros não mitigam as individualidades de cada profissional nem anulam a flexibilidade na execução. Pelo contrário, elas focam na clareza, alinhamento e categorização, permitindo assim que cada profissional tenha autonomia na tomada de decisão durante o processo.

Assim como outras padronizações do nosso time, como o Design System, nossos processos estão em constante evolução,adaptando-se à realidade de cada time.

E aí?

O processo de discovery veio como uma forma de aproximar a voz do usuário ao processo de desenvolvimento de produtos, trazendo um maior alinhamento das necessidades do público-alvo com a abordagem do negócio. Executá-lo de forma estratégica requer pragmatismo, aplicando metodologias com uma abordagem que foca em responder as principais perguntas de forma direta.

Com a implementação do nosso processo, otimizamos o alinhamento de expectativas da liderança, facilitamos a dinâmica com profissionais de produto nas etapas de descoberta e trouxemos mais clareza para os designers sobre a realização das etapas. Clareza essa que, alinhada com as iniciativas de desenvolvimento, colabora com o aumento da confiança do time.

Acreditamos que a abordagem de design deve ser sempre flexível, aberta aos erros, voltada para os aprendizados e focada nas soluções. Aliando o apoio ao negócio na tomada de decisão com um ambiente altamente eficiente.

A missão do time de design na Quero:

“Apoiar o negócio na tomada de decisão através da visão do cliente e da tangibilização da estratégia. Projetando experiências universais de alto valor para nossos clientes, em um ambiente altamente eficiente e humano.”

Se quiser fazer parte deste time, estamos com vagas abertas.

Leia também:

• Casa de ferreiro, espeto de ferro: sobre resultados exponenciais no investimento da sua ferramenta interna
• Design ágil na prática: adaptando UX ao seu meio e cultura
• Onboarding de design em tempos de pandemia: Simulando uma experiência real, o(a) novo(a) designer finaliza sua integração de forma remota gerando um entregável e conhecendo muito melhor seu usuário

Esse texto se baseia em materiais de terceiros para construir alguns argumentos, você pode saber mais sobre eles nos links abaixo:

[1] O que é o Manifesto Ágil, seus 4 valores e 12 princípios.

[2] Manifesto Ágil — Wikipédia, a enciclopédia livre

[3] Why Startups Fail: Top 20 Reasons l CB Insights

[4] A principal diferença entre as empresas de sucesso e as que fracassam

Você não precisa de um discovery! was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando falamos em escalabilidade, a primeira coisa que nos vem à cabeça é o auto-scaling, mas, na verdade, isso é apenas a cereja do bolo. Existem muitos fatores que devemos ficar atentos antes de configurarmos um auto-scaling. Usando como base o Vestibular Premiado, evento da Quero Educação com 57 mil inscritos, como estudo de caso, compartilhamos alguns aprendizados.

Métricas importantes

Antes de colocar a mão na massa, precisamos seguir esses 3 passos:

1. encontrar e entender quais problemas temos;
2. medir o tamanho desses problemas;
3. e por fim criar/usar uma estratégia de correção. Ou seja, neste bloco, vamos falar de como encontrar, entender e medir os problemas.

Uso de CPU da aplicação:

Essa métrica serve para entendermos o quanto nossa aplicação está otimizada em relação aos outros itens. É muitas vezes desejado que o gargalo principal seja o uso de CPU da aplicação por ser mais fácil de controlar o auto-scaling, mas isso não quer dizer que não devemos otimizá-la, muito pelo contrário. Comentarei sobre isso em “Código pouco eficiente”, abaixo.

Uso de Memória da aplicação:

Aqui, olhamos se a aplicação tem problemas de uso de memória conforme o volume de acessos aumenta e, via de regra, devemos sempre ter uma sobra de mais ou menos 20% do uso de pico para evitar travamentos repentinos (out of memory).

Reservar um espaço de SWAP é desejável e pode evitar um travamento, mas deve ser raramente usado.

Uso de CPU do banco de dados:

Aqui entendemos se nossas queries estão otimizadas e/ou faltam índices. É normal o uso de CPU do banco de dados subir com o volume de acessos, mas, se o uso subir de forma exponencial, pode ser um indício de falta de índices/otimizações.

Uso de memória do banco de dados:

A memória do banco de dados é usada para cache de consultas (leituras apenas) e a quantidade desejada depende do uso da aplicação e/ou quantidade de registros. Os bancos de dados normalmente vêm configurados de fábrica para usar entre 80% e 90% da memória total da máquina e isso é perfeitamente normal. Deve-se aumentar apenas se observar ganho de velocidade em consultas.

Tempo de resposta da aplicação:

Essa métrica é muitas vezes ignorada, mas é provavelmente a mais importante. O que medimos aqui é quanto tempo a aplicação demora para responder cada request. Ela é importante, pois, quando temos situações de lock ou concorrência o problema, pode não aparecer em outras métricas, mas será facilmente encontrado e medido pelo tempo de resposta.

Como testar

Agora que sabemos quais métricas devemos ficar de olho, devemos testar nossa aplicação para entender onde está o gargalo. Eu disse no singular pois esse é um processo minucioso no qual removemos um problema por vez e, depois, reiniciamos o ciclo de testes.

Para testar, basta simular uma alta carga de acessos, começando pelas principais rotas do sistema (as que os usuários acessam com mais frequência) e aumentando a cobertura de rotas depois de algumas rodadas. Existem diversas aplicações para criar testes de carga e relatórios, como jMeter e Cypress.

Outro ponto de atenção é criar uma bateria de testes mais realista possível para evitar de testar situações que não refletem o cenário real. Em um dos testes que fizemos no Vestibular Premiado, nós reutilizamos o mesmo usuário em todas as requisições e acabamos criando uma concorrência irreal pelo mesmo registro no banco de dados (ops!). Isso mascarou os resultados dos testes e tivemos que refazê-los para poder procurar os problemas.

Código pouco eficiente

Nesse momento, suponho que você rodou os testes e descobriu que o uso de CPU da aplicação ficou cravado em 100% ou pior: 100% de apenas um dos núcleos.

100% de um núcleo só:

Isso acontece porque sua aplicação está rodando com uma thread só (óbvio, né?) e é mais frequente em linguagens interpretadas, mas também é comum em outras linguagens. Felizmente existem bibliotecas que resolvem isso para você, como a cluster (NodeJs) e gUnicorn (Python).

100% de todos núcleos:

Lembra que eu disse lá no começo que isso era desejável, mas temos de ter cuidado? Aqui vale uma análise quantitativa e de custos. Se precisamos de 2 a 8 núcleos para atender a quantidade de usuários simultâneos que desejamos com tempo de resposta baixo, pode valer mais a pena investir seus esforços de engenharia em outros lugares do que tentar economizar alguns dólares com infraestrutura.

No entanto, se você precisa de muito mais poder de processamento para atender sua demanda (aqui, falo de uma ordem de grandeza ou mais de diferença), é hora de procurar o que está errado com o seu código. Existem ferramentas nativas de profiling que podem te ajudar a encontrar gargalos e momentos que aplicação fica esperando, mas também é importante termos um desenvolvedor capaz de entender os pormenores da linguagem e identificar práticas que causam problemas (como criar uma estrutura massivamente OO em Python, que não é otimizado para isso).

Não existe uma saída fácil nesse momento, você sempre deve tomar o cuidado de avaliar o custo (tempo + quantidade de devs) para resolvê-los e ponderar se vale a pena fazer intervenções grandes.

Banco de dados

Chegamos no ponto mais delicado, principalmente, quando usamos bancos relacionais. Não me entenda errado, bancos relacionais funcionam muito bem e muitas vezes ficam com a culpa por conta de devs preguiçosos e não por suas limitações. Aqui, precisamos falar de métricas novamente, pois a análise é mais complexa.

Uso de CPU alto, pouco uso de disco (iops baixo):

Indício de falta de índices ou de concorrência entre registros! Aqui, devemos olhar o slow query log ou, no nosso caso,que usamos RDS Postgres, a página “Performance Insights” do console da AWS. Essa página usa um código de cores que indica qual tipo de ação está bloqueando o comando, exatamente o que estamos procurando.

O mais importante é o uso de CPU (barra verde), mas vale a pena estudar as outras métricas para entender situações diferentes. Na imagem abaixo, conseguimos entender quais comandos estão causando problemas.

E o próximo gráfico mostra o que aconteceu quando criamos os índices necessários. A seta vermelha é o momento que criamos os índices — o volume de acessos continuou o mesmo:

Mesmo depois dessas correções, nosso tempo de resposta continuava alto. O RDS reportava ocupação alta de ClientRead e baixa quantidade de iops. Lembra que eu falei que testamos as rotas com um usuário só? Foi neste momento que descobrimos que criamos concorrência em um único registro.

Uso de CPU baixo, IOPS alto:

Indica que muitos dados estão sendo puxados em cada consulta. Não é necessariamente um problema, mas você deve procurar entender se está puxando campos demais nas suas queries (nunca use select * se não precisa de todos os campos).

Cereja do bolo:

Depois de fazer todas essa otimizações, é hora de escalar verticalmente e/ou horizontalmente. Aqui as possibilidades são imensas (sharding, replicas, máquinas com burst, etc.) e não é o foco desse artigo.

Dependência de terceiros

Aqui, foi o nosso maior aprendizado com o Vestibular Premiado. Temos algumas integrações com parceiros que funcionavam em tempo real e qualquer falha poderia causar impacto na nossa plataforma.

Por uma série de motivos que não valem a pena estender aqui, decidimos usar SQS para organizar e transformar essas integrações em eventos assíncronos. Criamos uma estrutura onde a aplicação guarda os dados necessários no banco de dados e envia o ID para a fila SQS, retornando um feedback de sucesso pro aluno imediatamente.

De forma assíncrona, temos um job que busca esses IDs da fila, carrega os dados e envia para o terceiro. Se der erro ou o terceiro não responder, o ID volta para a fila. Abordagem simples, direta e resiliente.

Foi assim que conseguimos atender mais de 20 mil provas (entre redações e múltipla escolha) e 3800 acessos simultâneos com apenas um mês de esforço de um squad de engenharia e custo mínimo de infraestrutura (uma única t3.medium deu conta da aplicação).

Leia também:

• Black Friday para estudar: como trabalhamos as campanhas para alunos e instituições de ensino.

Vestibular Premiado: como escalar uma API was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Levando o mesmo nome da equipe de Guias do Aluno, o squad Relacionamento é responsável por desenvolver produtos que melhoram a experiência dos usuários dos nossos principais produtos, seguindo a grande missão da unidade de negócio.

E, para atingir os nossos objetivos e missão em cheio, trabalhamos em tecnologias que incentivam e enaltecem o atendimento humano dos nossos guias ou naquelas que têm como diferencial a velocidade dos chatbots. E essa mensagem ecoa como um mantra em toda tarefa e reunião em que vivemos no nosso dia a dia e em cada linha de código que escrevemos.

Essencial para o business

Assim como o time de Customer Experience, o squad Relacionamento é essencial para o negócio da Quero Educação. Quando falamos de cultura e valores, dizemos que os alunos são nossa razão de existir, por isso, trabalhar em sua experiência é tão importante para o negócio da Quero Educação.

E sabe como trabalhamos na sua experiência? Melhorando as ferramentas de trabalho do time que atende esses alunos. Por isso, um dos grandes benefícios do squad é estar bem próximo — mesmo com a distância da pandemia — dos usuários dos produtos que desenvolvemos. O trabalho em conjunto é essencial para contribuirmos para a evolução constante das ferramentas, identificando quais são suas falhas e novas oportunidades.

Para ficar ainda mais claro, desenvolvemos o produto OPA (Painel do Guia do Aluno), suas variações e a Quiara, o chatbot, responsável pela automatização das respostas. Desta forma, garantimos por todas as vias a melhoria de atendimento dos alunos. Evoluindo a ferramenta OPA, damos suporte por meio da tecnologia à cordialidade e qualidade do atendimento humano e também contribuímos para a rapidez do atendimento com a utilização da inteligência artificial.

Ambos caminhos são importantes para a evolução da Quero Educação quando trabalhadas em conjunto. Por um lado, temos bons produtos de atendimento para que os guias atendam com qualidade os alunos. Por outro lado, a Quiara ajuda em um momento de grande crescimento de alunos nos procurando para tirar dúvidas. Nosso chatbot é uma resposta para uma inviabilidade de contratar inúmeros guias do aluno.

Como resultados, temos o atendimento cada vez mais rápido e com mais qualidade e a contribuição para o aumento de faturamento do projeto.

Produtos e tecnologias

O OPA é um painel, o qual os guias do aluno utilizam diariamente para conversar com os alunos por meio de chamadas de voz, Whatsapp e e-mail. O objetivo é facilitar o acesso aos dados de cada oferta e instituição de ensino, já que é lá que os guias encontram todas as informações que os alunos possam precisar.

Para vocês terem uma ideia, antes do OPA existir, os guias utilizavam diversas abas no navegador para conseguir conversar com o aluno e também acessar essas informações no Quero Bolsa. Agora está tudo no mesmo lugar e o guia pode acompanhar o aluno em toda a sua jornada, do momento que ele está escolhendo o curso certo até o final de seu curso, já que o time acompanha o aluno além da finalização de sua matrícula.

Para seu desenvolvimento, utilizamos Elixir e Phoenix no back-end e Vue e Nuxt no front-end. Outras tecnologias utilizadas são: websocket para atualizações real-time, K8s, Helm e Terraform na infraestrutura que está hospedada na AWS e também Github Actions e AWS Codebuild para integração contínua.

Também utilizamos PostgreSQL e Redis para salvar nossos dados, o Whatsapp Business API e Asterisk, Zendesk e Freshdesk para integração com serviços de telefonia, chat e email respectivamente.

Outro projeto do time é a Quiara, o chatbot que nasceu de um problema que precisávamos resolver. Nosso atendimento, ao receber uma carga alta de pedidos durante alguns períodos do ano, precisava ser escalado para melhorar seu serviço.

A partir da união de times multidisciplinares, a Quiara é desenvolvida para ajudar o aluno em dúvidas e perguntas mais simples e acelerar o atendimento humano com as dúvidas mais complexas. Neste serviço de inteligência, utilizamos o framework RASA em Python.

Desafios com foco nos alunos

Durante o período de matrícula em instituições de ensino, assim como os acessos do Quero Bolsa, o OPA recebe uma grande demanda de atendimento. O Whatsapp hoje é a ferramenta que mais recebe mensagens de alunos para conversar com nossos guias. E é a partir destes períodos de “alta temporada” que nascem os maiores desafios do time.

Quem entra no squad relacionamento recebe como missão encurtar o tempo de atendimento dos alunos sem perder a qualidade. Desta forma, sem dúvida, o maior desafio do time é encontrar formas de atendê-los de forma cada vez mais automática para diminuir, por exemplo, a fila do atendimento no Whatsapp.

Esses desafios serão resolvidos com a utilização da Quiara, nossa menina dos nossos olhos, com a criação de ferramentas em que o aluno possa resolver suas dúvidas sozinhos no site do Quero Bolsa e otimizando o trabalho dos guias.

Nossos novos parceiros e parceiras de equipe vão nos ajudar a desacoplar nossos sistemas do Quero Bolsa e a transformar a engenharia do OPA para que seja um produto independente para que qualquer vertical da Quero Educação possa utilizá-lo (Graduação, Ensino Básico, LLL, etc).

Outro desafio do nosso time de Engenharia do Relacionamento está relacionado à integração. Devido à função dos nossos sistemas, integramos o OPA com diversos canais de relacionamento para que os guias consigam resolver os problemas dos alunos em um só lugar. Enquanto isso, os alunos poderão comunicar por qual canal ele preferir (chamada de voz, e-mail, chat ou Whatsapp).

Por mais que essa parte do trabalho esteja bem desenvolvida, melhorias constantes nunca são demais, não é mesmo?

Diferenciais do squad, impacto para a empresa

Apesar de assumirmos o nome do time de Guias do Aluno, o squad Relacionamento também tem oportunidade de desenvolver produtos e novas features para os aluno. Como resultado, temos um grande número de cenários para atacar e melhorar a experiência dos alunos em sua jornada.

Desta forma, o trabalho em conjunto é um dos maiores diferenciais em estar no squad. Muitos de nossos projetos saem do papel pela ajuda multidisciplinar que contamos no desenvolvimento de nossos produtos. Um exemplo claro é a Quiara que nasceu com o trabalho da Engenharia, Produto, Data Science, além de outras áreas além de tech, como time de guias do aluno e de branding.

E, com isso, ter contato diariamente com os atendimentos é uma oportunidade de entender os problemas que precisamos resolver por meio da Engenharia, inteligência e novos produtos.

Estar próximo da equipe de atendimento é também sentir que está próximo deles recebendo seus feedbacks positivos e construtivos quando encontramos soluções.

Trabalhar nesse contexto de atendimento é também ter desafios únicos, já que os usuários de nossos produtos são experts. Complementando, a UI/UX para esses usuários são mais complexas do que para usuários casuais (como no Quero Bolsa), trazendo desafios para o front-end por ter muitas ações ocorrendo na mesma tela. O resultado deste trabalho, portanto, é construir grande parte do fluxo de atendimento de alunos.

Além disso, trabalhar no desenvolvimento de um produto que impacta toda a empresa é uma grande responsabilidade que transcende a nossa própria missão e a da empresa também.

Nossa missão nasceu com o propósito da empresa e com um de nossos valores como parte de suas peças fundamentais. Para a empresa, o aluno é rei. Para o OPA e a Quiara, os alunos são motivo de sua existência. E para o squad Relacionamento também.

Quer fazer parte deste desafio? Estamos com vagas abertas!

Leia também:

• Dos devs aos guias: como adaptamos nossa tecnologia para o Home Office
• Casa de ferreiro, espeto de ferro
• Inception: as dinâmicas de início de trimestre do B2C

Tecnologias para experiência dos alunos e o squad que as desenvolvem was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Com o mesmo objetivo de captar alunos, o time de tecnologia do Quero Inbound da Quero Educação reforça o nosso propósito de levar educação a mais pessoas de uma maneira diferente do nosso tradicional Quero Bolsa — por atração de tráfego e conteúdo.

Nosso time cria produtos com um papel consultivo para que os alunos consigam entender, ao longo de sua jornada em nossos sites, quais são as possibilidades e qual é o melhor caminho a ser seguido.

Nesse processo, não é oferecido um desconto, como é feito no marketplace Quero Bolsa, mas uma resposta a uma dúvida que o usuário possa ter.

Fazendo parte dos produtos B2C e ainda considerado um dos novos negócios da Quero Educação, a tribo Inbound herdou o modelo de negócio a partir do aporte das operações de educação da Quinstreet no ano passado.

Hoje, o objetivo do nosso time de tecnologia é inovar a partir desse modelo de negócio, gerando mais valor para a Quero, alunos e instituições de ensino de diversas formas, uma delas foi o lançamento de novos marketplaces: Guia da Carreira, Mundo Vestibular e EAD.

Somos da frente de Novos Negócios da Quero Educação, que investe em novas frentes de negócio, que vão além do marketplace de cursos de graduação. Na tribo Inbound, o time de tecnologia — composto por representantes de Produto, Design, Engenharia e Data Science — trabalha ao lado dos times focados nas estratégias comerciais, operação de vendas e mídia.

O funil

Para desenvolver nossos produtos devemos trabalhar com o funil do nosso modelo de negócio. Nosso fluxo se inicia nas impressões das nossas campanhas de mídia paga ou dos banners nos nossos sites de conteúdo, e é a partir dos cliques que o aluno entra em contato com nossos produtos — anunciando o início da jornada do estudante em nossa plataforma.

A mágica acontece quando o estudante acessa nosso formulário — o grande fio condutor que passa por todos os produtos que desenvolvemos. Ao responder as perguntas do formulário, o estudante nos ajuda com os nossos objetivos: qualificá-lo para seguir em sua jornada e aumentar seu engajamento até a decisão de compra.

Conforme o estudante responde cada uma das perguntas, ele nos ajuda a entender se ele possui o perfil para seguir no nosso processo. Caso ele se encaixe, ele está um passo mais perto de escolher um curso para estudar.

Não deu para qualificá-lo? Está tudo bem! O formulário, ao engajar o aluno, cumpre também com o fim de ajudá-lo a entender o que ele está procurando. Afinal, só quem passou por um momento de escolha de carreira sabe que a indecisão às vezes toma conta da gente, não é mesmo? Portanto, se ele for “desqualificado” em nosso formulário, ele ganha outras opções, como procurar por um curso no Quero Bolsa.

Por outro lado, caso ele avance em nosso fluxo, alguém do customer center entra em contato com o aluno e o ajuda no processo de inscrição no vestibular da instituição de ensino escolhida. A partir deste momento, para fins de aprovação em vestibular e, enfim, matrícula do aluno, a instituição de ensino assume e nossa ajuda na jornada do aluno está quase ao fim.

Os produtos

Okay, falamos do funil, falamos dos produtos de nossos colegas… Mas e os produtos da Tribo Inbound, quais são?

Os nomes de squads de nossas tribos respondem a pergunta — Baseline e Descoberta. O primeiro tem a função de garantir a eficiência dos produtos originais, enquanto o segundo trabalha na descoberta de novas oportunidades para nosso negócio.

Todos os nossos produtos atuais são baseados na geração de leads que pode estar conectada com o contato via call center. Atraímos os usuários por conteúdos relacionados a educação, essa atração pode ser por mídia orgânica a partir dos nossos sites de conteúdo próprios e também por campanhas de mídia paga com afiliados e campanhas de PPC.

Para gerar os leads, utilizamos o formulário que falamos no capítulo anterior para dar match do aluno com as faculdades parceiras nos cursos que possam interessar aos alunos. Esses formulários podem ser branded, ou seja, com a cara (layout e assets da marca) da instituição de ensino parceira.

Existem produtos que usam também o formulário unbranded, significando que o tráfego e o lead não são específicos e atrelados à uma marca de faculdade. Neste tipo de contato com formulário, o aluno pode receber resultados de diversas instituições de ensino parceiras e escolher as opções que preferir.

Entendendo que o formulário tem o papel de engajar, também trabalhamos para melhorar a experiência do fluxo que estudante terá enquanto responde as perguntas para encontrar seu melhor curso. Focando no engajamento, trabalhamos o layout de nossos produtos com mensagens motivacionais e tutores representativos do cenário brasileiro para que o aluno se identifique e entenda que ele pode, sim, estudar.

Nesse tipo de formulário, quando o aluno se sente representado, conseguimos aumentar o número de inscritos em 22% em relação ao formulário tradicional. Comparando o fluxo total, tivemos um aumento de 14% de taxa de sucesso, inscrevendo cada vez mais alunos nas faculdades parceiras.

Além do engajamento e qualificação

Somos uma equipe que trabalha com esse modelo de negócio há anos e é uma alternativa para impactar mais alunos que buscam uma forma de estudar. Em vez de oferecer um marketplace com as opções de cursos, instituições de ensino e descontos, trabalhamos diretamente com o tráfego e o interesse desses alunos para oferecer a melhor opção para ele.

Entre nossos objetivos, queremos aumentar a quantidade de alunos se matriculando em instituições de ensino e oferecer uma nova opção de acesso à educação para grande parte do mercado.

Trabalhar no time de tecnologia da Tribo Inbound é reforçar a missão da Quero Educação, desenvolvendo produtos para encurtar as distâncias da educação, ajudando cada vez mais pessoas a escolher e ingressar no curso compatível com sua realidade.

Obs. Este artigo foi escrito em conjunto com Helena Porchia, business & data analyst, que nos ajudou a desenvolver os produtos até setembro de 2020.

Está interessado neste desafio? Estamos com diversas oportunidades na nossa tribo!

Leia também:

• Tech para Novos Negócios: k12 e LLL

Quero Inbound e a tecnologia para estratégias de marketing de atração was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Em uma jornada imersiva de duas semanas, os participantes do evento estão vivendo a experiência real de descoberta de produto. Com 60 participantes em 20 equipes formadas, os inscritos no evento viveram um problema da Quero Educação e a dinâmica real de um product manager para finalizar o jogo.

O que é o Product Game

O Product Game é um evento externo, criado por Carolina Costa (product manager, fundadora do Güd Studio), Maria Lemos (product manager na Cubos Tecnologia) e Gabriela Ribeiro (UX designer na Conveste) com a intenção de ser uma jornada imersiva para quem quiser viver o universo de produto de verdade. Apesar do nome, nosso evento é mais que um jogo — é a oportunidade dos inscritos vivenciarem o dia a dia de um product manager durante a fase da descoberta do produto.

Essa oportunidade é focada naqueles que acabaram de entrar na área de product management e UX ou estão em processo de migração, já que a proposta é aprender tudo na prática (e não apenas na teoria). Em duas semanas, a proposta é de viver um desafio real de uma empresa com produtos consolidados, aplicando técnicas e recebendo mentoria de grandes nomes do mundo de produto.

O que é a jornada

Os participantes receberam um problema desenvolvido por nós, a empresa parceira do evento. Durante todo o processo de product discovery, está havendo a interação com stakeholders reais para alinhamento estratégico, levantamento de oportunidades até a definição da solução final.

Entre os stakeholders da Quero, estão participando Thomás Dias (CPTO), Éder Costa (head de tech do B2C/B2B), Lucas Gomes (Diretor de B2C e cofundador da Quero), Luã Vaz (líder de Design), André Simões (head de tech do Quero Inbound), Kelvyn Rosinski (líder de Data Science), Jan Klever (design system ops), Luiz Piazentini (PM), Lucas Aquino (tech lead), João Vitor Alves (tech lead), Gustavo Guimarães (engineering manager) e Ney Pimenta (group engineering manager).

E não é só isso! Os participantes têm a oportunidade de receber mentoria de especialistas em produto de fora da Quero, além de assistir palestras com grandes nomes de produto.

A parceria

O desafio foi desenhado a partir de um problema proposto pelo nosso time de produto, baseado em vivências do passado e em soluções que já desenvolvemos a partir deste problema.

Baseando-se em dados da Quero Educação, semanalmente os participantes estão consultando os nossos stakeholders para entender o contexto da Quero e do problema em si para, assim, poderem entregar o melhor planejamento. A ideia é viver a experiência do product discovery em sua totalidade.

O contato com os stakeholders também tem sido importante para que o resultado dos participantes esteja alinhado com a visão de produto e a estratégia da Quero, assim como nossa visão, missão e valores.

No final da jornada, a banca avaliadora da Quero será responsável por escolher o melhor time do Product Game se baseando nos critérios acima e se a solução é viável tecnicamente.

Além do mais, o projeto inteiro têm acontecido com suporte de Éder Costa (head de tech), Nathalia Lopes (BP de tecnologia) e Gisela Bobato (coordenadora de comunicação).

O que é Product Discovery

De forma bem resumida, essa descoberta de produto é um conjunto de atividades que realizamos para entender como evoluir um produto. Utilizamos técnicas, frameworks e ferramentas para descobrir evidências que nos ajudem a reduzir riscos, tomar decisões e testar novas hipóteses.

Nesse processo, entendemos melhor o valor, a usabilidade, a execução e a viabilidade do produto e entendemos se ela pode ou não dar certo no momento de lançamento. Assim, com suporte dos times de design, engenharia e produto, conseguimos mitigar os riscos antes de iniciar o processo de “delivery” do produto.

E, para finalizar este processo, vivemos três fases:

Exploração: É o momento em que sabemos pouco do assunto, quando precisamos pesquisar sobre o problema e também a solução. Liderado pelos UX designers, é o momento de pesquisar fontes de dados e realizar entrevistas com usuários.

Prototipação: É a procura de uma possível solução. É a prototipação rápida, dentro do seu grupo de trabalho, com os stakeholders, etc. E também a discussão com o time de Engenharia para entender se conseguimos entregar em um tempo razoável.

Acompanhamento/Otimização: Como o nome diz, é hora de acompanhar o MVP depois que entra em produção, comparando com o resultado esperado. Também é a hora de propor novas soluções.

Durante o Product Game, os participantes têm a chance de simular essas fases (a primeira e a segunda) para que a banca avaliadora entenda a viabilidade da última fase.

Fim de jogo

Ao final do jogo, além de aprender e ter contato com personagens reais do Produto, os participantes ganharão cursos da PM3 e também terão a chance de participar do Speed Hiring com empresas inscritas. Nosso time de tech recruiters já está pronto para participar e, quem sabe, contratar novos nomes da gerência de produto.

Entramos como colaboradores do Product Game por sermos apaixonados pelo mundo de Produto. Queremos encontrar outros apaixonados e acelerarmos a capacitação de quem quer construir novas e inovadoras soluções no Brasil.

Quer nos ajudar a descobrir novos produtos para encurtar as distâncias da educação no Brasil? Estamos com vagas abertas.

Quero no Product Game: capacitando novos profissionais de produto was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Os desenvolvedores da Quero Educação se reuniram organicamente para contribuir para projetos open source durante o Hacktoberfest de 2020. Com o objetivo de reunir interessados dentro e fora da Quero em aprender com esses projetos, montamos com um repositório público para contribuição até o último dia do mês de outubro.

O que é o Hacktoberfest?

Criado pela Digital Ocean, o Hacktoberfest convida a todos para contribuir com a comunidade global de open source durante o mês de outubro de todos os anos. Os participantes podem ser de todos os backgrounds e níveis de habilidade em desenvolvimento de projetos do tipo.

Só em 2019, foram 48127 pull requests em 154767 diferentes repositórios. Participaram pessoas de 142 países e a linguagem mais utilizada foi o JavaScript com 89603 PRs (o equivalente a 18,55%).

O maior objetivo do evento é o crescimento desses projetos, nos quais os participantes estarão focados para trabalhar neles durante um mês inteiro. Caso os inscritos concluam o desafio do evento, podem ganhar a camiseta oficial da edição ou plantar uma árvore pela Tree-Nation.

Por que e como a Quero entrou nessa?

Queremos facilitar o acesso aos participantes do evento (sejam da nossa empresa ou não). Com um repositório em português, disponibilizamos e centralizamos informações sobre projetos open source.

Além disso, estamos oferecendo mentoria para quem quiser tirar dúvidas em projetos específicos. Você pode agendar agora mesmo de acordo com os seguintes assuntos:

Fastify e Node.js:

• Rafael Gonzaga é nosso tech lead e é apaixonado pelo mundo open source. Para falar com ele, agende seu horário.

Javascript:

• Aderbal Filho é desenvolvedor do Quero Inbound, um dos projetos recentes aqui da Quero. Foi quem convidou todos os desenvolvedores da Quero Educação para o projeto. Se quiser bater um papo sobre Vue.js e React, é só consultar a agenda dele e marcar um horário.
• Pedro Costa é engineering manager do squad que desenvolve o Quero Bolsa e está com a agenda aberta para falar sobre Vue.js, React e Gatsby.
• Vinicius Hoyer é programador do squad responsável por desenvolver os novos marketplaces da Quero Educação (Guia da Carreira, Mundo Vestibular e EaD). Ele disponibilizou alguns horários para conversar sobre Vue.js, Nuxt.js, eslint e regex.

Ruby / Rails

• Pedro Costa também vai dar mentoria sobre assunto por ser a referência da comunidade de Ruby aqui na Quero Educação. Inclusive, ele foi o mediador da edição das Dev Talks sobre Ruby com Rafael França e Ney Pimenta. Confira um horário na agenda.

Tudo relacionado a Vim

Vinicius Hoyer também está dando mentoria sobre vimscript e regex por aqui.

Benefícios e algumas dicas dos mentores

Para os mentores da Quero Educação, participar de projetos open source durante o evento é sinônimo de aprendizado, pois é o momento de “sair da bolha” e de encontrar um grande número de issues para entrar um projeto. Ou seja, é muito mais fácil encontrar e aprender com um projeto durante o mês de outubro.

E eles reforçam: caso não se sintam preparados para contribuir, há repositórios com tarefas simples, normalmente marcados com a tag good first issue/hacktoberfest. Outras tags que valem dar uma olhada, mesmo que não sejam tão simples, são: help-wanted, documentation e contributions welcome.

Além das pequenas dicas, é importante seguir as regras:

• Fazer seu registro entre 1 e 31 de outubro.
• Fazer 4 pull requests (PRs) válidos (que não sejam marcados como spam ou invalid, havendo um prazo de 7 dias para a revisão) em qualquer repositório público.

Participe conosco!

Se quiser contribuir conosco e saber mais informações, confira nosso repositório no Github e leia mais sobre projetos open source.

Hacktoberfest e a contribuição dos desenvolvedores da Quero no open source was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Antes da pandemia, éramos conhecidos internamente por um processo de onboarding intenso, completo e bastante humano. A necessidade de passar por todo esse processo remotamente nos fez rever e reformular nosso calendário de atividades, que agora é mais produtivo e muito mais imersivo em nosso universo.

Processos de onboarding são custosos, tanto para a empresa, quanto para quem está iniciando o novo cargo. De um lado, temos toda expectativa de entregas a serem realizadas, enquanto, do outro, a necessidade de absorver um grande volume de informações.

Nessa nova proposta, o(a) novo(a) designer de produto da Quero Educação tem a oportunidade de viver uma simulação da experiência do dia a dia durante o processo de onboarding.

Dentro de um ambiente controlado, criamos a oportunidade de integração com os times, a vivência prática dos processos e a adaptação mais rápida ao novo desafio.

Entre os resultados positivos (e compartilhados abaixo), temos a otimização do processo e a produção de uma entrega real para o squad em que você vai trabalhar.

Está pensando em trabalhar no nosso time de design de produto? Então dê uma olhada no que espera por você nos primeiros dias de Quero Educação.

Desafios e motivações da mudança

Antes de mais nada, a adaptação e a revisão do processo de onboarding de design de produto foram feitas com os seguintes objetivos: garantir que o novo colaborador, além de conhecer a empresa como um todo, tenha uma imersão nos processos e ferramentas de design e que também consiga otimizar seu aprendizado em cada atividade, reduzindo de forma geral seu “ramp-up”.

E já adianto… Não foi uma tarefa simples!

Tínhamos, no geral, um grande volume de informação que precisava ser transmitida. Processos, design system, diretórios, reviews, critiques, cerimônias de gestão. Some tudo isso ao conhecimento de negócio, produto e ainda a variação de personas presente em cada contexto.

Os nossos principais desafios eram:

• Converter um processo presencial para remoto.
• Otimizar o tempo necessário para adaptação e performance.
• Melhorar a dinâmica e processo de aprendizado de um grande volume de informações.
• Entender a organização e aumentar integração com outros times e departamentos.

Shine bright like a double diamond

Todo o calendário foi pensado no conceito de double diamond, mapeando todas as necessidades para que fosse possível a contribuição para o desenvolvimento de um produto real no onboarding da Quero: descobrimos, definimos, desenvolvemos e entregamos algo relevante para o squad e para a empresa.

Depois de entregue, a solução deve ser acompanhada e ter seu resultado medido. Considerando que o acompanhamento das métricas possui complexidade e tempo variável, optamos por deixar fora do processo de onboarding e ser realizada posteriormente no fluxo padrão da squad.

Nos primeiros dias de descoberta, você passa por um momento de imersão bem intenso no qual tem contato com toda estrutura da empresa, nossa cultura, processos e documentação, além de uma série de 1x1 com todos seus stakeholders, líderes e pares.

Na segunda etapa, a mágica começa a acontecer, pois você passa pelo momento de análise para expandir seu conhecimento sobre o usuário, seus problemas e o produto. Neste caso, o treinamento com o time de CX e o contato com o usuário são essenciais para o processo. Para ajudar, nos próximos dias, exploramos essas oportunidades com o alinhamento com o produto e um entendimento do negócio e mercado.

Por terceiro, é o momento de exploração das hipóteses. É quando começamos a convergir todas as ideias já trabalhadas nos dias anteriores. Por isso, conhecer bem as ferramentas e gerar alguns entregáveis no dia é importante.

É hora da definição, quando, na quarta etapa, trabalhamos com a ideação e começar com o processo de validação das ideias. Neste caso, como estamos trabalhando com problemas pequenos e específicos, o curto espaço de tempo para o onboarding não é um impedimento.

E, assim, partimos para a fase final do nosso double diamond e a entrega do produto acontece, com todo suporte do squad, dos designers e dos stakeholders.

Mais que um cronograma, uma jornada de imersão

Para garantir o sucesso do cronograma, elaboramos um calendário com uma organização diária, no qual descrevemos todas as reuniões, atividades e documentação necessária para a realização de cada etapa. Assim, evitamos que a pessoa por falta de contexto ou até mesmo timidez, tenha problemas cumprir a agenda.

Tendo apoio de diferentes profissionais em diferentes etapas, há o contato direto com a unidade de negócio no qual o squad está inserido. Tudo isso para que haja o conhecimento do modelo de negócio, dos usuários do produto e dos problemas que vamos ajudar a resolver.

O processo pode durar de 15 a 25 dias. Alguns deles, como o de prototipação, têm sua programação estendida para se adequar a complexidade do projeto e ritmo de entrega. Dessa forma desenhamos o calendário da seguinte forma:

Dia 1: Ao lado dos novos colaboradores de todas as áreas, é o dia de onboarding institucional. É a oportunidade de conhecer um pouco da história da Quero Educação, a estrutura da empresa e a cultura.

Dia 2: O processo é o mesmo para todos. Neste dia, atendemos os alunos do Quero Bolsa, o primeiro produto da Quero Educação. Conhecemos de perto quem foram os primeiros usuários de nossos produtos utilizando o OPA (Painel de informações do Guia do Aluno), utilizado pelo nosso time de relacionamento.

Dia 3: Vamos começar a ter contato com design? É dia de alinhamento da cultura específica de design com o head de Design, Álvaro Rosa, e de apresentação do cronograma desse processo de integração. É também o dia em que você vai bater um papo com a Business Partner do time de tecnologia e os líderes de design das tribos.

Dia 4: Este dia é intenso! Vamos conhecer os guias de uso do branding e de escrita da empresa, algumas documentações de design e alinhamento com a Engenharia. Além de conhecer alguns dos representantes dessas áreas, existe um momento de leitura e estudo.

Dia 5: É chegada a hora da integração com a unidade de negócio em que você vai trabalhar. Vamos conhecer os stakeholders, o GPM (Group Product Manager), o PM (Product Manager), o tech lead do squad e o designer da tribo.

Dia 6:

Lembra do dia 2? Agora é hora de ir mais a fundo, conhecer melhor o usuário específico da unidade de negócio, que pode ser um aluno ou alguém da instituição de ensino. Você terá um treinamento ao lado do time de CX (Customer Experience) para entender os processos de atendimento e também o acesso à documentação para conhecer as personas. O objetivo é resolver um exercício com base nas personas e mapear as dores do usuário neste atendimento.

Dia 7: É o momento de explorar algumas oportunidades, fazendo alinhamento e conhecendo o produto, além de uma atividade prática para análise de concorrentes. É neste dia que um entregável é gerado: a matriz de posicionamento.

Dia 8: Vamos definir algumas hipóteses? Para isso, vamos trabalhar usando algumas ferramentas como service blueprint, Hotjar, Amplitude, entre outras. Além disso, os entregáveis do dia são a Matriz CSD e a definição dessas hipóteses.

Dia 9: É o momento de trabalhar com ideação, wireframes e validação, utilizando critique e heatmaps.

Dia 10 em diante: Com todos os passos anteriores cumpridos, podemos trabalhar em uma solução mais sólida. Assim, a partir deste dia, podemos introduzir contextos para otimizar o processo de construção em alto nível. Conhecemos o processo no Abstract e também é o momento em que apresentamos oficialmente o Zilla, nosso design system, aos novos designers. Assim, todos terão as ferramentas certas para executar a prototipação, se preparar para a critique final e passar pelo design review para validação.

E… voilà! Você está pronto para entrar em uma sprint junto de seu squad. Tendo uma visão inicial do usuário e negócio, conhecendo cada pessoa que vai te ajudar a fazer acontecer, além dos processos e ferramentas necessárias. E o melhor: você gerou um entregável e contribuiu para o squad mesmo ainda estando em onboarding.

Benefícios e resultados imediatos

O benefício que mais se sobressalta nesse novo processo de onboarding é, sem dúvida, o fato de que o novo designer recebe todas as ferramentas e suporte para entregar em poucos dias sua contribuição real para o squad. Desta forma, contribuímos para que a pessoa esteja mais preparada e confiante para atacar seu próximo desafio.

Porém, a geração de um entregável não é um benefício por si só. Ela só acontece por conta do itinerário que criamos para sua jornada, na qual cada etapa do processo é pensada de forma estratégica para seu aprendizado.

Por isso, todo o suporte do squad não é visto como um problema durante a integração dele(a) no time, já que, mesmo em onboarding, o(a) designer e seu squad já estão trabalhando juntos.

Assim, em um curto espaço de tempo, o(a) novo(a) designer de produto consegue acelerar a curva de aprendizado, tendo como consequência um nível de independência maior, podendo assumir mais responsabilidades dependendo menos de auxílio ao fim do processo.

Abrindo as portas para uma nova fase profissional

Mesmo com toda a otimização e reformulação do processo de onboarding do(a) novo(a) designer, sim, admitimos que é um momento intenso, no qual várias janelas de conhecimento se abrem para conhecermos toda a complexidade dos produtos da Quero Educação. Mas o importante é que, na fase final, quando o segundo diamante se forma, o(a) profissional estará muito mais mais preparado(a) para abrir as portas e começar sua história por aqui.

A partir daí, toda a interação feita com outras tribos, a guilda de design, seus usuários e companheiros de unidade de negócio acontecerá de maneira fluída no seu dia a dia como designer de produto da Quero.

Agora é só focar na nossa missão, que é encurtar as distâncias da educação, seja qual for o usuário que você vai ajudar — o aluno ou a instituição de ensino.

Gostou de conhecer nosso processo de onboarding? Conheça nossas oportunidades.

Leia também:

• Design Ágil na prática: adaptando ao seu meio
• Inception: as dinâmicas de início de semestre da tribo B2C
• Design System: da confusão à construção de um produto

Onboarding de design em tempos de pandemia was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

O time de marketing da Quero Educação lançou recentemente o Internet pela Educação, um manifesto que defende o acesso a conteúdos educacionais para pessoas que não têm possuem uma boa conexão de internet. E, se o assunto é tech e educação, nosso time de tecnologia não poderia ficar de fora.

Para contribuir com a causa, em vez de alocarmos os desenvolvedores no produto, criamos um hackday para entregar um página com o manifesto que promovesse acessibilidade, performance e uma boa experiência para usuários nessas condições. A proposta iria além de competição, já que mais de um squad estaria disposto a fazer parte do movimento.

Foram 24 horas e sete soluções entregues desenvolvidas por desenvolvedores, product managers e designers que queriam ir além da contribuição diária que fazem todos os dias em nossos produtos oficiais da Quero Educação.

Antes de mais nada, o que é o Internet pela Educação?

A educação remota durante a pandemia deixou clara a desigualdade digital. Enquanto poucos privilegiados conseguiram seguir com seus estudos de forma remota, temos um grande número de pessoas que podemos chamar de excluídos digitais.

Segundo o Cetic.br, cerca de 39% de estudantes não possuem um computador e 21% só tem acesso à internet via celular com planos limitados. Além disso, 33,5% dos inscritos do ENEM nos últimos cinco anos não têm acesso à internet ou a dispositivos que permitam essa conexão.

Para os criadores do manifesto,

“se queremos um país melhor, é necessário acabar com a desigualdade na educação. Limitar o acesso à internet para estudar é uma barreira que precisa cair imediatamente.”

Assim, o objetivo do movimento é criticar a limitação dos planos de dados no acesso a conteúdos educacionais pelas operadoras.

Tecnologia pela educação; logo, pelos estudantes

Mesmo após o manifesto ter sido lançado, resolvemos contribuir por acreditarmos no propósito da nossa edtech — queremos expandir esse acesso à educação para mais pessoas. Diariamente já desenvolvemos produtos, como nosso principal marketplace — Quero Bolsa, que segue à risca a missão da Quero:

“levar a educação a mais pessoas, ajudando-as a escolher e ingressar no curso certo, por um preço que possam pagar.”

Grande fã de eventos de tecnologia no geral, Augusto Queirantes, desenvolvedor do produto Quero Pago, se inscreveu com seu time neste hackday pelo seu objetivo final.

“Ajudar estudantes a ter acesso a conteúdos relacionados à educação sem que isso seja descontado na franquia é, de fato, um objetivo ousado, porém, decisivo para mudar vidas. E eu queria fazer parte disso”, conta.

Para João Vitor Alves, a oportunidade de trabalhar com propósito e com diversão com pessoas próximas foi também um ponto positivo. “Além disso, o objetivo bem definido do hackday nos chamou atenção. Cada time faria do seu jeito, com suas prioridades e premissas, porém, todos com um objetivo final em comum — melhorar um produto, torná-lo mais funcional e atrativo", explica.

Mãos à obra, digo, ao código

Com a landing page já criada, os squads inscritos para o hackday deveriam desenvolver uma solução seguindo um guia de boas práticas de front-end acessibilidade, documentado pelo front-ender responsável pelo nosso design system, Danilo Vaz. Álvaro Rosa, head de Design da Quero, escreveu o guia de UX design para os participantes. Além disso, os requisitos foram escritos pelo time de marketing, baseados em suas dificuldades encontradas com a primeira versão da página.

E, mesmo com uma página simples e com uma proposta simplificada, todos os times encontraram desafios. “A maior dificuldade foi, sem dúvida, o escopo do projeto. Parecia pouca coisa a se fazer à primeira vista, mas as várias funcionalidades diferentes para se preocupar e as 24 horas para atacar o problema foram os maiores desafios do hackday”, conta Pedro Adas, product manager do produto Quero Pago.

Mesmo assim, desafios como este sempre trazem aprendizados. Letícia Yanaguya, tech lead em um dos squads do Quero Bolsa, conta que, além da gestão de tempo, vender o produto é quase tão importante quanto desenvolver a solução. “O valor total da sua entrega não será visto e você será avaliado pelo que está visível. É importante entender que os investidores e interessados saibam todos os pontos positivos, as falhas e a motivação de investimento no seu projeto”, aponta.

As sete equipes de quatro pessoas tiveram um dia para desenvolver a ideia. No dia 26 de agosto, de meia-noite até às 23h59, recebemos os projetos que poderão estar disponíveis em repositórios pessoais de acordo com a vontade de cada participante.

Todos os times contaram com o suporte de Jan Klever, design system ops da Quero, que levou seu conhecimento para todos os times. No último instante, ele desistiu de participar apenas com o time com quem se inscreveu para ser o product designer coringa do hackday.

“Eu não sou fã de competições, mas essa foi a forma de ajudar em um propósito que eu acreditava e que tem tudo a ver com o que eu faço no meu dia a dia. Pelos nossos usuários, eu queria que a acessibilidade estivesse em primeiro lugar nesse projeto, independente da equipe que vencesse", conta Jan.

E, assim, cada uma dos sete projetos tiveram toques essenciais de acessibilidade e UX, enquanto os desenvolvedores das equipes tomaram conta da performance no novo site que iria ao ar na semana seguinte.

Caminhando para a vitória

A avaliação e escolha dos vencedores foram feitas pela banca avaliadora composta por Thomás Dias, CPTO da Quero Educação, e os heads de tecnologia, Álvaro Rosa, Éder Costa, Victor Bernardo, Einstein do Nascimento e André Simões. Além dos requisitos propostos pelo marketing, foram contadas notas de SEO, boas práticas, performance, acessibilidade, identidade de marca e também o pitch de #amorDeEmpreendedor, um de nossos valores na Quero Educação.

Os vencedores, além da premiação física, também ganharia os créditos na nova versão do site. Se você acessar o Internet pela Educação, vai ver os nomes de André Custódio, Augusto Queirantes, Gustavo Guimarães, Pedro Adas e Jan Klever estampados ao final da página.

Perguntei para eles porque acharam que foram os vencedores e a resposta de Gustavo resume a sua vitória: “Focamos no básico bem feito, usamos as tecnologias mais simples que existem para que entregássemos um produto de forma justa e que pudesse ser utilizado por todos os usuários que possuem um acesso mínimo aos dados.”

E André Custódio complementa: “Esse tipo de ‘competição’ traz o que os colaboradores têm de melhor e a troca de experiência é única. Os grupos acabam sendo diversos, dando um toque maravilhoso ao projeto. Sem falar da troca de conhecimentos que faz com que os aprendizados sejam gigantescos.”

Utilizando Firebase, HTML, CSS, JS, Netlify, NoSQL e S3, a equipe venceu a disputa e o site foi ao ar no início de setembro.

Que a vitória seja de todos os estudantes brasileiros

Todos os dias trabalhamos para encurtar as distâncias da educação com nossos produtos para instituições de ensino e para os alunos, mas dias como esses são tão importantes quanto. É ao sair um pouco da rotina que relembramos do nosso propósito diário na Quero Educação.

Seja no time de tecnologia, na equipe comercial, no RH, no marketing ou no financeiro, o objetivo maior é sempre o mesmo: fazer a nossa parte para que cada vez mais alunos tenham acesso à educação.

A vitória, desta vez, ficou por conta do André, do Augusto, do Gustavo, do Jan e do Pedro. Mas que ela — junto com a performance e acessibilidade — seja apenas mais um passo para que o acesso à educação seja sempre um direito de todos.

Leia também:

• Tech e educação: como a Quero influenciou alunos do Ensino Médio de São José dos Campos
• Design system: conectando desenvolvedores e designers: https://medium.com/techatquero/design-system-conectando-desenvolvedores-e-designers-51d2e5ac96d5

Internet pela educação e um hackday pelo acesso justo à educação was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pode ter certeza que a cultura de startup dessas últimas duas décadas transcendeu e influenciou os sonhos de algumas pessoas desta nova geração que está para entrar no mercado de trabalho. Talvez o que eu e você queríamos na nossa adolescência, entre o final dos anos 90 e o início dos anos 2000, não é o mesmo que os adolescentes do final desta década desejam. Os motivos são muitos, mas resolvi contar uma história a partir do ponto de vista de quem trabalha em uma startup de tecnologia.

Já que denunciei minha idade no parágrafo anterior, vou abrir o jogo. Já no começo da minha adolescência, aos 13 anos, eu sabia que queria ser um engenheiro e gostava de tecnologia. Foi quando descobri que o ITA existia, perguntei para meu pai se era uma faculdade boa. Quando ele respondeu que “sim”, pensei: “Ah, é lá que vou estudar então”. Determinado, né? rs. Sim, eu era o nerd que se divertia com as olimpíadas de física e afins!

Mas por que estou com esse papo nostálgico (para não dizer papo de velho)? Porque, no mês passado, eu recebi um pedido para dar uma mentoria de gestão e tecnologia para dois estudantes do Ensino Médio. E essa é a história que escolhi contar para vocês no dia de hoje.

Antes de tudo: Não, gente, isso não é um #publipost. rs! Isso é sobre o papel que o seu time de tecnologia que trabalha com educação pode ter em influenciar as novas gerações — e eu já adianto que estou muito orgulhoso do nosso time por isso.

O prefácio de uma história bem atual

André Guadalupe é diretor e professor e ministra um curso extracurricular para estudantes do Ensino Médio no Colégio Planck, aqui de São José dos Campos. O curso é chamado, nada mais, nada menos, que “Startup & Empreendedorismo”, no qual ele estimula os estudantes interessados a pensar fora da caixa e também em todo o fluxo que uma startup precisa passar para escalar suas ideias e produtos.

Trabalhei com ele, que também é formado em Engenharia Aeronáutica pelo ITA, de 2012 a 2015 e recentemente ele me procurou para falar sobre os produtos que estão sendo desenvolvidos no curso. Um deles é o do estudante Davi Rizzo, de 15 anos, e seus três colegas que estão desenvolvendo o “Protágonos” — plataforma que pretende oferecer cursos voltados 100% para as habilidades socioemocionais para jovens que buscam protagonismo. Eles já estão com o protótipo pronto e estão buscando professores parceiros. Quem sabe a gente não faz uma parceria com o Quero Bolsa lá no futuro, né?

Também ouvi sobre o projeto desses quatro alunos, incluindo a Maria Eduarda Mota, também de 15 anos, que estão estudando lançar o “iDog”, que pretende entregar ração 100% orgânica para pets. Estão até fazendo um alinhamento com uma veterinária para seguir com o modelo de negócio!

E, finalmente, a história que me chamou mais atenção (já já vocês vão saber o porquê), sobre a startup “Ensino”, do Enrico Salomão e Diogo Basso, de 15 e 16 anos respectivamente, que pretendem desenvolver produtos para a educação.

Todos eles deixaram claro que pretendem seguir com suas startups lançadas no curso e que desejam seguir no ramo. Até porque, se já não tinham sido influenciados anteriormente pelo tema de alguma forma, o curso acabou plantando uma sementinha.

A startup “Ensino” e a democratização de ensino

O primeiro projeto da startup de Enrico e Diogo é o aplicativo “Planck Conectividade” que transformou um projeto (até então analógico) de ensino que já existe na escola em um formato digital.

De aluno para aluno, o grande objetivo é o compartilhamento de conhecimento entre eles. O app os ajuda, portanto, a gerenciar essas aulas. Além disso, eles já estão pensando em novas features, como stories para compartilhamento de dicas de ensino, para pensar no aplicativo como uma rede social para o Ensino Básico.

E sabe qual é o objetivo deles? Democratizar a educação do país! Eles querem ajudar as escolas de pequeno a médio porte oferecendo funções para ajudar estudantes a continuar aprendendo.

O papel do time de tech da Quero Educação nessa história toda

Tudo começou com o Enrico, do “Ensino”, quando ele tinha 12 anos. Ele já tinha aquele sonho de ter uma startup e resolveu aprender tudo sobre o que precisava para ter sua própria empresa. Ele ouviu falar de startups como a Quero Educação e passou a estudar os requisitos de todas as nossas vagas de emprego para entender do que ele precisaria no futuro.

E foi aí que ele começou a programar, escolhendo o que ia estudar a partir dos pré-requisitos a partir das nossas vagas de tecnologia e, futuramente, dos artigos do nosso blog de tecnologia.

Felizmente, ele influenciou seu parceiro de desenvolvimento, Diogo Basso, que já tinha essa vontade de ter sua própria startup e interesse em ser dev. Assim, os dois vêm desenvolvendo o aplicativo do “Planck Conectividade”. Ambos têm vontade de empreender e começar sua própria startup e fico feliz por nosso time ter influenciado de alguma forma.

Foi assim que eu os conheci — a convite do André Guadalupe, dei mentoria para os dois, dando dicas sobre tecnologia, stacks, MVPs, validação e empatia com usuários e desafios de uma startup. Não vejo a hora de ver os resultados e o impacto do primeiro produto desenvolvido por eles em seu meio!

Vi o brilho nos olhos refletido no sucesso de Enrico ao falar de empreendedorismo e desenvolvimento de software e também o futuro do Diogo ao falar de suas habilidades com bancos de dados, Python e machine learning.

Quero mesmo é que essa pandemia acabe para poder convidá-los para conhecer nossos times de Produto, Engenharia, Data, Design e Infra (sim, todo mundo!) na Quero Educação. Porque dá pra ver que, em breve, o próximo passo é aquele que dá o impulso que os fará voar mais alto, né, meninos? E eu quero encontrá-los antes desse voo acontecer.

Educação e tecnologia, caminhando juntos

Confesso que, quando estava no Ensino Médio, sonhando em ser o engenheiro do ITA, nunca pensei que pudesse influenciar alguém. Ver que nosso time de tecnologia que trabalha por um propósito da educação, com sua história e empenho, conseguiu inspirar, de alguma forma, uma parte dessa nova geração me deixa sem palavras.

A missão da Quero Educação é trabalhar com o propósito de transformar a vida das pessoas por meio da educação. Nosso grande sonho é ser a maior empresa de acesso à educação do mundo para podermos impactar um número cada vez mais de vidas. Até hoje, conseguimos matricular mais de 650 mil alunos em instituições de ensino e isso foi feito com tecnologia.

E foi com nossa tecnologia e nosso propósito (de uma forma um pouco diferente, claro) que conseguimos impactar a vida desses dois estudantes sobre quem contei neste artigo. E é por isso que acho que vou carregar as palavras do Enrico para sempre comigo:

“minha evolução acompanhou toda a evolução da Quero Educação.”

E é com a emoção provocadas pelas palavras anteriores que digo ao Enrico, ao Diogo, à Maria, ao Davi e a todos os jovens que possam estar lendo este artigo:

a tecnologia, quando aliada à educação, sempre será transformadora.

Voem!

Leia também:

• Ciclo de vida das startups: adaptando a receita de bolo
• Encontre sua tribo: como o time de tecnologia da Quero é estruturado

Tech e educação: como a Quero influenciou alunos do Ensino Médio de São José dos Campos was originally published in Tech at Quero on Medium, where people are continuing the conversation by highlighting and responding to this story.