![Como os dados de código aberto e de série temporal se encaixam](https://optimuscloud.com.br/wp-content/uploads/2024/05/Como-os-dados-de-codigo-aberto-e-de-serie-temporal-150x150.png)
Como os dados de código aberto e de série temporal se encaixam
16 de maio de 2024![Navegando pelos riscos do software de código aberto: de quem é esse trabalho, afinal?](https://optimuscloud.com.br/wp-content/uploads/2024/05/1715890926_Navegando-pelos-riscos-do-software-de-codigo-aberto-de-quem-150x150.jpg)
Navegando pelos riscos do software de código aberto: de quem é esse trabalho, afinal?
16 de maio de 2024É o pior pesadelo de todo engenheiro de plataforma: seus desenvolvedores odeiam a plataforma interna de desenvolvimento que sua equipe passou meses (ou anos!) construindo. A adoção da plataforma é baixa e as principais partes interessadas estão prontas para abandonar a engenharia da plataforma. O que deu errado? E como sua equipe de plataforma pode evitar esse destino infeliz?
Os profissionais aprendem rapidamente que, na engenharia de plataformas, maior nem sempre é melhor. Em vez disso, o sucesso chega às equipes de plataforma que começam pequenas e permanecem enxutas. Como diz o coautor de “Team Topologies”, Manuel Pais: “Uma boa plataforma é grande o suficiente, mas não maior que isso”.
Isso não significa economizar na qualidade, mas sim usar dois conceitos-chave: produto mínimo viável (MVP) e plataforma mais fina viável (TVP). Usando essas abordagens, as equipes da plataforma podem alocar recursos internos de maneira ideal, garantindo que forneçam os recursos certos rapidamente e maximizem o valor comercial exclusivo da plataforma.
Comece pequeno: usando o produto mínimo viável
O autor de “The Lean Startup”, Eric Ries, define um produto mínimo viável (MVP) como “aquela versão de um novo produto que permite a uma equipe coletar a quantidade máxima de aprendizado validado sobre os clientes com o mínimo esforço”.
Em outras palavras, um MVP é a versão de produto mais simples necessária para obter feedback do usuário. Ao começar aos poucos, as equipes de plataforma podem validar suposições básicas e evitar o desperdício de recursos em recursos que os desenvolvedores não desejam nem precisam.
Seguindo uma abordagem MVP, as equipes de plataforma começam conversando com os desenvolvedores de sua organização. Eles conduzem pesquisas com usuários para identificar e compreender os desafios mais significativos dos desenvolvedores. Provavelmente, os desenvolvedores já encontraram e implementaram diferentes soluções para problemas persistentes. As equipes da plataforma devem identificar as limitações das soluções existentes e projetar uma alternativa atraente. O MVP deve ser uma ferramenta de aprendizagem, não um produto acabado, portanto não deve tentar dar suporte a todos os casos de uso. As equipes da plataforma devem criar os recursos mínimos necessários para resolver o problema.
A gerente de entrega da Mia-Platform, Francesca Carta, recomenda implantar o MVP em uma pequena “equipe pioneira” para teste. As equipes da plataforma podem então usar o feedback da equipe pioneira para iterar a solução antes de lançá-la para uma base mais ampla de usuários.
O desenvolvimento de um MVP normalmente leva de um a três meses. Esse cronograma abreviado permite que as equipes da plataforma aprendam rapidamente o que os desenvolvedores desejam. As equipes da plataforma podem fazer ajustes com base no feedback inicial e criar uma plataforma eficaz e atraente com investimento mínimo.
Na experiência da Carta, as equipes de plataforma também podem usar uma abordagem MVP para implementar ferramentas de terceiros com sucesso:
“Não comece automatizando tudo; comece resolvendo o problema principal da sua equipe. Por exemplo, se as implantações são um grande problema, você deve se concentrar em torná-las um recurso de autoatendimento. Depois, na segunda fase, você pode adicionar o plug-in para configuração da infraestrutura.”
As equipes de plataforma podem, portanto, iterar no sucesso de implementações mais limitadas de novas ferramentas. O feedback rápido ainda é importante porque a migração de desenvolvedores para soluções de terceiros pode criar tanto atrito quanto a migração de desenvolvedores para ferramentas internas.
Construir um MVP não envolve apenas envolver os desenvolvedores. Muitas iniciativas de plataforma falham porque as equipes de plataforma não conseguem provar seu valor às partes interessadas com rapidez suficiente. Carta diz que esse problema surge com mais frequência quando as equipes de plataforma tentam projetar para todos os casos de uso no início, em vez de focar no MVP. Ela recomenda que as equipes garantam o investimento das partes interessadas, começando com uma vitória rápida, mas significativa, e depois iterando.
Fique pequeno: plataforma viável mais fina
Embora uma abordagem MVP ajude as equipes de plataforma a desenvolver novos recursos, uma abordagem de plataforma mais fina viável (TVP) ajuda as equipes a alocar recursos internos de maneira ideal durante toda a vida útil da plataforma. Pais e seu coautor Matthew Skelton definem um TVP como:
“o menor conjunto de APIs, documentação e ferramentas necessárias para acelerar as equipes que desenvolvem serviços e sistemas de software modernos.”
O TVP de uma organização muda com o tempo. À medida que as ferramentas de terceiros se tornam mais competitivas, as equipes de plataforma devem escolher entre melhorar os componentes personalizados ou comprar de fornecedores. Ao definir um TVP, Carta diz: “Você tem que escolher como empresa: o que você vai construir dentro da sua empresa? O que você vai manter?” Com uma abordagem TVP, as equipes de plataforma alocam recursos internos apenas para aquilo que fornece valor comercial exclusivo.
Abby Bangser, da Syntasso, compartilhou como as ferramentas de observabilidade personalizadas do MOO foram retiradas em favor de opções fornecidas pelo fornecedor, apesar das preocupações sobre o desperdício de investimentos anteriores e dos temores em torno da dependência do fornecedor. Os benefícios foram aparentes meses após a mudança:
“Como a MOO agora estava pagando para outra empresa inovar no rastreamento, nós, como engenheiros de plataforma interna, poderíamos subir na pilha e nos concentrar em fornecer mais benefícios específicos da MOO, em vez de manter o serviço interno, agora desatualizado.”
Em sua palestra na PlatformCon 2022, “The Magic of Platforms”, o autor Gregor Hohpe discutiu a espessura da plataforma em termos de plataformas flutuantes versus plataformas afundantes. Imagine todas as plataformas apoiadas em uma plataforma base como o Kubernetes. Com o tempo, esta plataforma base ganha novos recursos e funcionalidades. Hohpe compara isso ao aumento do nível da água. As plataformas que não se adaptarem à maré alta irão afundar; eles continuarão duplicando as funcionalidades oferecidas pela plataforma base. Com uma plataforma flutuante, a equipe da plataforma terceiriza ou retira estrategicamente recursos redundantes. Isso libera recursos internos para focar na inovação, construindo funcionalidades além do que a plataforma base oferece.
De acordo com Hohpe, nenhuma das opções é inerentemente melhor que a outra. A chave é decidir proativamente se sua plataforma irá flutuar ou afundar e, em seguida, comunicar o plano às partes interessadas. Ao construir uma plataforma flutuante (ou seja, manter um TVP), as equipes da plataforma devem ser transparentes sobre o potencial de terceirização ou desativação de recursos desenvolvidos internamente. Caso contrário, as partes interessadas poderão ficar chateadas quando meses ou anos de trabalho forem descartados em favor de uma solução de terceiros.
Da mesma forma, as equipes de plataforma devem estar cientes de como a manutenção de um TVP afeta os desenvolvedores. Em sua palestra na QCon, Jessica Andersson, da Kognic, explicou que as equipes de plataforma ganham “créditos de confiança” quando aliviam os pontos problemáticos e seguem uma mentalidade de produto. Por outro lado, as migrações (mesmo que inevitáveis) gastam créditos de confiança. As equipes da plataforma devem ter a intenção de equilibrar ganhos com despesas.
![](https://optimuscloud.com.br/wp-content/uploads/2024/05/1715887326_776_Equipes-de-plataforma-comece-pequeno-para-ganhar-muito.png)
Crédito: Daniel Bryant no LinkedIn
Resumindo, manter um TVP permite que as equipes da plataforma se concentrem nas ferramentas e recursos específicos da sua organização. No entanto, definir expectativas precisas é crucial para sustentar a adesão das partes interessadas e manter os desenvolvedores satisfeitos.
Construindo de forma inteligente com MVPs e TVPs
As equipes de plataforma atuais são pioneiras em engenharia de plataforma. Como não existe uma plataforma de desenvolvedor interna que sirva para todos, as equipes devem descobrir como entregar uma solução adequada à sua organização. Ótimas plataformas podem ser construídas ou compradas, mas a maioria das organizações usa uma combinação de componentes construídos, comprados e de código aberto. Eles usam uma abordagem de plataforma como produto para entender as necessidades dos desenvolvedores, obter a adesão das partes interessadas e impulsionar a adoção da plataforma. MVP e TVP são conceitos de gerenciamento de produtos que garantem que as equipes de plataforma forneçam valor comercial exclusivo de forma rápida e em escala.
As equipes de plataforma podem maximizar a eficiência e o impacto adotando a filosofia “comece pequeno, permaneça enxuto”. Os MVPs garantem que os esforços de desenvolvimento sejam direcionados para os recursos que os desenvolvedores realmente desejam e precisam, evitando o desperdício de recursos em recursos indesejados. Este rápido ciclo de feedback promove a melhoria contínua e a inovação centrada no usuário.
TVP é um conceito complementar que incentiva as equipes da plataforma a alocar recursos internos de forma estratégica ao longo da vida útil da plataforma. Ao se concentrarem na construção do que agrega valor comercial exclusivo e no aproveitamento de soluções de terceiros para o restante, as equipes de plataforma podem manter um TVP que se mantém à frente da curva.
Mia-Platform Console é uma plataforma interna para desenvolvedores que permite que as equipes da plataforma gerenciem e monitorem o ciclo de vida de seu software nativo da nuvem em um só lugar. As equipes da plataforma usam o Mia-Platform para criar recursos de autoatendimento de forma rápida e em escala. Saiba como a Mia-Platform pode impulsionar sua plataforma.
A postagem Equipes de plataforma: comece pequeno para ganhar grande apareceu pela primeira vez em The New Stack.