tl;dr: Semelhante a software, as times também se beneficiam de composição. Um padrão comum é estabelecer uma equipe de plataforma que é aproveitada pelas equipes de aplicação. Identificar pontos fortes, limites e responsabilidades para cada equipe pode ajudar a estabelecer equipes para o sucesso ao introduzir mudanças.


Uma tensão em engenharia de software que sempre me fascinou é saber quando dividir um em muitos. Sempre parece haver esse ponto de inflexão, geralmente desencadeado pela percepção de duplicação, compreensão de complexidade de responsabilidades ou perceber que acoplamento se tornou um problema.

Da mesma forma, as organizações também se beneficiam desse padrão. Os sinais de que pode ser necessário são os mesmos: há duplicação de sistemas, uma fusão de escopo e acoplamento indesejável de objetivos entre times. Uma solução de design organizacional comum é estabelecer uma “equipe de plataforma” responsável por generalizar os casos de uso existentes em uma plataforma e “equipes de aplicação”, com foco nas especificidades dos casos de uso.

Apoiar esse tipo de mudança pode ser perturbador para as equipes e, às vezes, a frustração vem da definição de novos limites e propósitos dissociados. Aqui estão algumas idéias de como traçar limites e ajudar equipes de plataforma e aplicação a terem sucesso.

O que permanece nas equipes de aplicação

Definir responsabilidades claras para equipes de aplicação ajuda a definir o que uma plataforma poderia ser. Uma maneira de entender o que precisa ser uma plataforma é entender o que não deve ser, pois isso geralmente é mais óbvio do que o contrário.

  1. Plataformas têm menos probabilidade de resolver problemas subjetivos ou com muitas nuances. Considerando que o papel de uma plataforma é atender a vários casos de uso, elas geralmente são excelentes para resolver problemas objetivos. Embora, para a maioria dos problemas que tendem ao lado subjetivo, as equipes de aplicação brilham muito mais. Para uma plataforma de processamento de pagamentos, existem muitos desafios de produto difíceis a serem resolvidos como uma equipe de aplicação: quando e como autorizar um cartão, quando tentar um pagamento novamente, quando e com que frequência liquidar fundos, o melhor dia do mês para repetir um pagamento, para citar alguns.

  2. Otimização relacionada ao contexto deve viver próxima ao contexto. As plataformas são ótimas para resolver a maior parte dos problemas compartilhados entre aplicações, embora alguns dos trabalhos de otimização mais desafiadores, especialmente em sistemas de grande escala, estejam no contexto. Para uma plataforma de recomendações, o contexto em que uma recomendação é feita é extremamente relevante para que seja eficaz, por ex. uma recomendação em uma página de lista de produtos, com baixa intenção de compra versus uma recomendação de pré-pagamento ou upsell. Embora as plataformas possam fornecer vantagens para a otimização, todo o ajuste, calibração e significado do sucesso tende a viver mais perto do contexto. Em geral, as equipes de aplicação estão em uma posição muito melhor para localizar sinais de alta qualidade que são sensíveis ao contexto para otimização.

  3. A plataforma pode afetar seu usuário. Equipes podem ser extremamente bem-sucedidas trabalhando em estreita colaboração com pesquisadores de experiência do usuário para entender quais são as necessidades específicas de seus usuários. Às vezes, o insight gerado por meio de pesquisas pode ser contraditório em diferentes superfícies ou contextos, e esse entendimento pode determinar como a plataforma afeta o usuário. Os resultados da pesquisa podem variar de equipes de aplicação influenciando a direção da plataforma se o insight for válido em todos os casos de uso, até também revelar que talvez o limite traçado proposto afete de alguma forma o caso de uso e decidir que é prematuro ter uma plataforma.

Uma nova plataforma emerge

À medida que você entende o que fica, o que deveria ser generalizado fica muito mais claro. Mais do que mudar sistemas, times de plataforma exigem uma mudança massiva de mentalidade. Para quem não está familiarizado com equipes de plataforma, eles tendem a compartilhar algumas características. Um exemplo notável é trabalhar com vários clientes ou partes interessadas. Dito isso, grande parte da tensão para as equipes de plataforma é encontrar o equilíbrio entre a utilidade e permanecer agnósticos - as plataformas são projetadas para resolver bem um conjunto de problemas, mas não todos. Algumas características que observei que equipes de plataforma bem-sucedidas possuem são:

  1. Pense na infra-estrutura como parte do produto - ou o próprio produto. Quando uma equipe não consegue controlar todas as consequências downstreams de diferentes modos de falha, ela precisa ter SLAs, processos de gerenciamento de incidentes e práticas de continuidade de negócios muito mais rígidos. Por exemplo, um requisito de disponibilidade de 99% pode ser aceitável para uma plataforma de pagamentos com um ticket médio de $10 @ 500k transações por dia - significando uma perda de ~$3.5k por hora. No entanto, se o ticket médio está na casa dos milhares, isso pode significar diferentes requisitos de disponibilidade. Ser uma equipe de plataforma exige uma mudança no pensamento de que a infraestrutura é uma parte muito mais relevante da oferta do produto.

  2. Tenha cuidado ao presumir equivalências em dados. Especialmente para plataformas de machine learning ou data, pode ser muito difícil encontrar maneiras de comparar significados, padronizar e compartilhar protocolos para labelling de dados ou gerar insights. Além disso, às vezes pode ser enganoso se você não compreender totalmente os casos de uso antes de compartilhar dados para análise ou treinar modelos. Dito isso, uma boa maneira de evitar cenários como esse é ser conservador sobre onde traçar o limite do domínio da plataforma e começar com o menor valor possível. Por exemplo, uma plataforma de recomendações de produtos pode começar com uma API que retorna scores de probabilidade para vários tipos de recomendação - compre novamente, também comprei etc. - em vez de lidar com a ranking de produtos, que é um problema muito mais complexo e matizado.

  3. Pense na plataforma como recursos, em vez de um pacote único. Uma das formas pelas quais as plataformas geralmente falham é tentar empacotar todos os recursos em vez de fornecer às equipes de aplicativos um conjunto de recursos interoperáveis ​​que podem ser usados ​​como necessário. Embora possa ser bastante conveniente abstrair toda a complexidade por trás de uma única API, quando as equipes de aplicativos não têm acesso a recursos independentes, elas são incentivadas a “dar a volta” na plataforma. Em vez disso, dividir domínios lógicos em blocos de funcionalidade pode dar aos usuários a capacidade de estender funcionalidades. Esse post do Kislay Verma sobre como evitar “dar a volta” com platform thinking explica o problema e a solução muito bem.


Por mais que a mudança seja positiva quando você pode definir claramente a responsabilidade de cada constituinte, introduzi-la prematuramente pode ser muito prejudicial. Considerando o quão perturbadora uma decisão errada pode ser e quão lento é o ciclo de feedback para definir se uma reorganização foi bem-sucedida ou não, abordar a mudança por meio de experimentação pode ajudar a mitigar riscos e tornar a experiência menos frustrante para todos.