Olá, pessoal! Vamos dar continuidade ao nosso curso de Platform Engineering com a aula sobre o modelo de produto para plataformas. Eu serei o instrutor nesta jornada. Meu nome é Eduardo, atuo como Staff Technical Product Manager. Sou formado em Ciência da Computação pela Unesp de São José do Rio Preto, com pós-graduação em Redes e Infraestrutura de TI pela UFSCar e MBA em Cloud Architecture and Engineering pela FIAP. Também sou um Golden Cubistronaut da CNCF e recentemente obtive as certificações CNPA e CNPE de Platform Engineering da CNCF. Além disso, sou um dos desenvolvedores da KCNA, a certificação de entrada no mundo Kubernetes e Cloud Native.
Vamos falar sobre as fontes e referências utilizadas na construção desta aula, que também são sugestões de leitura. Primeiro, o livro de gestão de plataformas IAPs da Sheila, uma autora brasileira. Este livro foi fundamental na minha transição da área de engenharia para a área de produto. Recomendo fortemente, pois oferece muitas dicas e orientações valiosas. Além disso, é um livro 100% brasileiro, então é importante apoiar a contribuição nacional em tecnologia.
Outra indicação é "Inspirado", de Marty Kagan, considerado uma das bíblias do produto, que ensina como criar produtos de tecnologia que os clientes amam. Este livro é amplamente recomendado na área de produto. Também temos um report feito em parceria entre a Cintasso e a O'Reilly, que oferece uma visão de platform as a product. É um material curto, mas muito rico em elementos do dia a dia, tanto da parte técnica quanto de produto.
O "Platform Strategy", de Gregory Hope, é outra referência essencial em Platform Engineering, abordando a estruturação de times e funções. O livro "Engenharia de Plataforma", de Camille Fournier e Ian Nowland, é um guia para líderes técnicos e de produto, abordando a importância de estruturar equipes e criar estratégias de produto para a engenharia de plataforma.
"Accelerate" é um dos meus livros preferidos, pois mudou minha visão sobre tecnologia e meu trabalho. Recomendo fortemente. Por fim, "Team Topologies" é uma obra que utilizamos na aula de estruturação de times de plataforma e que será abordada novamente aqui, focando em como estruturar a plataforma como um produto.
Vamos falar sobre o modelo de produto para plataformas. Nosso objetivo é transformar uma plataforma técnica em um produto interno, mudando nosso mindset. Começamos sempre com o nosso Platform Manifesto, que nos acompanha em todas as aulas.
Nossa agenda inclui discutir o Platform Market Fit e a mudança de paradigma, já que ninguém realmente deseja plataformas. Recapitulando, falamos sobre a estruturação de times, com um Platform Team bem estruturado, papéis definidos, modos de interação claros e tecnologia de ponta. No entanto, a adoção ficou em 20% ou menos. O que está faltando? Talvez a mudança de mindset seja necessária: parar de tratar a plataforma como um projeto técnico e começar a vê-la como um produto interno.
Vamos começar falando do Platform Market Fit. Plataformas tecnicamente perfeitas podem ser inúteis. Como mencionado no livro da Sheila, uma plataforma pode ser de altíssima tecnologia, bem construída, seguir todas as melhores práticas e ainda assim ser inútil às necessidades. A plataforma não é apenas um problema tecnológico; a engenharia não resolve todos os problemas. Precisamos de uma boa gestão da plataforma, mudar nosso mindset e adotar uma mentalidade de produto.
Quais são os sinais de um Platform Market Fit ruim? Os times evitam a plataforma sempre que possível, criando workarounds e gambiarras. O feedback negativo é constante, ou às vezes nem há feedback. A adoção só ocorre quando é mandatória, o que pode causar silêncio por parte dos times. Eles começam a criar soluções paralelas, o que chamamos de Shadow IT.
E quando temos um Platform Market Fit bom? Os times escolhem usar a plataforma voluntariamente, recomendando-a entre si. O feedback é construtivo e engajado, com pedidos de novas funcionalidades. Isso indica que eles usam e querem mais da plataforma. Além disso, conseguimos reduzir o time to market. Manter o Platform Market Fit é tão importante quanto alcançá-lo, pois plataformas, empresas e negócios mudam constantemente.
Por fim, ninguém realmente quer plataformas. Mas como assim? Se estamos falando sobre criar plataformas e Platform Engineering...
Os times de desenvolvimento buscam desenvolver rapidamente seus aplicativos, colocando-os em produção de maneira ágil e segura. As pessoas de negócio desejam que o aplicativo gere valor e resultados rapidamente. O usuário final espera que novas funcionalidades sejam disponibilizadas rapidamente para resolver seus problemas e melhorar o uso do produto ou ferramenta, pois, como discutido, as pessoas utilizam produtos que auxiliam em seu dia a dia.
A plataforma é vista como um meio, não um fim. Ninguém expressa o desejo por uma plataforma; em vez disso, falam sobre suas necessidades, e as plataformas viabilizam essas necessidades. Quando os times mencionam a necessidade de CICD, na verdade, querem entregar código em produção de forma rápida e segura. Quando falam sobre a necessidade de um banco de dados, buscam um local seguro para armazenar e recuperar dados. Devemos mudar nossa perspectiva, focando menos no "o quê" e mais em como isso entrega valor.
Devemos parar de falar sobre fornecer Kubernetes, gerenciar Prometheus e Grafana, ou ter GitOps e Service Mesh, e focar menos no que construímos, mas sim no valor que isso entrega, que é o que realmente importa para nossos usuários. Habilitamos o deploy em minutos com auto-scaling, proporcionamos visibilidade instantânea da saúde das aplicações, garantimos que as mudanças são seguras e reversíveis, e simplificamos a comunicação segura entre os serviços. É importante sempre trazer a noção do valor que estamos entregando com nossas ações.
A mudança de paradigma é crucial. Devemos parar de ver as coisas como um projeto técnico e passar a tratá-las como um produto interno. O mindset de projeto técnico é aquele com escopo fechado, onde o sucesso é medido pela entrega. Se prometemos subir um cluster Kubernetes em dois meses, ele deve estar pronto nesse prazo, independentemente de estar sendo utilizado. Isso foca apenas na tecnologia, sem considerar o usuário. O sucesso não é apenas entregar, mas sim adoção e valor. Devemos focar no usuário, tomando decisões baseadas em suas necessidades, e não em tendências tecnológicas.
O usuário deve ser visto como cliente. É gratificante criar algo que parte do usuário, com sua participação, para facilitar sua vida. O produto deve viver enquanto gera valor. No mindset de produto, devemos conquistar clientes, garantindo que a adoção seja voluntária, e não obrigatória. A proposta de valor deve ser clara, explicando por que o time deve usar a plataforma e qual problema específico ela resolve. O roadmap deve ser orientado por necessidades, ouvindo o feedback do usuário e priorizando por impacto.
Devemos ter recursos dedicados para ajudar os clientes a gerar valor, como discutido sobre os enabling teams. Isso é essencial para a construção e evolução de documentações, um onboarding estruturado, e para manter suporte e uma comunidade funcional. A plataforma deve evoluir continuamente, baseada no feedback dos usuários e nas mudanças do negócio e da companhia.
Deixamos uma reflexão: se o uso da plataforma fosse opcional, quantos times continuariam usando? Se isso nos preocupa, há um problema. Sheila menciona que ninguém é forçado a comprar um celular específico; escolhemos porque acreditamos que vale a pena. A obrigatoriedade só faz sentido por questões regulatórias ou de segurança. Se a plataforma não é usada por escolha, é sinal de que não vale a pena.
Com essas reflexões, iniciamos nossa jornada em plataforma como produto. Na parte 1, sobre fundamentos de Platform as a Product, discutiremos o que significa tratar a plataforma como produto, abordando a Developer Experience como diferencial estratégico. Falaremos sobre Discovery e Gestão Estratégica, como encontrar o problema certo a resolver, definir estratégias e montar roadmaps orientados a valor. Discutiremos Métricas e Demonstração de Valor, como medir sucesso além das métricas técnicas e comunicar esse valor para stakeholders, usuários e nosso time de plataforma.
Encerramos com os papéis de Ciclo de Vida, abordando o papel do Product Manager, seja um Platform Product Manager ou um Technical Product Manager, e o Developer Advocate, além de como gerenciar o ciclo de vida do produto plataforma. Essa é a estrutura que seguiremos na nossa primeira aula. Na aula de Estrutura de Times, discutimos organização; agora, falaremos sobre como operar o produto para que essa estrutura gere resultados reais. Seguiremos para a parte 1, Fundamento de Plataforma como Produto, para aprofundar nesses temas. Até lá!
Vamos iniciar a parte 1 da nossa aula, que aborda os fundamentos de plataforma como produto. Nesta seção, vamos explorar o Plataforma Manifesto e nossa agenda incluirá tópicos como o significado de tratar a plataforma como produto e o foco no cliente da plataforma, o Developer Experience (experiência da pessoa desenvolvedora).
Começando com o significado de tratar a plataforma como produto, trazemos uma frase conhecida de Ivan Botcher, que define uma plataforma digital como uma fundação de APIs self-service (autoatendimento), ferramentas, serviços, conhecimento e suporte organizados como um Compelling Internal Product (produto interno atraente). A expressão "Compelling" é importante, pois indica que o produto é desejável e resolve problemas, tornando-o atraente para os usuários.
Quais são as características de uma plataforma efetiva? Ela deve ser self-service, permitindo que a pessoa desenvolvedora provisione recursos sem abrir chamados, faça mudanças sob demanda e resolva problemas com a documentação, sem precisar de ajuda externa. A ideia é automatizar tarefas manuais repetitivas. No entanto, self-service não significa "vire-se sozinho" sem suporte ou documentação. Não devemos transferir responsabilidade sem fornecer capacidade, ou seja, sem explicar o que, por que e como algo funciona.
Um exemplo de self-service eficaz é quanto tempo leva para uma nova pessoa desenvolvedora, no primeiro dia, fazer o deploy de um serviço simples. Se isso levar dias ou semanas, ou se depender de ajuda, não temos um self-service real. Além disso, as plataformas precisam ser acessíveis, com documentação fácil de encontrar, suporte responsivo e uma comunidade ativa que compartilha exemplos e ajuda mútua.
Ser compelling significa que usar a plataforma é mais fácil do que não usá-la. Ela deve resolver problemas de forma elegante, economizar tempo e ser recomendada por desenvolvedores para colegas. Por outro lado, uma plataforma não compelling é aquela onde usá-la dá mais trabalho do que buscar alternativas, tem muita burocracia e não agrega valor real. A adoção só ocorre quando é obrigatória, o que não é ideal.
Devemos seguir o princípio de que fazer a coisa certa deve ser a opção mais fácil, conforme a frase de Ivan Botcher. Isso inclui seguir as melhores práticas de segurança, observabilidade e conformidade. A plataforma deve tornar o caminho correto o de menor resistência.
Precisamos equilibrar quatro dimensões para uma plataforma eficaz: valor, usabilidade, factibilidade e viabilidade. O valor é percebido quando a plataforma resolve problemas reais e tem adoção voluntária. A usabilidade é garantida por uma interface intuitiva e documentação clara. A factibilidade envolve a capacidade de desenvolver a plataforma com os recursos disponíveis. A viabilidade considera o custo-benefício e o alinhamento com a estratégia organizacional, além de atender a conformidade e regulamentação.
Por fim, seguimos o princípio de construir abstrações, não ilusões, conforme o livro de Gregory Hope. Abstrações reduzem a carga cognitiva ao esconder complexidade desnecessária, permitindo que a pessoa desenvolvedora defina o que quer enquanto a plataforma cuida do como. Devemos oferecer visibilidade e possibilidades de continuar o caminho em caso de problemas, evitando ilusões que escondem complexidade e eventualmente falham.
Quando discutimos sobre a escalabilidade de uma aplicação, surge a dúvida: a plataforma realmente entende como nossa aplicação deve escalar? Não especificamos isso em nenhum lugar. Como garantir que nossa aplicação terá desempenho e escalabilidade adequados? A segurança é automática, não precisamos nos preocupar com isso. No entanto, essa abordagem pode parecer genérica, pois sabemos que segurança é um aspecto sensível. Quando falamos de escalabilidade infinita e transparente, precisamos ter cuidado para não criar ilusões, acreditando que estamos construindo abstrações. Quando a ilusão se desfaz, a pessoa desenvolvedora não tem contexto para entender ou resolver o problema. Isso diferencia uma abstração de uma ilusão. Uma abstração saudável reduz a carga cognitiva e esconde complexidades desnecessárias, sem transformar tudo em mágica. Devemos ter cuidado com isso.
Falamos também sobre os Golden Paths (caminhos pavimentados). O conceito de Golden Path é amplamente conhecido e, às vezes, referido como Paved Road ou Paved Path. Todos representam o caminho ideal que a plataforma oferece para realizar tarefas comuns, facilitando o uso. É a materialização do princípio de tornar a coisa certa a mais fácil de se fazer. Um Golden Path é um fluxo otimizado e bem documentado para um caso de uso comum, incorporando as melhores práticas de segurança, observabilidade e conformidade. Ao seguir um Golden Path, sabemos que tudo isso já está abstraído de forma coerente. Ele reduz a carga cognitiva e elimina decisões desnecessárias, sendo o caminho de menor resistência. Usar é mais fácil do que não usar. Um Golden Path facilita o entendimento e ajuda no dia a dia.
As características de um bom Golden Path incluem ser opinativo, mas não autoritário. Ele ajuda a tomar decisões para reduzir a fricção, mas permite ajustes quando necessário, oferecendo alternativas. É bem documentado, permitindo que a pessoa desenvolvedora entenda o que está acontecendo e evolua sem quebrar. Quem já utiliza o Golden Path não sofre com mudanças, pois ele é evolutivo.
No entanto, devemos evitar transformar um Golden Path em uma Golden Cage (armadilha da rigidez). Quando um Golden Path se torna inflexível, ele aprisiona a pessoa desenvolvedora em vez de ajudá-la. Um Golden Cage força um único caminho rígido, sem alternativas, e esconde a complexidade de forma que impede o entendimento do fluxo. Isso pode resultar em dificuldades para realizar tarefas simples, como um deploy. Devemos evitar essa armadilha da rigidez.
Gregor Hope menciona que as plataformas devem "flutuar acima" do que já está disponível, adaptando-se e integrando-se com capacidades existentes, em vez de reconstruir tudo do zero com caminhos rígidos. Devemos usar o que já existe, construir abstrações por cima e manter a flexibilidade para que as equipes possam resolver seus problemas, sem impor um mandato rígido.
A diferença entre Golden Paths e Golden Cages é que um Golden Cage obriga a seguir um caminho, enquanto o Golden Path oferece um guia. O Golden Cage esconde sem explicar, enquanto o Golden Path abstrai com transparência. O Golden Cage é rígido e imutável, enquanto o Golden Path evolui com base no feedback do usuário. Ao usar o Golden Path, a pessoa usuária entende o que está acontecendo e pode fornecer feedback para melhorias.
Falando sobre adoção voluntária e obrigatória, se ouvirmos que todos os times devem usar a plataforma, já sabemos as consequências: conformidade superficial, falta de engajamento real, ausência de feedback genuíno e proliferação de soluções alternativas. As pessoas podem se sentir acuadas e não se sentirem à vontade para reclamar de algo obrigatório. O ressentimento cresce, e o shadow IT continua existindo, mas de forma oculta.
Refletimos sobre quantos times continuariam usando a plataforma se o uso fosse opcional. Assim como ninguém é forçado a comprar um produto específico, devemos criar uma plataforma tão boa que a pergunta não seja "por que devo usar?", mas sim "por que não usaria?". Queremos que a plataforma seja vista como um produto valioso.
Agora, vamos para o próximo tópico, que é a Developer Experience. Vamos explorar como a experiência da pessoa desenvolvedora pode ser um diferencial entre uma plataforma que é tolerada e uma que é adorada. Discutiremos métricas, feedback, empatia com o usuário e como transformar a plataforma em um produto interno de sucesso. Este é o final do nosso primeiro tópico, e agora seguimos para a parte de Developer Experience. Até já.
Vamos dar continuidade à parte 1 da nossa aula com o segundo tópico, que é o foco no cliente da plataforma, utilizando o Framework Developer Experience (Experiência da Pessoa Desenvolvedora). A ideia é usar o Developer Experience como um diferencial entre o uso forçado da nossa plataforma e a adoção voluntária. Antes disso, vamos discutir as três dimensões do Framework Developer Experience.
A primeira dimensão é o que chamamos de Feedback Loops (Ciclos de Feedback). Trata-se da rapidez com que os feedbacks são recebidos no dia a dia de trabalho das pessoas desenvolvedoras. Por exemplo, quando uma implementação é feita e um deploy é realizado, independentemente do ambiente, é importante saber rapidamente se o deploy funcionou ou não e o que aconteceu caso não tenha funcionado. Outro exemplo é a rapidez do feedback de uma pipeline. Se uma pessoa desenvolvedora precisa rodar uma pipeline cinco vezes ao dia, e cada execução demora uma hora e ainda falha no final, isso atrapalha o fluxo de trabalho. Além disso, quanto tempo demora para receber as análises de Code Review e implementar as sugestões? Tudo isso está relacionado à dimensão de feedback loop, que mede a rapidez das interações com outras pessoas e com as ferramentas utilizadas no dia a dia.
A segunda dimensão é a carga cognitiva, que se refere à quantidade de esforço mental necessário para trabalhar. Isso inclui a interação com outras pessoas, a alternância de contexto, a facilidade de uso das ferramentas, a documentação dessas ferramentas e a manipulação de uma base de código antiga e sem documentação. Essa dimensão avalia o esforço cognitivo necessário para realizar o trabalho.
Por fim, a terceira dimensão é o flow state (estado de fluxo), que mede o quanto a pessoa desenvolvedora consegue trabalhar e se manter focada em uma tarefa sem ser interrompida. As interrupções podem vir de várias formas, como reuniões não planejadas ou incidentes no ambiente de produção que exigem atenção imediata. A falta de um cronograma claro para lidar com incidentes também pode ser uma fonte de interrupção. Tudo que tira o foco e gera interrupção está relacionado a essa dimensão.
Como podemos integrar o developer experience em toda a jornada da nossa plataforma? Isso vai além da usabilidade, abrangendo também a parte de discovery (descoberta). Como as pessoas desenvolvedoras descobrem a existência da plataforma e suas capacidades? É fácil entender o que a plataforma faz ou o que uma capacidade específica oferece? O golden path (caminho ideal) é atrativo? Ele será o primeiro contato da pessoa desenvolvedora. Está claro quando usar ou não usar determinadas capacidades?
Após a descoberta, a pessoa desenvolvedora já sabe que a plataforma e suas capacidades existem. O início do uso é importante: quanto tempo leva para gerar valor? Quantos passos são necessários para realizar o primeiro deploy? Mesmo que seja um deploy de uma aplicação fictícia, quanto tempo isso demora? Quais são os pré-requisitos para gerar valor, pelo menos inicial, para entender a plataforma?
Durante o desenvolvimento, o feedback deve ser rápido e claro. As pipelines da plataforma precisam ser rápidas, e os alertas, claros. É fácil depurar um deploy para saber se deu certo ou não. A jornada de developer experience abrange todas essas fases.
Na operação, após um deploy, é importante saber o que está acontecendo com a aplicação. Ela já possui observabilidade? É fácil realizar um troubleshooting? A performance é previsível? Essa parte da operação é crucial para criar confiança na plataforma.
A evolução também é importante. Quando uma nova capacidade chega à plataforma, há muitas mudanças que quebram funcionalidades? Os usuários são impactados? As novas features agregam valor? Elas foram solicitadas pelos usuários ou surgiram de ideias não validadas, que não resolvem problemas reais? Precisamos integrar o developer experience em todas essas jornadas, sempre pensando no usuário e fazendo o melhor para ele.
Quais são os custos de uma má developer experience? Existem custos diretos e indiretos. Diretamente, vemos a presença de shadow IT, baixa produtividade dos times, alta rotatividade e incidentes causados por mal-entendidos no uso da plataforma. Indiretamente, a reputação é danificada, há resistência à mudança, a inovação é reduzida e os custos de suporte aumentam.
Como medimos a developer experience? Quais métricas importam? Dividimos em algumas fases. Na fase 1, focamos na adoção e satisfação, analisando o NPS, o tempo para o primeiro deploy e a adoção das features. Quando a adoção e satisfação estão equilibradas, começamos a olhar para a confiabilidade.
Quem utiliza a plataforma confia nela? Qual é a taxa de sucesso de implantação? Qual é o P95 de latência das APIs que operam na plataforma? Qual é o MTTR dos serviços na plataforma? Quão confiável é executar um serviço dentro dessa plataforma? E, por último, a entrega. Quão rapidamente conseguimos entregar estando dentro da plataforma? Quanto reduzimos o tempo de espera? Como aumentamos os deploys? É importante que as equipes consigam realizar deploys cada vez mais rapidamente e com um baixo CFR, que é a taxa de falha de mudança. Assim, podemos realizar deploys mais rápidos, aumentar a frequência de deploys e manter a taxa de erro o mais baixa possível para entregar com qualidade e segurança, e não apenas lançar qualquer coisa em produção.
Como conseguimos isso? Temos algumas iniciativas e práticas que podemos implementar no dia a dia. Uma delas são as entrevistas espontâneas e aleatórias, nas quais selecionamos pessoas aleatoriamente e agendamos conversas informais. Fazemos perguntas abertas sobre o cotidiano das pessoas com base em frameworks, que discutiremos mais adiante, para melhorar o dia a dia de trabalho dessas pessoas. Às vezes, não precisamos nem fazer perguntas específicas sobre a plataforma, mas sim identificar os problemas que enfrentam e resolvê-los a partir da plataforma.
Além disso, realizamos observações e o que chamamos de Shadow Session. Durante uma Shadow Session, sentamos com a pessoa usuária e pedimos que ela realize um deploy de uma nova aplicação, uma migração ou algo que faria no dia a dia, enquanto observamos como ela executa essas tarefas. Identificamos pontos de fricção, analisamos onde ela clica e como realiza as ações. Às vezes, descobrimos aspectos interessantes apenas observando como a pessoa usuária trabalha. Acompanhamos tarefas comuns para entender suas necessidades. Por que ela clicou ali? O que ela pretendia ao clicar ali? Será que clicou porque achou que era outra coisa? Será que essa outra coisa que ela precisa não está disponível? Deveríamos disponibilizá-la? Particularmente, gostamos muito das Shadow Sessions, pois elas nos fornecem muitas respostas.
Outra iniciativa transformadora é a prática de community building, que envolve identificar os early adopters da plataforma, pessoas que gostam de testar e contribuir. Oferecemos acesso antecipado a essas pessoas para novas funcionalidades. Lançamos uma funcionalidade em alpha ou beta e permitimos que essas pessoas a utilizem, validem e forneçam feedback. Criamos um canal privado para feedback, onde essas pessoas podem dizer o que ficou bom, o que precisa melhorar, etc. Assim, obtemos feedback em tempo real de uma funcionalidade que ainda não foi lançada para todos, mas já está sendo testada. Quando lançamos a funcionalidade, reconhecemos as contribuições dos early adopters e seus feedbacks, mostrando que contamos com as equipes e reconhecemos a importância delas para o sucesso da nossa iniciativa de plataforma.
Como conectamos essa parte de experiência da pessoa desenvolvedora com valor de negócio? Podemos usar o que chamamos de métricas proxy. Por exemplo, ao falar de horas de desenvolvimento, podemos calcular o custo por hora e apresentar uma visão de economia. Ao reduzir incidentes, podemos calcular o custo médio de um incidente e transformá-lo em economia. Um tempo de mercado mais rápido pode ser medido com base no valor das funcionalidades. Retenção de talentos também é importante. Se a plataforma é boa e as equipes gostam de usá-la, as pessoas vão querer trabalhar na empresa e permanecer nela. Qual é o custo de substituição de uma pessoa desenvolvedora? Sabemos que não é apenas o salário; a pessoa precisa aprender, entender o contexto e adquirir conhecimento antes de começar a gerar valor de fato. Essa é uma métrica importante para deixar claro o valor dela para nossos stakeholders.
Como calculamos isso? Por exemplo, se uma funcionalidade da plataforma economizou duas horas por deploy e realizamos 200 deploys por semana, economizamos 400 horas. Sabendo que o custo médio de uma hora de uma pessoa desenvolvedora é 150 reais, podemos afirmar que economizamos semanalmente 60 mil reais e, anualmente, 3 milhões de reais. Embora usemos números aleatórios para ilustrar, é uma forma de mostrar o valor com base em nossas ações e como resolvemos os problemas dos usuários.
Como trazemos a experiência da pessoa desenvolvedora como vantagem competitiva? No recrutamento, se temos uma plataforma que resolve problemas e ajuda no dia a dia, que as pessoas desenvolvedoras gostam de usar, é mais fácil contratar novas pessoas. O mundo da tecnologia é pequeno, e todos sabem quando uma plataforma é boa, quando gera valor. As equipes gostam de trabalhar em lugares com plataformas que geram valor. Temos mais inovação, podemos experimentar mais, e é mais fácil lançar novos produtos em produção em empresas com plataformas que oferecem uma boa experiência para a pessoa desenvolvedora. Os fallbacks são seguros, e as equipes têm mais coragem para inovar. Elas têm vontade de tentar.
A grande vantagem competitiva de mercado é a velocidade. Enquanto o competidor demora semanas, conseguimos lançar um produto em produção em dias, reagindo rapidamente às mudanças. A experiência da pessoa desenvolvedora traz toda essa vantagem competitiva, desde o recrutamento até a retenção dos melhores talentos na empresa. Ela ajuda na inovação, pois se a experiência é boa, se é fácil realizar um fallback, se é fácil testar, as equipes sempre vão querer inovar mais e pensar fora da caixa. No final do dia, nossa empresa entrega mais rapidamente e estamos um passo à frente dos nossos competidores e de outras empresas que prestam o mesmo tipo de serviço.
Essa foi uma introdução sobre a experiência da pessoa desenvolvedora como vantagem competitiva e como tornar nossa plataforma uma escolha voluntária, e não obrigatória. Vamos discutir mais sobre a experiência da pessoa desenvolvedora em breve, mas, por enquanto, é isso. A seguir, começaremos a parte 2, que trata de Discovery e Gestão Estratégica. Até lá!
O curso Engenharia de Plataformas: Tratar plataformas como produto possui 207 minutos de vídeos, em um total de 64 atividades. Gostou? Conheça nossos outros cursos de Platform Engineering em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
