Flutter — Caso de uso — Como saber e manter o tamanho de um widget?

Oi pessoal, tudo bem?

Nos últimos dias passamos por um desafio aqui na Revelo e notei que é uma pergunta comum para desenvolvedores Flutter. O desafio foi como obter o tamanho ou posição de um widget após sua renderização.

Um widget, por si só, não tem uma posição ou um tamanho pré-determinados. Estes são definidos após sua renderização e ficam “dentro” de um componente chamado RenderBox que é criado na construção da tela. Precisamos, portanto, acessar esse RenderBox após a renderização da tela e, com ele, pegar as dimensões necessárias.

O desafio

Podemos nos deparar com um desafio como esse em diversas situações e, no nosso caso, precisávamos manter o tamanho de um botão quando trocássemos seu estado (para fazer uma animação de carregamento dentro dele).

A animação tinha tamanho diferente do texto que recebemos da API e, como esse texto pode mudar, definir dimensões fixas não seria a melhor estratégia para manter o tamanho do botão.

Para ilustrar melhor:

O que já tínhamos

Nós já tínhamos um widget de botão feito e utilizado em várias partes do app, o ReveloContainedButton. Ele já era um Stateless Widget com um ElevatedButton e embutia espaçamentos, lógica de ativo/inativo, tema de cores e estilo de texto e elevação.

Para melhor entendimento, levem em conta que a classe Dimens é a nossa classe de dimensões padrão, sendo Dimens.base = 16.0.

Como podem ver, esse widget tem suas dimensões definidas pelo tamanho do Text recebido. Também não tínhamos a animação de carregamento (daqui para frente vou chamar de loading, belê?).

A solução inicial

A solução mais simples seria colocar nosso widget de loading, com renderização dependente de um booleano isLoading.

Essa solução, porém, faz o botão mudar suas dimensões para a mesma do widget de loading. Para evitar o pulo, colocamos um AnimatedSize na transição.

É claro que não ficamos muito satisfeitos por não seguirmos o design, então continuamos tentando!

E então como fazer para que o botão mantenha suas dimensões?

A primeira coisa que precisamos fazer é transformar nosso botão em um Stateful Widget. Com isso conseguimos executar funções logo após a renderização e definir variáveis fora do método build do widget.

Depois, ainda é necessário saber qual é o elemento, naquele contexto, que queremos utilizar.

O Flutter faz essa identificação utilizando Keys, então vamos criar uma GlobalKey() para o nosso botão.

Importante: Nosso ElevatedButton tem padding interno e, por isso, seria um pouquinho mais complicado manter seu tamanho com o widget interno diferente se utilizássemos uma Key nele. Por isso a atribuímos ao widget Text().

Até agora só identificamos qual é o elemento que precisamos. Vamos então pegar as dimensões dele?

1. Começamos criando as variáveis que receberão as dimensões de altura e largura do nosso widget Text(): buttonTextHeight e buttonTextWidth.
2. Depois disso, criamos uma função _getButtonTextSize(), que atribui valores a essas variáveis de acordo com o contexto atual. Podemos também criar funções para obter outras informações, como a posição do elemento na tela.

Então, vamos executar essa função somente no initState() do widget! Mas tem um detalhe importante: dependemos da renderização dos widgets estar completa (lembra daquele RenderBox? Ele precisa já estar disponível!).

Também vamos colocar uma condicional para que a função seja executada depois que isso aconteça, utilizando a instância atual do Mixin WidgetsBinding no initState() e o método addPostFrameCallback(), que nos permite executar funções uma vez assim que a fila de renderização acabar.

Ficou assim:

Agora que as variáveis buttonHeight e buttonWidth são atribuídas após a renderização do widget, precisaremos utilizá-las né?

Utilizando as dimensões

Nosso widget de loading não tem parâmetros de dimensões definidos, então criamos um container que tem buttonTextHeight e buttonTextWidth como height e width, respectivamente.

Bônus: no nosso caso, tivemos uma outra pegadinha! Precisamos ajustar o padding desse container de acordo com a buttonTextWidth e o tamanho do ícone para mantê-lo sempre centralizado horizontalmente e com o tamanho ideal.

Foi uma conta simples: subtraímos o tamanho do ícone da largura total e dividimos por 2!

Finalmente, conseguimos o resultado desejado! :)

E aí, por quais desafios vocês tem passado? Estamos sempre disponíveis para ajudar!

Flutter — Caso de uso — Como saber e manter o tamanho de um widget? was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

This was one of the hardest migrations I've ever experienced and I believe these tips will help you in the process.

We took around 3 months to fully migrate our app without stopping the delivery of new features. And here’s how we did it.

A bit of background first

The first version of the Revelo App was built natively in Android with Kotlin, so we took advantage of a great language that already had support to null-safety.

This really helped us during the migration because sometimes we referred to this app to check what was nullable and what wasn't.

However, when we decided to start supporting iOS and had to develop the app all over again in Flutter, the Dart language didn't support null-safety yet. Back then it felt like a huge step back not having this and other great features such as data classes out of the box.

Even though this wasn't available at that time, we found a few threads in the Dart's repository on Github, in which the team was discussing the implementation NNBD (non-nullable by default). After a few months it became available with the release of Dart 2.12.

Here are the steps and a few tips that we used at Revelo that made the process a bit easier.

1. Make sure your dependencies are already migrated

As advised by Dart, it's not recommended to start migrating your app if you have dependencies that are not yet migrated. That's because without it, it's not possible to enable "sound null-safety" and therefore it'd be necessary to test and review each part of the app at least twice.

At this time what we did was create a spreadsheet to keep track of which libs were ready and which weren't.

The "Link" column was useful for referring to issues about the migration to check if any progress was made and we checked them sometimes daily and sometimes weekly.

2. Map all features of your app

This was important to have a sense of what was the size of the migration and also to keep track of which features we've had already migrated. We've also used a spreadsheet for this purpose and we've just used the folder's names.

Our project was structured this way:

companies
 └── list/
      └── data/
      └── domain/
 └── details/
      └── data/
      └── domain/
core
 └── app_banner/
 └── browser/
 └── database/

We weren't too detailed at this point to include every folder, but it was more like a feeling of what's a reasonable size (not too huge and not too little code).

We ended up with something like this, and even though it's not shown in this print, we've also listed the subfolders oftest :

3. Draw a plan on how to tackle it

We knew the company couldn't afford spending several weeks to do this migration and stop the product delivery, so we used the previous map to split it into several weeks. We planned it as a team to check if seemed right for everyone in terms of how much we could deliver each week.

We agreed with the product team to spend around 20% of our time every sprint to tackle these features. After all of it we had a sense of how much time would be needed.

Tip: When you make this plan, make sure to save some time for fixing up the tests and for testing the whole app.

4. The migration of the code itself

I suggest creating a feature branch to receive all code updated and having other branches created after this one so you can review the code chunk by chunk.

4.0 Settle down your expectations

Assume this a long process and you won't see the project compiling for quite some time in this branch. When we first started there were 3K+ errors.

4.1 Update the libs from pubspec.yaml

Firstly set the dart and flutter version on pubspec.yaml and start updating the libs until flutter pub get runs with no error.

Tip: Don't run flutter upgrade on the current version of the Flutter you're already using. Download the newest version and create an alias such as flutter2 . With VSCode it's possible to use different versions of Flutter and Dart.

4.2 Fix the build runner issues

This part is important so you can stop worrying about the issues with generated code which will also show to you as compilation errors.

4.3 Start migrating the code from the leaf classes

Just like we did with the app dependencies, the same logic can be applied for the migration of the proprietary code itself. I recommend starting with the most basic components of your app, such as classes with no dependencies. It will be easier to update the features which depend on these classes later on.

4.4 Open small Pull Requests

I recommend a PR for each folder migrated and I recommend avoiding going into the habit hole. For example, if you change the leafs, avoid changing all occurrences which depend on it, otherwise you might end up changing a lot of different files that you're expected to review later on.

Tip: if you use Firebase, make sure to read the migration guide, which can be very helpful. There are a lot of breaking changes and it can be very time consuming.

4.5 Start fixing the runtime issues

After you fix all compilation errors within the lib folder, you'll be able to run your app. Hope for the best but be prepared for the worst. Certainly there'll be a few (or a lot of) runtime errors that you will need to address but don't focus too much on getting the app perfect at this time. That's because if you have tests then this will be a great time to fix them so you can stop errors easier.

5. Fixing the Tests

Now it’s time to fix the tests and run them to make sure nothing was broken. At Revelo we use Mockito for mocking classes and we struggled with it. Mockito returns null when you use any and a lot of methods stopped accepting nullable values. Because of that, we had to change the way we declare our mocks.

Instead of declaring the interface type we had to declare it as the mock itself, like this:

MyDependency dep = MockMyDependency(); //previous way
MockMyDependency dep = MockMyDependency(); //new way

This works because Mockito overrides the implementation of the methods which don't accept nullable parameters.

Tip: You don’t have to fix all compile errors in the test suite in order to run a single test file. So I recommend fixing each test file starting from the leafs up to the tests with more dependencies and run each one as you progress.

6. Tests before release

If you have a team responsible for quality it will be very helpful, but if you don't, be prepared to spend a considerable amount of time to fully test the app. Make sure to stress different scenarios, mainly the ones you know there might be null values.

One thing I recommend testing is the endpoints which might have null values returned and possibly also mocking their returns with Mockoon + Ngrok. The first is open source and the second one has a free version.

Tips

• As you develop features in Flutter 1, document what fields are nullable. We left a comment after each property with // nullable . It was really helpful. Besides that we could also use the code of the first version of the Android app to check what fields were nullable.
• Keep this branch up-to-date with the branch used for developing the features in Flutter 1 if you won't have time to do the whole migration at once. Cesar Castro suggested this great approach by updating this branch weekly. Since we had just developed it, it was easier to remember what were the decisions.
• Ask for pair review and if possible pair program the core pieces of code you have in your codebase.

A huge thanks and kudos to Cesar Castro and Gabriel Araujo who worked really hard on this migration and made it possible.

How to migrate your existing app from Flutter 1 to Flutter 2 was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na parte 1, foi mostrado um guia prático de experimentos que podemos realizar dentro de um ambiente de app. Agora, na parte 2, vou detalhar como experimentamos e criamos uma plataforma de mentoria gratuita para pessoas na área de tecnologia utilizando metodologia de experimentação, contando um pouco do racional para tomar as decisões e dicas de boas práticas durante este processo de experimentação.

Começando pelo começo

Na Revelo, temos ciclos trimestrais para tirarmos nossas ideias do papel com todo o time e planejarmos como podemos experimentá-las ao longo dos próximos 3 meses. Levando em conta que a Revelo é uma plataforma de HR Tech, durante este processo de brainstorming e análise das ideias, identificamos que uma iniciativa de mentoria com profissionais seniors poderia ter um impacto muito grande para os usuários de nossa plataforma e também para o negócio mas, ao mesmo tempo, tínhamos poucas evidências da desejabilidade e da viabilidade de uma plataforma como essa dentro do app da Revelo.

Então, tendo isso em mente, eu e o Michel, Product manager e minha antiga dupla na equipe do app da Revelo, sabíamos que o maior desafio nesse processo seria levantar e mostrar essas evidências sem envolver ainda o time de tecnologia, já que estavam com o foco em outras tarefas e na construção de outras funcionalidades para o app da Revelo. Então, por onde começar? 🤔

Discovery e Definindo primeiros passos

Depois de um processo de benchmarking para conhecermos um pouco mais sobre os nossos possíveis concorrentes, junto a um exercício de matriz CSD para esclarecer nossas certezas, suposições e dúvidas, identificamos que precisávamos entender como funcionava a rotina dos mentores. Como um primeiro passo, uma entrevista com este público poderia nos ajudar no começo da nossa iniciativa pelo baixo custo em realizá-las e poderia nos mostrar outros caminhos que nos auxiliariam no processo de experimentação.

🧪 1º “Experimento” (pesquisa): Entrevista com o usuário

Para essa entrevista, estabelecemos um roteiro e tivemos alguns pontos claros que surgiram de nossa matriz CSD que queríamos esclarecer:

• Entender como funciona de forma macro a jornada de dar uma mentoria e se os mentores já utilizavam alguma plataforma para auxiliar neste processo.
• Descobrir quais problemas e dores que passam neste processo.
• Qual é a sua motivação em fazer mentorias e o que ganham neste processo
• Identificar se existe algum ponto de risco para o negócio e a iniciativa

Depois de uma conversa muito rica com mais de 20 mentores, tabulamos os resultados e resumimos os principais insights que tiramos das entrevistas.

Como próximos passos, criamos um canvas ( lean canvas, do livro running lean) para entendermos nosso público, a proposta de valor e viabilidade de modo a facilitar conversas com stakeholders e outras pessoas da empresa para receber feedbacks. Porém, durante este processo, identificamos um ponto crucial e um possível risco para o nosso produto: um número relevante de mentores da área de desenvolvimento relataram a falta de interesse de pessoas da área em querer participar de mentorias com outros profissionais, mesmo sendo gratuitas.

Como o processo de entrevista entrega uma força baixa de evidência dos fatos e levando em consideração que grande parte do público da Revelo são de desenvolvedores, precisávamos levantar mais dados para entender se de fato poderia ser um risco para a iniciativa. Com isso, depois de quebrar um pouco a cabeça, conversando com stakeholders e outros designers, precisávamos executar um experimento que nos ajudasse a coletar evidências mais fortes para entender se este risco era real. Com isso, surgiu a ideia do nosso próximo experimento.

🧪 2ª Experimento: Push notification e lista de espera

Notificações sendo mal utilizadas podem gerar frustrações e insatisfação em usuários. Mas se bem utilizadas, podem ser uma boa fonte de dados para avaliar o interesse das pessoas por novas funcionalidades de forma rápida e barata.
Para coletar mais evidências do problema que identificamos anteriormente, fizemos disparos de pushes com a abordagem de um experimento de lista de espera para 2 públicos com um número controlado de usuários:

• Desenvolvedores Seniors: Identificar se este público cadastrado na Revelo manifestava interesse em ser mentores, sem remuneração.
• Desenvolvedores iniciantes: Identificar se esse público manifestava interesse em marcar uma mentoria gratuita com profissionais seniors do mercado.

Fica a dica: Fizemos os mesmos disparos para a carreira de design, pois identificamos em nossa pesquisa que pessoas desta área de atuação já realizavam as mentorias em comunidades e plataformas online. Esse disparo nos ajudou a entender o comportamento deste público em nossa plataforma, além de permitir comparar públicos de áreas distintas.

Nesta push, os usuários eram levados para um Typeform onde registravam o seu interesse, respondendo algumas perguntas e colocando algumas informações de contato, para participar da nossa lista de espera da nova funcionalidade. Com isso, conseguimos entender a desejabilidade dos dois públicos: Pessoas que queriam fazer mentoria e que queriam dar a mentoria.

Registrando os aprendizados deste experimento, identificamos que de fato, o número de pessoas interessadas na área de design era maior, porém, o número de pessoas interessadas na área de desenvolvimento era considerável. Isso nos deu evidências suficientes para continuar a evoluir a iniciativa.

Desenvolvendo e colocando na mão do usuário

Identificando a desejabilidade do nosso público pela funcionalidade, tínhamos uma lista de pessoas interessadas em mentorar e outras desejando receber ajuda. Partimos então para a próxima etapa de validação:

Como podemos conectar essas duas pontas, de forma a comprovar a viabilidade do negócio?

Pegando os aprendizados adquiridos nos processos anteriores, sabíamos que precisávamos fazer um experimento com um caráter mais de validação e menos de descoberta. Com isso, veio a ideia do nosso próximo experimento.

🧪 3ª Experimento: Mágico de Oz e ferramentas low code

Como expliquei na 1ª parte do artigo, o experimento de mágico de oz consiste em entregar uma experiência funcional para o consumidor final de forma manual, reduzindo custos, mas ainda assim, coletando evidências fortes do funcionamento do serviço final. Porém, com a evolução de plataformas low code, é possível criar experiências fidedignas a uma final diminuindo várias etapas manuais no processo.

Existem várias ferramentas no mercado para auxiliar nesta etapa. A que melhor encaixou em nossa realidade foi o webflow, que apesar de ser uma ferramenta para desenvolvimento de websites, queríamos que o experimento fosse flexível, caso precisássemos mostrar o produto final em um app para as pessoas da Revelo e também em um formato desktop para os mentores interessados em ver a iniciativa.

Com a ferramenta definida, fomos para o escopo desta primeira proposta. Pegando os nossos benchmarks e insights da nossa pesquisa, decidimos que o serviço seria gratuito para ambas as partes e precisávamos que nessa primeira versão contemplasse:

Para pessoas que buscam a mentoria:

• Uma lista de mentores
• Uma página com mais detalhes, para a pessoa avaliar se o mentor poderia auxiliar em suas dúvidas
• Conseguir visualizar uma agenda de horários e marcar uma conversa com o mentor via vídeo chamada

Para os mentores:

• Pegar as informações para realizar seu cadastro
• Criar uma agenda de horários disponíveis para conversar
• Registrar o evento em sua agenda com a sala da videochama para a conversa

Identificamos que o calendly já era uma ferramenta muito utilizada para gerar os agendamentos das conversas para os mentores. Aproveitamos então essa tecnologia para facilitar o processo de agendamento e com o typeform, criamos uma primeira versão do nosso signup dos mentores para adicioná-los em nossa lista.

Depois de 4 dias montando a interface e coletando as informações dos mentores interessados, tínhamos a nossa primeira versão do produto funcionando. Gostaria de deixar um agradecimento para todas as pessoas da Revelo e para todos os mentores que participaram da lista para ajudar a validar a nossa ideia ❤️

Fica a dica: Nesta etapa inicial de validação, uma dica muito valiosa é colocar uma área de feedback no final da página com um link para um forms para coletar observações e insights dos usuários que estão utilizando. Isso pode acelerar no processo para entender ainda mais se a proposta está funcionando.

Com a nossa página construída, o próximo passo foi estabelecer um tracking mínimo para entender se o critério de sucesso que estabelecemos no início do experimento foi atingido. Com a ajuda do time de BI e Growth da Revelo, usamos a ferramenta do google analytics para nos auxiliar nesta etapa.

Agora a parte que mais estávamos esperando: testar e colocar na mão do usuário. Pegamos a nossa lista de pessoas que estavam interessadas em participar da iniciativa, disparamos uma push pelo app com um link para a nossa página no webflow. Depois com uma pequena ajuda de tech, colocamos um card (estrutura que comentei no 1ª parte do artigo) dentro do nosso app com um link para a página via back-end, tirando a necessidade lançar uma nova atualização na loja.

Fica a dica: caso seu app tenha um volume de acesso muito grande, deixe essa área disponível para um número controlado de pessoas, evitando assim possíveis problemas que podem ocorrer pelas limitações das ferramenta lowcode.

Resultados e observações

Depois de alguns dias rodando a página, conseguimos ter dados suficientes para entender e avaliar o nosso critério de sucesso. E os resultados superaram as nossas expectativas: tivemos o dobro de conversas do que era esperado, sendo que dessas conversas, cerca de 60% foram marcadas por pessoas da área de desenvolvimento, mitigando o risco que levantamos no início da pesquisa. Mas o que mais impactou a gente foi o relato de duas pessoas que participaram no processo:

O Rodolfo que tem o sonho de virar desenvolvedor mas sabia pouco sobre a área e ,em sua cidade, é muito difícil ter o contato com algum profissional que atua no mercado. Pela mentoria, Rodolfo pode conhecer pela primeira vez uma pessoa que atua na área, conseguiu tirar suas dúvidas e conheceu ainda mais sobre a profissão que tanto sonha em atuar.

E o Lauro que recebeu dicas do que fazer em entrevistas e foi contratado em nossa plataforma com a ajuda dessas dicas!

Com os resultados, conseguimos validar nossa aposta e junto ao time de tecnologia, vamos escalar a iniciativa para ajudar e impactar ainda mais pessoas no processo.

…

Gostaria de deixar um agradecimento especial ao Michel, sendo um dupla e tanto durante esta jornada, ao Paulo e Will, que nos guiou com conselhos em todas as etapas do processo. E por último, mas não menos importante, a todos os mentores que participaram nas pesquisas e em nossos experimentos, sempre muito dispostos a ajudar outras pessoas, não esperando nada em troca e visando na evolução do próximo.

…

Referências

Michel Nassif, tech revelo. Nuggets de Experimentos: como tornar acessível os resultados de seu discovery

Will Sertório, UX Collective. Batendo o bumbo: boas práticas para empoderar times de produto e design

Douglas Iacovelli, tech revelo. Como lançamos o app iOS da Revelo em 1 mês

Alex Osterwalder, David J. Bland. Testing Bussiness Ideas: Este é um guia de campo de experimentação rápida

Tomer Sharon. Validating Product Ideas

Ash Maurya, Running Lean: Iterate from Plan A to a Plan That Works

Experimentação em app: como testar de forma ágil sem precisar lançar uma nova versão na loja … was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na 1ª parte apresentarei um manual prático de experimentos e como realizá-los em seu app. Já na 2ª parte, detalharei como validamos a ideia de uma plataforma de mentoria gratuita em nosso app utilizando essa metodologia.

Antes, um pouco de contexto

O app da Revelo foi lançado em março de 2020 e teve como principal aposta trazer uma nova forma de interação dos usuários com a plataforma, além da versão web já previamente consolidada. Após alguns meses, começamos a notar uma melhoria no engajamento dos usuários com o produto, que resultou em taxas de respostas 4x mais rápidas se comparado com os candidatos que utilizavam o produto na web.

Mas este resultado gera um custo. O desenvolvimento de aplicativos tende a ter um tempo de implementação mais elevado se comparado com outras plataformas, devido a:

• Tecnologia — Além das dificuldades técnicas envolvidas no back-end e na construção da interface e deeplinks, o custo da mão de obra envolvida no desenvolvimento é mais elevado considerando que equipes distintas são envolvidas na construção de apps para IOS e Android. É possível ganhar velocidade utilizando tecnologias híbridas, como Douglas mostrou muito bem em seu artigo sobre como tomamos a decisão de migrar o app da Revelo para o flutter. Mas ainda assim, a velocidade de desenvolvimento de versões mobile e web ainda tem suas diferenças
• Ciclo de atualizações — Todo app tem seu ciclo de atualizações nas lojas (PlayStore ou AppStore) e passam por um processo de validação antes de irem para o ar. Dentro deste processo, temos a variável da loja aceitar a sua versão e esperar que os usuários a baixem para ter acesso à nova funcionalidade. Isso pode levar dias até a entrega do serviço/produto na mão do usuário, o que deixa todo o processo de experimentação e validação de novas ideias mais demorado.

Na Revelo, temos uma cultura de ‘discovery’ de ter ao menos um aprendizado na semana, seja por experimentos de funcionalidades ou por pesquisas (se quiserem saber mais, o Will, Product Design Manager na Revelo fez um ótimo artigo sobre). Então, nos deparamos com um desafio:

Como podemos experimentar uma nova funcionalidade de forma mais ágil dentro do contexto de desenvolvimento de app?

Mas calma… o que é um experimento?

“Os experimentos são o meio de reduzir o risco e a incerteza de sua ideia de negócio” — David J. Bland & Alex Osterwalder

Dentro da Revelo, temos a cultura de realizar experimentos com objetivo de reduzir as incertezas e riscos em nossos projetos. Em nosso Playbook, detalhamos o que são os experimentos e como fazemos para registrá-los afim de defender as nossas ideias com o time de tecnologia e stakeholders.

Priorizando seus experimentos

Para conseguir escolher o melhor experimento para o seu momento, existem fatores que ajudam a nos nortear nesta jornada. O primeiro é entender o momento em que você está em seu projeto:

Descoberta (Desejabilidade) — esta etapa é considerada a inicial no processo, quando você ainda tem dúvidas sobre a validade de suas hipóteses. Nela, experimentos com evidências fracas são o suficiente para entender se você está indo no caminho certo.

Validação (Viabilidade) — esta é uma etapa mais avançada, que requer experimentos com um grau de complexidade maior já que exigem evidências mais fortes para reconhecer se a direção que você tomou no início do processo foi validada ou refutada.

Entendendo o momento que está em seu projeto, você já consegue visualizar qual experimento faz mais sentido para conseguir coletar evidência/dados necessários, seguir com seus próximos passos e finalmente validar sua ideia. Existem alguns critérios que também o auxiliarão na escolha do melhor experimento para a etapa da sua jornada de experimentação:

💪 Força da evidência — Evidências são aprendizados que te ajudam a dar suporte ou a refutar suas ideias/hipóteses durante sua jornada de experimentação. Quanto menos evidências você tiver de suas ideias, menos custo e tempo você deve perder.

💰 Custo — Neste critério você deve levar em consideração quantas pessoas vão estar envolvidas no processo e quanto tempo você ainda tem para conseguir escolher o experimento certo para mostrar e convencer os stakeholders sobre o andamento do projeto.

⏱ Tempo — Neste critério deve-se levar em consideração dois pontos: o tempo para você construir o experimento e o tempo para você conseguir coletar os resultados. Tente aproveitá-lo da melhor forma para a coleta o máximo de evidências em seu projeto.

Boas práticas:

• Comece da forma mais barata e rápida. Quanto menos você sabe, escolher experimentos rápidos ajudam a entender se está em uma direção certa.
• Aumente a força de suas evidências com múltiplos experimentos.Nunca faça decisões importantes com base em um experimento ou em uma evidência fraca.
• Tente sempre priorizar o experimento que fornecerá uma evidência forte. Sempre leve em consideração o seu contexto e o tempo que você tem para tomar suas decisões.
• Tente reduzir o máximo de incertezas antes de começar a construir algo grande. Às vezes achamos que precisamos construir algo para testar uma ideia. Na parte 2 deste artigo, mostrarei como experimentamos uma ideia sem ainda ter o produto funcionando.

Tipos de experimentos em ambientes de app

Agora vou mostrar como e quais experimentos você pode executar em sua jornada para testar suas ideias. Leve em consideração os critérios acima para escolher o melhor experimento para o seu momento. Logo a seguir, você encontrará as ferramentas que utilizamos e quais experimentos podemos executar com elas.

Um ponto importante é que essas ferramentas tem o objetivo de minimizar o esforço do time de tecnologia, sem precisar que você tenha que lançar uma nova versão na loja para conseguir experimentar sua ideia. Para isso, o back-end em app acaba sendo um grande aliado no processo de experimentação ágil, fazendo com que você consiga executar seus experimentos sem precisar entrar em ciclos de atualização.

Push notifications

Notificação é uma das ferramentas mais democráticas para conseguir suas primeiras evidências em um curto período de tempo. Ela possui um custo inicial alto porque primeiramente você precisará construir ou contratar um serviço de disparo de notificações para deixar o processo mais ágil e sem precisar envolver toda vez o time de tecnologia no processo. Mas depois de construído, você consegue realizar experimentos que te darão resultados no mesmo dia em que executá-los. Um boa prática é sempre utilizar as notificações em grupos controlados de usuário para minimizar possíveis riscos para o seu produto

Quais experimentos posso executar com ela:

Fake door (porta falsa)
💪 💪 | 💰 | ⏱ | Descoberta (Desejabilidade)

O que é — Descreva a sua proposta de valor no texto da notificação e quando o usuário tocá-la, você comunicará que a funcionalidade ainda não está pronta e que ainda está em construção. Por isso o nome porta falsa.

Como fazer — Uma boa forma de você executá-lo é criando um link da notificação para um formulário, como o Typeform ou Google forms. Assim você pode dar mais contexto da sua ideia e coletar pessoas que estão interessadas em ajudar, criando um lead rápido para realizar pesquisas futuras. Quando a pessoa acessar o seu formulário, tente escrever um texto que não a frustre, já que a experiência neste experimento não é a das melhores. É de extrema importância coletar o número de clicks na notificação para conseguir avaliar o interesse do seu público por aquela funcionalidade

Lista de espera
💪 💪 | 💰 | ⏱ | Descoberta (Desejabilidade)

O que é — Este experimento é bem parecido com o do Fakedoor, mas ele tem o objetivo de coletar pessoas interessadas em testar seu produto no futuro. Este tipo de pessoa tende a estar disposta a testar sua ideia, mesmo ela não sendo 100% completa. São pessoas muito valiosas para você conseguir experimentar e pegar feedbacks de suas ideias mais tarde

Como fazer — Você pode utilizar a mesma estratégia como foi comentada no experimento de fakedoor. Mas, quando a pessoa acessar seu formulário, mostre uma mensagem que o seu produto ainda está em fase de teste e que para participar, ela deve preencher o formulário para entrar em uma lista de espera. Sempre lembre de medir os acessos para validar o seu critério de sucesso do experimento.

Teste A/B
💪 💪 | 💰 | ⏱ ⏱ | Descoberta (Desejabilidade)

O que é — Testes A/B são testes que realizam comparações entre 2 grupos de variáveis com o objetivo de definir qual delas gera a melhor resposta para a solução.

Como fazer — Neste caso, um exemplo mais prático utilizando notificações seria identificar qual de suas ideias têm um maior interesse por parte do seu público. Basta disparar duas notificações com duas propostas de valores diferentes para dois grupos separados, assim, quando você analisar a taxa de abertura das duas, você consegue identificar qual delas teve uma significância estatística maior de interesse do seu público. Existem calculadoras que ajudam a fazer esta conta, como está aqui. Este é um exemplo de teste A/B, mas você pode criar as suas próprias alternativas para avaliar a melhor resposta para os seus problemas.

Estruturas internas dentro do app

Criar estruturas internas dentro do seu app também pode ajudar a entender o engajamento e a desejabilidade do seu público pelas suas funcionalidades. Os tipos de experimentos que podem ser realizados são iguais aos realizados pela notificação, mas, com a diferença que você vai estar avaliando o uso da funcionalidade conforme a pessoa estiver utilizando seu app, sem ser um aviso instantâneo como é a notificação.

Criar estas estruturas acabam tendo um custo maior de implementação, já que você e seu time vão ter que criá-las para conseguir alterar e mandar informações via back-end para não precisar lançar uma nova versão na loja para fazer seus experimentos. Existem alguns serviços, como o appcues, que auxiliam nisso, mas ainda está em versão beta para ambientes de aplicativos. Vou citar dois exemplos de estrutura que você pode construir com seu time:

Pop-up Banner — Neste exemplo, você pode acionar um banner quando um usuário abrir seu app ou ao acessar uma sessão de seu aplicativo. É de extrema importância o banner ter um padrão de informação e que você crie uma estrutura junto ao seu time de tecnologia para fazer o seu envio para o usuário final via back-end quando necessário. Assim, você tira a variável de esperar a autorização da loja para subir um novo banner.

Card — O card seria uma abordagem bem parecida com banner, porém, ele constitui de um componente que se encontra dentro de uma sessão em seu app. Ele deve ter a mesma facilidade de acrescentar e tirar informações via backend, como comentado anteriormente.

Ferramentas low-code

Hoje, está cada vez mais fácil conseguir experimentar ideias de produto de forma fiel a uma proposta final sem prejudicar a experiência final do usuário. As ferramentas low-code podem auxiliar você neste processo, possibilitando construir experimentos que necessitam de um grau de validação e de amostragem mais real com uma proposta final.

Existem várias ferramentas low-code para ambientes de app, como Adalo, Bubble, Webflow e elas permitem você criar estes experimentos em uma página web de forma rápida e sem código, sendo fácil linkar com o seu produto no app por meio de uma webview.

Na segunda parte do artigo, mostro um pouco como construímos um serviço funcional utilizando ferramentas lowcode.

Quais experimentos posso executar com ela:

Landing page
💪 💪 | 💰 💰 | ⏱ ⏱ | Descoberta (Desejabilidade) e Validação (Viabilidade)

O que é — A landing page é uma simples página na web que mostra de forma clara a proposta de valor do produto/serviço vendido ali com um ação clara do que o usuário precisa fazer.

Como fazer — Escolha um melhor template de design para a sua estrutura e sempre lembre de otimizar a experiência para ambientes mobile. Uma dica de ouro é utilizar outros serviços, como google analytics, para entender o comportamento do usuário na página e tenha em mente 4 pontos importantes que a sua estrutura deve ter:

• Uma proposta de valor clara com a ideia de testar sua hipótese e já criar uma conexão com o usuário sobre o que está falado naquela página
• Fale nessa página sobre as principais dores de seu usuário para que ele crie uma conexão com a sua proposta de valor.
• Mostre qual a solução que você tem para essas dores de forma clara
• Sempre lembre do seu CTA (Call to action) e qual o objetivo que você quer extrair quando o usuário tocar neste botão, como pegar algumas informações de contato para utilizá-las no futuro.

Mágico de Oz
💪 💪 💪 | 💰 💰 | ⏱ ⏱ ⏱ | Descoberta (Desejabilidade) e Validação (Viabilidade)

O que é — O mágico de oz consiste em você entregar uma experiência mínima do seu produto de forma a reduzir ao máximo o uso de tecnologia e fazê-lo de forma manual, mas sem que o consumidor saiba que tem uma pessoa fazendo este serviço por trás.

Como fazer — Com as ferramentas low-code, você pode construir uma experiência mínima em uma webpage e linkar com outras tecnologias para facilitar e diminuir o impacto manual no processo. Uma ferramenta que pode ajudar bastante neste processo é o Zapier, que consegue integrar planilhas no google sheets com as estruturas nas ferramentas low-code, como o webflow, deixando todo o processo mais fácil de se gerenciar.
No próximo artigo, mostrarei como executei um experimento utilizando Mágico de Oz para validarmos nossa plataforma de mentoria, junto a um guia de boas práticas durante o seu processo de execução.

Concierge
💪 💪 💪 | 💰 💰 💰 | ⏱ ⏱ ⏱ | Descoberta (Desejabilidade) e Validação (Viabilidade)

O que é — O concierge parte do mesmo princípio do mágico de oz, porém, a ideia é que a pessoa que está envolvida no processo manual fica clara e visível para o consumidor final

Como fazer — Você pode utilizar a mesma lógica de webpages comentadas acima para conseguir ter um primeiro contato com seu usuário. Tente executar outros experimentos antes de começar com esse. Tente coletar o contato das pessoas que querem resolver o problema com o seu produto/serviço e converse com elas por email ou whatsapp vendendo uma proposta final para ajudá-las em suas dores. Lembre-se sempre que concierge não é uma solução escalável e sim, uma forma de apenas testar sua ideia na prática. E lembre-se também desses 3 passos para auxiliar no processo:

• Prepare seu plano, tente utilizar planilhas para registrar os seus passos e ordens que você precisa executar com cada pessoa interessada.
• Execute a ordem e registre nessa planilha quanto tempo demorou para realizá-la e tente pegar o feedback dos usuários que você entrou em contato com um forms.
• Analise os resultados junto aos feedbacks que você coletou no forms para melhorar a próxima vez que você entrar em contato com uma nova pessoa.

Observações finais

Experimentos ao mesmo tempo que podem ser interessantes, se não documentados afim de entender o objetivo final que se quer atingir com eles, podem virar uma bola de neve interminável. Mantenha o registro de seus experimentos e sempre analise com cautela os resultados que atingiu antes de partir para o próximo (neste artigo o Michel, Product Manager na Revelo, explica bem como fazemos isso na Revelo).

Tente sempre se guiar pelos dados e aprendizados que você extraiu e nunca se apaixone pela sua ideia/hipótese, e sim, pelo problema que você quer resolver. Lembre-se: experimentos servem para validar ou invalidar sua hipótese.

E não se limite em realizar apenas os experimentos que mostrei neste artigo. Vou deixar aqui em baixo as referências que utilizei para a construção deste guia e lá você poderá encontrar vários outros tipos de experimentos. As observações acima foram tiradas dessas referências e da minha vivência no mundo de produto. Não tome elas como verdade absoluta, busque suas referências, converse com outros profissionais para ganhar mais contexto e para evoluir ainda mais rápido com seus experimentos.

Agora, na 2ª parte, mostrarei na prática esta metodologia de experimentação e como utilizamos ela para validar uma ideia de plataforma de mentoria gratuita dentro do app da Revelo. Te espero lá 👋

…

Mas e ai, como você testa e experimenta suas ídeias no seu dia-a-dia em aplicativos? Compartilhe aqui embaixo sua experiência com a gente! :)

…

Referências

Michel Nassif, tech revelo. Nuggets de Experimentos: como tornar acessível os resultados de seu discovery

Will Sertório, UX Collective. Batendo o bumbo: boas práticas para empoderar times de produto e design

Douglas Iacovelli, tech revelo. Como lançamos o app iOS da Revelo em 1 mês

Alex Osterwalder, David J. Bland. Testing Bussiness Ideas: Este é um guia de campo de experimentação rápida

Tomer Sharon. Validating Product Ideas

Ash Maurya, Running Lean: Iterate from Plan A to a Plan That Works

Experimentação em app: como testar sem precisar lançar uma nova versão na loja - Parte 1 was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Um pouco de contexto

No começo de 2021, o time de design da Revelo começou a crescer. Até então, cada um era responsável pelo próprio recrutamento para entrevistas, testes de usabilidade, validações e afins.

O time sentia que poderíamos melhorar esse processo. Nesse texto, vamos contar um pouco sobre o que fizemos.

Eu comecei a acompanhar quantas entrevistas o time de design e produto faziam por trimestre. No Q4 de 2020, foram 23 entrevistas. Éramos um time de cinco pessoas na época,então decidimos melhorar esses números.

Quebrando a cuca juntos

A primeira coisa que fizemos foi colocar todo mundo na mesma página.

Rodamos um workshop com o time de design e produto, que seguiu a seguinte estrutura:

1. Levantamento

Em post-its, cada pessoa colocou quais são os problemas que temos com recrutamento hoje. Quais são os pontos que você perde mais tempo e energia?

😺 Jump of the cat — Em atividades assim, prefiro limitar o número de post-its de cada um. Três é um bom número. Assim as pessoas priorizam os problemas que querem levar, fica mais fácil de agrupar e não vira um pity party (o famoso chororô desnecessário).

2. Agrupamento

Peça aos participantes irem agrupando os problemas parecidos. A pessoa que está puxando o workshop vai orientando, e ajudando a dar um nome a cada grupo de problemas.

3. Priorização

É pouco prático tentar resolver todos os problemas. Então fizemos um processo onde cada um tinha três votos, e podia votar nos grupos de problemas que achava mais importante de ser resolvido primeiro.

4. Criando um ponto de vista

Até aí, beleza. Antes de pular na solução, o próximo passo foi criar um “how might we…” (“como podemos”, em português). A partir dos problemas priorizados, a ideia aqui era pensarmos em qual pergunta exatamente queremos responder.

Comecei dando uma sugestão, e as pessoas foram construindo em cima dela. Isso é super importante. Em exercícios criativos, começar com uma “página em branco” pode intimidar e travar as pessoas.

Escrevemos umas 4 ou 5 versões diferentes, até sentir que chegamos na frase que melhor representava o problema e seguimos.

A frase que chegamos foi:

“Como podemos criar um processo de escuta ativa, para conseguir coletar mais feedbacks do mercado?”

😺 Jump of the cat — Pra mim, exercícios de escrever em conjunto são um dos mais difíceis de facilitar. Esse, se você não souber moderar e não dominar o problema, pode demorar demais. Garanta que todos dêem sua opinião, mas não abra demais. Se alguém der uma sugestão muito longe, é seu papel tesourar educadamente e trazer as pessoas pro foco certo. Quando sentir que a frase certa chegou, tente construir consenso e pular pra próxima atividade. Nem tudo precisa de votação.

😺Jump of the cat 2 — Muitas pessoas que fazem design tem medo de soarem “agressivas” e usam votação para tudo. Pense bem em qual o momento certo de ser mais democrático, e onde temos que ter pulso mais firme. Design por comitê não funciona.

5. Dando ideias

Com a pergunta definida, começamos a pensar em ideias para respondê-la. Sem prototipar, apenas escrevendo as ideias em post-it mesmo. Também limitamos o número de ideias por pessoa, pra que cada um faça seu próprio filtro e não tenhamos que todos ficar discutindo ideias “half-baked” em grupo. Isso economiza bastante tempo.

6. Pós-workshop

Depois do workshop, comecei a agrupar e dar um contorno para as ideias geradas. Depois de algumas iterações e discussões, chegamos na ideia final: criar um “user’s day”. Um dia onde todos do time entrevistariam usuários.

Isso facilitaria o recrutamento, e daria mais cadência para as conversas que temos com o mercado.

Pra fazer essa ideia funcionar, precisávamos de duas coisas: uma lista de pessoas interessadas em conversar (usuárias e não-usuárias), e um processo para recrutá-las semanalmente.

Setupando

Landing Page

Construímos uma landing page pra explicar como o programa funcionaria, respondendo uma série de perguntas que as pessoas poderiam ter.

A landing é boa até como exercício de alinhamento interno. As pessoas batem o olho e conseguem conversar melhor se é aquilo mesmo que elas tinham imaginado.

Você pode conferir a LP aqui. A estrutura dela é basicamente a seguinte.

1. Proposta de valor
   Enfatizamos o benefício-chave: nos ajudar a construir o futuro do mercado de recrutamento e seleção.
2. Vendendo o peixe
   Sensibilizamos a pessoa, explicando que a maioria dos apps que ela gosta de usar foi construído com muitos testers.
3. Como funciona
   Um passo-a-passo, pra pessoa ter visibilidade do que a espera.
4. FAQ
   Colocamos perguntas frequentes, que podem remover impedimentos na hora da pessoa se cadastrar.

No formulário, colocamos algumas perguntas que nos ajudariam a filtrar e agrupar as pessoas, facilitando o recrutamento depois.

Começamos a gerar tráfego para a landing compartilhando ela organicamente no LinkedIn. Em poucos dias, tínhamos quase cem pessoas cadastradas.

Ferramentas

1. Webflow — construir a página
2. Typeform — coletar os dados
3. Google Spreadsheets — armazenar os dados
4. Calendly — gerar um link automático de calendário
5. WhatsApp — recrutar as pessoas

Users Day

Apesar do nome rocambólico, é apenas um dia onde limpamos a agenda pra falar com quem a gente conseguisse. Escolhemos quinta-feira.

As pessoas que preenchiam o Typeform caiam automaticamente em uma planilha. Até aí, beleza. Na segunda de manhã, seguimos o seguinte passo-a-passo pra coisa funcionar.

Atualizar e classificar novos participantes

Pegar a turma nova que entrou, colocar em uma nova aba da planilha e clusterizar em cima dos nossos casos de uso (ex: quer trocar de emprego, quer se qualificar, etc).

Escolher público que vamos abordar

Isso aqui a gente mudou bastante. Mas no geral é definir que tipo de usuário você vai querer entrevistar essa semana. Pode ser todos os clusters, clusters específicos, and so on.

Verificar link do Calendly

Antes de sair recrutando, é importante checar se o link do Calendly está funcionando, e limitado apenas aos horários na próxima quinta-feira.

Verificando template da mensagem

Criamos uma mensagem padrão de recrutamento, onde colocamos o nome da pessoa para ficar mais pessoal e parecer menos um robô falando.

Nossa mensagem é assim:

Oi <nome> ! Aqui é o <seu nome>, sou <cargo> na Revelo. Muito prazer! Recentemente você se cadastrou pra ser beta tester.

Temos uma pesquisa que tem tudo a ver com o seu perfil. Ela acontece nessa quinta-feira, no Google Meet. No link abaixo tem algumas opções de horário, é só escolher o que funcionar melhor.

Se não puder esta quinta, sem problema! Te convidaremos para as próximas rodadas.

<Link do calendly>

Mandando no zap

Criamos uma fórmula no Google Spreadsheet para facilitar essa etapa. Ela é assim:

=CONCATENATE(“https://api.whatsapp.com/send?phone=“;CÉLULA COM O TELEFONE DA PESSOA;”&text;CÉLULA COM A MENSAGEM)

Instalar o WhatsApp Desktop ajuda bastante nesse processo. Basta clicar no link dinâmico da planilha que o WhatsApp já criar uma janela de conversa com a pessoa. Aí é só revisar a mensagem e um abraço.

Colocando a turma nos convites

Com os convites chegando, alocamos o time de design para entrevistar essas pessoas. Colocamos no máximo duas pessoas por conversa (uma observadora, uma entrevistadora). Mais do que isso, a pessoa do outro lado pode se sentir em um interrogatório. Take it easy my brother Charles.

Resultados e próximos passos

Na primeira semana, entramos em contato via WhatsApp com 12 pessoas, e entrevistar 4 delas. Nas semanas seguintes, fomos aumentando esse número aos poucos, e fazendo ajustes no processo.

No final do quarter, o time havia entrevistado 80 pessoas, um número 3x maior que o quarter anterior.

Ainda estamos melhorando esse processo. Com a ajuda do time de growth, temos e-mails automáticos convidando essas pessoas em momentos-chave da experiência. Futuramente, queremos levar isso para o produto, oferecendo um opt-in para a pessoa se cadastrar de forma mais fácil.

Ah, e se você quiser ser beta tester, chega mais!

Criando um grupo de beta testers was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na última semana passei por uma situação de bastante aprendizado na @Revelo e gostaria de compartilhar um pouco mais dela com vocês, minha rede. A intenção aqui é, se der tudo certo, dar uma amostra para pessoas que como eu estão em uma fase de transição de carreira sobre como é pensar em melhorias de código e como foi a nossa discussão durante esse processo.

O Problema

Na Revelo, como parte do nosso design system, utilizamos Badges (crachás, insígnias ou distintivos) para ressaltar informações relevantes no nosso app. Portanto temos, como vocês já devem imaginar, vários estilos diferentes de Badges em várias partes do app.

Focamos sempre em entregas de altíssima qualidade e queremos evitar erros de design que possam ser inseridos acidentalmente por nós mesmos no momento do desenvolvimento de novas funcionalidades ou até de refatoração de funcionalidades mais antigas.

Por conta disso, ter uma API interna que nos ajude a evitar tais erros, padronizar o código e facilitar a inserção de novos modelos de design é super importante, certo? Certo! Olhem como estava a nossa Badge antes:

Na nossa visão, esse modelo de Badge deixaria qualquer desenvolvedor com uma escolha muito aberta em relação a parâmetros importantes como a backgroundColor (cor de fundo da Badge) e a textColor (cor do texto). Além disso, não conseguíamos configurar as bordas caso fosse necessário.

O mais legal de tudo? Pude pegar esse desafio para mim!

Solução 1

Meu ponto de partida foi ir mais a fundo no código do Flutter, entender mais sobre como são feitos os Widgets do próprio framework. Minha ideia era que eu já tinha visto algo semelhante no código, então precisaria entender melhor como as coisas são feitas “por trás dos panos” para poder propor uma solução.

Decidi investigar os botões e acabei chegando no FlatButton, que estende do MaterialButton (isso já me deu uma pequena luz). Acontece que o FlatButton tem exatamente a primeira solução que pensei: um construtor FlatButton.icon que faz o widget principal aceitar um ícone dentro dele, mesmo que o FlatButton não tenha esse paramêtro no seu construtor.

Long story short: O FlatButton.icon é uma classe com construtor própio, que herda do FlatButton e utiliza um Mixin do MaterialButton para poder utilizar sua própria instância do ButtonTheme.

Essa parte ficou bem complicada para mim e acabei não entendendo muito bem o uso do Mixin antes de utilizá-lo, mas mesmo assim utilizei e criei classes novas para a nossa Badge como ReveloBagde.transparent, ReveloBadge.red, etc., utilizando essa estratégia.

Funcionou!

Mas o nosso código ficou gigante e complexo, por isso fica aqui o primeiro aprendizado: é muito importante entender o que o código faz exatamente antes de adaptá-lo para uma solução própria.

Segundo aprendizado: git commit é muito bom, use sempre! Queria trazer o código dessa versão aqui para vocês mas não commitei e perdi :(

Para pelo menos ilustrar um pouco, deixo o link do Github do Flutter com o código fonte do FlatButton: Código fonte FlatButton Widget.

Solução 2

Trouxe o resultado do meu estudo e implementação para o Cesar Castro e o Douglas Iacovelli, meus mentores e companheiros de squad na Revelo, para saber o que achavam da minha solução.

Ela funcionava, de fato, mas não resolvia um dos nossos principais focos: ela nos ajudava em relação a evitar erros na inserção dos parâmetros pois as classes estavam “travadas” mas ela era de difícil manutenção/atualização. Em cada mudança de design, precisaríamos alterar uma classe inteira para poder adaptar a Badge. E se precisássemos de uma Badge com borda E fundo colorido? E se a Badge transparente se tornasse uma com cor de fundo diferente?

Daí vem uma das maravilhas de poder contar com pessoas incríveis e bastante experientes como o Cesar e o Douglas. Com base nessa solução complexa, chegamos a uma que se tornou muito mais simples e, na minha humilde opinião, bem bonita!

Aqui fica o terceiro aprendizado: esteja sempre aberto a discutir o seu código, aceitar propostas de melhoria e abraçar todo o aprendizado que vem com isso.

Decidimos então criar uma classe de estilos com construtor privado (não pode ser declarada com construtor fora dela mesma) e utilizá-la com factories para termos todas as opções de estilo das Badges travadas em um só lugar. Isso ajuda muito na manutenção do código, sério.

Para ilustrar, aqui a classe de estilos que criamos:

Como vocês podem ver, cada estilo tem as suas cores de fundo e texto já definidas e quando necessário conseguimos definir uma borda também, vide o estilo .outlined.

Mas só isso também não resolveria o nosso problema, pois ainda teríamos a inserção de um estilo na declaração da Badge, então fomos mais a fundo e utilizamos a mesma estratégia de Factories para termos construtores específicos para cada um deles, como ReveloBadge.blue e ReveloBadge.outlined.

Agora sim, temos um widget que se tornou uma API interna, pode ser utilizado em todo o código com menos risco de fugir do Design System e e maior velocidade de desenvolvimento.

Para finalizarmos, aqui está o código da nossa classe ReveloBadge refatorada e pronta para uso:

Obrigado Cesar e Douglas pela oportunidade ❤

TL;DR

Novos devs: não tenham medo de ir fundo no código do framework que estão aprendendo e entender o que eles está fazendo de verdade. Ouçam seus companheiros de equipe que tem mais experiência e não tenham muito apego em relação ao código que fizerem, valorizem cada oportunidade dessas como um intenso aprendizado e internalizem o modo de pensar deles. Isso é super importante na minha sincera opinião e acredito que vá ajudá-los a se desenvolverem muito mais rapidamente. E usem git commit sem muito dó.

Devs experientes: dêem desafios e oportunidades como essa para os juniores dos seus times, estejam abertos a ouvir e discutir as soluções propostas e os estimulem a procurar sempre novas e melhores soluções sozinhos, mas sempre os apoiem quando necessário — isso vai ajudá-los a crescer muito mais rápido!

Obrigado pessoal, até a próxima :)

[Flutter] Melhoramos uma API interna: o processo e aprendizados na visão de um dev junior was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Na Revelo, nossas métricas e objetivos tem um ciclo de três meses (quarter). No início do quarter, cada área é responsável por fazer um kickoff para alinhar as expectativas de entrega entre gestores e colaboradores, além de (re)conectar as pessoas desses times com a visão estratégica da empresa.

O time de Produto da Revelo é multidisciplinar, com profissionais de Tecnologia (engenheiros de software e analistas de dados), Produto (product managers e designers) e Growth (growth hackers). Portanto, todas essas pessoas estão inclusas no nosso Kickoff de TPG.

Deixo abaixo um guia de passos que consideramos para organizar o kickoff atualmente na Revelo.

Escolha da data e local do Kickoff

Na Revelo, a data escolhida para fazer o Kickoff de TPG é sempre a primeira sexta-feira (para evitar quebras no fluxo de entregas semanal) dos meses de Janeiro, Abril, Julho e Outubro. Nesse dia, é recomendado que nenhuma outra reunião seja agendada com integrantes do time, todos devem estão inteiramente focados no conteúdo do Kickoff.

No cenário anterior à pandemia da COVID19, o Kickoff era realizado presencialmente em um ambiente externo à empresa, justamente para causar o sentimento de reduzir o foco nas ações que fazemos o dia-à-dia e olhar para a empresa do lado de fora.

Desde o período de quarentena até o momento atual em que a Revelo se tornou Remote First, os eventos de Kickoff vem sendo feitos online através da plataforma de reunião utilizada na empresa.

Organize a agenda do evento

A agenda do Kickoff tem normalmente início às 9h30 e no período de 15 min fazemos a abertura do evento, apresentando a agenda do dia para que todos se organizem. O evento normalmente conta com blocos de Estratégia da empresa, Retrospectiva, Métricas e Apostas do próximo quarter e Team Building.

Estratégia da empresa: Nessa apresentação é importante escutar dos fundadores(as) da empresa ou diretores(as), qual será a estratégia da empresa para o próximo quarter, isto é: qual será o objetivo principal da empresa? Para que público alvo estamos olhando? Quais são nossos principais concorrentes? Porque estamos guiando a empresa para esse objetivo?

Retrospectiva: Tão importante quanto sabermos os próximos passos, é olhar para trás e ver o quanto entregamos de valor no trimestre que passou. Nesse momento, cada Squad apresenta suas principais entregas, quais resultados obtiveram, o que deu certo e também os aprendizados.

Métricas e apostas do próximo quarter: A cada quarter as métricas mudam e com isso às vezes se faz necessário rearranjar os times. Nesse bloco os integrantes que irão compor os Squads são apresentados juntamente com as métricas de Produto e apostas que serão feitas ao longo do trimestre.

Team Building: o termo pode ser traduzido como formação ou consolidação de equipe. Esse momento é separado para promover uma série de atividades para criar e fortalecer as relações entre pessoas participantes do Kickoff que não interagem normalmente no dia-à-dia.
Para isso, os membros do kickoff são agrupados em times entre 5 e 8 pessoas e realizamos as atividades entre eles. O site FunRetrospectives contém varias atividades de Team Building para você usar ou se inspirar.

Happy Hour (Bônus): Ao final do Kickoff deixamos uma chamada aberta para que os participantes continuem à interagir e trocar conversas opcionalmente.

Faça pausas

Assim como as pausas são necessárias durante um dia normal de trabalho, também são importantes durante o evento, por isso não esqueça de intercalar os blocos de apresentação com pausas de 10 à 15 minutos. Além do cuidado com a saúde, essas pausas curtas ajudam com que as pessoas recuperem o foco.

Para a pausa do almoço, que é a mais longa, gostamos de deixar com uma folga de 1h30. Antes das pausas, não se esqueça informar o horário da volta às atividades para que nenhum participante perca o conteúdo.

Brindes

Quem não gosta de um mimo, não é? Fazemos questão de oferecer uma lembrança desse dia para as pessoas através da entrega de um brinde. Entre os brindes que as pessoas mais gostaram de ganhar, estão camisetas e cadernetas personalizadas com artes que remetem à características da equipe e que eles podem usar no dia-à-dia.

Cuidamos da logística para que cada colaborador(a) receba os brindes utilizando plataformas de entrega ou entregadores autônomos. É importante que a surpresa seja feita um dia antes do evento, evitando que as pessoas fiquem ansiosas durante o dia do Kickoff.

Escolha um(a) apresentador(a)

Escolha uma pessoa do time para ser a responsável por intermediar os momentos de apresentação durante o dia, essa pessoa também ira mediar as perguntas que os participantes tiverem.

Durante apresentações online, é comum que alguma ferramenta não funcione corretamente ou que hajam imprevistos. Essa pessoa poderá gerar momentos de descontração enquanto o problema estará sendo resolvido evitando silêncios durante a chamada.

Por fim, finalize o Kickoff de quarter com um formulário de feedback para entender o que foi muito bom no evento e o que pode ser melhorado. É importante para os colaboradores se sentirem parte e verem suas ideias implementadas.

Agradeço as pessoas que já estiveram comigo no time de organizadores. Em especial Débora Fernandes, Leticia Rodrigues e Paulo Moraes que me ensinaram tanto ❤.

Espero ter contribuído com a organização do seu próximo Kickoff. Até mais :)

Melhores práticas para realizar um kickoff de quarter was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Antes de começarmos a resgatar a história desse projeto, é importante darmos uma breve explicação sobre o que significa esse termo que é muito falado hoje em dia, pois provavelmente você já se deparou em uma situação parecida com essa:

Bom, desmembrando elementos deste componente, podemos tirar um ótimo exemplo da implementação de um DS, vamos lá

E agora, o que isso tudo tem a ver com um DS?

Para nós é um produto, que evolui constantemente de forma escalável com a finalidade de construirmos aplicações diferentes com uma linguagem visual única e de forma rápida, concentrando cores, tipografia, componentes visuais e todas suas regras de aplicação em uma documentação única para os times, deixando a comunicação fluída.

Vamos dar início à nossa linha do tempo, afinal já demos muita introdução

O problema inicial

Inicialmente tínhamos uma única aplicação na Revelo. Vamos apelidar de App1(bem criativo), um sistema monolítico responsável por todos os nossos produtos. Nesse sistema nós chegamos a ter mais de 60 cores diferentes, bastante né? Mas calma, isso foi só uma curiosidade, vamos seguir. Resumidamente nossa arquitetura de aplicações era basicamente assim:

Surgiu a necessidade e nossa primeira aplicação Front End em Vue.js foi criada para ser responsável por parte do nosso produto. Nessa aplicação, componentes visuais já foram criados com uma arquitetura bem modular, porém reutilizados apenas dentro dele mesmo. As cores, tipografia e espaçamento se reduziram um pouco em quantidade, porém ainda sem padrão definido e sem regras de implementação

Nesse cenário nós tínhamos:

O primeiro problema aparece neste momento, pois a App 1 ainda é responsável por muitas páginas do nosso sistema, como vamos garantir que as telas de ambas as aplicações resultem em experiências semelhantes para a pessoa usuária? Bom, a oportunidade da criação de uma biblioteca veio juntamente com o nascimento de uma terceira aplicação, resultado de um novo desmembramento da App1, pense como uma grande peça de lego sendo desmontada em pecinhas menores e mais poderosas.

Linha do tempo até este momento da história

Definição das tecnologias:

Algumas opções foram estudadas, desde as mais simplistas até as mais complexas, para sabermos qual caminho tomar na nossa lib inicial:

• Utilizar lib de terceiros já consolidadas, o que resultaria em alto acoplamento e baixíssima liberdade para tomarmos nossas próprias decisões
• Criar uma lib CSS que exportaria para nós todos os estilos necessários (tokens, componentes, etc…)
• Mesclar ambas as soluções

Por que não escolhemos alguma dessas opções?

Nós tivemos uma experiência muito boa com a stack do VueJS e sabíamos que na próxima aplicação Front End que surgisse, a mesma ferramenta seria usada. Seguimos a seguinte linha de pensamento:

- Já temos uma ferramenta front-end bem testada e consolidada na empresa

- Precisamos de componentes dinâmicos e customizáveis que trabalhem bem com nossa experiência visual

- Em nossa App2, grande parte dos componentes que poderiam ser reutilizados entre as aplicações, já estavam criados em VueJS

Conclusão: Vamos criar uma lib própria usando uma stack conhecida, com testes e dando pra área de tech uma experiência boa em desenvolver nas aplicações.

Com a estratégia escolhida, vamos preparar o terreno!

Passos cruciais antes da criação da nossa App 3:

• Isolamos dentro da App 2, todas as peças que inicialmente fariam sentido serem reutilizadas entre aplicações Front End, sem muita regra, afinal não existia um DS
• Com a App 2 funcionando normalmente com esse isolamento, demos início à criação da nossa primeira biblioteca interna

Essa biblioteca é o conjunto de recursos que podemos consumir nos nossos sistemas, contendo uma fonte única de código.

Podemos ilustrar esse cenário dessa forma:

Um exemplo de como os componentes eram utilizados nas aplicações, agora com nossa primeira versão da library em forma de plugin VueJS chamada Everest.

Exemplo de como exportamos os componentes desse plugin nessa v1

Everest - main.js

Como instalamos o plugin nos projetos Vue

Projeto Consumer — main.js

Exemplo de utilização em nossas views

Projeto Consumer — ViewExemplo.vue

Prontinho, agora com nosso plugin sendo consumido por nossas aplicações, o primeiro problema de unificar nossa linguagem visual está resolvido! Mas ainda temos muito o que evoluir pois esta foi apenas o primeiro passo para nossa solução. No próximo artigo nós vamos contar em alguns pontos sobre como nós escalamos o Everest até se tornar nosso DS:

• Everest deixa de ser um plugin
• problemas de bundle: como o modo de exportar e consumir esses componentes estava impactando nossas aplicações
• solução para múltiplas “fontes da verdade” surgindo
• documentação e seu processo
• interface com App mobile

Até logo o/

A construção do Design System da Revelo was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Desde o último trimestre de 2020, a estrutura organizacional do time de Growth na Revelo passou a ser integrada em squads já existentes, compostos por profissionais de Produto, Tecnologia e Design. Essa estrutura está permitindo uma maior eficiência em atingir nossas metas através do alinhamento e velocidade na definição e execução de projetos e experimentos.

Neste texto, pretendo compartilhar como foi a integração do time de Growth em squads, apresentando as práticas vivenciadas e detalhando esse processo na Revelo.

TL;DR

• Realizamos a alocação das pessoas de Growth nos squads a partir de dois fatores: priorização dos objetivos e eficiência de recursos;
• O processo de adaptação no novo squad foi feito com o alinhamento dos objetivos, apostas e métricas entre Growth e as outras áreas (Produto, Design e Tech), e com a integração em rotinas e ferramentas já utilizadas;
• Realocações são normais e podem vir a acontecer — não tratamos como um tema “tabu”;
• Criamos novas rotinas com o squad: Planejamento de experimentos e análise de métricas;
• Também criamos novas rotinas em Growth: Chapters (CRM e Performance), alinhamento de projetos, health checks e checkpoints com gestores;
• Estamos constantemente aprimorando a estrutura dos squads a partir dos novos desafios e contexto da empresa ao longo do tempo.

Alinhamento a partir dos objetivos de negócio

Para qualquer estrutura de time, precisamos, antes de tudo, entender a estratégia da empresa em seu momento atual. A partir disso, conseguimos fazer as mudanças necessárias para adequar a estrutura do time aos objetivos da empresa, considerando o seu escopo de atuação. É claro que cada caso é um caso, não existe uma estrutura universal “certa” ou “errada”. Em nosso contexto, estávamos em um momento da empresa com objetivos de negócio a longo prazo bastante claros que faziam muito sentido realizarmos mudanças na estrutura do time de Growth.

A figura acima mostra como era a nossa estrutura antes e como ela está agora, com a integração em squads. Antes, éramos organizadas em três focos de atuação:

• B2B (empresas)
• B2C (candidatos)
• CRM (implementação da infraestrutura)

A partir de um novo contexto multi-produto, nos adaptamos para que os esforços de Growth (aquisição e retenção) fossem alinhados de acordo com o processo de construção dos novos produtos. Na estrutura de squads, trabalhamos em equipes multidisciplinares e o nosso escopo core de atuação nasce alinhado com o desenvolvimento do produto, a partir da criação de experimentos mais relevantes que aceleram o crescimento da empresa. Um exemplo disso seria o lançamento de uma nova ferramenta com um volume mínimo de tráfego, possibilitado a partir da estrutura em squad.

Temos três principais frentes no nosso escopo core:

• Analytics: modelagens e análises de dados para tomadas de decisões de negócio e acompanhamento de experimentos;
• CRM: implementação de infraestrutura, construção e otimização de jornadas do usuário para retenção e reativação;
• Performance: gestão de canais de mídia paga para aquisição e engajamento, controle de orçamento e otimizações.

O que aconteceu para isso mudar?

É aqui que eu falo sobre o contexto de cada empresa. Estava muito claro para nós que os objetivos da Revelo eram focados em escalar os novos produtos e segmentos de atuação, portanto, era imprescindível a estrutura em squads multidisciplinares, que trazem muitos benefícios, como:

• Alinhamento das métricas de negócio de acordo com o objetivo — temos uma padronização dos dados em relatórios e dashboards que são analisados;
• Mensuração de todos os experimentos realizados no Produto — garantimos o tracking e tráfego em todos os experimentos no Produto;
• Comunicação entre áreas acontece dentro dos squads — a informação não precisa ser alinhada entre os gerentes (top-down) para ser repassada para os times, viabilizando tomadas de decisão mais eficientes;
• Maior colaboração no trabalho — evitamos que projetos iguais aconteçam em paralelo em cada área e os tornamos realmente multidisciplinares.

Alocação de pessoas na nova estrutura em squads

A estrutura em squads é explicada aqui neste vídeo sobre a cultura do Spotify, que também é utilizada em várias outras empresas que seguem a metodologia ágil. Basicamente, um squad é um time multidisciplinar focado em um segmento de atuação específico (segmento de cliente, feature de produto, unidade de negócio, etc), e suas características principais são a autonomia e velocidade para tomadas de decisões pautadas entre os membros que compõem o próprio squad.

Para realizar a integração dos membros do time de Growth nos squads da melhor maneira possível, traçamos o seguinte raciocínio:

Priorização dos objetivos:

Quais são os principais objetivos de negócio?

Aqui é muito importante ter a clareza nos focos da empresa em horizontes de tempos definidos, geralmente traçados pela liderança.

Eficiência de recursos:

Como é a relação de demanda e impacto da competência de Growth nos squads?

Sabendo quais são os objetivos de negócio, entendemos especificamente onde Growth pode ter mais alavancas de atuação focadas em resultados.

Qual é o escopo de atuação e expertise da pessoa?

É importante que a nova alocação esteja bem alinhada com o desenvolvimento profissional e o escopo de atuação dentro do novo squad.

Portanto, de acordo com esse raciocínio, a estrutura de um squad não é uniforme. Ou seja, ser um time multidisciplinar não significa que todos os squads devem conter sempre profissionais de todas as áreas (Produto, Tecnologia, Design e Growth), a estrutura vai depender muito de dois pontos: priorização dos objetivos com eficiência na alocação de recursos.

Como na imagem exemplo, temos diferentes composições de squads, algumas com uma ou mais profissionais de Growth (ex. Squad A, C e E), ou até mesmo squads sem nenhuma pessoa de Growth (ex. Squad B, D e F).

Processo de adaptação

Com a nova estrutura definida, vem o processo de adaptação no squad. É aqui que o novo time vai se conhecer, alinhar o escopo de trabalho, apresentar as rotinas e ferramentas utilizadas. Nesse caso, esse processo foi marcado com o nosso kickoff — evento que encerra um trimestre e dá início ao próximo ciclo, onde cada squad apresenta os objetivos e apostas para o novo trimestre.

Alinhamento com membros do squad

Na Revelo, o planejamento do trabalho é organizado em trimestres, e desde esse início, é muito importante que os membros do squad estejam alinhados na definição dos objetivos, apostas e métricas que serão utilizados para guiar o trabalho do time no novo período. Todos foram muito abertos e receptivos na integração de pessoas de Growth, o que facilitou bastante esse alinhamento inicial. Além disso, algumas reuniões mais frequentes no início para entendimento do Produto e esclarecimento de dúvidas que iam surgindo também foram feitas para garantir que todos estavam na mesma página.

Integração em rotinas e ferramentas

No squad, existem algumas rotinas e ferramentas do processo ágil para o desenvolvimento do produto, que eram novidade para o time de Growth. No começo, muitas dúvidas foram surgindo, e após algumas participações, o processo se tornava mais natural. Apesar de não serem rotinas específicas de Growth, participamos ativamente levantando opiniões e questionamentos através de uma perspectiva nova para o desenvolvimento do produto.

Realocações

Tratando-se de um processo de adaptação, nem tudo funciona 100% no começo, e na Revelo isso não é um tema “tabu”. Após quase um mês com a nova estrutura, percebemos que algumas pessoas deveriam estar alocadas em squads diferentes do que estavam, seguindo o raciocínio de priorização de objetivos e alocação de recursos. Dessa maneira, algumas mudanças foram realizadas durante o processo de adaptação. Mudanças são sempre delicadas, tanto para o squad quanto para a pessoa em questão, mas às vezes são necessárias. Por isso, devemos avaliar com atenção os impactos das mudanças e garantir que elas sejam realizadas somente quando realmente necessárias.

Criação de novas rotinas

Para garantir a organização funcional do time de Growth, criamos as nossas próprias rotinas: para alinhamentos com o time do squad, e com o próprio time de Growth, que geralmente ocorrem com frequência semanal.

Rotinas novas nos squads

• Planejamento de experimentos: reunião interna no squad para pensar nos próximos experimentos a serem priorizados e definir os critérios de sucesso que irão medir seus resultados. Essa rotina é importante para alinhar o foco de trabalho do time, onde todos têm participação ativa para decidir o que será priorizado dentre os experimentos e ideias levantadas. Com a definição dos experimentos, outras reuniões ao longo da semana são feitas para alinhar o ciclo de desenvolvimento.
• Análise de métricas: momento para apresentar a evolução das métricas norte, secundárias, e de saúde a todos do squad, para garantir a visibilidade do trabalho e direcionamento para as alavancas que mais precisam de atenção para trazer os resultados esperados traçados pelas metas definidas no começo do trimestre. Geralmente esse momento ocorre em um dia da semana durante o checkpoint (reunião diária para apresentação do status do que está sendo trabalhado), ou na reunião de Planejamento de Produto & Growth (alinhamento dos experimentos com a liderança).

Cada squad é totalmente autônomo para criar as rotinas que mais fazem sentido para o time, e estamos em constante avaliação para adotar e ajustar o modo como trabalhamos.

Rotinas novas com o time de Growth

• Chapters: rotinas comuns em estruturas de squads, os chapters (“capítulos”) são os grupos de pessoas que possuem o mesmo escopo de atuação. Eles são essenciais para que exista o acompanhamento do escopo de trabalho da área em questão com a gestão de conhecimento entre os membros do time. Na área de Growth, criamos o Chapter de CRM e o Chapter de Performance, que são disciplinas de nossa expertise. Cada Chapter é liderado por um membro do time de Growth que possui mais conhecimento do escopo, e todos da área se reúnem uma vez por semana para reportar o status do que está sendo realizado em cada squad em relação à disciplina, alocar tarefas submetidas por squads/outras áreas da empresa que não possuem alguém de Growth, e também para colaborar e compartilhar boas práticas para gestão de conhecimento.
• Alinhamento de projetos: quinzenalmente, é um espaço para apresentarmos os projetos que estão sendo realizados e o que está planejado para acontecer em cada squad, onde podemos compartilhar dificuldades e pedir ajuda/feedback do time, garantindo a visibilidade do que está sendo construído na área de Growth entre todos os membros.
• Health check: quinzenalmente, nos reunimos para compartilhar sobre como estamos nos sentindo no trabalho, sendo um momento de união e acolhimento entre o time em relação a alguma dificuldade, problema ou conquista que aconteceu durante as duas últimas semanas. É bem importante para manter o time unido, ainda mais em um ambiente de home office.
• Checkpoints com gestores: ocorre de uma a duas vezes por semana entre os membros de Growth do squad com seus respectivos líderes, com o propósito de dar visibilidade do trabalho aos gestores, tirar dúvidas de tarefas bloqueadas, e alinhar o direcionamento do que está sendo feito.

Todas essas rotinas foram sendo criadas ao longo do processo de integração de Growth nos squads, e nos ajudam bastante a entender as responsabilidades do nosso trabalho no dia a dia, garantindo o desenvolvimento da área e das pessoas de Growth na Revelo.

Aprimorando a estrutura em squads

É claro que toda mudança traz muitos desafios, e estamos constantemente aperfeiçoando o modo como trabalhamos. Conquistamos resultados ótimos no primeiro trimestre com essa nova estrutura, e para cada novo período, buscamos aprimorar ainda mais, com a revisão da organização estrutural para a criação de novos squads, realocações e direcionamentos em torno dos objetivos da Revelo.

Os principais desafios que surgiram em relação à essa nova estrutura são relacionados à auto-organização dos próprios squads, como a falta de clareza sobre as responsabilidades de cada um, em um ambiente onde todos tomam decisões em conjunto — criando-se certa nebulosidade entre autonomia e alinhamento, a existência de muitas reuniões e rotinas que impactam na organização do tempo para executar as tarefas, e a necessidade de uma comunicação bastante clara e eficiente, tanto entre os membros do próprio squad como com os outros squads, para garantir que ninguém esteja trabalhando no mesmo problema e que a colaboração entre as pessoas esteja sendo realizada sem fricções desnecessárias.

A nova estrutura organizacional do time de Growth em squads foi implementada devido ao momento específico e aos objetivos que a Revelo possui atualmente, sendo que tal estrutura nos possibilita criar dinâmicas de trabalho multidisciplinares mais eficientes e integradas. Não existe estrutura certa ou errada, e é preciso revisitar a organização de tempos em tempos para certificar um alinhamento claro com os objetivos da empresa.

Espero que este texto tenha te ajudado de alguma forma a refletir sobre criação de squads com profissionais de Growth.

Ah, e se a sua empresa está com vagas abertas para profissionais de tecnologia ou digital me avisa, ok? Vai ser legal entender se podemos ajudar. Me manda um email: camila.yamashiro@revelo.com.br 😄

Agradeço à Juliana Uechi (Head de Growth na Revelo) que me ajudou na elaboração desse texto.

Que tal acelerar ou começar a sua carreira na área de tecnologia? Conheça o Revelo UP — o programa de incentivo aos cursos mais quentes do mercado. Saiba mais aqui!

Leituras recomendadas 💡

Henrik Kniberg, Spotify Engineering. Spotify engineering culture

Casey Winters, Casey Accidental. The types of Product Team Organizational Structures

Will Sertório, UX Collective. Batendo o bumbo: boas práticas para empoderar times de produto e design

Michel Nassif, Tech Revelo. Nuggets de Experimentos: como tornar acessível os resultados de seu discovery

Como integramos o time de Growth em estrutura de squads was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Desenvolvedores que usam Mac ou máquinas com pouco armazenamento, sabem que é comum perceber que ao usar Docker você está com pouco espaço.
Antes de pensar em upgrade de memória, conheça e adote hábitos de limpeza da sua stack podem te mostrar o que você realmente usa e gerar uma economia de recursos consumidos simultaneamente.

Separei umas dicas dos hábitos que tenho adotado há pelo menos um ano e desde então nunca mais tive problemas por pouca memória.

Docker

O docker funciona sobre containers e estes sobre suas respectivas imagens.
Fazendo um paralelo com orientação à Objetos, você pode ler a frase acima entendendo que:

• uma imagem é "como uma Classe"
• cada container é "como uma instância da classe à qual se refere"

Docker x Memória

Quando falamos de Docker x uso de memória, é importante lembrar que do mesmo jeito que os objetos e variáveis ocupam memória, assim é com os containers e imagens do Docker: só que estes, por sua natureza, ocupam muito mais memória.
Todo recurso que não está sendo usado pode e deve ser liberado, já que a orquestração do ambiente está nas instruções escritas no Dockerfile e no docker-compose, e liberando recursos, suas instruções de configuração não serão perdidas. Dentre os principais recursos que usamos do Docker, esta é a ordem de maior consumo de memória:

• imagens
• volumes
• containers

Para limpar esses recursos, você deve começar pelos container, já que as imagens e volumes só podem ser liberados se não estiverem sendo usados por alguma instancia (que é um container).
Por costume, eu sempre faço minha limpeza na ordem: containers, imagens e depois volumes.

Para gerenciamento de containers, a doc de containers do Docker nos dá vários insights. Os comandos que eu mais uso são:

• verificar os recursos que estes containers estão consumindo: docker container stats
• ver todos os containers: docker container ls -a , o -a te permite ver até os containers parados
• remover os containers que não estão em uso: docker container prune
  Esse comando remove todos os containers que não estão em uso no momento, sempre faço a limpeza após confirmar que todos os containers que uso estão rodando, para não remover algo inesperado.
  Você pode fazer dessa forma ou aplicar um --filter=OPTION para remover apenas o que quiser, dá um check na Documentação.

Após remover os containers, limpo as imagens que não estão instanciadas e os volumes.

• docker image prune , que a doc indica que pode ser personalizado com alguns filtros

• docker volume prune , que a doc indica que pode ser personalizado com alguns filtros

Uso de memória Antes x Depois

PLUS: se é você a pessoa que cria as imagens que seus projetos usam, além de seguir boas práticas para criar imagens pequenas, você pode verificar o tamanho de cada camada usando docker history IMAGE para facilitar a identificação de camadas que podem ter seu tamanho reduzido.

Ruby & suas versões

Quem trabalha com Ruby, em geral utiliza mais de uma versão de ruby, e a cada versão que você adiciona, são instalados binários, aliases e alguns outros arquivos que consomem espaço local.
Sempre que você deixar de usar uma versão de ruby, é interessante remover toda essa bagagem desnecessária.

Existem alguns gerenciadores de versão do ruby, como gosto de usar o RVM, os comandos abaixo fazem referencia à ele, mas explico o princípio da escolha para que você possa replicar com o gerenciador que você use.

É possível desinstalar apenas o executável do ruby e deixando outras dependências espalhadas na máquina.
É isso que o rvm uninstall ruby-x.x.x remove apenas a instalação do ruby,

Para remover completamente uma versão de ruby de uma máquina, use um comando que remova a instalação do Ruby e também seus aliases, gemsets e quaisquer binários/demais arquivos associados.
No RVM, esse comando é rvm remove ruby-x.x.x

Após remover 2 versões de Ruby, minha memória foi liberada em mais 5GB:

Ferramentas de análise de armazenamento

Pra quem usa VS Code, instalar a extensão VSCode Docker te ajuda a fazer muito do que fiz na linha de comando dentro do próprio Visual Studio.

Outra dica para não ter que descobrir manualmente o que está consumindo seu armazenamento, é instalar o ndcu, uma ferramenta gratuita que te ajuda a identificar onde no disco você usa mais espaço e liberá-lo.

PLUS: Outros recursos bastante usados em desenvolvimento e que também podem ser limpos de tempos em tempos são versões do node e versões de extensões do Chrome.

NVM node version manager

No meu caso, além de ruby eu também uso node nos projetos, usando o NVM como gerenciador de versões.
Sigo o mesmo principio de limpeza das versões do node, com
nvm uninstall vx.x.x
Para conferir a limpeza, é só dar um ls em ~/.nvm/versions/node

Chrome extensions

Ao atualizar as versões das extensões no browser, as antigas não são removidas. Em ~/Library/Caches/Google/Chrome/Default/Storage/ext acesso cada pasta e removo as versões antigas das extensões que uso.

Essas últimas limpezas não são tão impactantes em liberar memória, mas ajudam um pouco e mantém a saúde em dia.

E você, tem alguma dica para compartilhar comigo e com a galera da comunidade? Add nos comentários =)

De dev para dev: como liberei 10GB na minha máquina was originally published in tech.revelo on Medium, where people are continuing the conversation by highlighting and responding to this story.