Papéis e Funções
Publicação da série sobre as diversas funções e posições em uma equipe de ProdOps, juntamente com as adaptações que o ProdOps faz no fluxo e na estrutura organizacional:
Literatura preliminar
Hierarquia de Cargos e Papéis
Expansão do Squad com Times Fixos e Times Virtuais
Especialidades ProdOps
ProdOps Tracker
ProdOps Specialist
ProdOps Quality Engineer
ProdDevOps Engineer
ProdOps Reliability Engineer
ProdOps Manager
Tech Product Manager
Cargo ou Papel?
O DevProdOps ou ProdDevOps (*) Engineer representa uma evolução do DevOps dentro do contexto do ProdOps, integrando o papel de ProdOps Tracker para a elaboração de Planos de Confiabilidade. Essa abordagem conjunta visa fortalecer os alicerces da Engenharia de Produto, consolidando-se como uma peça fundamental na garantia da confiabilidade e desempenho do produto.
ProdDevOps é a junção das áreas de Product Management e DevOps, focando na melhoria da gestão e entrega de produtos digitais. O objetivo é acelerar a entrega, melhorar a qualidade e alinhar a equipe de desenvolvimento com as necessidades do negócio, criando uma cultura de trabalho mais colaborativa e eficiente.
A discussão persiste há muito tempo sobre se DevOps deve ser tratado como um cargo específico ou se representa uma cultura que todos devem adotar em um modelo DevOps. No contexto do ProdOps, reconhecemos a importância dos cargos, considerando o trabalho contínuo e essencial na construção de engenharia, alinhando-se às mudanças e seguindo a abordagem liderada pelo produto (Product-Led). Nossa perspectiva destaca a necessidade de papéis definidos para garantir uma execução eficaz da engenharia, enquanto mantemos a essência da cultura DevOps em nossa abordagem geral.
* Encontrarão as duas formas de escrita em algumas vagas de emprego no mercado DevProdOps ou ProdDevOps (que é nossa preferência).
Contexto Histórico
Durante a consolidação da indústria de software, as estruturas organizacionais das equipes foram moldadas majoritariamente por modelos tradicionais de separação entre CAPEX e OPEX, refletindo uma abordagem simplificada e funcional para a época. A lógica predominante dividia o trabalho entre projetos (CAPEX) — com escopo definido, orçamento fechado e prazo de entrega — e sustentação (OPEX) — responsável por manter o sistema funcionando no dia a dia, com foco em operação e correções.
A sustentação, por sua vez, era segmentada entre operações clássicas (infraestrutura, suporte e monitoramento) e desenvolvimento evolutivo (pequenas melhorias, ajustes e correções no código). Essa estrutura funcionava bem em contextos onde mudanças eram esporádicas e o ritmo de inovação era previsível.
A Ruptura: Internet, Velocidade e Escala
Com o advento da Internet e a aceleração da transformação digital, esse modelo começou a apresentar limitações severas. A necessidade crescente de respostas rápidas ao mercado, entrega contínua de valor e inovação constante evidenciou os gargalos desse modelo linear e fragmentado. Problemas antes considerados “administráveis” tornaram-se proibitivos, transformando-se em um freio para o crescimento de produtos e serviços digitais em escala.
Além disso, o modelo de governança, centrado em controle rígido de custos e minimização de riscos, não acompanhava a velocidade exigida pelas novas demandas do negócio. Foi nesse cenário que surgiram movimentos como o Manifesto Ágil, propondo uma abordagem mais flexível e iterativa. Dentre os métodos derivados desse movimento, destaca-se o DevOps, uma evolução direta dos princípios do Extreme Programming (XP), propondo integração entre desenvolvimento e operações para lidar com os desafios de entrega contínua, automação e colaboração multidisciplinar.
Principais Problemas Técnicos do Modelo Tradicional
- Infraestrutura durante o projeto: quem é responsável?
Durante o desenvolvimento, a responsabilidade pela provisão e gestão da infraestrutura frequentemente era difusa ou negligenciada. Isso gerava ambientes inconsistentes, atrasos e retrabalho, especialmente com a constante evolução das plataformas (bancos, serviços, SDKs, etc.). Sem uma infraestrutura como código ou ambientes versionados, o time ficava preso a soluções manuais e instáveis.
- Transição problemática entre projeto e operação
Projetos muitas vezes eram desenvolvidos com recursos simulados (mocks) e pouca paridade com o ambiente de produção. Isso gerava um vácuo técnico e financeiro na hora da transição: custos imprevistos, tempo adicional para ajustes e uma curva de aprendizado cara e arriscada para as equipes de operação.
- Ambientes de homologação desatualizados
Após a entrada em produção, o ambiente de homologação frequentemente ficava desalinhado com o ambiente real, dificultando correções, evolução e manutenção. Sem pipelines de integração contínua e deploy automatizado, as equipes de sustentação não tinham como testar de forma confiável, comprometendo a qualidade das entregas.
- Produção como único ponto de verdade (e falha)
Por seguir padrões mais rigorosos de segurança e compliance, o ambiente de produção era muitas vezes o único espelho real do sistema, sendo também o único onde certos erros ocorriam. Isso criava um paradoxo: o problema só aparece em produção, mas o time não tem acesso suficiente nem visibilidade adequada para analisá-lo com rapidez. A ausência de observabilidade estruturada (logs centralizados, métricas, tracing) tornava o diagnóstico lento e impreciso.
Novas Maneiras de Resolver esses Problemas
Com o surgimento do movimento Extreme Programming (XP) no final da década de 1990, liderado por Kent Beck, novas práticas começaram a transformar a maneira como o software era desenvolvido. Publicado em 1999 com o livro Extreme Programming Explained: Embrace Change, o XP propunha uma série de práticas que, combinadas, visavam aumentar a qualidade do software e sua capacidade de adaptação.
Entre essas práticas fundamentais, destacam-se:
- Integração Contínua (Continuous Integration) Formalizada no XP como uma prática essencial, propõe que todos os desenvolvedores integrem código com frequência, pelo menos uma vez ao dia, para evitar conflitos e acelerar a entrega de valor. ➤ Popularizada por Martin Fowler em 2000 com seu artigo Continuous Integration.
- Build em 10 minutos Definido como um dos requisitos do XP, esse princípio visava garantir que o processo de compilação, testes e empacotamento pudesse ser feito rapidamente, favorecendo ciclos curtos de feedback.
- Deploy automatizado Embora ainda embrionário no final dos anos 1990, o conceito de automação de deploy surgiu como desdobramento natural da integração contínua. Equipes começaram a automatizar o empacotamento e a entrega como extensão do processo de build.
Essas práticas criaram as bases para uma mudança cultural importante:
“A equipe que constrói o software também deve ser responsável por operá-lo.”
Essa ideia começaria a ganhar força real nos anos seguintes.
A Transição Cultural: de XP (1999) ao DevOps (2009)
Entre 1999 e 2010, vivenciamos uma transformação gradual:
- As equipes começaram a se responsabilizar não apenas pela entrega do código, mas também pela sua operação em produção.
- Esse período foi marcado por uma evolução na maturidade das práticas de engenharia de software, infraestrutura e colaboração.
- O foco passou de apenas “escrever código funcionando” para “entregar software confiável e observável em produção”.
A convergência entre práticas de XP, Lean e Agile levou ao surgimento, em 2009, do termo DevOps, cunhado por Patrick Debois — um consultor belga que organizou a primeira conferência DevOpsDays em Ghent.
DevOps formaliza o conceito cultural que já vinha emergindo nas equipes XP mais maduras:
“Não existe mais uma separação entre quem escreve o código e quem o coloca no ar.”
Esse princípio ficou conhecido como:
“You build it, you run it” — cunhado por Werner Vogels, CTO da Amazon, em 2006, como filosofia central do time da AWS.
A literatura sobre DevOps atualmente é vasta, diversa e amadurecida, refletindo a consolidação do movimento como um dos pilares da engenharia moderna de software. Obras como “The Phoenix Project” (2013) e “The DevOps Handbook” (2016), ambos de Gene Kim, contribuíram significativamente para popularizar os conceitos entre líderes técnicos e de negócios, ao mostrar como práticas como entrega contínua, infraestrutura como código, automação de testes e monitoramento estruturado impactam diretamente na performance organizacional.
O modelo tradicional de projetos e sustentação, baseado na separação CAPEX/OPEX, foi eficaz em um contexto industrial anterior. Contudo, os novos tempos exigem equipes multifuncionais, infraestrutura automatizada, cultura de colaboração e observabilidade plena. O surgimento de práticas como DevOps, GitOps, Platform Engineering e SRE não representa apenas uma modernização tecnológica — mas uma resposta organizacional à complexidade e velocidade do mundo digital atual.
Hoje, a literatura DevOps vai além dos aspectos técnicos e aborda temas como cultura de responsabilidade compartilhada, métricas de fluxo, segurança integrada (DevSecOps), plataformas internas de desenvolvimento (IDPs) e engenharia de confiabilidade (SRE), frequentemente conectando esses temas à agilidade organizacional e ao impacto direto na experiência do usuário. Além dos livros, há uma ampla produção de artigos, cases e white papers de empresas como Microsoft, AWS, Google, Netflix e GitHub, que enriquecem a base de conhecimento com aprendizados práticos em larga escala.
Evolução do DevOps
O movimento DevOps evoluiu significativamente ao longo dos anos, dando origem a especializações voltadas para contextos técnicos específicos, como forma de aprofundar práticas em domínios com necessidades distintas.
Um exemplo disso é o FrontOps, que aplica os princípios de automação, observabilidade e entrega contínua ao ecossistema de aplicações frontend — tradicionalmente menos integrado ao fluxo DevOps — tratando de desafios como versionamento de interfaces, testes visuais automatizados, distribuição em CDN e deploy progressivo (ex: feature flags e A/B testing).
Outra ramificação importante é o GitOps, que consolida o uso do Git como fonte única de verdade para operações de infraestrutura e aplicações, utilizando ferramentas como ArgoCD e Flux para aplicar mudanças de forma declarativa e auditável. Essas especializações refletem a maturidade do DevOps como filosofia adaptável, capaz de se moldar às diferentes camadas da stack tecnológica, promovendo eficiência, rastreabilidade e alinhamento entre times de desenvolvimento e operação em contextos cada vez mais complexos e distribuídos.
Papel do ProdDevOps
Apesar da ampla disseminação dos conceitos DevOps, muitas organizações ainda operam com estruturas baseadas no modelo tradicional de Projeto e Sustentação, caracterizado por forte separação entre times de desenvolvimento, operação e suporte. Nesses contextos, a tentativa de adotar uma cultura DevOps frequentemente esbarra em obstáculos como a fragmentação do ownership, a ausência de responsabilidade compartilhada pelo ciclo de vida completo do software e a falta de visibilidade sistêmica sobre problemas técnicos persistentes.
O framework ProdOps surge como uma abordagem pragmática para esse cenário, oferecendo modelos de atuação que ajudam a mapear e eliminar o TOIL — trabalhos operacionais manuais, repetitivos e de baixo valor — que o time DevOps precisa identificar e reduzir. A partir de técnicas como a criação de Planos de Confiabilidade, é possível estabelecer um ciclo estruturado de identificação de riscos, visibilidade de dívidas técnicas e planejamento incremental de melhorias.
Essa estratégia permite que o DevOps atue sem a necessidade de reestruturar toda a organização, alinhando-se ao espírito do Kanban: agir com os recursos e estrutura que já existem, promovendo mudanças evolutivas e visibilidade contínua. Com isso, cria-se um ambiente informativo onde todos os envolvidos podem compreender, priorizar e agir sobre os pontos críticos do sistema, elevando a confiabilidade e a fluidez do desenvolvimento mesmo dentro de estruturas tradicionais.
Maturidade das Capabilidades
Com o tempo, desenvolvemos um conjunto de modelos práticos para avaliar as capabilidades técnicas e operacionais das equipes, baseando-nos na literatura atual e nas boas práticas consolidadas do mercado. Esses modelos permitem que profissionais façam uma autoavaliação estruturada da maturidade de seus times e plataformas, considerando capabilidades em dimensões como automação, observabilidade, integração contínua, confiabilidade, governança de APIs, entre outras.
A partir dessa avaliação, é possível comparar o cenário atual com o estado da arte, identificando lacunas críticas e oportunidades de evolução. Para apoiar esse processo, fornecemos templates prontos para diagnóstico e planejamento, que ajudam os times a construir planos de melhoria sob medida, levando em conta suas restrições organizacionais, técnicas e culturais. Essa abordagem orientada por evidências favorece a evolução contínua e realista, sem depender de grandes reestruturações, e promove um ciclo de aprendizado onde a equipe ganha clareza sobre onde está, para onde pode ir e quais passos concretos tomar para alcançar esse próximo estágio.
A Carreira ProdDevOps
A carreira ProdDevOps surge como uma evolução natural do papel tradicional do DevOps, adaptada à realidade de organizações que buscam entregar produtos digitais com alta confiabilidade, agilidade e clareza operacional — mesmo em estruturas legadas ou fortemente baseadas em Projetos e Sustentação. O ProdDevOps atua como ponte entre produto, desenvolvimento e operação, com foco em garantir que a entrega de software seja contínua, observável, segura e sustentável ao longo do tempo.
Diferente do DevOps tradicional, que muitas vezes se limita à automação de infraestrutura ou integração de ferramentas, o ProdDevOps olha para a cadeia de valor como um todo, promovendo alinhamento entre os objetivos de negócio e as capacidades técnicas. Ele atua com mentalidade de produto, o que significa que valoriza não apenas a entrega, mas a experiência de uso, a resiliência da solução e os feedbacks em tempo real.
Comparativo entre o DevOps e a amplitude para ProdDevOps
| Dimensão | DevOps | ProdDevOps |
|---|---|---|
| Origem do Papel | Surge como extensão do movimento ágil e XP, integrando Dev + Ops. | Evolução do DevOps aplicada à realidade de produtos digitais complexos e empresas com estruturas legadas. |
| Foco Principal | Automatizar a entrega e integração de código com estabilidade. | Garantir confiabilidade, visibilidade técnica e evolução contínua do produto em produção. |
| Abordagem Técnica | Infraestrutura como código, CI/CD, automação de testes e deploys. | Inclui tudo do DevOps, mas também mapeia TOIL, dívidas técnicas, risco operacional e planos de confiabilidade. |
| Relacionamento com Produto | Suporte técnico para entregas do time de desenvolvimento. | Atua junto ao time de produto com mentalidade de ownership e evolução contínua da plataforma. |
| Entendimento de Negócio | Pode atuar de forma técnica isolada das decisões estratégicas. | Participa da priorização de melhorias técnicas que afetam o valor entregue ao usuário final. |
| Forma de Medir Sucesso | Tempo de build, frequência de deploys, taxa de falhas. | Redução de TOIL, melhoria de confiabilidade, visibilidade técnica e alinhamento com metas de produto. |
| Adoção de Métricas | DORA Metrics, cobertura de testes, uptime. | Métricas DORA + maturidade técnica, plano de confiabilidade e análise contínua de gargalos. |
| Atuação em Ambientes Legados | Exige mudanças estruturais ou encontra limitações organizacionais. | Usa frameworks como ProdOps para atuar sem reestruturações, aproveitando o que a organização já tem. |
| Integração com Especializações | Atua com DevSecOps, SRE, Platform, GitOps como extensões técnicas. | Integra essas áreas, mas com papel de facilitador e articulador técnico entre elas. |
| Responsabilidade sobre dívidas | Pode executar correções, mas nem sempre tem visibilidade ou poder de decisão. | Mapeia, comunica e planeja ações sobre dívidas técnicas com clareza e envolvimento do time. |
| Papel Cultural | Promove colaboração entre Dev e Ops. | Promove maturidade técnica, ownership e visão sistêmica entre Produto, Dev, QA, Sec e Operações. |
Papel do ProdDevOps em “Observabilidade em Primeiro Lugar”
Dentro do Framework ProdOps, o profissional ProdDevOps é o principal agente de articulação entre a intenção do negócio, a realidade técnica e a experiência operacional. Ele é quem viabiliza na prática a aplicação do princípio “Observabilidade em Primeiro Lugar”, desde a concepção do produto até sua operação em larga escala.
Enquanto o DevOps tradicional pode estar focado na automação de deploys e infraestrutura como código, o ProdDevOps atua de forma mais ampla e sistêmica: ele assegura que tudo o que for construído seja observável desde o início — e que essa observabilidade tenha valor tanto para os times técnicos quanto para o negócio.
Como o ProdDevOps concretiza esse princípio:
- No Discovery: participa ativamente das discussões iniciais de produto para garantir que as histórias e épicos já tragam critérios de observabilidade. Ele colabora com times de produto e arquitetura para que os objetivos de negócio sejam traduzidos em sinais mensuráveis e acionáveis.
- No Design da Solução: orienta os desenvolvedores a pensar em componentes que exponham logs úteis, métricas de comportamento e rastreamento distribuído, integrando boas práticas de diagnóstico desde o código-fonte.
- Na Implementação e Integração: lidera ou apoia a criação de pipelines de rastreabilidade completa, garantindo que do commit ao comportamento em produção tudo seja traçável, auditável e visível para todos os envolvidos.
- Na Operação e Evolução: atua na construção de painéis e alertas que cruzam dados técnicos com indicadores de experiência e negócio, permitindo decisões baseadas em dados reais, não em suposições.
- Na Cultura do Time: promove uma visão compartilhada da operação, reduzindo o TOIL com base em evidências, e incentivando práticas como postmortems acionáveis, melhoria contínua baseada em métricas e documentação viva da arquitetura operante.
Em suma, o ProdDevOps é quem transforma a observabilidade em uma alavanca de evolução técnica e de produto. Ele garante que cada linha de código seja construída para ser compreendida em execução, e que cada entrega venha acompanhada de uma visão clara de seu impacto. Sua atuação faz da observabilidade não apenas uma responsabilidade da operação, mas uma linguagem comum entre desenvolvimento, produto, segurança e negócio.