Uma síntese não exaustiva sobre times de plataforma

Olá!

Recentemente me dei conta de que apesar de ter trabalhado com assuntos relacionados ao desenvolvimento de plataformas de software já faz algum tempo, me dei conta que não tinha parado para pensar sobre o assunto de forma estruturada. Desse processo, saiu esse artigo.

Antes de começar, recomendo a leitura dos seguintes materiais para melhor aproveitamento: sobre dívida técnica, cultura das empresas, papel do arquiteto de software e o resumo do Team Topologies. Irei utilizar alguns conceitos previamente abordados nesses textos.

Dito isso, vamos iniciar pelo começo: o que de fato é uma plataforma de software? Acho que nesse caso vale usar o dicionário para tentar entender primeiro o que é uma plataforma:

• Superfície plana e horizontal, mais alta que a área circundante.
• Programa político, ideológico ou administrativo de um candidato a cargo eletivo.

Bom, o que isso tem a ver com software? Além da palavra programa na segunda definição, na verdade, não muita coisa. Agora vamos a uma definição mais específica (dessa vez, da wikipedia):

Uma plataforma computacional é, no senso mais geral, qualquer que seja o ambiente pré-existente, um pedaço de software que é projetado para ser executado internamente, obedecendo às suas limitações e fazendo uso das suas instalações.

Também não ajudou muito, dado que isso é uma definição mais voltada para o hardware. Devido a isso, a definição que talvez seja a que se aplique ao que eu estou querendo dizer é a seguinte:

Uma plataforma digital é uma fundação de APIs self-service, ferramentas, serviços, conhecimento e suporte organizados de uma forma convincente como um produto interno (Evan Bottcher, daqui).

Em outros termos: É uma especie de conhecimento de engenharia que passou por uma cuidadosa curadoria, que é usado por times autônomos para entregar software mais rápido e melhor, com necessidade de coordenação reduzida.

Em linhas gerais, toda empresa que quer ser digital de verdade deveria estar enxergando a tecnologia como o negócio (ou seja, tech como uma área enabler — mais detalhes aqui), também deveria estar pensando em construir uma plataforma.

Porém, temos alguns problemas envolvidos: não é algo simples de se fazer. Pela minha experiência liderando times dessa natureza eu consegui enxergar alguns padrões que gostaria de compartilhar com vocês. Talvez o que eu vou dizer não se aplique a boa parte dos times, mas, espero que agregue algo para você que me lê mesmo assim.

Qual a diferença de um time de plataforma para um time stream-aligned, por exemplo? Simples, vou começar pela mais simples de todas: o Product Manager. Um PM tradicional geralmente não possui as habilidades necessárias (geralmente, aprofundamento técnico) para conduzir um time desse. O que nos leva a necessidade de um Technical Product Manager:

Diferenças entre os diferentes perfis

Boa sorte tentando contratar um desse. Se tá difícil contratar pessoas desenvolvedoras, imagine um perfil hiper específico que nem esse?

Fica a dica para as pessoas desenvolvedoras que querem ir para produto: tem muito mercado ($$$) para esse perfil.

Há ainda outra diferença: quem é o cliente. Nesse caso, acaba sendo toda a empresa, literalmente. Como é um software que tem que atender a diversos clientes internos, esteja preparado para uma diversidade muito maior que o comum em termos de quem usa seu produto. Apesar do principal cliente ser muitas vezes outros times técnicos, as áreas podem variar muito. Vou citar dois exemplos que eu trabalhei: uma plataforma core de finanças de uma fintech que os clientes em potencial eram todas as áreas (da Contabilidade até Compliance, passando por CX, Marketing, Financeiro…), dado que tudo passava pela plataforma. E na outra, uma plataforma interna que em uma reunião de stakeholders, tinham 7 áreas diferentes, quase todas com interesses conflitantes. Boa sorte tentando coordenar essas expectativas. A solução aqui para lidar melhor com tudo isso é simples: Autonomia. Mas já comento sobre isso.

Além desses pontos, há também o fator missão crítica desse tipo de time. Nenhuma empresa investe em uma plataforma para ficar fora do ar ou não suportar a escala que o negócio pretende atingir. Portanto, indisponibilidade não é uma opção. Isso implica em muita coisa. Eu também adicionaria uma outra nota: nesse caso, a tecnologia importa. Não é possível fazer uma plataforma escalável com alguma tecnologia que não foi feita para suportar serviços back-end de alto throughput com pouco esforço. Apesar de algumas linguagens serem ótimas para o caso de uso padrão: CRUD Web com algum framework, em se tratando de escala, tolerância a falhas ou simplesmente performance per watt, algumas se saem melhor (e mais baratas!) que outras. Eu nunca começaria nada dessa magnitude com PHP ou C++ (uma por performance, outra por complexidade), por exemplo.

Há uma outra recomendação da literatura que gostaria de frisar aqui: a importância de uma estratégia bem definida. Plataformas custam muito dinheiro e demoram até entregar valor (geralmente, são sistemas mais complexos que o habitual) e requerem pessoas desenvolvedoras com um perfil muito bem definido: especificamente, com mais traquejo em arquitetura e performance.

Devido a isso, se aventurar construindo plataformas acaba sendo um investimento de altíssimo risco, por três motivos:

1-) Pessoas desenvolvedoras com essa expertise são caras e difíceis de achar.

2-) Em caso de algum erro de cálculo de tamanho, haverá um desperdício significativo de dinheiro, construindo algo que não irá para frente (que lembrando: plataformas de software tendem a começar grandes ao invés de crescer aos poucos). É muito fácil cair no BDUF aqui.

3-) Caso haja qualquer dúvida na estratégia, por menor que seja, isso se refletirá na plataforma. Sem exceção. Exemplo: imagine um banco que decida ser multi-região e multi-moeda, por exemplo. Após algum tempo, os executivos desistem de operar fora do Brasil e só vão suportar a moeda brasileira. O que acontece com tudo que foi criado dentro da plataforma para suportar tudo o que foi definido antes? Vira legado inútil. Portanto, lembre-se: O melhor código é aquele que não precisou ser escrito.

Em última instância, a plataforma é um produto técnico. Portanto, o time tem que ter autonomia para escolher o melhor caminho técnico. A gestão de bugs e outras prioridades é vista de uma outra forma em times dessa natureza, por exemplo. O que acaba até facilitando alguns trade-offs. Já me deparei com situações de ter que decidir entre atuar em bug em uma feature específica ou priorizar a execução de uma nova arquitetura de um serviço que ao parar, simplesmente matava uma linha de receita da empresa, completamente. Desnecessário dizer o que eu decidi, né?

Para um time desse tipo dar certo, é necessário que a equipe tenha autonomia real para priorizar algumas coisas. Se ocorre muita intervenção externa, acaba não sendo um time de plataforma e sim só um time comum com um sistema com carga cognitiva e responsabilidade maior que o restante dos times. Na prática, um time caro com alto turnover, pois pessoas desenvolvedoras experientes não querem— e nem precisam — de top-downs. Ou seja, um time bucha.

Ao atuar em um time dessa natureza, tudo que você estudou na sua carreira, provavelmente será usado e testado de forma real. Aqui, o uso dos fundamentos da computação são particularmente necessários. Além disso, a paralisia por análise ocorre também, dado que é possível se perder facilmente nas escolhas entre linguagens, frameworks, sgbds, cloud providers e demais tecnologias e esquecer de entregar valor. Não confundamos perfeição arquitetural com valor para o negócio, certo?

Nesse ponto cabe o seguinte conselho: o time deve focar em usar o que domina e só escolher algo arcano e esotérico se houver muitíssima necessidade. Nunca implemente uma tecnologia em uma plataforma só pelo hype, sem fazer benchmarks e provas de conceito, pois plataformas precisam ser robustas e estáveis, ao invés de um laboratório de ideais de vanguarda. Existe um equilíbrio tênue entre inovação e estabilidade que precisa ser respeitado nesse caso.

Dado a importância e criticidade desse tipo de time, caso atue com gestão, você pode ficar tentado a não contratar iniciantes para essas posições. Como eu sou um adepto de formar pessoas, eu foco no lado positivo desse cenário: Imagine o quão bom uma pessoa desenvolvedora pode se tornar trabalhando em um time desse por alguns anos, ainda mais no começo da carreira, que é onde construímos hábitos que muitas vezes levamos pelo resto da carreira? A curva de aprendizado é mais íngreme que o comum, mas isso não necessariamente é um problema grave a longo prazo para esses profissionais. O déficit de profissionais de tecnologia já está em 530 mil segundo estimativas recentes, portanto, contratar e formar pessoas é uma questão de sobrevivência.

Como recomendação, acho que vale acompanhar o Manifesto Tech e o Movimento Tech para ver o que a indústria está fazendo para atacar esse problema.

Para finalizar, gostaria de terminar com a seguinte frase (que eu acredito que resuma um pouco esse texto):

Plataforma de software é aquele sistema que toda pessoa desenvolvedora adora fazer, porém, nunca fica pronto de fato e ninguém de fora dela entende muito bem o que ela faz.

Até!

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