O que é ser um arquiteto de sistemas na prática - um exemplo em Gestão de Performance
Muitos conteúdos falam sobre o RH sair da postura de servidor/fazedor e adquirir um lugar como arquiteto de sistemas de organizações. Mas na prática, como isso funciona? O termo é lindo. Mas sabemos que temos demandas no dia a dia que são operacionais, pesadas, e que já existe muito histórico pronto.
No meu artigo sobre como usamos IA para nos apoiar com pesquisas de clima na Blip, um dos elogios que mais recebi foi ter um passo a passo claro, sem floreio. Esse artigo estava “na gaveta” há algum tempo, pois a minha intenção inicial era escrevê-lo “quando o processo terminasse". E aí me dei conta de que é uma história sem fim.
O grande desafio que tive na Blip
A Blip, empresa em que eu trabalhei por quase 4 anos como Diretora de RH, teve um desafio grande: cresceu mais de 200% em headcount em poucos anos. Adquiriu duas empresas, uma delas internacional. Atravessou a pandemia e agora tinha líderes e alguns times em modelo híbrido, no Brasil, México e Espanha. Estávamos vivendo evolução em tudo: cultura, modelo de negócio, design organizacional, produto, modelo de gestão.
No meio disso tudo, perdíamos talentos-chave. E quando olhávamos para os dados, a resposta que esperávamos encontrar não estava lá: promoções e aumentos não estavam segurando as pessoas. Nosso eNPS oscilava, mas não nos dizia o porquê. Entendemos que precisávamos implementar um processo de gestão de performance.
Apesar de a empresa nunca ter implementado isso corporativamente, todo o nosso time já havia feito, muitos mais de uma vez. Se você olha por uma ótica do RH implementador, que abre sua caixa de ferramenta e busca algo que já sabe fazer, parece simples:“- Vamos escolher o modelo, escolher a ferramenta, definir o calendário, treinar, implementar, coletar os resultados”.
Processo de gestão de performance: como começar
Antes de escolher ferramenta ou definir calendário, fizemos um diagnóstico co-construído com a alta liderança. As perguntas que guiaram essa conversa: por que fazer GP agora? Quais são os principais receios? O que já foi tentado antes? O que faz sentido para o nosso momento e maturidade?
Se a empresa ainda não implementou GP, é porque em algum momento não se viu valor. Ignorar isso é a primeira armadilha.
As premissas que definimos: foco em resultados e cultura, eliminar vieses de avaliação, dar clareza às pessoas, apoiar a tomada de decisão de líderes, não tomar muito tempo da agenda de ninguém e “eat our own dog food", ou seja, usar AI da Blip!
Como muitos de nós já havíamos feito isso inúmeras vezes, outra armadilha que fatalmente poderíamos cair é : vamos rodar já com todo mundo. Eu vejo que em RH constantemente temos essa dificuldade, de fazer protótipo, grupo teste, e ir validando as hipóteses. Nesse momento, resolvemos adotar um modelo de gestão de produto padrão.
Definimos 3 fases simples: MVP / Beta / Lançamento
Fase 1: MVP
Em vez de lançar para 1.400 pessoas, escolhemos 2 diretorias de áreas diferentes: engenharia e vendas enterprise. Formato simples: planilha, Google Forms e dashboard em Power BI.
Para endereçar a premissa de eliminar vieses, usamos ONA - um algoritmo que analisa a rede de interação entre funcionários para rankear os avaliadores no 360, trazendo mais assertividade para quem avalia quem.
O primeiro NPS não foi bom. E tudo bem. "Se você não tem vergonha da primeira versão do seu produto, você demorou para lançar." Se tivéssemos lançado para toda a empresa, o potencial de erro seria gigantesco. Com o grupo menor, em um formulário de 5 perguntas, ficou claro o que precisava melhorar: clareza nos critérios, clareza na comunicação, qualidade do treinamento e um framework estruturado para os feedbacks depois.
Fase 2 – Beta
Só então fomos olhar ferramentas de mercado. E a premissa de usar nossa própria tecnologia de IA venceu: desenvolvemos o produto internamente.
O que foi mais legal de tudo é que iniciamos testando protótipos com ferramentas lowcode dentro do próprio time de People. Só fomos em busca de desenvolvedores para apoiarem mais profundamente na hora de desenvolver. Vimos na pele que o papel de design de produto também tem evoluído e as ferramentas que existem já nos permitem testar mais.
Validamos com três times: RH, por ser a área especialista no tema; Produto, para dar respaldo técnico da qualidade do que estava sendo desenvolvido; e Operações Internacionais, para validar que a IA respondia bem em três idiomas e que os critérios faziam sentido para diferentes culturas.
O beta foi super importante porque tivemos muito sucesso no uso da IA, conseguimos adiantar um teste que estava em backlog sobre os relatórios de devolutiva já serem desenvolvidos em um formato que auxiliaria o PDI. No entanto, a interface estava tornando o processo lento demais, ofendendo uma das premissas centrais. Voltamos para a estrutura antes de seguir.
Fase 3: Lançamento
A história segue sendo construída pelo time. Os testes foram tão promissores que geramos momentum espontâneo: times técnicos querendo ver a ferramenta, lideranças oferecendo expertise e força de trabalho para acelerar o desenvolvimento. Começamos também os testes para migrar de uma interface SaaS para uma interface conversacional — deixando tudo ainda mais com a cara da Blip.
O que aprendemos
O que mais me marcou nessa fase não foi a tecnologia. Em outras experiências, cheguei com processos prontos e ouvi: "lá vem o RH com mais uma ferramenta para tomar nosso tempo." Dessa vez foi diferente. Co-construir desde o início mudou o que as pessoas sentiam sobre o processo, antes mesmo de ele chegar para elas. Em todo evento que eu participava, alguém me parava: "quando meu time vai testar o Flow?” (nome dado ao produto).
Isso não foi acidente. Foi consequência de envolver as pessoas certas nas decisões certas, desde o começo. E de não sair para a ansiedade de implementar algo que teoricamente já sabíamos, mas nos permitir fazer algo novo.
Desenvolver um produto dentro da empresa, usando nossa própria tecnologia, nos trouxe algo que não estava no planejamento: conhecimento técnico, visão de negócio e empatia com os times que vivem essa realidade no dia a dia. Muitas pessoas do meu time diziam: "me envolver nesse projeto me fez ver a empresa de forma muito mais ampla."
E o melhor: você não precisa de conhecimento técnico para começar. As ferramentas que existem hoje permitem prototipar e testar muito antes de envolver um time de desenvolvimento.
O que você está esperando para começar?
