Maria é gerente de vendas em uma empresa de SaaS. Toda manhã, ela abre o CRM e vê centenas de negociações ativas. Algumas estão paradas há semanas, outras têm prazos urgentes e ainda tem aquelas “quentinhas” que acabaram de entrar, mas é impossível analisar todas. Priorizar pode significar perder receita e não priorizar pode sobrecarregar a equipe. Além disso:

• 44% das empresas estimam perder mais de 10% da receita anual devido à baixa qualidade dos dados em seus CRMs.
• 65% dos vendedores dedicam a maior parte do tempo a atividades que não estão diretamente relacionadas à venda, como preenchimento de relatórios e outras tarefas administrativas.
• O vendedor médio gasta apenas 22% do seu tempo efetivamente vendendo; o restante é consumido por tarefas como envio de e-mails, inserção de dados e prospecção de leads.

Como a RD resolveu esse problema?

Construímos uma feature que usa Machine Learning e IA Generativa que:

• Classifica negociações a partir de seu potencial de venda e urgência.
• Explica o motivo ao vendedor em linguagem natural.
• Integra-se ao fluxo atual dos vendedores.

A solução combina algoritmos de ML para priorização, SHAP values para interpretabilidade e Gemini para uma comunicação simples com o usuário.

Desafio: Como saber quais negócios priorizar?

• Nem todas as negociações com alta probabilidade de fechamento são as mais urgentes — algumas oportunidades precisam de atenção imediata para não serem perdidas, mas passam despercebidas.
• Explicar por que uma negociação foi priorizada é importante para ganhar a confiança dos vendedores.
• A recomendação deve ser rápida, explicável e acionável.

Solução: Machine Learning + SHAP + IA Generativa

Para resolver esse problema, criamos um pipeline baseado em três componentes principais:

1. Machine Learning: Modelos treinados para prever o impacto em uma negociação dada uma atuação (o que chamamos de uplift) e a probabilidade de fechamento de cada negociação, assim como a criação de um score baseado nos dois valores.
2. SHAP Values: Explicabilidade para identificar o que mais influenciou cada previsão.
3. Gemini: Geração de explicações personalizadas em linguagem natural para os vendedores.

Para ranquear as negociações que devem ser priorizadas, portanto, trabalhamos em três diferentes algoritmos.

Probabilidade de Fechamento

Para estimar a probabilidade de fechamento de uma negociação, utilizamos um modelo LightGBM treinado com um conjunto de features que representam o histórico e o comportamento do lead.

• O modelo LightGBM é treinado para classificar as negociações como fechadas (1) ou não fechadas (0).
• Ele recebe como entrada um conjunto de features extraídas do CRM, incluindo o tempo desde o primeiro contato, número de interações, etapa atual no pipeline, rating do lead e engajamento nas comunicações.
• O modelo é integrado a um pipeline de pré-processamento, garantindo que os dados passem por transformações como Imputação de valores ausentes, normalização de variáveis numéricas e codificação de variáveis categóricas.

Uplift

Enquanto o modelo de probabilidade de fechamento estima a chance natural de uma negociação ser concluída, o modelo de uplift busca responder a seguinte pergunta: “se o vendedor atuar agora, qual será o impacto real na probabilidade de fechamento?”

• Utilizamos um UpliftTreeClassifier, que compara grupos de controle e tratamento para medir a diferença de impacto da ação do vendedor.
• Os dados de treino são processados para incluir uma coluna de tratamento, que indica se o vendedor realizou uma ação relevante (como o agendamento de uma reunião ou o envio de uma comunicação).
• O modelo então aprende a diferença entre grupo controle (negociações onde não houve intervenção) e grupo tratado (negociações onde houve uma ação do vendedor)

Score

O score final da negociação é calculado combinando as previsões dos modelos de probabilidade de fechamento e uplift, resultando em um ranking de prioridade para o vendedor.

• O score é calculado ponderando os seguintes fatores:
• Score = α×Probabilidade de Fechamento + β×Uplift

Onde:

• Probabilidade de Fechamento representa a chance da negociação ser concluída independentemente da ação do vendedor.
• Uplift representa o impacto esperado caso o vendedor tome uma ação agora.
• Os pesos α e β são ajustados para balancear a influência de cada fator no ranking e são otimizados para maximizar as vendas dos clientes.

Explicabilidade com SHAP

Após a predição, utilizamos SHAP (SHapley Additive Explanations) para entender quais fatores mais impactaram cada negociação. O SHAP nos permite decompor a previsão do modelo e atribuir importâncias individuais para cada feature, tornando o modelo de Machine Learning mais interpretável para os usuários.

• O SHAP calcula a contribuição de cada variável na previsão final do modelo.
• Para cada negociação, ele gera um conjunto de valores que indicam quanto cada feature aumentou ou diminuiu a probabilidade de fechamento.

Geração de Explicações com IA Generativa

Após calcular os valores SHAP, utilizamos o Gemini, LLM do Google, para transformar essas previsões e outputs em explicações claras e acionáveis para os vendedores. O objetivo é que o vendedor compreenda por que uma negociação foi priorizada e qual ação ele deve tomar.

• A API do Gemini recebe o score, as previsões, os valores SHAP e os respectivos valores das features.
• A resposta gerada contém um alerta, um contexto e uma ação recomendada.

Utilizamos o método de COSTAR (context, objective, style, tone, audience e response) para engenharia de prompt:

• Contexto: Define o papel da IA e o cenário da explicação.
• Objetivo: Explica exatamente o que a IA deve fazer.
• Estilo: Define o formato e a estrutura da resposta.
• Tom: Estabelece a comunicação ideal com o público-alvo.
• Audiência: Adapta a resposta ao nível de conhecimento do usuário final.
• Retorno: Define a estrutura da resposta gerada.

## CONTEXTO ##
context = """
Atue como um assistente especializado em traduzir informações técnicas 
sobre priorização de negociações em explicações claras e concisas para 
vendedores.

Seu papel é fornecer explicações, insights e acionáveis sobre por que
cada negociação foi (ou não) priorizada, usando um tom humanizado e 
amigável, mas mantendo o profissionalismo.
"""

## OBJETIVO ##
objective = f"""
Siga estas instruções específicas para a resposta:

1. A resposta deve ter três partes:
   - Parte 1 (Alerta/Título): Um alerta ou título curto...
   - Parte 2 (Contexto): Uma explicação concisa...
   - Parte 3 (Ação): Uma sugestão prática na segunda pessoa...

2. Seja o mais conciso possível:
   - A Parte 1 não deve exceder {TITLE_MAX_CHAR} caracteres.
   - As Partes 2 e 3 não devem exceder {DESCRIPTION_MAX_CHAR} caracteres.

3. Evite:
   - Mencionar números específicos...
   - Fazer suposições sobre resultados...

4. Mantenha consistência nos termos e na linguagem...

5. Escreva em português brasileiro.
"""

## ESTILO ##
style = """
Use uma linguagem simples e prática, sem termos técnicos desnecessários. 
Seja direto e estruturado.
"""

## TOM ##
tone = """
O tom deve ser humanizado, amigável e encorajador, 
mantendo o profissionalismo.
Evite gírias, piadas ou linguagem excessivamente casual.
"""

## AUDIÊNCIA ##
audience = """
O público-alvo são vendedores que não possuem conhecimento 
técnico em Machine Learning.
As explicações devem ser fáceis de entender e focadas em ações práticas.
"""

## RETORNO## 
response_format = """
Estruture a resposta em três partes:
1. **Título curto:** Um resumo direto da oportunidade.
2. **Contexto:** Explicação breve dos principais fatores 
que influenciaram a priorização.
3. **Ação:** Sugestão prática para o vendedor.

Formato esperado da resposta:
{
  "reason": "<Título curto><Context><Ação>"
}
"""

Exemplo de resposta gerada pelo Gemini AI:.

{
    "reason": "Priorize essa negociação! O lead apresentou 
interesse no produto, possui várias interações e apresenta 
alto engajamento. Retome o contato com uma proposta."
}

Infraestrutura e Deploy na Nuvem

A solução foi desenvolvida para funcionar de ponta a ponta no Google Cloud Platform, permitindo escalar tanto o processamento de previsões quanto a geração de explicações:

Modelos Armazenados no GCS

Após o treinamento, os artefatos dos modelos (probabilidade de fechamento e uplift) são salvos no Google Cloud Storage. Dessa forma, sempre que a aplicação é atualizada, a Cloud Function carrega automaticamente a versão mais recente desses modelos.

Inferência Online via Cloud Functions

Uma Cloud Function expõe um endpoint HTTP para receber requisições de predição em tempo real. Ao receber um pedido, a função:

• Consulta os dados no BigQuery, obtendo o estado atual da negociação.
• Carrega e aplica os dois modelos (probabilidade e uplift).
• Calcula o score final e retorna o resultado em formato JSON.

Geração de Explicações com Vertex AI

Ao mesmo tempo, a Cloud Function se integra ao Vertex AI para invocar o modelo Gemini. Os valores SHAP e os dados relevantes da negociação são enviados para a API, que retorna uma explicação em linguagem natural pronta para exibição no CRM.

Monitoramento e Logs

Através do Cloud Monitoring e Cloud Logging, todas as métricas de uso, latência e possíveis erros são consolidadas em um só lugar, facilitando a observação e a escalabilidade quando o volume de requisições aumenta.

Conclusão

A combinação de Machine Learning, Explainable AI (via SHAP) e IA Generativa trouxe uma solução completa para priorizar negociações de forma rápida, explicável e acionável.

• Benefícios para o Vendedor: Recebe um score claro e orientações personalizadas, entendendo por que uma negociação é prioridade (ou não) e quais ações devem ser tomadas.
• Transparência na Tomada de Decisão: Com a explicação detalhada do motivo de uma negociação ser priorizada, o vendedor sente confiança para agir.
• Ganho de Eficiência: A equipe de vendas foca nas oportunidades com maior impacto, aumentando o potencial de conversão e reduzindo o tempo desperdiçado.

Referências

• TI Inside, Má qualidade dos dados tem impacto negativo nos resultados das empresas, link
• Sales Coaching, Fechamento de vendas: estatísticas que você deve conhecer, link
• Meetime, Produtividade de vendas: Como otimizar seu processo comercial?, link

Como Usamos ML, Explainable AI e IA Generativa para Priorizar Negociações no CRM was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Se você chegou até aqui, provavelmente está passando alguma dificuldade com relação à cobertura de testes do seu projeto. Então imagine a seguinte situação:

Você está fazendo uma remoção simples no código do seu projeto. Você faz todas as alterações que deveriam ser feitas, altera os testes para se adequarem aos seus ajudes… talvez até tenha escrito testes novos. Os testes passam, um-a-um, até que um evento fatídico toma conta do seu PR: a cobertura geral de testes foi REDUZIDA!?!

Mas… se eu removi trechos de código, a cobertura não deveria ter sido AUMENTADA? Se eu reduzi a amostragem e mantive os testes, não deveria o percentual de cobertura ter SUBIDO?!? Minha cobertura de testes não faz sentido!!

Este é mais um daqueles momentos em que a matemática parece não estar “matematicando”. E para nós, programadores, que temos a lógica como base da profissão, pode ser algo de tirar o sono.

Se você já passou por isso — como eu passei recentemente — pode ser que tenha quebrado a cabeça por horas tentando descobrir o que aconteceu, qual mudança afetou a cobertura total e qual dos diversos arquivos “atacar” para aumentar a cobertura.

O que eu não fazia ideia quando passei por isso é que existe uma metodologia muito simples para resolver o problema de coverages que “não fazem sentido”. Ou pelo menos para te dar dados reais e uma base matemática para você tirar suas próprias conclusões e tomar decisões.

A lógica é simples e consiste em comparar a cobertura antes e depois das mudanças feitas. Ou seja, os dados de cobertura geral da sua branch com os da branch main/master do projeto (Iremos utilizar JavaScript e Jest como exemplo).

Por que disso?

Ora, o que queremos verificar aqui é se mantemos ou não os padrões de garantia da qualidade de código. Afinal de contas, ninguém quer ser o responsável por uma entrega que prejudica a qualidade do produto, certo?

Isso posto, ao comparar os dados da cobertura nesse método de antes/depois é possível verificar:

1. Qual arquivo teve a cobertura reduzida e quais as linhas impactadas.
2. Ou se, por pura questão de matemática, as mudanças na amostragem geral de código refletiram no percentual coberto.

No caso um, é preciso retornar a cobertura à taxa anterior, uma vez que os padrões de garantia de qualidade do código não estão sendo mantidos.

Já no caso dois, é perfeitamente aceitável mantê-la abaixo dos parâmetros anteriores, pois fica provado matematicamente que o padrão de garantia de qualidade está sendo mantido. E, confia em mim, não tem argumento melhor do que algo provado em dados.

Ta, mas pera aí… meu projeto tem mais de 200 arquivos… cada um com a sua coverage própria. Comparar as taxas manualmente seria uma tarefa enorme, monótona e com risco de erro!

Eu tive esse mesmo pensamento quando ouvi esse método pela primeira vez… Mas, eu sou programadora, e como todo programador, pensei: Porque gastar duas horas em uma tarefa manual se eu posso automatizá-la em cinco horas e nunca mais ter que fazê-la, certo?

Para os que não estão familiarizados com Jest, ao calcular a cobertura de testes ele gera uma tabelinha para você no próprio terminal, mais ou menos como a mostrada na figura abaixo:

O que pouco se fala sobre é sobre o relatório em HTML infinitamente mais completo que é gerado e salvo dentro da pasta do projeto. Geralmente vai estar dentro de uma pasta coverage > lcov-report e, por padrão, o arquivo gerado chama-se index.html. É só clicar que ele abre no seu navegador padrão e é ele que vamos usar no método. Para fins de demonstração, esse arquivo se parece com o da imagem abaixo:

Eu imagino que a essa altura do artigo você já está pensando no que eu estou pensando…

Bom, se eu tenho duas tabelas com as mesmas colunas, mas com dados diferentes, eu posso abri-las no Excel e escrever fórmulas para compará-las automaticamente: e foi exatamente essa a solução que desenvolvemos no meu time na RD Station — Cá, entre nós, algo que foi muito mais divertido do que ficar olhando linha-a-linha de um arquivo HTML.

Montamos um modelo de planilha que compara coluna-a-coluna e que sinaliza as diferenças entre o “antes” e o “depois” de uma maneira automática e visual. Basta copiar e colar os dados da planilha de coverage.

O melhor de tudo é que agora você, leitor, pode usá-la também. Basta fazer uma cópia desse arquivo aqui e seguir as instruções dentro dele.

A planilha te mostra em quais arquivos houve diferença na cobertura de testes na aba “Comparação” e na aba “Cálculo de Coverage” te mostra o impacto numérico disso no cálculo de porcentagem.

A vantagem é que, se for preciso agir, você já saberá qual o arquivo. Então basta abrir o index.html correspondente à sua branch atual, clicar no arquivo indicado como “Diferente” pela planilha e ele te mostrará quais as linhas podem ser melhoradas.

Para fins de exemplo, deixei duas linhas com os Statements diferentes na tabela “Comparação”, linhas 5 e 8:

Como você pode perceber, ambas as linhas foram sinalizadas como “Diferente”, pela tabela. Pode-se verificar que uma delas foi de 13/14 para 10/14, e a outra de 6/6 para 4/4.

Ou seja, no primeiro exemplo, como foi mantido o número de funções totais (14), mas reduzido o número de funções cobertas de 13 para 10, conclui-se que aqui houve perda da garantia da qualidade — o que exige ação e a escrita de mais testes neste arquivo.

Já no segundo exemplo, o número total de Statements foi reduzido juntamente com o número de funções cobertas. Por sua vez, indicando que não houve perda na garantia de qualidade, apenas uma redução da amostragem.

Essa mesma análise dos últimos dois parágrafos é feita na tab “Cálculo de Coverage” e entregue de maneira visual para cada usuário se houve apenas uma redução da amostragem, ou se houve perda de garantia de qualidade. Olha que legal:

Como outro exemplo, se olharmos para as Branches da tabela “Comparação”, você pode perceber que esta também é sinalizada como “Diferente”, pois foi de 3/3 para 2/2:

Da mesma forma, a tab “Cálculo de Coverage” faz a análise e sinaliza a perda como “Redução da amostragem”:

Dito isso, o desfecho da minha história — e que eu espero que seja o da sua também — foi o seguinte: Descobrimos que os 0.2% de diferença na cobertura de testes acontecia porque a cobertura de um dos arquivos ia de 6/6 para 4/4, mantendo os 100% de cobertura, mas reduzindo a amostragem geral.

Ou seja, como o que foi reduzido foi apenas o número de funções existentes, ficou nítida e sinalizada a “Redução da amostragem”, me dando a justificativa necessária para poder subir um PR com redução do coverage geral.

Só sei que eu não tive que escrever mais nenhum teste automatizado naquele dia e, para mim, esse é um final mais do que feliz.

Me conta nos comentários como você resolveria esse problema e se você tem alguma sugestão de melhoria pra planilha :)

#coverage #calculodecoverage #coberturadetestes #testesautomatizados #qualidadedecodigo #qa #jest #automatedtests

Minha cobertura de testes não faz sentido! — O método do “antes e depois” was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como conseguimos manter nosso projeto atualizado com a última versão da linguagem

O RD Station Marketing, que hoje é a ferramenta de Automação de Marketing mais usada no Brasil, foi lançado pela RD Station em 2011. Na época, o projeto foi construído utilizando as versões mais recentes de Rails (3.0) e Ruby (1.8.7), e ambas já não são mais suportadas atualmente.

Hoje, nosso RD Station Marketing conta com cerca de 300.000 linhas de código Ruby e 470.000 linhas de código em testes automatizados unitários do rspec (dados obtidos com auxílio da gem rails_stats), distribuídas em mais de 37.000 testes e 280.000 commits. Um dos maiores desafios para quem trabalha em um projeto desse porte é manter o software atualizado, de forma a assegurar a performance e a segurança do projeto.

Entendemos que essa é uma missão a ser abraçada por todo o time de engenharia, mas, dada a complexidade dos nossos projetos, aqui na RD Station, também contamos com times especializados na atualização de frameworks, bibliotecas e dependências. No caso do projeto RD Station Marketing, esse papel é do time kernel.

A indústria de desenvolvimento de software está a todo vapor e, com isso, as pessoas desenvolvedoras estão normalmente sujeitas a grande pressão para entregar novas features e lançar novidades que acompanhem as inovações do mercado (alôoo IA). Então, será que é mesmo relevante investirmos tempo e recursos da engenharia em atualizações do sistema? Quais são os benefícios de manter o software atualizado na visão da RD Station?

Por que consideramos importante manter o sistema atualizado?

A seguir, listamos algumas das principais razões pelas quais a atualização de sistemas na RD Station é tão importante:

1. Correções de vulnerabilidades de segurança: As atualizações incluem correções de vulnerabilidade de segurança, sendo corrigidas ao longo de suas descobertas. Ao não atualizar, você deixa seu sistema vulnerável a ataques cibernéticos e malwares. Por exemplo, a última atualização do Ruby para a versão 3.2.2 corrigiu dois “ReDÔS” (onde o ataque usa uma negação de serviço com um simples Regex para derrubar o Sistema).
2. Correção de bugs: As atualizações também abordam problemas e bugs identificados. Por exemplo, em 2006, encontraram um Bug: ataque DoS contra servidores Ruby. A biblioteca CGI do Ruby (cgi.rb) tem um bug que permite enviar uma única requisição HTTP para qualquer programa Ruby que utiliza parsing multipart com cgi.rb com um corpo MIME mal formado, levando o processo Ruby a atingir 99% de utilização da CPU em um loop infinito, matando-o. Essas atualizações ajudam a garantir que o sistema funcione de maneira mais estável e confiável.
3. Novos recursos e funcionalidades: Algumas atualizações introduzem novos recursos, funcionalidades e melhorias, tornando o software mais versátil e atraente para os usuários. As últimas versões de ruby, por exemplo, trouxeram melhorias nas mensagens de erro, apontando para argumentos relevantes como TypeError e ArgumentError, além do preenchimento automático no “IRB”. Outro exemplo notável em nosso histórico é a realização de uma migração crucial para o Google Analytics 4, executada com suavidade e sem impacto, mesmo em um período crítico, devido à prévia atualização das dependências essenciais.
4. Melhorias de desempenho e de estabilidade: A cada versão nova do Ruby, o time tenta melhorar o seu desempenho, deixando-o cada vez mais rápido. Uma curiosidade é o benchmark feito com o auxílio do Optcarrot, um emulador de Nes por meio do qual é possível verificar o desempenho do Ruby a cada nova versão.

Certo, já entendemos a importância de nos mantermos atualizados. Mas isso não significa que essas atualizações ocorrem sempre de forma simples e sem riscos. Por isso, vamos te contar alguns dos maiores desafios que temos enfrentado no processo.

Quais desafios enfrentamos nos processos de atualizações?

Para iniciar a conversa, precisamos mencionar que atualizar a versão do Ruby em si não foi a mais desafiadora das missões. O verdadeiro desafio foi compreender que, juntamente com essa atualização, precisávamos explorar novos caminhos, muitas vezes desconhecidos, e analisar sistemas antigos e desatualizados. É importante destacar que atualizar a versão da linguagem não se resume apenas em mudar o número da versão e executar o “bundle update”. Requer garantir que outras dependências também estejam prontas e compatíveis com a nova versão, o que se reflete em uma camada adicional de complexidade.

Muitas outras dependências precisaram ser atualizadas antes da atualização do Ruby (o famoso bump), já que elas deviam estar compatíveis com a nova versão. Para isso, precisamos aprender o que cada “changelog” nos dizia, como testar cada nova alteração e como não quebrar nenhuma outra dependência. Além disso, foi preciso decidir o que fazer com as dependências que não recebiam mais atualizações.

E, como nem tudo são flores em uma atualização, ao subir para a versão 3.0, houve a separação dos “Keyword Arguments” ou argumentos de palavras-chave, levando à quebra de mais de 5 mil testes. Os keyword arguments alteraram a maneira como os argumentos são passados para os métodos, utilizando nomes de parâmetros ao invés de apenas a ordem ou posições no qual os argumentos são fornecidos, tornando o código mais legível e menos propenso a erros, especialmente em métodos com muitos parâmetros. Compreender essas mudanças e fazer as alterações relativas a ela em todo o projeto não foi uma tarefa fácil, mas foi possível a partir do uso da gem pry, que nos auxiliou a debugar e encontrar os problemas no código.

O RD Station Marketing, como mencionamos anteriormente, representa um monolito de porte considerável, contamos com várias equipes trabalhando num codebase único e alguns times atuando em seus microsserviços externos à base de código principal. Apesar de contarmos com inúmeros testes automatizados em muitas partes do sistema, nos trazendo maior segurança nos processos de atualizações, para garantir a qualidade das entregas, aprendemos a fazer testes de validação dos cenários de uso em todo o fluxo do nosso software. Como você pode imaginar, realizar os testes em todos os casos de uso da aplicação não foi nada fácil. Para superar esse desafio, contamos com a colaboração crucial das equipes especialistas em cada funcionalidade, o que possibilitou a elaboração de um roteiro de testes abrangente. Esse esforço conjunto nos permitiu buscar a cobertura máxima possível dos cenários e minimizar potenciais erros.

A cada desafio que encontramos, também foi fundamental contar com a especialidade de pessoas engenheiras com domínio da linguagem e do RD Station Marketing. Aqui, a nossa referência foi o André Jr, nos auxiliando pacientemente a cada novo desafio.

Vencidos os desafios, vamos explorar um pouquinho de como estruturamos nosso passo a passo para as atualizações.

Como realizamos as atualizações?

Após resolvidos os problemas no build da aplicação e os testes quebrando, tínhamos pull requests enormes, um deles, por exemplo, apresentou 489 arquivos modificados e 11 times codeowners para solicitar review. Qual era a probabilidade dessa revisão ser feita utilizando as boas práticas?

Diante desse cenário, desenvolvemos estratégias por meio de tentativa e erro. Juntas, após a resolução de cada teste ou conclusão de cada etapa de atualização, adotamos a prática de nomear os commits contendo o caminho relativo do arquivo alterado, visando facilitar a sua separação em outra ramificação por meio do processo de cherry-pick. Cherry-pick é um comando git que permite ao usuário selecionar commits específicos de uma ramificação ou branch para outra, permitindo, assim, a criação de branchs específicas para serem avaliadas por cada time codeowner.

Isso simplificou o processo de solicitação de revisão dos times, uma vez que priorizamos pull requests menores e, consequentemente, conseguimos segmentar cada um deles por domínio, reduzindo significativamente o tempo de revisão e a complexidade para cada time e possibilitando às pessoas engenheiras avaliar apenas o código referente à sua especialidade.

Nesse ponto, nossos pull requests estavam passando em todas as etapas do CI e com as devidas aprovações dos revisores. Podíamos, então, seguir para o deploy em produção?

resposta curta é “não”. Para garantir a qualidade das entregas, iniciamos os testes de validação da maior parte possível de cenários e casos de uso da nossa aplicação. Testamos exaustivamente cada pull request. Testamos cada passo do roteiro criado em conjunto com os times nos ambientes de desenvolvimento e staging, e refizemos tudo inúmeras vezes. Nesta etapa, contamos com o auxílio indispensável de ferramentas de observabilidade e monitoramento de erros.

Após separar em pull requests menores e realizar as entregas de forma incremental — o que faz parte de um dos valores da RD Station, já que aqui priorizamos nossas entregas no formato “lean”, como você pode conferir no nosso código de cultura — restou um PR limpo, com poucos commits e bem objetivo quanto à atualização em si.

É importante destacar que, para a separação dos pull requests ser possível e, consequentemente, realizarmos o merge por etapas, foi preciso manter nosso código compatível entre as versões, reduzindo o risco de uma atualização quebrar algo base da aplicação.

Abaixo, apresentamos um exemplo de resultado, onde podemos observar o histórico completo depois de todas as alterações realizadas e mergeadas no pull request inicial:

E então, finalmente seguimos para o deploy em produção da atualização em si. Para isso, implementamos um processo faseado com o auxílio do time de SRE, que apelidamos de “Canário Manual”. Com atenção redobrada às ferramentas de observabilidade, conseguimos monitorar cada pod conforme era executado, identificando e mitigando possíveis erros. No caso da atualização que fizemos para a versão 3 do Ruby, identificamos um erro por meio do Rollbar que não ocorreu no ambiente de staging. Com o deploy faseado, conseguimos corrigir o problema e evitar um incidente, diferente do que aconteceria se estivéssemos realizando um deploy automático.

Usando as tecnologias mais recentes nos mantemos atualizados e relevantes no mercado

Apesar dos desafios, nosso software hoje utiliza a última versão lançada de Ruby (3.2) e estamos trabalhando para atualizar o Rails da versão 7.0 para 7.1 (lançada recentemente, em outubro de 2023), além de mantermos uma meta constante de manter pelo menos 90% das dependências atualizadas na versão major. Para se ter uma ideia da dimensão desse trabalho, temos atualmente 212 gems declaradas explicitamente no Gemfile e um total de 486 gems utilizadas na nossa aplicação (dados obtidos com auxílio da gem bundler-stats), mas vale lembrar que esse número está em constante mudança.

Em meio a tantas dependências, o time deve se estruturar de forma a entender quais são as prioridades, qual o benefício de tal atualização naquele momento e quanto tempo precisará ser investido. Porém, é importante ter em mente que, em algum momento, invariavelmente o processo de atualização (ou substituição) da dependência precisará ser realizado e, em geral, quanto maior a demora para abraçar o processo, mais difícil e complexo potencialmente ele se tornará.

Mantendo nosso software atualizado, acreditamos estar mais preparados para rapidamente absorver novas tecnologias que possam ter impacto positivo para o nosso cliente e a nossa marca, além de agilizar os processos de correções de bugs e vulnerabilidades.

Aprendizados, dicas e recomendações baseadas na nossa experiência

Por fim, deixamos algumas recomendações baseadas na nossa experiência e aprendizados para que o processo de uma atualização crítica ocorra da maneira mais suave possível:

• Pequenos passos:

Confira o changelog e se atente principalmente para as mudanças que alteram o comportamento de classes ou métodos e/ou que têm potencial para quebrar o funcionamento de parte do seu código. Se a versão do seu código tem muitas diferenças para a versão atual, faça o processo de atualização aos poucos, subindo versão a versão e realizando as alterações necessárias.

• Conte com bons testes automatizados e, se possível, ferramentas de observabilidade:

Aqui na RD, além dos testes automatizados, dispomos de testes sintéticos que monitoram o desempenho e a disponibilidade dos aplicativos, e contamos com alertas e monitoramento de erros via Datadog e Rollbar.

• Conte com o review cuidadoso do time owner da feature potencialmente afetada:

Como mencionamos, temos um time dedicado a realizar a maior parte das atualizações no projeto RD Station Marketing, mas nem sempre esse time consegue ir a fundo para compreender todas as etapas que podem ser impactadas, principalmente em relação à experiência do usuário. Por isso, tem sido crítico contar com as pessoas especialistas por domínio para a revisão do código e validação do funcionamento da feature via app.

• Dedique um tempo de qualidade para testar e validar o funcionamento da sua aplicação nos ambientes de desenvolvimento e staging:

A própria pessoa desenvolvedora é responsável por essa etapa aqui na RD. Por mais que possa parecer uma tarefa mecânica e que nem sempre está entre as atividades mais amadas pelas pessoas desenvolvedoras, testar cuidadosamente a sua aplicação pode evitar problemas futuros como rollback e o temido post-mortem de incidente.

Próximos passos

Para finalizar, destacamos que estamos sempre de olho em novos lançamentos para definir quais as prioridades de atualizações para o nosso momento na engenharia. Por mais confortável que a situação possa parecer, sempre pode surgir algo crítico que precise de atenção imediata, ou que traga algo benéfico para a nossa aplicação.

Manter ao menos 90% das dependências atualizadas, incorporar a nova versão do Ruby que vem sendo preparada e é lançada historicamente no Natal, atualizar o Rails para a última versão 7.1 e habilitar o compilador de código YJIT em produção visando melhorar a performance, são ações previstas ou que já estão em andamento nas prioridades do time kernel.

Obrigada pela leitura! E se você curte trabalhar com Ruby on Rails ou ficou curioso para entender melhor como funcionam os nossos softwares e a cultura da RD Station, dá uma olhada nas vagas abertas e vem se juntar ao time!

Co-autora: Cristhyane Araldi

Atualização do Ruby no monolito da RD Station was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Estruturar um time de Governança em Segurança da Informação e Privacidade não é uma tarefa fácil, por mais que nos dias de hoje o nível de acesso a informação, cursos e o desenvolvimento de processos e métodos na área seja de grande volume e qualidade, fazer com que esse métodos sejam “aplicáveis” na prática é um grande desafio mesmo para profissionais experientes, pois cada empresa, segmento ou produto possui um viés único.

Por esse motivo essas escolhas e esse iniciar devem estar embasados em diretrizes, suportes legais, conhecimento técnico e principalmente no estudo das características e necessidades únicas de cada contexto.

O objetivo deste artigo é falar um pouco sobre as vivências e experiências adquiridas durante o ano 1 da estruturação de uma área de Governança em Segurança da Informação e Privacidade durante a criação das áreas em uma empresa do segmento de Tecnologia e Marketing Digital.

Entender o foco da área

De forma geral a área de Governança em Segurança da Informação e Privacidade é uma vertente da área de Governança Corporativa, que tem por objetivo levar os padrões de compliance e adequação de normas, processos e procedimentos para a área específica, adicionando os fatores especialistas, neste caso, os relacionados a segurança da informação e privacidade.

A governança de segurança da informação envolve a definição de estruturas e processos que permitem a identificação e gestão de riscos de segurança, a implementação de controles de segurança apropriados, a resposta a incidentes de segurança e a conformidade com regulamentações e padrões aplicáveis. Isso inclui a definição de políticas de segurança, a realização de avaliações de risco, a implementação de controles técnicos e organizacionais, a realização de treinamentos e conscientização, e a realização de auditorias e monitoramento contínuo.

A governança de privacidade, por sua vez, está relacionada à proteção dos dados pessoais e ao cumprimento das leis e regulamentações de privacidade, como a Lei Geral de Proteção de Dados (LGPD) do Brasil. Ela envolve a definição de políticas e processos para o tratamento adequado dos dados pessoais, a obtenção de consentimento adequado, a implementação de medidas de segurança apropriadas para proteção dos dados e a resposta a solicitações e incidentes relacionados à privacidade.

A área de governança de segurança da informação e privacidade é essencial para garantir a confidencialidade, integridade e disponibilidade das informações em uma organização, bem como para estabelecer a confiança dos clientes e parceiros comerciais em relação ao tratamento de seus dados.

Muitas empresas desenvolvem essas áreas de forma individualizada, pelo tamanho do universo de atuação de cada uma delas, mas a convergência em apenas uma área também possui pontos positivos, principalmente em uma fase inicial, pois permite centrar objetivos, traçar uma operação otimizada e alinhar perspectivas que vão se tornar o cerne das áreas, dando maior potencial de crescimento partindo dos mesmos princípios e criando uma cultura de conexão e alinhamento.

Dando os primeiros passos na estruturação

Um dos primeiros pontos na estruturação é entender o modelo de negócio, perspectivas da evolução da empresa, analisar a potencial estrutura e expansão dos times de Segurança da Informação e Privacidade, para então, criar uma visão realista sobre as necessidades e a ordem de prioridade dentro de cada uma delas.

A maior parte das empresas não parte de um investimento massivo para desenvolvimento destas áreas, o habitual é um crescimento progressivo, tanto de time (número de pessoas), quanto de outros recursos como a contratação de ferramentas e a implementação de processos. Por esse motivo é importante entender junto à alta gestão a expectativa de evolução e crescimento destas áreas.

Outro ponto a se considerar é que, não é porque as melhores práticas indicam uma determinada ação, que ela será prioritária no seu contexto, cada empresa exige, pelo seu core business, um nível de maturidade em segurança da informação e/ou privacidade diferentes, uma healthtech ou fintech, terá exigências diferentes de maturidade de empresas de outros segmentos, que trabalham com outras informações, com tanto, é claro, que alguns critérios básicos, como atendimento de leis, sejam cumpridos.

Então, defina sua estratégia, comece estabelecendo os objetivos e metas da área de governança de segurança da informação e privacidade, alinhados aos objetivos estratégicos da organização. Para isso, o “não reinventar a roda” acelera o processo e reduz potenciais atritos. Olhe o planejamento da empresa, processos que já são executados e veja como o planejamento da área pode se encaixar, isso ajuda a ganhar permeabilidade e articulação para o estágio pós-estruturação.

A partir desses pontos é possível criar um belo diagnóstico de área!

Estudando modelos e métodos

Hoje em dia no mercado temos diversos modelos, métodos, processos e frameworks em segurança da informação e privacidade, um passo importante é estudar os que já são utilizados pela empresa ou ainda, caso não haja um método definido, escolher um que melhor se adeque às necessidades. Nesse ponto é importante considerar que não precisa ser aplicado o famoso “by the book”, os métodos podem ser parcialmente implementados e evoluídos de forma incremental, método bom é o método que funciona para sua finalidade!

O método (nesse contexto considerem a forma ampla, podendo ser frameworks, processos, modelos, etc.) não define a área, ou limita sua expansão, mas ele serve como um guia operacional que permite uma comparação da evolução da empresa com o mercado, com as melhores práticas e cria bases para uma posterior evolução da adequação e certificação de normas. Iniciar a estruturação das áreas e já implementar normativas, pode ser um desafio inicial grande, dependendo da maturidade de segurança da informação e privacidade da empresa, é claro que o que tiver sinergia será aproveitado e já implementado, mas o principal é a empresa estar segura!

Para empresas com um baixo nível de maturidade, muitas vezes é necessário criar uma base para depois trabalhar adequações mais complexas. Ainda assim, normas em geral são genéricas, justamente para se adequarem de forma ampla, os métodos acabam sendo mais direcionadores operacionais, ainda mais porque você pode escolher um que se adeque melhor à necessidade da sua empresa.

Depois da escolha do método, a partir da primeira análise de maturidade, que é basicamente a realização de um check list do modelo, onde são avaliados os pontos que a empresa “possui” e “não possui” ou ainda os níveis de adequação de cada item, é gerada uma nota que localiza a empresa no ponto de maturidade. A partir dos “não possui” marcados na planilha, associado aos itens de diagnóstico de área que discutimos anteriormente, você já tem belos ingredientes para um plano de ação.

Instrumentalizar é o guia

Na maior parte dos métodos, os primeiros passos de desenvolvimento da maturidade estão relacionados à criação de documentações, além de ser um passo importante também para governança corporativa e até mesmo para produtividade da empresa e organização do trabalho.

Portanto, elabore políticas e procedimentos de segurança da informação e privacidade que sejam adequados às necessidades e regulamentações da organização. Isso inclui políticas de acesso, autenticação, proteção de dados, gerenciamento de incidentes, privacidade e conformidade e documente ou crie procedimentos que já são executados.

A partir desse passo você já possui instrumentos que servirão de guia para orientar ações, indicar melhores práticas e apoiar nas execuções do dia a dia. Por mais que nesse estágio inicial, muitas vezes não seja possível garantir o cumprimento dos requisitos documentados, você terá um material básico para iniciar. Muitas vezes essas criações são mais autônomas, podem ser criadas pelo próprio time de governança, mas é claro que as demais áreas da empresa e que executarão as políticas e documentos, precisam ser envolvidas e consultadas, afinal, tem que ser exequível por elas e ao fazerem parte da criação cria-se um laço de corresponsabilidade.

Embora todas essas ações citadas sejam primordiais, o “golden step” da instrumentalização é fazer com que as pessoas criem consciência dessa responsabilidade, entramos assim na esfera que alimenta qualquer processo de mudança, a educação: pense desde o dia 0 na criação de materiais que se comuniquem com a empresa e abordem os tópicos de segurança da informação e privacidade, desde de o processo de compreensão das expectativas com a alta gestão, eduque antes de falar com eles, ensine o que é a área e qual sua importância. Aplique também nas ações de implementação com seu time, com outros times e em todo restante da vida da área. Pense materiais, crie vídeos, mesmo que caseiros para cada processo ou política que será implementada, pense em contratar ferramentas que já tenham cursos prontos sobre questões básicas ou indique materiais disponíveis online — de boa procedência é claro.

Por fim, estabeleça parcerias, a área não vive só: Colabore com outras áreas da organização, como administração, produto e engenharia, jurídico e recursos humanos, para garantir uma abordagem integrada à governança de segurança da informação e privacidade e serem aliados nos processos de implementação.

O segredo é a mão na massa!

Não é só de criar documentações e educar que a área vive! Começar a implementação nas áreas não é fácil, mas precisa ser iniciado por algum lugar, nesse momento, priorizar é fundamental!

Para priorização um ponto importante é não considerar apenas a análise técnica da área, ou o passo a passo que as boas práticas trazem, por mais que aparentem ser uma receita de sucesso com uma priorização ideal, não se esqueça, não serão elas que irão executar o planejamento e para executar precisamos considerar o que falamos no tópico de primeiros passos da estruturação, cada contexto é um contexto.

Veja seus recursos! Movimente primeiro o que tem um baixo custo de implementação e maior autonomia de decisão e execução. Depois desse primeiro passo você consegue mostrar o primeiro valor e então passa a conquistar mais recursos, sejam eles financeiros com a gestão, ou ainda, engajar pessoas a impulsionarem os próximos passos.

Alguns pontos podem servir de direcionadores quando falamos do apoio estrutural à área de segurança da informação e privacidade como um todo:

Participe da implementação de controles de segurança: Estabeleça junto ao time técnico os controles técnicos e organizacionais para proteger as informações e os dados. Isso pode incluir a implementação de firewalls, sistemas de detecção de intrusões, criptografia, implementar sistema de análise de vulnerabilidade periódica e a realização de pentestes externos. Para algumas empresas a contratação de serviços terceirizados para alguns desses pontos acaba se tornando uma estratégia interessante e o time de governança deve estar próximo também desses terceiros.

Realizar avaliações de risco: Mesmo não tendo uma área de riscos na empresa, você pode implementar uma análise de riscos de forma mais orgânica e passiva, criando um canal de comunicação com as demais áreas da empresa a fim de receber o relato de potenciais riscos. Ou ainda realizar avaliações periódicas de risco em áreas chaves para identificar vulnerabilidades e ameaças aos sistemas de informação e dados pessoais. Isso permitirá o desenvolvimento de medidas de segurança apropriadas e a priorização dos investimentos em segurança e privacidade.

Monitorar e auditar: Realize monitoramento contínuo dos controles de segurança e privacidade para garantir sua eficácia, avaliando periodicamente o nível de maturidade e certifique que nos planejamentos de segurança da informação e privacidade, está sendo colocada a intencionalidade de evolução de maturidade nos pontos críticos priorizados. Além disso, pense na coleta de indicadores, sejam eles operacionais (KPIs) que vão apontar o equilíbrio das ações ou ainda crie indicadores baseados em objetivos a serem atingidos (OKRs). Caso não seja possível realizar auditorias internas, tente contratar uma vez ao ano ou em algum momento decisivo, auditorias externas para verificar a conformidade com as políticas e padrões estabelecidos e como os passos estão sendo dados.

Finalizou? Agora é começar tudo de novo em uma nova perspectiva!

Você passa a perceber que essa fase de estruturação chegou ao fim, quando tudo que foi criado não cabe mais no modelo e você precisa expandir, o time ganhou maturidade, a alta gestão entendeu a entrega de valor, os clientes e o mercado querem mais da empresa, novos serviços e atendimentos são direcionados ao time e o foco de atuação é ampliado.

Você entende que o método selecionado já está muito genérico e você precisa praticamente de um modelo para cara frente de atuação da área. A base estrutural já está bem consolidada, com processos que “rodam sozinhos” com indicadores marcados e os times que antes “fugiam” da sua área, passam a procurá-los. Isso marca o início de uma nova e desafiadora etapa, a de crescer!

Mas é claro que tudo isso só vai acontecer se a área estiver o tempo todo em movimento, em contato com as demais áreas e a gestão, acompanhando as mudanças nas regulamentações de segurança da informação e privacidade e mantendo-se atualizada sobre as melhores práticas e tendências do setor. Isso permitirá que esses ajustes contínuos na área de governança aconteçam de forma orgânica.

Espero que esse artigo tenha colaborado no compartilhamento de experiências e que em breve possamos falar também sobre esse crescimento nas diferentes perspectivas de evolução da área!

O que aprendemos na estruturação da área de Governança em Segurança da Informação e Privacidade… was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fique tranquilo, que neste post explicaremos passo a passo, construindo uma integração do zero!

O primeiro passo é atendermos os pré-requisitos:

Conta no RD Station

Precisamos de uma conta na plataforma RD Station, afinal, a API coleta e manipula dados de uma conta na plataforma.

Pode-se utilizar a conta de um cliente ou criar uma conta trial aqui.

Se a sua integração for pública, você pode solicitar uma conta de testes aqui.

Aplicativo

Precisamos criar um aplicativo na appstore do RDStation.

Para criar esse aplicativo, precisa usar uma conta da plataforma que será responsável por esse aplicativo. Ou seja, você como techpartner, deverá ter uma conta sua no RDStation.

Para criar um aplicativo, basta logar na appstore com sua conta e clicar para criar um novo aplicativo, preenchendo os seguintes campos:

Nome: Qual será o nome do seu aplicativo?

Tipo: Seu aplicativo será privado ou público?

Categoria: Seu aplicativo se encaixa em qual categoria? Integração com CRM? Produtividade?

Idiomas do aplicativo: Seu aplicativo estará disponível para quais linguagens?

Site da empresa: Qual o site da empresa responsável pelo aplicativo?

Urls de callback: Seu aplicativo precisará ter pelo menos uma url de callback. Esta URL será utilizada no processo de autenticação.

Mais detalhes da criação do aplicativo neste tutorial da nossa seção de ajuda.

Conta na plataforma do parceiro

Estamos falando de uma integração entre 2 sistemas. Logo, além da conta na plataforma da RD Station, você precisará de uma conta na plataforma que se integrará.

Por exemplo: para utilizar uma integração com a Pluga, você precisará de uma conta na plataforma da Pluga.

Requisitos atendidos? Bora para prática!

Criando URL de autorização

Para criar esta URL, precisaremos do client_id e da URL de callback cadastradas no seu aplicativo da appstore.

Nota: A URL de callback é uma rota desenvolvida e de responsabilidade do techpartner.

Tendo essas informações, conseguimos criar a URL seguindo esse padrão:

https://api.rd.services/auth/dialog?client_id=[CLIENT_ID_APP]&redirect_uri=[URL_CALLBACK_APP]

Utilizando o aplicativo de exemplo, ficaria desta forma:

https://api.rd.services/auth/dialog?client_id=6b5f1e9a-4d58-4fee-a17b-b31fca15500d&redirect_uri=https://webhook.site/38f21196-057e-42a0-aa63-621a10bd96ed

Este será o link que deverá ser disponibilizado para os clientes que desejam integrar a sua plataforma com o RDStation.

Usuário autorizando o aplicativo

Seu aplicativo está configurado e você possui a url de integração. Bora testar?

Basta abrir a url de integração criada anteriormente, que abrirá uma tela para que o usuário do RD Station autorize seu aplicativo a acessar os seus dados da plataforma.

Neste cenário, estou logado no usuário Renan Porto; onde este deseja integrar com meu aplicativo. Esta tela permitirá que o usuário se conecte ao seu aplicativo.

Clicando em conectar, o usuário será redirecionado para a sua URL de callback:

Note que será enviado como query string um parâmetro chamado CODE, que seu aplicativo deverá salvar para utilizar na geração do primeiro token.

Nesta tela, é sugerido fazer um aviso para o cliente informando que a integração foi feita com sucesso!

Gerando o primeiro token

Usuário está integrado com seu sistema! Legal! Mas.. e aí? Quando o usuário criar um novo lead no seu sistema e você deseja criar esse lead no RD Station, como você pode fazer?

Primeiramente, temos que entender que a autorização das APIs do RD Station são feitas via tokens. O parâmetro CODE enviado anteriormente para a sua URL de callback permitirá gerar o primeiro token de acesso de seu aplicativo à conta do usuário do RD Station.

Para gerar o primeiro token, você precisará — além do CODE — do cliente_id e do client_secret do seu aplicativo. Esta informação pode ser vista no passo “Criando URL de autorização”.

Basta fazer a requisição abaixo, para gerar o primeiro token:

curl --request POST \
     --url 'https://api.rd.services/auth/token' \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "client_id": "6b5f1e9a-4d58-4fee-a17b-b31fca15500d",
  "client_secret": "2d3585f2ceba402e82d41c3a12fee3f2",
  "code": "7d63c19de92d87e44608f6e40169e106"
}
'

O retorno será algo como:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9",
    "expires_in": 86400,
    "refresh_token": "ctald8r3GFg85IIwVBalBVlg1Hh8cJ1KNinAO78uwl0"
}

*O access_token será uma string maior do que a do exemplo. Diminuímos para ficar didático.

Com este token, terás a autorização para utilizar todas as APIs disponibilizadas pelo RDStation (verificar disponibilidade da API por plano), conforme nosso portal de desenvolvedor.

Chamando a primeira API

Com o token em mãos, conseguimos utilizar todas as APIs, como dito anteriormente. Para fins didáticos, iremos pensar no seguinte caso de uso:

Os leads no nosso sistema possuem um campo que não existe por padrão no RDSM: o campo CEP. Para isto então, desejamos criar um campo personalizado no RDSM, para que possamos enviar esse campo ao criar um lead.

Para isto, iremos utilizar a API Criar Campo Personalizado. Utilizando o nosso token, fazemos a requisição conforme a documentação:

curl --request POST \
     --url https://api.rd.services/platform/contacts/fields \
     --header 'accept: application/json' \
     --header 'authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9' \
     --header 'content-type: application/json' \
     --data '
{
  "data_type": "STRING",
  "name": {
    "pt-BR": "CEP"
  },
  "label": {
    "pt-BR": "CEP"
  },
  "presentation_type": "TEXT_INPUT",
  "api_identifier": "cf_cep"
}
'

O retorno foi:

HTTP Code 201

{
  "uuid": "356d925c-ba3f-48aa-aa12-d6f6b66ebd46",
  "label": {
    "pt-BR": "CEP",
    "default": "CEP"
  },
  "name": {
    "pt-BR": "CEP",
    "default": "CEP"
  },
  "api_identifier": "cf_cep",
  "custom_field": true,
  "validation_rules": {},
  "presentation_type": "TEXT_INPUT",
  "data_type": "STRING"
}

Verificando no sistema, vemos que o campo personalizado foi criado:

E está disponível para ser cadastrado tanto via API, como na própria interface do RD Station:

Conclusão

Agora basta aproveitar todas as nossas APIs disponíveis para enriquecer a integração cada vez mais!

Autenticação APIs RD Station was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Errar é humano, mas nos dias de hoje, dependendo do contexto, errar é necessário. Não é sobre o erro pelo erro, mas pela descobertas de caminhos para fazer algo novo, que poucos ou ninguém ainda fez.

Inovação é a criação de soluções novas e criativas para desafios e necessidades, mas para chegar em uma solução final, caminhos tortuosos geralmente precisam ser percorridos e erros fazem parte do percurso. Porém onde uns vêem erros, outros veem aprendizado.

Validando hipóteses antes de investir alto

A prototipação de soluções é uma técnica fundamental em diferentes áreas, desde a construção de produtos e serviços até a resolução de problemas complexos em diferentes contextos. No livro “The Lean Startup”, o autor Eric Ries apresenta o conceito de ciclo “Build-measure-learn” como uma abordagem eficiente para a prototipação.

A abordagem de criar um Produto Mínimo Viável (MVP) permite testar rapidamente soluções com os usuários e coletar dados para análise. Com base nos resultados, ajustes e melhorias contínuas devem ser realizados, aumentando a eficiência e eficácia das soluções a cada ciclo de aprendizado. A prototipação é uma estratégia eficaz para validar ideias e reduzir riscos pois permite testar hipóteses antes de investir em soluções completas e definitivas, reduzindo tempo e custo de desenvolvimento.

Prototipação em desenvolvimento de software

Enquanto desenvolvemos software como pessoas engenheiras é normal escrevermos métodos, classes e serviços que podem ou não ser utilizados no futuro. Estamos testando a viabilidade de uma possível solução. Escrevemos, apagamos e reescrevemos o código até que o problema que estamos tentando resolver seja solucionado da maneira mais eficiente possível.

Subindo um pouco de nível, dependendo da necessidade, precisamos escrever um software ou serviço em nuvem especializado para resolver determinado problema, seja um processamento de imagem, uma análise automatizada de logs ou ainda tarefas mais complexas que podem depender de outros produtos ou serviços. Mas a pergunta que precisamos resolver ainda é a mesma: “esta proposta de solução resolve o problema proposto? E se resolve, é suficiente para validar ou refutar a hipótese?”

Prototipação no final das contas é exatamente sobre isso: validação de uma hipótese da maneira mais rápida e barata possível.

Uma necessidade de casa: inovação em ferramentas de internacionalização

Aqui na RD Station temos a missão de entregar soluções de automação de marketing digital para que nossos clientes possam vender mais e de forma mais eficiente. Temos um enorme número de clientes que já utilizam nossas soluções no Brasil, mas o potencial do mercado internacional ainda é imenso.

Para que nossos produtos sejam internacionalizados de forma apropriada e escalável, precisamos prover ferramentas aos demais times da RD Station para que estes possam desenvolver nossos produtos e soluções já pensando no mercado internacional. É o que chamamos de “global first”, e atualmente nossos produtos devem estar disponíveis nos idiomas Português, Inglês e Espanhol.

Para que este objetivo seja cumprido, não podemos usar textos fixo nas nossas telas, precisamos usar chaves de tradução que serão substituídas em tempo de execução pelo respectivo texto no idioma escolhido pelos nossos clientes nas configurações do sistema.

Validando uma necessidade real

A provocação que nos fez pensar fora da caixa foi “eu como gestor quero saber qual o percentual de internacionalização das nossas plataformas”. A nossa primeira pergunta foi: “e isso é pelo menos possível?”. Mas de acordo com Walt Disney, "se você pode sonhar, você pode realizar", e assim partimos para a validação da hipótese.

A grosso modo pensamos em uma rotina que rodasse no nosso ambiente de integração contínua (CI) que verificasse automaticamente se algum texto foi inserido diretamente no HTML das nossas telas ou se foram usadas chaves de tradução. Cada vez que encontrássemos um texto fixo em Português do Brasil (“pt-BR”), precisaríamos saber qual foi o projeto que gerou este débito técnico e registrar essa informação para futuramente auxiliar os times a resolver essas questões.

Já tínhamos uma rotina que fazia esta checagem de strings “hard coded” usando regras do ESLint. O que precisávamos agora era que esses warnings fossem mandados para um banco de dados (ou quase isso 😎).

Olhando para o custo de uma instância de banco de dados no nosso serviço de nuvem, a complexidade de manutenção de um banco de dados e mesmo a necessidade de um banco de dados (ainda estamos na fase de validação da hipótese, lembra?), contra o custo financeiro zero de armazenar essas informações em uma planilha do Google Sheets, não tivemos muita dúvida. Vamos validar a hipótese da forma mais enxuta e rápida possível, e a nossa arquitetura inicial ficou mais ou menos assim:

Basicamente nosso MVP rodava no CI existente que já executava os passos de checagem sempre que um novo commit era feito em determinada branch. Assim, colocamos mais um passo no nosso CI para que os warning de internacionalização fossem gerados. Implementamos um pacote Node.js que era chamado em um step seguinte à geração dos warnings no CI, e que postava esses warnings para a API do Google Sheets. E uma vez que os dados brutos eram inseridos na planilha, poderíamos agregá-los da melhor forma para transformá-los em inteligência de negócio.

Nossa primeira hipótese foi validada, e sim, conseguimos inferir o percentual de internacionalização de um projeto de forma automatizada! 🎉

Coisas que a vida nos ensinou no processo

Um MVP serve pra validar a hipótese, dizendo se aquilo que se está testando é ou não viável. Um MVP não deve ser considerado como o produto final.

Você descobrirá o que fazer enquanto estiver fazendo. Não existe um processo rígido de especificação, depois validação, depois codificação e depois testes, assim de forma linear e imutável. As vezes implementamos um código em um dia pra jogar fora em outro, absorvendo apenas o conhecimento daquele processo. Precisamos falar com pessoas, entender de negócio e manter muito claro o objetivo final do experimento. Lembre-se de que você está buscando um fim, e não um meio.

Erre rápido, aprenda rápido. No momento da prototipação sua solução não precisa ser a mais rápida ou escalável, ela precisa validar uma hipótese de forma rápida e barata. Se alguma parte da implementação do MVP estiver dando muito trabalho, é possível que você esteja fazendo algo além do necessário. Banco de dados pode ser substituído por planilhas ou arquivos texto; uma tela de formulário a ser desenvolvida pode ser substituída por um Google Forms; a implementação de um serviço pode ser substituído pro chamadas à APIs. Apaixone-se pelo problema, não pela solução.

Evite overengineering a todo custo. Lembre-se que o que você está construindo é um estudo de viabilidade, não um produto final. Quanto mais complexa for a solução, mais tempo será necessário para encaixar novas funcionalidades a ela.

Pense na arquitetura do MVP de forma modular, onde peças de funcionalidade possam ser encaixadas, "plugadas", onde a saída de processamento de uma "peça" seja a entrada de dados da próxima peça. Assim melhorias podem ser aplicadas localmente sem impactar tanto nas demais funcionalidades.

Quebre problemas grandes em problemas menores, e resolva um dos problemas menores por vez.

Ferramentas para prototipação

Dependendo da necessidade, algumas ferramentas serão mais adequadas que outras. Mas determinadas ferramentas tem um uso genérico e podem ser utilizadas pra resolver uma gama maior de problemas.

Desenvolvida pensando em IoT mas podendo ser utilizada para outras finalidades, o NodeRED é uma ferramenta de prototipação baseada em fluxos, onde a saída (output) de um processo é a entrada (input) para o próximo processo.

Esse fluxo acima exemplifica a facilidade de criar um MVP de um formulário de captação de leads, onde o usuário informa nome e email. Ao clicar em enviar é mostrada uma mensagem de confirmação visual, e ao mesmo tempo é iniciado o fluxo de registro. No fluxo acima, caso o email fornecido já exista na "base de dados" é enviado um email de boas vindas, e caso ainda não exista na base, o lead é registrado e em seguida o email é enviado.

Simples assim, MVP feito em pouco mais de 10 minutos e (quase) sem código!

Resumindo

Prototipação é uma abordagem valiosa para validar hipóteses, explorar soluções viáveis e aprender rapidamente ao longo do processo de desenvolvimento de software. É essencial apaixonar-se pelo problema em vez de se apegar excessivamente a uma solução específica. Ao adotar uma abordagem modular e quebrar problemas complexos em partes menores, é possível alcançar resultados mais eficientes e evitar o “overengineering”. Ao abraçar a mentalidade de aprendizado contínuo e priorizar a validação rápida das hipóteses, as pessoas engenheiras de software podem impulsionar a inovação e obter insights valiosos para o desenvolvimento de produtos mais robustos, inteligentes, inovadores e eficazes.

Happy prototyping! 😉

Impulsionando a Inovação: A Importância da Prototipação e Validação Rápida no Desenvolvimento de… was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Há várias formas de evoluir suas habilidades comportamentais relacionadas à liderança, sendo participar de programa de mentoria uma forma muito efetiva de evoluir na prática.

Enquanto participando do programa de mentoria da RDStation com a temática de metodologias ágeis, tive a oportunidade de aplicar um pouco do meu conhecimento e ajudar minha mentorada da área de savers, responsável por resgate de alguns clientes que estão em via de cancelar o produto ou inadimplentes, adquirir mais conhecimento e conseguir aplicar com sabedoria em sua rotina de trabalho.

Um aspecto importante do programa de mentoria, que vale ressaltar, é que ele vem para prover um ambiente seguro entre uma pessoa mentora e uma pessoa mentorada para a troca de conhecimento e evolução bidirecional.

O início de uma mentoria

A seguir, descrevo um pouco de como busquei conduzir a mentoria que dei, vale ressaltar que não é uma forma certa ou errada, é apenas a forma como eu me senti a vontade em repassar o conhecimento da melhor forma possível.

• Comecei com uma reunião de onboarding, trazendo um pouco do conhecimento que tenho a respeito da temática da mentoria focando em 3 princípios:

1. A importância de um fluxo de trabalho bem definido dentro de um sistema Kanban;
2. Qual o papel do quadro Kanban, como meio de visualização em tempo real do que está sendo feito;
3. Limitação da carga de trabalho por colaborador, buscando a criação de um ambiente sustentável e saudável.

• Tendo apresentado uma introdução, pedi para minha mentorada me explicar um pouco do fluxo de trabalho em seu dia-a-dia, para que com isso eu conseguisse estruturar um conteúdo melhor direcionado à sua realidade, onde ela me trouxe os seguintes aspectos de sua rotina:

1. O time possui uma cerimônia semanal, onde são apresentados os resultados, discutidas métricas relevantes ao time, e levantados pontos de melhoria, bem como validado se algum membro do time está precisando de algum apoio;
2. Tendo formação em licenciatura, tem como forma de aprendizado preferida por meio de livros, tendo uma motivação maior quando vê uma aplicação prática daquilo que está lendo;
3. Com isso, conseguiu observar pontos de melhoria na documentação apresentada semanalmente, e já vinha fazendo um trabalho de tornar a forma de conduzir a reunião mais atrativa, fazendo com que o restante do time ficasse cada vez mais engajado por meio de melhorias na diagramação do conteúdo apresentado.

A condução de uma mentoria

Estando claro para ambas as partes, tanto os conceitos relacionados à temática da mentoria, bem como o estado atual do processo e pontos de melhoria, partimos então para o mão na massa, que seriam as sessões da mentoria focando em 3 aspectos principais:

• Desde a última mentoria, como você está e o que foi feito nesse intervalo de tempo?
• Apresentação de um conceito relacionado ao momento atual, que pudesse ser útil;
• Repasse de material de suporte para alguma prática a ser realizada entre os intervalos de mentoria.

Um aspecto muito importante, que eu não devo deixar de comentar, é a cadência das reuniões, no meu caso foram feitas de 15 em 15 dias, sendo que o principal cuidado que deve-se ter é o seguinte:

“O intervalo entre mentorias não deve ser nem tão pequeno que a pessoa não consiga aplicar na prática e nem tão grande para garantir que a pessoa tenha insumos suficientes para serem consumidos em uma janela de tempo não maior do que 1 hora.”

Um ponto importante no fechamento de uma mentoria, é garantir que este seu tempo com sua pessoa mentorada tenha sido produtivo para ela, no meu caso acredito termos conseguido alcançar um objetivo, pois a minha mentoria gerou os seguintes resultados para a minha mentorada:

• Como savers, cada membro do time tem uma carteira de clientes a cancelar e/ou inadimplentes e, para gerir o seu tempo e sua produtividade, a minha mentorada criou uma planilha para gerir a média de clientes atendido por ela diariamente;
• Para realizar a prova de conceito, ela apresentou essa planilha atuando como mentora, onde teve o feedback que seu mentorado melhorou sua gestão do tempo e produtividade com uso desta planilha;
• Estando a frente de ações de melhoria do processo do time, ela trouxe os resultados para discussão com sua liderança direta para aplicar em seu time todo.

O que aprendi como mentor

Este artigo teve como propósito relatar a minha experiência como mentor, para que possa auxiliar outras pessoas também a entender a importância de estar participando de programas de mentoria, seja na sua empresa ou online como meio de crescimento pessoal e profissional.

Finalizo, deixando aqui algumas conclusões minhas com base na experiência que tive:

• Em uma mentoria, tu não é líder de outra pessoa, seu papel é entender a realidade de outra pessoa e trazer suas experiências como provocações para o seu crescimento, bem como seu conhecimento em cima de determinada temática;
• Suas vivências não são para criar estratégias diretas, mas sim para trazer provocações para a pessoa mentorada;
• Não se envolva em nenhum momento diretamente com o processo e fluxo de trabalho, seu papel não é mudar algo no processo, mas sim auxiliar a pessoa mentorada, evitando ao máximo opiniões pessoais que não sejam condizentes ao momento.

Fica aqui o meu muito obrigado pelo seu tempo de leitura e, se ficou interessado em viver esse tipo de situação na prática, sinta-se à vontade para se candidatar em algumas das vagas abertas aqui na RDStation:

https://grnh.se/d56f9b722us

O papel da mentoria na evolução profissional e pessoal was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine você num carro com sua família e duas crianças no banco do passageiro. Você estão viajando e a viagem demorará cerca de 4 horas. Uma das crianças se entretem com seu celular e se dá por satisfeita quando a mãe se vira e diz “Pronto, já chegamos filho”.

Já a outra criança pergunta, a cada 5 minutos, “nós já chegamos? já chegamos? já chegamos?”. Ela precisa de uma resposta constante para seu questionamento, e só para de perguntar quando a resposta a satisfazer, ou seja, ela só vai parar quando a mãe virar e dizer “já chegamos!”.

A criança impaciente é uma analogia para uma polling.

Às vezes, quando escrevemos um código, não podemos ficar presos a uma execução específica (como no caso das funções assíncronas). Precisamos seguir em frente independente do resultado daquele retorno. Mas, em alguns casos, precisamos ficar perguntando o resultado daquela função até que ela retorne algo diferente e, então, execute algo diferente.

Isso são pollings.

Vamos então transformar esse exemplo num caso que trabalhei aqui na RD:
Em uma de nossas ferramentas utilizamos a API do github, e utilizamos algumas informações encontradas no body do retorno da requisição. Nesse body temos o atributo mergeable, que denuncia se o PR em questão é mergeável ou não. Ele retorna os valores true ou false, mas ele também retorna null .

Nós tínhamos apenas tratado os casos em que o retorno do atributo fosse true ou false , ignorando o null , até que né, começou a dar ruim.

Quando o atributo retornava null todo o processo parava e dava erro. Fomos pesquisar e entendemos através da documentação que o atributo fica nulo devido à falta de interatividade no PR.

Decidimos então criar uma polling, que, dentro dessa checagem (se o PR é mergeável), fica perguntando: “o atributo body.mergeable é null?” Caso a resposta seja positiva, chama a função da polling novamente, que faz a requisição e volta a perguntar: “o atributo body.mergeable é null?”, e assim continua até o resultado ser true ou false .

No nosso caso, se o atributo for true, nossa promise se resolve, e, se for false , uma mensagem de erro é retornada:

“Seu pull request tem conflitos com a master. Você deve resolvê-los.”

checkIfPRIsMergeable(repositoryName, prNumber){
    const path = `repos/${repositoryName}/pulls/${prNumber}`;

    return new Promise((resolve, reject) => {
      const _performPollingCheck = () => {
        octonode.get(path, (err, status, body) => { // aqui fazemos a requisição

          if (err || status !== 200) { // aqui ele rejeita a promise e retorna um erro pois o status é diferente de 200
            return reject(new Error(`Não foi possível verificar o status de mergeabilidade do seu pull request.`));
          }
          if (body.mergeable !== null) { // aqui ele resolve ou rejeita a promise caso o atributo seja diferente de null
            return body.mergeable ? resolve() : reject(new Error(`Seu pull request tem conflitos com a master. Você deve resolvê-los.`));
          }
          
          delay(() => _performPollingCheck()); // aqui ele performa a polling de novo caso não haja quaisquer dos retornos acima
        });
      };
      _performPollingCheck(); // aqui ele executa a função
    });
  }

Podemos comparar a criança maior — que se mantém quieta durante o percurso e se contenta com um “já chegamos” ao final, com um interrupt . Mas isso já assunto pra um próximo artigo!

Gostou? Não gostou? Deixe sua opinião para que eu possa melhorar :)

Polling — a criança impaciente was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

os desafios de uma liderança técnica

No último ano eu assumi a posição de Tech Lead dentro da RD Station. Nesse artigo eu vou contar algumas coisas que eu aprendi (e outras que eu consolidei) vivendo diariamente nessa função.

Eu não vou entrar em definições desse papel aqui, pois já existem diversas abordagens e explicações a respeito (vou deixar alguns links no final) além de variar entre cada empresa. Meu objetivo nesse texto é trazer algumas provocações para te tornar um Tech Lead melhor, pois essas provocações me ajudaram a crescer ao longo do ano passado.

Você é um líder

Um papel de liderança não é sobre poder, mas sobre responsabilidade. Seu time é sua responsabilidade. Não me entenda mal, no caso de um Tech Lead não estamos falando especificamente de gestão, mas é importante ter clareza de que, em um time onde as pessoas não estão bem, não vai ter habilidade técnica que faça seu time gerar valor para ninguém.

Se você não se enxerga como um líder, vai deixar a desejar nesse quesito, deixar de estudar e crescer como um líder. Não cometa esse erro.

Como destaque eu deixo duas habilidades a serem olhadas com carinho nesse papel: a influência e a delegação.

Essas duas habilidades vão te ser fundamentais para evitar que você tenha que estar presente a todo momento.

Exemplo prático: ao longo desse último ano, eu tive oportunidade de entender mais sobre as habilidades que meu time tinha, e pouco a pouco deixar de resolver as coisas para delegá-las para cada um deles. Em vários casos a resposta mais rápida seria eu ir lá e executar, mas isso ia roubar duas coisas: meu foco em outra atividade e a oportunidade do meu time crescer junto comigo. E se no final, eles não conseguirem resolver, eu estava pronto pra ajudar (não é de largar não viu?)

Liderança pelo exemplo

Eu repito isso praticamente todas as semanas: você precisa liderar pelo exemplo.

As palavras são baratas, qualquer um pode juntar um punhados delas e construir um discurso (se ele vai ser bom é outra história).

Mas o que você faz é o que conta.

Você quer que seu time entregue com mais qualidade? Revise a qualidade com que você está entregando.

Quer que eles escrevam mais testes? Escreva mais testes com eles. Ensine-os como testar melhor.

Aqui eu tenho dois exemplos práticos:

Antes de virar oficialmente o Tech Lead, eu tinha o hábito de mergear alguns PRs sem pedir revisão do restante do time. Como eu poderia cobrar isso do meu time se eu não fizesse?

Então hoje eu simplesmente não faço mais, sem exceções (mas a zueira será eterna com a Paula que odeia que eu faça isso haiahua)

O segundo exemplo tem a ver com documentação. Essa é uma prática pela qual eu tenho muito apreço. Durante o ano, por diversas vezes eu me esforcei por cobrar e executar mais documentações, por revisar as que o time fez, dar feedback, elogiar, estar presente nesse assunto. Isso inclusive levou nosso time a ter um Tech Writer.

Se eu puder resumir: não seja um hipócrita

Multiplicação de valor

A senioridade na minha carreira veio com um plot twist com o qual eu não contava: meus líderes não esperavam que minhas entregas fossem apenas relacionadas a escrever código.

E isso sem dúvida nenhuma cresceu ainda mais agora que eu estou no papel de um Tech Lead. A execução não é onde eu posso gerar mais valor.

Não estou dizendo que você precisa parar de escrever código, é longe disso (eu pessoalmente gosto muito), mas o balanço entre a execução e o estratégico ganha maior destaque. Seu papel passa a ser multiplicar o valor que seu time entrega.

Usar o seu conhecimento para guiar seu time de forma que eles consigam ter mais impacto, errar menos e crescer mais.

Isso pode se desenrolar através de revisão de código, construção de prioridade na hora de atacar as dívidas técnicas do produto, escrever documentação e muitas outras coisas. Tenha em mente que você precisa gerar valor através do seu time.

Aqui tem um ponto que eu sempre gosto de dizer: eu permito que meu time erre num espaço controlado (e seguro). Às vezes, aquela solução não é a melhor, mas ela carrega um aprendizado. E experiência vem de se experienciar, então cuidado para não virar a mãe coruja 🦉. Aqui vale um destaque até para uma estudo que o Google fez e constatou que equipes de alta performance tem um espaço seguro para cometer erros (e aprender)

Não é sobre fazer, é sobre ensinar

Outra coisa que eu digo sempre pro meu time: eu não dou respostas prontas.

Na verdade, eu digo isso para todo mundo que já aprendeu comigo. Na terapia eu descobri que o meu método de ensino tem uma base na maiêutica , que resumidamente consiste em perguntar ao invés de responder. Isso tem seu nível de frustração envolvido, mas eu acredito que no longo prazo constrói um conhecimento (e uma atitude) que torna a pessoa um indivíduo melhor.

Mas porque eu acredito que isso é importante para um líder técnico?

Porque em muitas situações o caminho mais fácil é executar, ou simplesmente dar a resposta. Existem situações em que isso é necessário, como em um incidente, mas no dia a dia isso pode ser prejudicial, pois vai criar uma dependência do seu time em você.

Prepare seu time para executar num nível de excelência mesmo que você não esteja presente.

Achar o balanço certo entre a entrega de valor e o crescimento do time é essencial, tanto para que a equipe consiga encarar cada vez desafios maiores, quanto para que você possa preparar seu time para assumir seu papel (o que permite que você assuma novos papéis).

Outro aspecto que eu aprendi a ter cuidado é em dividir coisas que eu sei com meu time. Desde conhecimento específico como kubernetes até em como revisar um PR (mérito para o meu grande Team Lead Almeida que levantou essa bola).

Eu já falei sobre ilhas de conhecimento, é importante que vocês estejam atentos a isso.

À procura do desafio certo

Alguns anos atrás eu li o livro Engajamento, do Rogério Chér, e nele eu aprendi um conceito que é chamado de estado de flow.

De maneira simples, o estado de flow é aquele momento que você “se perde no tempo” de tão envolvido que está numa tarefa.

Mas o que eu realmente quero chamar atenção é o gráfico que sempre vem acompanhado desse conceito, que fala da relação desafio x habilidade

Eu já mostrei esse gráfico pelo menos uma vez para todo mundo do meu time, pois eu acredito que ele está intimamente relacionado com um dos meus deveres dentro do time.

Conhecer as habilidades de cada indivíduo vai me permitir ajudar essa pessoa a atuar em algo que não seja nem fácil de mais, nem difícil demais. Só o suficiente para que essa pessoa tenha espaço para crescer. E quando ela cresce, o desafio aumenta.

Quando eu erro nessa etapa, as pessoas vão invariavelmente ficar na linha do tédio (fácil demais) ou na ansiedade (difícil demais).

E acredite, você vai errar. Então estar atento e escutar as pessoas vai te ajudar a corrigir isso e aprender mais sobre seu time.

Claro, existem situações que não tem o que fazer de fato: Tem a tarefa fácil demais que precisa ser feita, ou um problema que é complicado. Faz parte do trabalho (se só tivesse coisa legal ia ser diversão, não trabalho né?)

Explicar, mostrar, corrigir, repetir

Ajudar pessoas a se desenvolverem passa por um processo repetitivo, onde você explica um conceito (como fazer card X), você mostra como isso pode ser feito (esse PR faz X), você corrige (deixei um Review no seu PR) e começa tudo de novo (às vezes até para o mesmo conceito). Repetição é parte do processo de aprendizagem.

Se você já trabalha com seu time a mais tempo, isso tem uma velocidade maior, pois você já sabe que eles conhecem certas coisas, e que não sabem outras.

E esse feedback os ajuda a ter mais confiança, pois eles têm alguém mais experiente olhando e dando um selo de confiança, por isso é importante você também falar sobre os acertos e não só sobre os erros. Aqui fica inclusive a recomendação do Conventional Comments (que a grande Marcela Sisiliani me apresentou) que ajuda muito a alinhar comunicação nas revisões de código.

Um dos meus atuais desafios é entender onde as habilidades de cada integrante do meu time estão concentradas. Essa pessoa conhece mais dessa linguagem? Dessa tecnologia? Desse framework? Compreender isso me ajuda a combinar as tarefas para permitir que pessoas aprendam mais e que as que conhecem o assunto possam passar esse conhecimento adiante. E quando ninguém sabe? Ai eu tenho que ensinar (mesmo que eu não saiba também XD)

Um exemplo prático: Ano passado nós começamos a trabalhar com o Backstage na empresa. Minha expertise não era tão profunda em Typescript, React e outros componentes que envolvem o front dessa aplicação. Ao mesmo tempo que eu quebrava tarefas para o meu time executar e entender mais sobre a arquitetura do Backstage em si, eu aprendia o suficiente sobre o ecossistema para me permitir dar bons feedbacks e orientações sobre como e onde eles podiam fazer algo.

Comunicação, Alinhamento e Comunicação de novo

Um aprendizado poderoso na minha carreira que ganhou destaque para mim esse ano foi o alinhamento de expectativas e a comunicação constante.

Eu já falei que não acredito em coisas óbvias, mas quero destacar o quão importante é o alinhamento. Em muitos cenários, você acaba chegando em uma conclusão e deixa de comunicar ela para os envolvidos. Isso gera ruído, porque você espera algo, ou alguém espera algo de você, que não vai acontecer.

Por diversas vezes eu fazia questão de ressaltar o alinhamento que eu tinha feito, para que diversas pessoas estejam na mesma página. Além disso, comunicação constante.

E comunicação não é micro-gerenciamento tá? Não usa comunicação como desculpa pra isso.

Dois exemplos do meu dia-a-dia: Em um projeto que estávamos trabalhando envolvendo dois times, eu sempre deixava no canal público o alinhamento que eu tinha feito com as lideranças sobre os passos que íamos seguir. Isso deixava todo mundo na mesma página e abria espaço para questionar caso algo estivesse estranho.

Outro cenário foi o da daily: Nosso time é totalmente distribuído e por vezes a daily era nosso ponto central de alinhamento. Mas e se alguém faltar? Filhos, médicos, internet, são muitos os imprevistos que podem fazer alguém precisar não estar presente nesse momento. Nossa alternativa foi deixar no canal do time um alinhamento sobre os combinados que fizemos, principalmente nos casos em que alguém não estava presente. E se a gente esquecer, a pessoa que faltou cobra a gente.

Conclusão

O ano foi intenso, mas duas coisas eu vi acontecer: meu time entregou MUITO e cresceu MUITO ao longo dele. Eu tive a oportunidade de falar e aprender com outros Tech Leads, de aprender com meu time e com meu líder como estar nesse papel.

Você deve ter reparado que ao longo desse texto eu não falei praticamente nada sobre aprender e aprimorar novas habilidades técnicas e o motivo é simples: eu não acredito que isso é o mais importante.

“Quer dizer que o Tech Lead não precisa ter habilidade técnica?”

Longe disso, precisa ter muita. Um exemplo trivial é que ao longo do ano passado, enquanto eu aprendia tudo isso que eu falei ali em cima, ainda tirei a minha certificação da CKA (depois de estudar muito).

O meu argumento é que ao longo da nossa carreira técnica, nós focamos em aprender e desenvolver as habilidades específicas a tecnologia, mas deixamos de lado as famosas “ Soft Skills” e quando você assume um papel de líder elas são essenciais e quanto menos você tiver delas, mais complicada sua vida vai ser. Então tem que correr atrás das habilidades comportamentais E da sua habilidade técnica.

Um exemplo prático, esse ano eu vou assumir um novo desafio envolvendo duas coisas que não são parte da minha expertise: novas tecnologias (React por exemplo) e um contexto de negócio novo ( CRM).

Não significa que eu não saiba nada desses dois itens, mas eu vou precisar colocar mais energia para aprender e me aprimorar nesses contextos. Ao mesmo tempo, o último ano foi mais intenso no aprendizado das habilidades comportamentais que eu vou precisar bastante no novo desafio: delegação e influência, então eu posso colocar menos energia nessas duas habilidades.

Claro que achar o balanço disso vai ser novamente um desafio, mas aí que está a graça: continuar crescendo, como profissional, como pessoa, como Tech Lead.

Eu vou deixar uma lista de referências abaixo, inclusive uma live que eu fiz tempos atrás falando disso (na época eu nem me imaginava nesse papel).

E se você quiser vir trocar uma ideia sobre, só me chamar no Linkedin :) (pode demorar mas eu respondo todo mundo)

Referências:

• Team Lead ou Tech Lead — Liderança na tecnologia
• What is a lead developer? A leader amongst their peers
• Things they didn’t teach you about Software Engineering
• GitHub — gabiduarte/awesome-techleads: Uma lista selecionada de conteúdos sobre liderança técnica, com preferência em conteúdos em português
• O Que Faz Um(A) Tech Lead? by Cabeça de Lab
• Talking with Tech Leads (aka How To Become a Tech Lead)
• The Definition of a Tech Lead
• (Online Course) Shortcut to Tech Leadership: Accelerate Your Journey From Maker to Multiplier (Eu não fiz esse curso, só assisti muitos vídeos do Patrick)
• Talking with Tech Leads — Patrick Kua (Ainda não terminei de ler, são várias entrevistas com Tech Leads. Tem sido legal até onde eu li)
• Guides for reaching Staff-plus engineering roles — StaffEng (O site eu já li tudo, o livro ainda não. Mas é bem legal)
• When It Comes to Communication from the Top, Less Isn’t More | Stanford Graduate School of Business
• Kind Engineering

Tech + Lead was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.

Alan Turing, considerado o pai da Inteligência Artificial, foi perseguido pelo fato de ser homossexual. A primeira pessoa programadora de computadores da história foi Ada Lovelace, uma mulher. O maior jogador brasileiro da história do futebol, Pelé, era negro. Richarlyson, ex-jogador que recentemente assumiu ser bissexual, mesmo sendo titular e fundamental em uma das épocas mais vencedoras da história do São Paulo, era o único jogador que não tinha seu nome gritado pela torcida por suposições de que ele não era heterossexual. Na música, podemos citar Renato Russo e Freddie Mercury.

Felizmente, todas essas pessoas puderam compartilhar seu talento, mas a diferença é que precisaram ter grande resiliência para mostrar seus trabalhos. Turing, mesmo setenta anos após sua morte, ainda tem grande influência no ramo.

Mas, e se por uma questão puramente de preconceito, Turing e tantas outras pessoas não pudessem compartilhar seu talento?

Imagine agora quantas pessoas não conseguem superar essa barreira e não podem contribuir para um mundo melhor. Imagine quantas músicas deixamos de ouvir, quantos jogadores deixamos de assistir e o quanto o mundo não se desenvolveu por esse preconceito. A ideia deste artigo, inclusive, é mostrar a correlação existente entre o desenvolvimento de um país e os índices relacionados a direitos humanos e minorias. Poderemos ter uma ideia do quão importante essas pessoas são no desenvolvimento de uma nação.

Foram capturados 32 arquivos do site Our World in Data, contendo diversos indicadores socioeconômicos para as análises.

Desigualdade de Gênero

O machismo ainda é um problema mundial. Na Copa do Mundo de futebol masculino, no Qatar, os países do Oriente Médio ficaram em evidência e o Irã foi destaque na mídia pelo fato de ainda proibir a entrada de mulheres no estádio. Também não é novidade que as mulheres recebem no Brasil, em média, um salário menor em comparação aos homens atuando no mesmo cargo e a liderança das empresas ainda é majoritariamente masculina.

Essa diferença, no entanto, é maior em lugares mais pobres, mais corruptos, com qualidade de vida mais baixa, com baixa escolaridade e até QI médio inferior.

O primeiro gráfico abaixo mostra a relação entre Índice de Desenvolvimento Humano (IDH) e o Índice de Desigualdade de Gênero (GII). A correlação existente entre esses dois índices, em módulo, é de 0,91, representando uma correlação muito forte. Os cinco países com os melhores índices relacionados a desigualdade de gênero (Suíça, Dinamarca, Suécia, Países Baixos e Bélgica) foram destacados em vermelho e estão entre os países com maior IDH do mundo. Noruega, Finlândia, França, Islândia e Eslovênia, países que fecham o top-10, também possuem um índice elevado - todos acima de 0,9. O Brasil, para efeito de comparação, está destacado com a cor verde.

O mesmo vale para o indicador de corrupção. A correlação entre os índices é de 0,75:

E abaixo temos a relação entre o GII e indicadores voltados à educação (média de anos de estudo), e inteligência (QI), evidenciando o mesmo comportamento:

Racismo

Mensurar a tolerância racial de um país é mais difícil quando comparamos com outros índices. No caso da desigualdade de gênero, podemos comparar o salário médio por hora entre homens e mulheres do mesmo cargo, por exemplo. Podemos dizer que um indicador que mensura o racismo é mais subjetivo, uma vez que existem diversas formas de ele existir e é possível que uma pessoa ou grupo social não tenha problemas com uma raça X, porém é intolerante a uma raça Y. Além disso, uma vez que a maioria das pessoas entrevistadas tem a consciência de que o racismo não é aceito na sociedade atual, pode ser difícil afirmar que todos estão sendo honestos. Para tentar minimizar esses problemas, o índice consiste em uma série de perguntas ou afirmações como: “Um país é mais forte quando é mais racial e etnicamente diverso”.

Sabendo disso, vamos às análises. Podemos observar que, apesar de a correlação com os indicadores socioeconômicos ser mais baixa quando comparada à desesigualdade de gênero, ainda é bem perceptível. Nesse primeiro gráfico, temos um índice, o Happiness Index, que mede o quanto as pessoas se sentem felizes no país em que vivem.

Os países com o menor índice de preconceito estão novamente destacados em vermelho: Países Baixos, Canadá, Nova Zelândia, Suécia e Dinamarca. Esse grupo também faz parte dos países em que as pessoas se sentem mais felizes no mundo. O único país que passa o valor 7 no índice de felicidade e possui um alto índice de racismo é Israel.

Em seguida, podemos analisar outros indicadores relacionados ao desenvolvimento em educação: expectativa de anos de estudo e o total gasto pelo governo em educação, em percentual do PIB, entre 2013 e 2018. Destaque para a Austrália com quase 22 anos de estudo esperados (o ponto azul mais acima no gráfico à esquerda), enquanto os nórdicos Noruega, Suécia e Dinamarca gastaram quase 8% do PIB. Todos esses países listados estão entre os países menos racistas do mundo.

LGBT+

Outra relação que pode ser feita é entre a legalidade do casamento homossexual com alguns desses indicadores já mencionados aqui, e nesse caso a discrepância é bem alta. Foram três categorias analisadas:

• Casamento entre pessoas do mesmo sexo é legalizado
• Casamento entre pessoas do mesmo sexo é ilegal
• Somente alguns direitos entre casais do mesmo sexo, o que significa dizer, nesse estudo, que os países dessa categoria permitem que casais do mesmo sexo realizem uniões civis, mas não se casem. Alguns exemplos são República Tcheca, Croácia, Itália, Grécia e Hungria.

Quando analisamos a média do IDH por categoria, vemos que o número entre lugares em que o casamento é legalizado é bem mais elevado do que países onde é ilegal, representando um IDH médio de um país subdesenvolvido (0,68). Para se ter uma ideia, países como Venezuela, Iraque e Nicarágua têm um índice próximo a esse valor. Itália, França e Espanha são exemplos de IDH próximo a 0,89.

Além disso, os países onde o casamento é ilegal representam, em média, uma taxa de pobreza três vezes maior do que a média de países onde o casamento é legal. A receita mediana, convertida em dólares, também é bem maior nestes locais:

No setor de educação, o QI em países com casamento legal é 20% maior, enquanto o tempo médio de estudos é quase 50% mais elevado.

Quando impedimos e restringimos uma pessoa apenas por sua raça, cor, gênero ou orientação sexual de viver bem e mostrar seu trabalho, também estamos impedindo o desenvolvimento econômico, de uma empresa ou de um país inteiro. Seja qual for a causa e qual for o efeito, fica claro que os países com os melhores indicadores de qualidade de vida também são aqueles que mais se preocupam com o bem-estar da sociedade.

A RD se preocupa muito com esse assunto e está sempre em busca de lutar contra o preconceito, e por isso temos várias oportunidades abertas, exclusivas e afirmativas. Essas e outras vagas, você encontra aqui!

Todos os gráficos foram gerados em Python e você pode encontrar o código e todos os arquivos aqui no meu repositório do Github.

Referências

• https://ourworldindata.org/
• https://g1.globo.com/dia-das-mulheres/noticia/2022/03/08/mulheres-ganham-em-media-205percent-menos-que-homens-no-brasil.ghtml

Como o preconceito e o desenvolvimento socioeconômico de um país estão relacionados was originally published in Ship It! on Medium, where people are continuing the conversation by highlighting and responding to this story.