12.4
12.4 Autoavaliação de maturidade
Todo capítulo deste guia termina com um “Modelo de maturidade” que descreve como uma prática costuma evoluir. Este apêndice consolida o modelo de maturidade de cada capítulo numa única referência, para que vocês possam avaliar uma equipe, um domínio ou toda uma organização num relance.
A escala compartilhada de cinco níveis
Todos os capítulos descrevem a mesma progressão. A redação exata varia um pouco de capítulo para capítulo, mas a intenção se mapeia de forma limpa nestes cinco níveis:
- Nível 1, Iniciar. Ad hoc, reativo e movido por personalidades. As práticas existem apenas onde um indivíduo as escolhe, de modo que os resultados dependem de heroísmo e sorte.
- Nível 2, Desenvolver. Existem práticas básicas, mas elas são inconsistentes entre as equipes, em parte manuais e muitas vezes contornadas sob pressão.
- Nível 3, Padronizar. As práticas são documentadas, padronizadas e impostas em toda a organização. Este é o piso de auditoria e conformidade: o nível que a maior parte do trabalho corporativo e governamental precisa atingir para ser confiável e auditável.
- Nível 4, Gerenciar. As práticas são medidas e controladas com dados e métricas em relação a linhas de base. Vocês sabem quantitativamente como cada prática se desempenha e agem sobre os números.
- Nível 5, Orquestrar. As práticas são continuamente melhoradas, integradas em toda a organização e adaptativas. O caminho seguro ou correto é o padrão, e a organização aprende e evolui deliberadamente.
Como usá-la para a autoavaliação
- Para cada capítulo relevante ao seu contexto, leiam as cinco células abaixo e escolham o nível que descreve com honestidade o seu comportamento típico, não a sua melhor equipe no melhor dia, nem a sua política escrita, mas o que de fato acontece.
- Deem a cada capítulo uma nota de 1 a 5. Arredondem para baixo na dúvida; uma prática inconsistente é Nível 2, não Nível 3.
- Façam a média das notas dentro de uma parte para ver onde está um domínio inteiro e depois olhem a dispersão: uma parte com “3 em média” que esconde um capítulo de Nível 1 ainda tem um risco de Nível 1.
- Reavaliem periodicamente e acompanhem a tendência. O movimento importa mais que qualquer instantâneo isolado.
Maturidade é um meio, não um fim
Maior maturidade não é automaticamente melhor. O objetivo é o ajuste: rigor suficiente para gerir o risco e a escala que vocês de fato enfrentam, e não mais que isso. Uma ferramenta pequena e de baixo risco não precisa de engenharia do caos de Nível 5. Buscar um nível alto como troféu, e não para resolver um problema real, produz cerimônia sem valor. Leiam todo “Nível 5” abaixo como “apropriado quando os riscos justificam” e deixem o risco, a escala e a exposição regulatória decidirem até onde subir.
Parte 1. Pessoas
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Cultura e valores de engenharia | A cultura é acidental e movida por personalidades; incidentes significam culpa; o conhecimento vive na cabeça de poucos. | Algumas equipes fazem post-mortems e escrevem documentos, mas a prática é inconsistente e não é reforçada pela liderança. | Aprendizado sem atribuição de culpa, modelos de propriedade e uma cultura de escrita são normas de toda a organização, com expectativas e ferramentas claras. | A saúde da cultura é medida (pesquisas de segurança psicológica, taxas de aprendizado com incidentes, retenção), acompanhada em relação a linhas de base e atuada. | A cultura é continuamente melhorada e as práticas se espalham entre as equipes; a liderança adapta as normas conforme a organização cresce e aprende. |
| Topologias de equipe | As equipes se formam por acaso ou por número de pessoas; a estrutura espelha a hierarquia legada; dependências por toda parte. | Existem algumas equipes alinhadas ao fluxo, mas gargalos compartilhados e silos funcionais persistem. | Os quatro tipos de equipe e os modos de interação explícitos são usados deliberadamente; plataformas e InnerSource cortam dependências. | Carga cognitiva, fluxo e contagens de dependências são medidos por equipe contra metas; as fronteiras são ajustadas quando os números escorregam. | A organização remodela continuamente equipes e modos de interação para sustentar o fluxo conforme produtos e plataformas evoluem. |
| Papéis, trilhas de carreira, crescimento | Sem trilha escrita; promoções e salários são ad hoc e movidos por personalidades. | Existe uma trilha básica, mas aplicada de modo inconsistente; sem calibração; a contratação não é estruturada. | Trilhas duplas, uma matriz clara de competências, calibração e contratação estruturada são padrão. | Taxas de progressão, equidade salarial e tempo no nível são medidos contra linhas de base; os resultados da calibração são analisados quanto a viés. | O arcabouço evolui continuamente com o trabalho; o patrocínio e o aprendizado são deliberados e de toda a organização conforme os papéis mudam. |
| Formas de trabalhar | O processo é ad hoc ou de culto à forma; a comunicação é guiada por reuniões e não documentada; as estimativas são tratadas como promessas. | Uma metodologia é seguida de modo consistente, mas as cerimônias são mecânicas e a coordenação entre equipes é pesada. | As práticas são escolhidas para se ajustar ao contexto; a comunicação assíncrona e com documentos primeiro é a norma; a estimativa informa, não controla. | As métricas de fluxo (prazo de entrega, trabalho em andamento, vazão) são acompanhadas contra linhas de base e revisadas a cada ciclo. | As equipes ajustam continuamente sua forma de trabalhar a partir dessas métricas; a necessidade de coordenação é minimizada na origem e a boa prática se espalha por toda a organização. |
| Tomada de decisão e governança | As decisões são ad hoc e não registradas; a governança é ausente ou um gargalo generalizado; a dívida é invisível. | Algumas decisões são documentadas e existe alguma revisão, mas o processo é inconsistente e desproporcional ao peso da decisão. | ADRs, um caminho pavimentado, delegação baseada em reversibilidade e um inventário de dívida são padrão e transparentes. | O tempo de ciclo das decisões, as taxas de reversão e os níveis de dívida são medidos; o escrutínio é calibrado pelo peso da decisão contra esses números. | A governança é continuamente ajustada em toda a organização; o escrutínio mira as decisões irreversíveis; a dívida e a aquisição são geridas como portfólios em evolução. |
Parte 2. Programação de software
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Padrões e estilo de código | O estilo é por autor; sem configurações compartilhadas; a formatação é discutida na revisão. | Cada equipe tem um formatador e um linter, mas as configurações e regras variam entre as equipes. | Configurações compartilhadas centrais por linguagem; imposição no CI; novos repositórios herdam os padrões via modelos. | A adoção dos padrões, as taxas de violação e o impacto no tempo de revisão são medidos contra linhas de base; as configurações são versionadas e governadas. | Os padrões são continuamente refinados a partir desses dados e compartilhados por toda a organização; a imposição é quase sem atrito e se adapta a novas linguagens. |
| Princípios de projeto de software | O projeto é ad hoc; o acoplamento se acumula; os princípios são desconhecidos ou invocados como slogans. | As equipes conhecem os princípios e os aplicam, mas de modo inconsistente e muitas vezes dogmático. | Vocabulário de projeto compartilhado, análise deliberada de acoplamento/coesão e contextos delimitados alinhados às equipes. | Métricas de acoplamento, coesão e falha de mudanças informam as revisões de projeto contra linhas de base; as decisões são registradas. | As decisões de projeto são revisitadas conforme as evidências se acumulam; os princípios são aplicados com nuance e as escolhas de paradigma se adaptam em toda a organização conforme o domínio evolui. |
| APIs e projeto de interfaces | As APIs emergem da implementação; sem convenções compartilhadas; mudanças incompatíveis são comuns e sem aviso. | As equipes seguem convenções REST básicas e versionam informalmente, mas a consistência e a documentação variam. | Projeto com contrato primeiro, especificações legíveis por máquina, uma política de descontinuação e convenções consistentes de erro/paginação. | Adoção, latência, taxas de erro e frequência de mudanças incompatíveis são medidas por API contra metas. | As APIs são produtos governados num catálogo com forte DevEx; a prática se adapta continuamente e as quebras são raras e bem geridas em toda a organização. |
| Estratégia de testes | O teste é manual e ad hoc; a cobertura automatizada é mínima; as regressões são frequentes. | Existem testes unitários automatizados e alguns de integração, mas a suíte é lenta ou instável e a confiança é baixa. | Uma suíte equilibrada, rápida e confiável condiciona cada mudança; a instabilidade é gerida; o teste não funcional é integrado. | Cobertura, instabilidade, defeitos escapados e duração da suíte são acompanhados contra linhas de base para direcionar o esforço. | Técnicas avançadas (propriedades, mutação, fuzz) miram o código de alto valor; a estratégia melhora continuamente e se espalha entre as equipes. |
| Revisão de código e colaboração | A revisão é inconsistente ou pulada; os problemas mecânicos dominam; as normas de feedback não estão definidas. | A revisão é exigida mas lenta e variável; a automação é parcial; o tamanho e a qualidade dos PRs variam muito. | PRs pequenos, verificações mecânicas automatizadas, padrões e normas de feedback claros e latência monitorada. | Latência de revisão, tamanho de PR e taxas de escape de defeitos são acompanhados contra metas; a profundidade é ajustada ao risco medido. | A organização melhora continuamente a revisão a partir desses dados; a programação em par e a assistência de IA são adotadas deliberadamente e as práticas se espalham entre as equipes. |
| Controle de versão e gestão de código-fonte | Ramificação ad hoc; branches de vida longa; mensagens ruins; sem varredura de segredos; dor frequente de merge. | Existem um modelo de ramificação consistente e convenções de mensagem, mas os branches vivem demais e a imposição é parcial. | Desenvolvimento baseado em trunk, linha principal protegida, convenções de commit impostas, varredura de segredos, estrutura de repositório deliberada. | A vida dos branches, a frequência de merge e as taxas de reversão são medidas contra as métricas de entrega e linhas de base. | A automação impõe a higiene de ponta a ponta; a estrutura de repositório e o fluxo evoluem continuamente em toda a organização conforme as necessidades de entrega mudam. |
| Documentação | A documentação é escassa, dispersa e obsoleta; o conhecimento vive na cabeça das pessoas. | Existem documentos-chave (READMEs, alguns runbooks), mas são mantidos de modo inconsistente e difíceis de achar. | Documentação como código com estrutura clara, documentação de API e changelogs gerados, registros de decisão e expectativas de atualização. | Cobertura, atualidade e precisão da documentação são medidas contra linhas de base; a obsolescência é sinalizada automaticamente. | A documentação é viva, em grande parte gerada ou testada contra o sistema, com dono e descobrível; a prática melhora continuamente em toda a organização. |
Parte 3. Sistemas
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Fundamentos de arquitetura | A arquitetura é implícita e vive nas cabeças; sem atributos de qualidade nem ADRs; as decisões surgem durante incidentes. | Existem diagramas-chave e as grandes decisões às vezes são registradas; os atributos de qualidade são nomeados mas raramente quantificados; a documentação deriva. | Cenários de atributos de qualidade e ASRs são especificados; ADRs rotineiros; documentos C4/arc42 mantidos perto do código; ocorrem revisões de compromissos. | As funções de aptidão impõem atributos de qualidade no CI e registram resultados medidos contra linhas de base; os compromissos são quantificados. | A arquitetura evolui continuamente com esses dados em toda a organização; a documentação permanece confiável o bastante para os auditores conforme o sistema se adapta. |
| Estilos e padrões arquiteturais | Um monolito emaranhado ou uma bagunça distribuída acidental; as fronteiras seguem camadas ou a história; o estilo é escolhido por moda. | Fronteiras modulares deliberadas ou poucos serviços grossos; algumas preocupações transversais consistentes; as divisões ainda são ad hoc. | Serviços alinhados a contextos delimitados que são donos de seus dados; gateway/BFF onde cabível; camadas limpas/hexagonais padrão. | As decisões de estilo são baseadas em evidências, usando dados medidos de acoplamento, latência e custo de mudança contra linhas de base. | Uma plataforma madura torna barata a distribuição; a organização reconsolida quando uma divisão deixa de compensar e adapta o estilo conforme as evidências mudam. |
| Sistemas distribuídos | Chamadas remotas tratadas como locais; repetições ausentes ou ingênuas; as falhas se propagam em cascata; a depuração é garimpar logs máquina a máquina. | Existem timeouts e repetições básicas, mas inconsistentes; alguma idempotência; logs centralizados mas não correlacionados. | Idempotência, recuo exponencial, disjuntores e anteparas por bibliotecas compartilhadas; sagas; rastreamento distribuído; consistência documentada por fluxo. | A resiliência é medida contra SLOs; resultados de injeção de falhas e taxas de falha são acompanhados contra linhas de base. | A resiliência é o padrão da plataforma, continuamente testada com injeção de falhas; a degradação graciosa é projetada e evolui em toda a organização. |
| Arquitetura e armazenamento de dados | Um banco de dados para todos os fins; sem disciplina de migração; cache incidental; escala por máquina maior. | As escolhas de armazenamento são em sua maioria deliberadas; um cache e talvez um warehouse; migrações versionadas às vezes exigem indisponibilidade. | Persistência poliglota ajustada às cargas, cada repositório com dono; migrações automatizadas sem indisponibilidade; cache e réplicas explícitos. | As escolhas de armazenamento são medidas contra padrões de acesso, latência e linhas de base de custo; as decisões de sharding e cache são guiadas por dados. | A arquitetura de dados é continuamente revista e evoluída em toda a organização; as migrações são automatizadas e auditadas conforme as cargas mudam. |
| Escalabilidade, desempenho, resiliência | Instância única ou escalada verticalmente; estado no servidor; sem teste de carga nem orçamentos; as falhas causam quedas totais. | Camadas sem estado escaladas horizontalmente; escalonamento automático básico; algum teste de carga pré-lançamento; DR documentado mas raramente testado. | Capacidade planejada com folga; orçamentos de desempenho no CI; padrões de resiliência padrão; RTO/RPO definidos e DR testado. | A capacidade é prevista a partir da carga medida; os orçamentos de desempenho e RTO/RPO são acompanhados contra linhas de base. | Failover automatizado multirregião, caos contínuo e game days provam e melhoram os objetivos de recuperação conforme o sistema evolui em toda a organização. |
| Modernização de legado | O legado é temido e congelado; sem inventário; a modernização é uma reescrita tudo ou nada; o conhecimento está em cabeças que se aposentam. | Existe um inventário e algum risco é compreendido; o legado é envolvido em APIs; ainda pensamento big-bang; a migração é subestimada. | Os sistemas são priorizados por risco e valor; strangler-fig e branch-by-abstraction são padrão; a migração é reconciliada com execução em paralelo. | A modernização é gerida como portfólio com risco, valor e progresso medidos contra linhas de base. | A modernização é contínua em toda a organização; a substituição incremental é rotineira, reversível e se adapta conforme as prioridades mudam. |
Parte 4. Segurança
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Fundamentos e cultura de segurança | A segurança é reativa e centralizada; revisões tardias, se houver; sem modelagem de ameaças; a segurança é “problema de outro”. | Uma equipe de segurança define padrões; alguma modelagem de ameaças nos grandes projetos; treinamento básico; a segurança é vista como portão. | Campeões de segurança embutidos; modelagem de ameaças rotineira; SDLC seguro documentado; priorização baseada em risco; revisões sem atribuição de culpa. | As métricas de segurança (cobertura de modelagem de ameaças, tempo do achado à correção, adoção de controles) são acompanhadas contra linhas de base. | A segurança é genuinamente trabalho de todos; a modelagem de ameaças é habitual; o zero-trust é em grande parte realizado e a prática melhora continuamente em toda a organização. |
| Segurança de aplicações | A segurança depende do conhecimento individual; sem controles padrão; segredos no código; dependências obsoletas; autenticação ad hoc. | Consciência do OWASP Top 10; algumas proteções de framework; gerenciador de segredos usado de modo desigual; varredura ocasional de dependências. | Requisitos baseados no ASVS por camada; consultas parametrizadas; identidade central com MFA; segredos gerenciados; SBOMs e varredura no pipeline. | A densidade de vulnerabilidades, o tempo médio de remediação e a cobertura de controles são medidos contra linhas de base entre os serviços. | Padrões seguros vêm nos frameworks do caminho pavimentado; credenciais de curta duração e garantia completa da cadeia de suprimentos (SLSA) são verificadas continuamente em toda a organização. |
| Segurança de infraestrutura e nuvem | Provisionamento manual; permissões amplas e chaves estáticas; redes planas; criptografia inconsistente; sem gestão de postura. | Alguns papéis de IAM e MFA; camadas de rede básicas; criptografia em repouso nos grandes repositórios; revisões manuais periódicas; IaC parcial. | RBAC/ABAC de privilégio mínimo com credenciais de curta duração; segmentação de negação por padrão; criptografia por padrão com KMS; CSPM com política. | Métricas de postura, deriva e violação de política são acompanhadas contra linhas de base; a eficácia dos guardrails é medida. | Padrões seguros vêm nas landing zones e na IaC; a microssegmentação e os guardrails preventivos evoluem continuamente e a deriva é remediada automaticamente em toda a organização. |
| Operações de segurança | Teste de segurança manual e raro; sem log central nem SIEM; sem plano de incidentes; correções ad hoc; nunca testado de forma adversarial. | Alguns scanners no pipeline; log central; um plano básico de incidentes; prazos frouxos de correção; teste de intrusão anual. | Varredura DevSecOps completa com portões baseados em risco; SIEM com algum SOAR; resposta a incidentes ensaiada com simulações de mesa; SLAs de remediação; red teaming. | MTTD e MTTR são medidos contra linhas de base; a cobertura de detecção é mapeada às técnicas de adversários e acompanhada. | O teste e a resposta são altamente automatizados; o purple teaming e a engenharia de detecção melhoram continuamente e se adaptam a novas ameaças em toda a organização. |
| Privacidade e proteção de dados | Dados pessoais coletados livremente; sem inventário, minimização nem retenção; o consentimento é uma ideia de última hora; sem processo de direitos. | Existem uma política de privacidade e consentimento básico; alguma consciência de retenção; pedidos de direitos tratados manualmente e devagar. | Privacidade desde a concepção com DPIAs; dados mapeados e classificados; retenção imposta; base legal documentada; direitos atendidos no prazo. | A postura de privacidade é medida: cobertura do inventário de dados, conformidade de retenção e tempo de resposta a pedidos de direitos contra linhas de base. | A privacidade é uma restrição padrão de engenharia; a minimização e a retenção automatizada são padrão; os pedidos de direitos são de autoatendimento e a prática se adapta em toda a organização. |
| Conformidade e governança | A conformidade é reativa; sem arcabouço de controles; evidências montadas manualmente sob prazo; achados frequentes. | Arcabouços-chave identificados; alguns controles documentados; as auditorias passam com muito esforço manual; a acessibilidade é considerada tarde. | Um arcabouço de controles unificado mapeia os padrões entre si; evidências parcialmente automatizadas; acessibilidade testada; registros e autorizações estabelecidos. | A eficácia dos controles e a cobertura de evidências são medidas continuamente contra linhas de base; os achados são acompanhados em tendência. | A conformidade é contínua, com evidências sempre ativas e conformidade como código; novas certificações são de baixo custo e o arcabouço se adapta em toda a organização, pronto para auditoria a qualquer momento. |
Parte 5. Design de UI/UX
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Fundamentos de UX | Sem prática dedicada de UX; decisões por opinião; pesquisa ad hoc; fluxos e terminologia inconsistentes. | Alguns designers e teste de usabilidade ocasional; personas sem manutenção; a UX é uma fase, muitas vezes contornada. | Pesquisa contínua de métodos mistos alimenta a priorização; personas, mapas de jornada e AI compartilhados; portões de qualidade de UX na Definição de Pronto. | As métricas de UX (sucesso nas tarefas, satisfação, pontuações de usabilidade) são acompanhadas contra linhas de base ao lado das métricas de negócio. | A pesquisa é contínua e ligada a resultados; experimentos controlados fecham o ciclo e os insights se espalham entre as equipes conforme os produtos evoluem. |
| Design de UI e sistemas de design | Cada equipe constrói sua própria UI; sem componentes compartilhados; visual inconsistente; cores e espaçamento fixados no código. | Existe um guia de estilo ou biblioteca de componentes parcial, mas opcional e muitas vezes fora de sincronia entre design e código. | Um sistema de design com tokens e uma biblioteca em código mantida, documentação e governança é usado entre as equipes; a11y embutida. | A paridade design-código, a adoção de componentes e a deriva são medidas contra linhas de base; o versionamento é acompanhado. | O sistema é um produto governado com roteiro; melhora continuamente em toda a organização e as mudanças de marca viram mudanças de tokens. |
| Acessibilidade | Sem prática de acessibilidade; problemas descobertos por reclamação ou processo; marcação não semântica e não testada. | Existe consciência; alguma varredura automatizada e uma auditoria pré-lançamento; a a11y é uma lista tardia, muitas vezes despriorizada. | A WCAG 2.2 AA é o padrão; a a11y é embutida no sistema de design, testada e na Definição de Pronto; as equipes são treinadas e há um dono. | A conformidade de acessibilidade é medida no CI contra linhas de base da WCAG; as taxas de defeitos e os resultados de auditoria são acompanhados. | A acessibilidade é contínua; pessoas com deficiência participam da pesquisa; está embutida na contratação, nos tokens e no CI e melhora em toda a organização. |
| Design de conteúdo e comunicação | Sem prática de conteúdo; palavras escritas ad hoc; terminologia e tom inconsistentes; erros e estados vazios inúteis. | Pode existir um guia de estilo; alguma consciência de linguagem simples; o conteúdo ainda é de fase final e por equipe, com pouco reúso. | Uma estratégia de conteúdo, um guia de voz e tom e um glossário usados entre as equipes; linguagem simples como padrão; padrões compartilhados. | O conteúdo é medido contra resultados (compreensão, conclusão de tarefas, taxas de erro) em relação a linhas de base. | O conteúdo é continuamente melhorado a partir dessa evidência; os padrões obscuros (dark patterns) são proibidos e auditados; os padrões são localizados e acessíveis por padrão em toda a organização. |
| Internacionalização e localização | Um só idioma; strings fixadas no código; suposições não Unicode; novos locales exigem mudanças de código. | Strings externalizadas e Unicode usado, mas a localização é um lote manual pré-lançamento; formatação e plurais inconsistentes. | Arquitetura i18n compartilhada e formatação sensível ao locale; um TMS e um pipeline contínuo; pseudolocalização e CI multilocale. | A cobertura de localização, a atualidade das strings e as taxas de defeitos por locale são medidas contra linhas de base. | A i18n é imposta por ferramentas e lint entre as equipes; a localização é contínua, a adaptação cultural é sistemática e novos locales são lançados rapidamente. |
| Engenharia de frontend | Frontend ad hoc por equipe; muito código no cliente; sem orçamentos; testado só nos dispositivos da equipe; framework por moda. | Algumas ferramentas compartilhadas e uma biblioteca de componentes; o desempenho é medido ocasionalmente, não orçado; teste limitado entre dispositivos. | Framework e renderização escolhidos deliberadamente por superfície; orçamentos impostos no CI com RUM; aprimoramento progressivo padrão. | Desempenho, resiliência e alcance são medidos contra linhas de base de usuários reais e orçamentos; as regressões quebram o build. | Esses sinais são ligados a resultados e continuamente melhorados entre as superfícies conforme o frontend e seus usuários evoluem. |
Parte 6. Inteligência artificial
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Estratégia e prontidão de IA | Experimentos ad hoc; sem estratégia compartilhada; decisões movidas por moda e entusiasmo individual. | Enquadramento de problema em alguns projetos; uma primeira linha de base de plataforma; construir versus comprar discutido de modo inconsistente. | Um portfólio de casos de uso com métricas claras, uma árvore de decisão, avaliações de prontidão e análise de aprisionamento (lock-in) e TCO. | O valor dos casos de uso, a adoção e a prontidão são medidos contra linhas de base; o ROI do portfólio é acompanhado. | A estratégia de IA é integrada ao planejamento de negócio e de risco; a prontidão é mantida continuamente e os sistemas têm o escopo redefinido com base em evidências em toda a organização. |
| MLOps | Modelos construídos ad hoc em notebooks; implantação manual; sem versionamento de dados/modelos; sem monitoramento. | Algum acompanhamento de experimentos e um registro de modelos; implantação semiautomatizada; monitoramento básico para alguns modelos. | Plataforma compartilhada com feature store, registro, pipelines reproduzíveis, linhagem; monitoramento de deriva/qualidade; promoção governada. | A qualidade do modelo, a deriva e o impacto no negócio são medidos contra linhas de base; o retreinamento é disparado por limiares com portões. | O ciclo de vida é totalmente automatizado e auditável; caminhos pavimentados de autoatendimento e avaliação contínua melhoram os modelos em toda a organização conforme os dados mudam. |
| IA generativa e aplicações de LLM | Prompting ad hoc em projetos isolados; sem fundamentação, guardrails nem avaliação; alucinações descobertas em produção. | Algum RAG e versionamento de prompts; validação básica de saída; um pequeno conjunto de avaliação manual. | Padrões compartilhados para RAG, guardrails e uso de ferramentas; avaliação offline automatizada a cada mudança; métricas online e revisão humana. | As pontuações de avaliação offline e online e as taxas de alucinação e de injeção são medidas contra linhas de base. | A avaliação é ligada a resultados e melhora continuamente; as defesas contra injeção, agentes governados e observáveis e a mitigação se adaptam em toda a organização. |
| Desenvolvimento de software assistido por IA | Indivíduos usam assistentes ad hoc; sem política; sem medição; segredos e PI em risco. | Orientação básica de uso e regras de dados; alguma varredura de segurança; alegações anedóticas de produtividade. | Normas claras por nível de risco; revisão e varredura obrigatórias; métricas honestas de resultado; implantação segura e divulgação. | O impacto da assistência na entrega e na qualidade é medido contra linhas de base; a cobertura de verificação é acompanhada. | A verificação é forte no pipeline; o desenvolvimento de habilidades é deliberado e a política se adapta continuamente conforme as ferramentas e as evidências mudam em toda a organização. |
| IA responsável e confiável | Sem teste de equidade, explicações nem governança; responsabilidade indefinida; problemas descobertos só depois do dano. | Algum teste de viés e documentação; supervisão ad hoc; consciência do arcabouço mas adoção parcial. | Governança mapeada a arcabouços reconhecidos; teste sistemático de equidade/segurança/privacidade; supervisão e recursos documentados; red teaming. | As métricas de equidade, segurança e privacidade são monitoradas em produção contra linhas de base e limiares. | A governança é integrada à entrega; a responsabilidade é de todos e a abordagem melhora continuamente em toda a organização. |
| Infraestrutura e operações de IA | Alocação de GPU ad hoc; sem batching nem cache; sem visibilidade de custo; prompts sem versão; monitoramento mínimo. | Algum agendamento e cache compartilhados; acompanhamento básico de custo; prompts no controle de versão; avaliação ad hoc. | Plataforma compartilhada com agendamento, cotas, batching, cache, dimensionamento correto; infraestrutura vetorial; avaliação automatizada; atribuição de custo. | A utilização, o custo por resultado e a latência são medidos contra linhas de base; orçamentos e cotas são impostos. | O roteamento e o escalonamento são automatizados, a observabilidade de LLMOps é completa e a utilização e o custo são continuamente otimizados com portabilidade mantida em toda a organização. |
Parte 7. Dados, análise e insight
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Estratégia e governança de dados | Dados não documentados e sem dono; definições conflitantes; qualidade descoberta quando os relatórios quebram; sem catálogo nem linhagem. | Alguns conjuntos de dados têm donos e documentos; um catálogo parcial; verificações de qualidade manuais e reativas; política escrita mas pouco imposta. | Os produtos de dados críticos têm donos, contratos, SLAs; catálogo com linhagem automatizada; qualidade contínua; governança federada. | A qualidade dos dados, a conformidade com contratos e a atualidade são medidas contra SLAs e linhas de base. | Dados como produto é a norma; os contratos são impostos automaticamente, os guardrails de autoatendimento se adaptam e as definições são confiáveis em toda a empresa. |
| Engenharia de dados | Scripts ad hoc, execuções manuais, sem testes nem monitoramento; falhas descobertas pelos consumidores; custos não geridos. | Alguma orquestração e agendamento; transformações básicas no controle de versão; testes ocasionais; apagar incêndios reativo. | ELT com modelos em camadas, testados e versionados; dependências orquestradas com repetições/preenchimentos retroativos; observabilidade; custos acompanhados. | A confiabilidade, a atualidade e o custo dos pipelines são medidos contra SLAs; as anomalias são detectadas contra linhas de base. | Os pipelines são software com CI/CD, contratos e testes; a plataforma melhora continuamente e novos produtos de dados são entregues rápido em toda a organização. |
| Análise e inteligência de negócios | Relatórios construídos ad hoc em planilhas; métricas inconsistentes; gráficos enganosos; sem governança. | Uma ferramenta de BI com alguns painéis compartilhados; as definições de métricas ainda divergem; autoatendimento descontrolado e dispersão começam. | Uma camada semântica define as métricas centrais uma vez; conteúdo certificado versus experimental; autoatendimento dentro de guardrails; ciclo de vida gerido. | O uso das métricas, a atualidade e as mudanças de definição são acompanhados contra linhas de base; o conteúdo certificado é monitorado. | As métricas são governadas como APIs com donos e changelogs; a análise vai do descritivo ao prescritivo e se embute nos pontos de decisão em toda a organização. |
| Análise de produto e experimentação | Pouca instrumentação ou inconsistente; decisões por opinião; sem experimentos; métricas de vaidade; consentimento descuidado. | Alguns eventos rastreados mas taxonomia inconsistente; testes A/B ocasionais sem análise de poder; estrela-guia proposta, não embutida. | Um plano de rastreamento governado e validado; funis/coortes/retenção rotineiros; experimentos numa plataforma compartilhada; consentimento tratado corretamente. | O volume de experimentos, o poder e as taxas de vitória são medidos contra linhas de base; a cobertura de instrumentação é acompanhada. | A experimentação é o padrão; um repositório compartilhado de resultados e instrumentação com dono permitem à organização aprender de forma cumulativa e se adaptar. |
| Ciência da decisão e cultura de dados | Decisões por hierarquia e intuição; correlação tratada como causação; incerteza ignorada; as métricas vigiam e são manipuladas. | Dados consultados seletivamente para justificar decisões; alguma consciência de armadilhas causais; incerteza raramente comunicada. | Análises ligadas a decisões com critérios predefinidos; correlação e causação distinguidas; incerteza comunicada; foco em resultado. | A qualidade das decisões e a calibração das previsões são acompanhadas contra resultados e linhas de base. | “O que mudaria a nossa opinião?” é rotina; o rigor causal e a incerteza honesta são normas e os líderes se atualizam visivelmente com base em evidências em toda a organização. |
Parte 8. Automação
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| CI/CD e entrega | Builds e implantações em grande parte manuais e inconsistentes; integração tardia; lançamentos raros e estressantes; rollback manual. | Builds e testes unitários automatizados por commit; implantações com script mas supervisionadas manualmente; artefatos podem ser reconstruídos a cada estágio. | Um pipeline padronizado promove um artefato imutável entre ambientes com portões automatizados; canário/azul-verde; registros de mudança automáticos. | As métricas DORA (prazo de entrega, frequência de implantação, taxa de falha de mudanças, MTTR) são acompanhadas contra linhas de base e condicionam rollbacks. | A entrega progressiva desacopla o lançamento via flags; o pipeline se autoaperfeiçoa e a evidência de conformidade é automática em toda a organização. |
| Infraestrutura como código e configuração | Infraestrutura provisionada manualmente; ambientes inconsistentes e não documentados; recuperação lenta e incerta. | Alguma infraestrutura com script, mas as práticas variam; estado inconsistente; deriva comum; política imposta por revisão manual. | IaC declarativa padrão a partir de módulos compartilhados e versionados com estado remoto; guardrails de política como código; detecção regular de deriva. | A deriva, o tempo de provisionamento e as taxas de violação de política são medidos contra linhas de base; a evidência de conformidade é automática. | A infraestrutura é imutável, guiada por GitOps e autorrecuperável; a biblioteca de módulos e de políticas melhora continuamente e se adapta em toda a organização. |
| Contêineres, orquestração, nativo de nuvem | Contêineres usados ad hoc; imagens construídas à mão e não varridas; implantação manual; sem plataforma compartilhada nem modelo de isolamento. | As equipes conteinerizam e usam um orquestrador, mas as práticas variam; varredura e limites inconsistentes; custo e multilocação não governados. | Uma plataforma padronizada com imagens endurecidas, portões de assinatura/varredura, multilocação por namespace com cotas e política de rede, alocação de custo. | Utilização, densidade e custo por carga de trabalho são medidos contra linhas de base; a otimização de FinOps é guiada por dados. | Uma plataforma de autoatendimento e autorrecuperável, com forte multilocação, permanece portátil e pronta para híbrido/soberano e melhora continuamente em toda a organização. |
| Engenharia de plataforma e DevEx | Sem plataforma; cada equipe monta suas ferramentas de modo inconsistente; passagens de bastão por chamados; alta carga cognitiva. | Algumas ferramentas e modelos compartilhados, mas fragmentados e em parte manuais; autoatendimento limitado; DevEx não medida. | Uma equipe de plataforma mantém caminhos dourados, provisionamento de autoatendimento, um portal do desenvolvedor e scorecards; guardrails nos caminhos pavimentados; DevEx medida. | A adoção, as pontuações de DevEx e os sinais de carga cognitiva são medidos contra linhas de base e revisados. | Um produto de plataforma maduro melhora continuamente com esse feedback; a adoção voluntária é alta e a governança permanece invisível no fluxo de trabalho em toda a organização. |
| Automação de testes e de processos | Testes e operações em grande parte manuais; cobertura inconsistente; procedimentos nas cabeças ou em documentos obsoletos; evidência de conformidade à mão. | Existem testes automatizados mas lentos/instáveis e executados de modo inconsistente; alguns scripts operacionais; remediação manual; governança por revisão periódica. | Infraestrutura de testes rápida, paralela e confiável; runbooks codificados; ChatOps; evidência de conformidade gerada automaticamente; governança como verificações automatizadas. | A cobertura de automação, as taxas de falsos positivos e os tempos de remediação são medidos contra linhas de base. | Os incidentes rotineiros são autorremediados com salvaguardas; a conformidade é contínua e pronta para auditoria e os humanos focam o julgamento em toda a organização. |
Parte 9. Operações, confiabilidade e observabilidade
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Engenharia de confiabilidade de sites | Operações manuais e reativas; sem SLOs; a confiabilidade é opinião; os mesmos incidentes se repetem; apagar incêndios domina. | Os serviços-chave têm SLIs/SLOs básicos; algum monitoramento e alertas; o trabalho repetitivo é reconhecido mas não medido; post-mortems inconsistentes. | Os orçamentos de erros influenciam a priorização; o trabalho repetitivo é medido e limitado; planejamento rotineiro de capacidade; automação financiada; PRR e modelo de engajamento. | Os orçamentos de erros, o trabalho repetitivo e o cumprimento dos SLOs são medidos contra linhas de base e conduzem a priorização. | A política de orçamento de erros é automatizada e respeitada; operações de autoatendimento e capacidade proativa deixam a organização trocar velocidade e estabilidade com base em dados e se adaptar. |
| Observabilidade e monitoramento | Verificações básicas de disponibilidade e logs não estruturados por máquina; depurar significa SSH; alertas ruidosos e ignorados. | Métricas centralizadas e agregação de logs; alguns painéis e alertas por limiar; traces parciais ou ausentes; correlação manual. | Instrumentação OpenTelemetry com IDs de trace propagados; logs estruturados, rastreamento, painéis curados, alertas de sintoma por SLO; sobreaviso sustentável. | A qualidade dos alertas, o MTTD e o custo de telemetria são medidos contra linhas de base; os alertas de taxa de queima são ajustados aos SLOs. | A observabilidade de alta cardinalidade e rica em eventos sustenta a investigação ad hoc; a retenção é otimizada em custo e a telemetria informa decisões em toda a organização. |
| Gestão de incidentes | Incidentes tratados ad hoc por quem notar; sem papéis, gravidades nem post-mortems; sobreaviso informal; as falhas se repetem. | Rodízios de sobreaviso e gravidades básicos; alguns post-mortems, mas papéis pouco claros e ações corretivas acompanhadas de modo inconsistente. | Um sistema formal de comando de incidentes com papéis e critérios claros; post-mortems sem atribuição de culpa padrão; ações acompanhadas; sobreaviso remunerado. | A frequência de incidentes, o MTTR e a carga de sobreaviso são medidos contra linhas de base; as causas recorrentes são acompanhadas em tendência. | A resposta é ensaiada por game days; o sobreaviso permanece sustentável e calmo e a análise agregada conduz o investimento estrutural conforme a organização aprende. |
| Custo, sustentabilidade, software verde | Os custos de nuvem são uma surpresa mensal; sem etiquetagem, alocação nem consciência de carbono; provisionamento generoso e nunca revisitado. | Visibilidade básica de custo e etiquetagem; algum redimensionamento reativo e limpeza do ocioso; a sustentabilidade é reconhecida mas não medida. | Uma prática de FinOps com atribuição, orçamentos, previsões, alertas de anomalia, compromissos, redimensionamento; carbono medido nos serviços principais. | Custo e carbono são medidos por equipe contra orçamentos e linhas de base; as anomalias são sinalizadas. | Custo e carbono são sinais contínuos de que as equipes são donas; padrões eficientes, otimização automatizada e agendamento ciente de carbono melhoram continuamente em toda a organização. |
Parte 10. Gestão de projetos, produtos e programas
| Tópico | Nível 1 Iniciar | Nível 2 Desenvolver | Nível 3 Padronizar | Nível 4 Gerenciar | Nível 5 Orquestrar |
|---|---|---|---|---|---|
| Gestão de portfólio e de programas | Prioridades definidas ad hoc por quem pede mais alto; sem visão de portfólio; dependências surgem como crises; correrias anuais de financiamento. | Um inventário de portfólio revisado periodicamente; objetivos publicados fracamente ligados ao trabalho; um registro de dependências; orçamentação por projeto. | A estratégia desce em cascata via OKRs; um arcabouço consistente de priorização; planejamento entre equipes gere as dependências; financiamento persistente de equipes. | Os resultados do portfólio, a previsibilidade da entrega e as contagens de dependências são medidos contra linhas de base. | O portfólio é continuamente reequilibrado com base em evidências de resultado; as dependências são eliminadas por projeto e a cadência de financiamento acompanha a cadência de aprendizado em toda a organização. |
| Risco, auditoria e garantia | O risco é tratado de forma reativa após incidentes; sem arcabouço nem registro; controles não documentados; auditorias manuais dolorosas. | Registros de risco para os grandes sistemas; um arcabouço de controles adotado, as auditorias passam mas são manuais e pontuais; fornecedores avaliados na integração. | Modelo de três linhas e arcabouço comum em toda a organização; muitos controles automatizados; monitoramento contínuo; inventários de fornecedores/SBOM; DR agendado. | A eficácia dos controles, as contagens de riscos abertos e os achados de auditoria são medidos contra o apetite de risco e linhas de base. | A garantia é contínua e em grande parte automatizada; os auditores amostram evidências ao vivo e a integridade da cadeia de suprimentos é verificada conforme os riscos evoluem em toda a organização. |
| Contratação, código aberto, licenciamento | Código aberto adicionado livremente; sem política nem inventário; licenças sem exame; fim de vida descoberto por acidente; sem dono. | Uma política básica e uma lista de licenças aprovadas; alguma varredura manual/tardia; um inventário dos grandes sistemas; contribuição ad hoc. | Um OSPO é dono da estratégia e das ferramentas; varredura automatizada de licenças/vulnerabilidades e atribuição; SBOMs; contribuição clara; EOL acompanhado. | A conformidade de licenças, a atualidade das dependências e a exposição a vulnerabilidades são medidas contra linhas de base. | O código aberto é um ativo estratégico gerido com conformidade totalmente automatizada; o investimento upstream é deliberado e a atualidade e o EOL são geridos continuamente em toda a organização. |
| Sustentação de sistemas grandes e de longa vida | Os sistemas dependem de heróis; a propriedade é por memória; conhecimento não documentado; sistemas congelados até quebrar; as aposentadorias nunca terminam. | Propriedade atribuída e registrada para os grandes sistemas; alguns documentos e runbooks; as funções críticas óbvias têm uma pessoa de reserva; manutenção reativa. | Propriedade em nível de equipe num catálogo que sobrevive a reorganizações; fator ônibus medido e mitigado; registros de decisão e runbooks; modernização incremental. | O fator ônibus, a cobertura de propriedade e o progresso da transferência de conhecimento são medidos contra linhas de base. | A custódia é uma disciplina financiada; nenhum sistema crítico é um ponto único de falha humana e a transferência de conhecimento e os encerramentos planejados continuam em toda a organização. |
| Ética, responsabilidade, interesse público | A ética não é tratada ou é reativa após um escândalo; a acessibilidade é ignorada; decisões automatizadas opacas sem recurso; viés não testado. | Um código de conduta e alguma acessibilidade (tardia); as decisões automatizadas de grande visibilidade recebem alguma supervisão; verificações ocasionais de viés. | A revisão ética faz parte do processo; acessibilidade projetada e testada com usuários; decisões consequentes carregam explicação e recurso. | Os resultados de equidade, acessibilidade e responsabilidade algorítmica são monitorados contra linhas de base. | A responsabilidade está embutida em como a organização constrói; a equidade é um padrão inegociável e a responsabilidade algorítmica é padrão e continuamente melhorada em toda a organização. |
Autoavaliação geral de maturidade
Usem as matrizes acima para produzir uma pontuação leve e honesta.
Critério de pontuação
- Deem a cada capítulo uma nota de 1 a 5 usando o nível cuja descrição melhor corresponde à sua realidade típica. Quando o comportamento é inconsistente, deem a nota do nível inferior.
- Façam a média por parte. Somem as notas dos capítulos de uma parte e dividam pelo número de capítulos. Isso dá uma maturidade por parte (por exemplo, “a Parte IV tem média de 2,5”).
- Registrem o mínimo, não apenas a média. Uma parte com média de 3,0 mas que contém um capítulo de Nível 1 carrega o risco desse capítulo independentemente da média.
- Tracem a tendência. Reavaliem a cada trimestre ou dois e observem a direção do movimento. Um domínio indo de 2 para 3 é mais saudável que um parado num 3 estático.
Uma planilha simples por parte:
| Parte | Capítulos avaliados | Média | Capítulo mais baixo | Notas / prioridade |
|---|---|---|---|---|
| I-X | contagem | média | nível mínimo | … |
Priorizando o que melhorar
Não tentem elevar tudo de uma vez, e não persigam a maior média. Priorizem pela lacuna de maturidade ponderada pelo risco: ataquem os domínios onde um nível baixo encontra uma consequência alta.
- Primeiro: os capítulos de menor maturidade nos seus domínios de maior risco. Para a maioria das organizações isso significa segurança, privacidade, confiabilidade, conformidade e qualquer sistema cuja falha prejudique pessoas ou viole a lei. Um Nível 1 aqui é urgente.
- Em seguida: os habilitadores fundamentais (cultura, formas de trabalhar, CI/CD, IaC, observabilidade) que elevam o teto de todos os outros domínios. Melhorá-los torna os ganhos posteriores mais baratos.
- Depois: os domínios que já estão no Nível 3 e poderiam subir ao Nível 4 ou 5. Só avancem além do piso onde os riscos e a escala justifiquem o investimento adicional.
A linha de base corporativa e governamental
Os contextos corporativo e governamental geralmente não podem parar em “funciona”. Para passar em auditorias, sustentar autorizações e cumprir obrigações regulatórias e de prestação de contas públicas, a maioria dos domínios precisa alcançar pelo menos o Nível 3 (Padronizar), o nível em que as práticas são padronizadas, documentadas, impostas entre as equipes e produzem evidências. O Nível 2 tipicamente reprova na auditoria porque é inconsistente e montado manualmente sob prazo; o Nível 1 reprova de saída.
Leiam o Nível 3 como o piso para tudo que seja auditável ou relevante à segurança, e os níveis mais altos (4 e 5) como metas apenas onde a garantia contínua, a escala ou a confiança pública tornem o rigor extra vantajoso. A maturidade continua sendo um meio: o objetivo é um nível de controle defensável e proporcional ao risco que vocês de fato carregam, não uma pontuação perfeita.