Como medir sucesso de plataformas digitais?

Olá!

Hoje eu gostaria de abordar um tema que me foi sugerido no meu formulário de pautas, disponível aqui. Se quiser me sugerir alguma pauta, só mandar por lá.

Como o tema Plataformas é um tema muito abrangente e extenso, para melhor entendimento do que se trata recomendo que você leia esse texto aqui antes de continuar.

Agora vamos ao argumento principal em si.

Ao meu ver, antes de construir uma plataforma, o ideal é entender exatamente o que se quer atingir e o motivo. Dado isso, a resposta meio que surge sozinha. Vamos a um exemplo:

Em uma empresa de e-commerce, o time de desenvolvimento está demorando muito para construir novos produtos, há muitos bugs e muitos conflitos que surgem da integração entre códigos de diferentes times em um mesmo repositório. O famoso monólito atrapalhando a velocidade do negócio.

Qual é a solução óbvia aqui? Tornar todo o back-end uma plataforma, criando formas de se criar serviços padronizados e de fácil manuseio, com bibliotecas padrão de logs, filas e demais componentes comuns a todos os serviços, além de subir um cluster Kubernetes para lidar com a orquestração de containers e que tenha uma forma de suportar auto-scaling e afins.

Um exemplo de sucesso documentado dessa iniciativa no mercado é a Fury, do Mercado Livre.

Nesse exemplo mencionado, qual o motivo da criação da plataforma, para começar? Na maioria das vezes, é o simples mesmo: Não atrapalhar o crescimento do negócio.

Se o foco é no negócio, a resposta é óbvia. Podemos usar indicadores como receita, custo de aquisição de cliente (CAC) e retorno sobre o investimento (ROI). Em alguns casos, pode fazer sentido medir o Efeito Rede (Network Effect) da empresa também, dado que muito provavelmente em um cenário desse estamos querendo medir a taxa de crescimento.

Um ponto aqui: Estou assumindo que se uma empresa se propõe a fazer uma iniciativa dessa natureza, provavelmente já tem uma área de gestão estruturada para estimar e gerir esses números. Afinal, você não vai construir uma plataforma hiper-complexa se nem tem o produto validado ou volume de acessos para justificar tal empreitada, certo?

Em alguns casos, é melhor esperar ter o problema do que tentar antecipá-lo de alguma forma. Em tecnologia, esse problema é documentado com a seguinte frase do Donald Knuth: Otimização prematura é a raiz de todos os males.

Resumindo: Se o objetivo da plataforma é ajudar o negócio, então meça o sucesso do negócio.

Eu até pensei em comentar um pouco sobre os indicadores de sucesso pensando em uma plataforma puramente de tecnologia. Pensando que para medir esse tipo de iniciativa, eu poderia citar pesquisas de satisfação com os desenvolvedores (adaptando NPS, por exemplo), taxa de adesão (dividindo quantidade de projetos que usam plataforma pelo total de projetos da empresa, por exemplo), indicadores de retenção e similares.

Porém, eu me dei conta enquanto escrevia do seguinte: Toda plataforma é para atender o negócio, em ultima instância, cada linha de código tem como propósito dar suporte a operação de uma empresa. Por mais que me doa dizer isso (o meu lado romântico que acredita que a tecnologia pode mudar o mundo acabou de desmaiar de desgosto), eu não posso ser leviano ao ponto de dizer que como profissional de tecnologia deveríamos buscar um ideal técnico inalcançável e purista. Esse estereótipo tem nome e é danoso, inclusive. O ótimo é inimigo do bom na maioria dos sistemas.

Logo, em essência, todos os indicadores de sucesso de uma plataforma precisam ser de negócio, toda e qualquer outra métrica que meça algo relacionado ao desenvolvedor, se torna uma espécie de métrica de vaidade.

Um exemplo para esse caso: Do que adianta ter uma plataforma em que todos os desenvolvedores usam (ou seja, uma taxa de adesão de 100%) sendo que devido a vários outros problemas, o ecossistema de tecnologia da empresa continua não parando em pé, gerando instabilidades e perdas financeiras?

Você precisa mesmo dessa complexidade toda?

Nesse caso, é um caso óbvio de fazer com muita eficiência o que não deveria ter sido feito. O foco deveria estar em resolver outros problemas e não em trocar um punhado de linhas de código duplicadas para uma biblioteca que abstrai alguma outra coisa (situação muito comum em iniciativas de plataformização, inclusive).

Aqui vale um disclaimer: Vale medir developer experience em situações assim? Sim. Vale abstrair código ao invés de duplicar código? Sim! O que não pode acontecer é tornar metas como essa como o objetivo final a ser alcançado.

É justamente essa a lição que aprendi estudando sobre OKRs: A partir do momento em que perseguir uma meta vira o objeto final ao invés der uma espécie de estrela-guia que nos ajuda a medir se estamos no caminho certo, algo deu errado e os critérios de sucesso foram contaminados e precisam ser revistos.

No final, por mais belo que seja uma plataforma, o que importa é se ela suporta o negócio ou não. Há casos famosos de monólitos em Rails que vão muito bem ainda (ex: Shopify).

Olhando o caso deles e a escala (~1.3MM requisições/segundo), não consigo pensar em um motivo racional que justifique ir para um caminho de plataformização mais complexo. Ainda dá para fazer muita coisa legal com o básico bem feito.

Até!

Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.