Avaliação Contínua (Continuous Assessment)

A primeira versão do Framework ProdOps utilizava a abordagem “Deploy First” para trazer a visibilidade e desafios de várias disciplinas até a chegada do produto em produção antes do planejamento.

Na era pré-Cloud, precisávamos preparar um plano de compra de equipamentos com detalhes antes de submeter o Business Case, sabendo da dificuldade histórica de receber aplicações em produção, principalmente construídas por fábricas, foi natural antecipar o próprio plano de entrega das aplicações junto com o plano de construção da estrutura em produção.

Deploy First é uma prática utilizada para construir a visibilidade completa, inspirada no conceito de “Planning horizon“, similar à prática de Path to Production que o Lean Inception incluiu no método e que saiu como recomendada para adoção no Radar da TW.

Diferente do Path to Production realizado tradicionalmente, a abordagem de Deploy First não apenas visualiza, o entregável é o plano de Delivery com a definição de Deploy como primeiro Work Item executável para o time, que destrava todos os demais itens necessários.

O tempo invisível que se perde

O principal benefício do Deploy First é um plano de construção ou melhoria, criado pelo processo de identificação do Toil em cada Cycle Time sob o ponto de vista da peça (aplicações e componentes do produto) e dos responsáveis pelas ações (Dev, tester, devops e quaisquer membros do time que tenham entregáveis no fluxo), cada Toil identificado pode ser medido e um plano de eliminação deste Toil deve ser criado com as automatizações necessárias no que chamamos de Plano de Confiabilidade.

Quando David J. Anderson publicou o livro Kanban: Successful Evolutionary Change for Your Technology Business, trouxe um conto sobre como um gerente chamado Dragos assumiu o considerado pior time de uma divisão da Microsoft da qual o David trabalhava.

O interessante deste conto foi o formato utilizado para resolver o problema de Lead-time desse time, primeiro visualizando o fluxo de trabalho.

No livro, o David escreveu:

“Eu pedi que Dragos esboçasse o fluxo de trabalho e ele elaborou um desenho simples
que descrevia o ciclo de vida de uma solicitação de mudança, e então, nós discutimos
os problemas.”

Trecho do Capítulo 4, seção “Visualizar o Fluxo de Trabalho

Similar ao modelo de Deploy First que prepara uma visualização sobre os passos necessários para o produto chegar em produção tentando prever o trabalho inútil e manual, aqui o David demonstrou uma estratégia de mapear a jornada e identificar a ineficiência do fluxo.

O tempo de estimativa, no caso do David, era praticamente um terço do tempo consumido em atividades que não entregavam valor, a sugestão inicial foi eliminar a estimativa (Toil) nessa jornada.

Podemos perceber que existem muitos detalhes que consomem tempo do time e impactarão a previsibilidade de um Roadmap de produto, aprendemos com o Kanban em visualizar primeiro para apoiar na gestão do fluxo:

Visualizar
Uma boa visualização é a chave para uma colaboração efetiva e para identificar oportunidades de melhoria. Muitas vezes, o trabalho na organização está escondido. Visualizar esse trabalho e o fluxo dele melhora muito a transparência.
De um ponto de vista evolutivo o sentido da visão do ser humano é muito antigo. Isso nos permite absorver e processar muita informação num curto espaço de tempo. Além disso, a visualização apoia a cooperação, pois todos os envolvidos têm literalmente a mesma imagem. Mais detalhes sobre visualização serão apresentados na seção sobre Quadros Kanban.

The Official Kanban Guide

O método Kanban inspirou com seus princípios e conjuntos de práticas na ampliação do Deploy First como base em entender a visualização como um processo holístico, não apenas o fluxo de Delivery, mas entender todas as jornadas que se cruzam e se intercalam.

Nova Jornada

Avaliação contínua é a jornada que investiga e cria mecanismos para explorar e visualizar todas as jornadas e fluxos com profundidade de forma iterativa e incremental, trazendo os ganhos mais visíveis para o plano.

O time ProdOps ou o gestor com ProdOps Solo avalia e visualiza cada jornada, seja numa dimensão macro como Planning e Delivery ou paralelas como Change Management e Release Management, aprofundando suas capabilidades e conexões para identificar tudo que afetará o Roadmap do produto.

A nova jornada reforça o conceito de Observabilidade em primeiro lugar, para trazer na frente de todas as disciplinas um movimento de enxergar com profundidade tudo que pode afetar o Roadmap, adequando o Trade Off do que é possível resolver imediato e planejar a solução ao longo do tempo.

Avaliação Contínua é a jornada que avalia as jornadas

O livro Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology trouxe um conceito de focar em capabilidade em vez de maturidade. A indústria de Software por muitas décadas tem criado modelos de maturidade para avaliar times, empresas e até produtos de Software.

Os modelos de maturidade tentam se enquadrar em cenários bastante diversos e falham pela complexidade da natureza das empresas e seus produtos e processos.

A jornada de Avaliação Contínua prega uma Maturidade das Capabilidades para resolver o problema de tentar encaixar um único modelo para todas as empresas, a idéia é que cada empresa adapta o seu modelo conforme práticas e padrões consolidados na engenharia. Para montar o seu padrão, a Avaliação Contínua ajuda a identificar as capabilidades de cada jornada no fluxo que a empresa adota e auxiliar melhorias para o Plano de Confiabilidade.

Aprofundamento na Jornada

Quem observa a observabilidade?

Dado que a Jornada de Avaliação Contínua é a jornada de avaliação de todas as jornadas e utiliza o conceito de Observabilidade de forma holístico, até a própria jornada de Observabilidade é analisada e usada neste artigo como exemplo de como avaliar e aprofundar as capabilidades.

O modelo segue 4 passos de avaliação, não necessariamente sequenciais, com o tempo o time de ProdOps aprende a construir um fluxo não linear. Para introdução, recomendamos na sequência:

Estabelecer Cohorts

Identificar grupos de Capabilitades

O ideal é que os especialistas dos temas no início do processo da jornada avaliada, definam os agrupamentos de disciplinas com base na literatura e boas práticas de mercado.

Classificação da maturidade

Após um entendimento inicial, classificar e isolar as capabilities para criação do entendimento de maturidade.

Criar cadência de revisitação contínua

O ideal é o plano servir como modelo para avaliação frequente e ser constantemente melhorado e adaptado para a realidade de cada aplicação, seguindo as práticas do Kanban de implementar um Loop de Feedback e melhorar colaborativamente, evoluir experimentalmente.

Passamos cada aplicação no modelo de maturidade de cada capabilidade para um entendimento e primeiro nível de visualização no detalhe que fornecerá subsídios para a construção do Plano de Confiabilidade.

Expansão das Capabilidades

Aprofundar Capabilidades

Aprofundar a criação de grupos de capabilities isolando mais cenários, o item Availability (disponibilidade) encontrado no modelo do passo anterior, não reflete apropriadamente as necessidades de avaliar as aplicações por inúmeras diferenças de maturidade em uma única capabilidade.

Podemos dividir e explorar numa dimensão mais profunda:

Medir as Capabilidades

Identificar as capabilidades que possam ser medidas, criar métricas e eventos para investigar a eficiência da capabilidade. Exemplo, instrumentar a capabilidade de Alertas para coletar métricas inteligentes de quando os alertas não são visualizados.

Linguagem Ubíqua

Desenvolver um entendimento corporativo para facilitar a linguagem ubíqua das maturidades, quando alguém citar que aplicação X tem maturidade 3 na capabilidade de Monitoramento e Status Check , todos os times entendem o que significa ou possuem uma base de consulta para o entendimento.

Isso começa a criar uma ferramenta poderosa para a tomada de decisão sobre priorização de itens necessários para o avanço do produto.

Identificação de Propósitos

Identificar áreas beneficiadas

Um grande benefício no trabalho de visualizar e mapear todas as jornadas é entregar valor para todas as áreas de companhia que dependem do produto avaliado.

Áreas como Operation que precisam de eficiência na gestão de incidentes, áreas que precisam de Analytics sobre o ciclo de vida do produto, as áreas de negócios que precisam de um ambiente informativo para suas operações, etc.

Conectar com as áreas para entregar conhecimento

Capabilidades que fornecem apoio às áreas são priorizadas para garantir apoio e confiança na evolução dos planos de Confiabilidade. Uma gestão eficiente de ambiente informativo para o time de produto pode diminuir bastante o MTTR (métrica utilizada como tempo de retorno após um incidente) economizando dinheiro numa operação de negócio pela rápida disponibilidade da aplicação.

Um erro em produção não visualizado pode sinalizar para o Marketing, por exemplo, que a performance do negócio está perdendo para uma concorrente e por causa disso, investir mais dinheiro em campanhas de mídias pagas potencializando o prejuízo causado por um incidente.

Adicionar observabilidade com apoio do negócio ao DoD

As métricas de produtos e de fluxos podem e devem ser utilizadas para apoio ao DoD (Definição de Pronto) de funcionalidades, principalmente as métricas DORA.

Mapeamento de Integrações entre Jornadas

Conexões entre Jornadas

A identificação de conexão das capabilidades com outras jornadas apoia a identificação dos propósitos, no ciclo de vida dos produtos, todas as capabilidades se interagem em alguns momentos independente das jornadas que elas participam.

Criar um guia de boas práticas e mesclar maturidades

Para coletar uma métrica DORA, por exemplo o Change Fail Rate, precisamos identificar a ligação da capabilidade de monitoramento com várias capabilidades da jornada de Change Management, sobretudo o Deploy.

Tornar as políticas explícitas com Building Blocks e Plataformas

O passo mais avançado no modelo é utilizar o mapeamento para construção de Building Blocks com a maturidade mínima desejada pela companhia para todas as aplicações e fomentar a boa prática da utilização do Plano de Confiabilidade para gerar não só a evolução, mas como um modelo diligente de aplicar as plataformas adequadas ao momento do produto.

Nova turma do curso de ProdOps

Achou o texto interessante? Esta jornada é a protagonista do curso de ProdOps que disponibilizamos, observa no link a próxima turma e vem trabalhar o conceito conosco.


Publicado

em

,

por

Tags:

Comentários

7 respostas para “Avaliação Contínua (Continuous Assessment)”

  1. […] A primeira jornada é um fluxo com uma equipe ProdOps dedicada em criar um Product Deck com todos os detalhes importantes para as tomadas de decisões do time de produto. A partir daí, mapear as necessidades para uma boa gestão sobre o produto antes do planejamento das mudanças com um Plano de Confiabilidade para elevar a Maturidade das Capabilidades. […]

  2. […] do Framework ProdOps é um modelo para preparar um Plano de Confiabilidade durante a jornada de Avaliação Contínua que consiste na melhoria incremental e iterativa das capabilidades do […]

  3. […] a jornada de Avaliação Contínua, o time de ProdOps conduzirá a investigação individual nos envolvidos sobre um tema que envolve […]

  4. […] mitigar esses desafios, o Framework ProdOps propõe a abordagem da Avaliação Contínua Essa jornada visa alinhar as equipes e equipar os tomadores de decisão com indicadores que […]

  5. […] template nos guia na jornada de Avaliação Contínua para a construção de Planos de Confiabilidade que melhoram a Maturidade das Capabilidades de […]

  6. […] avaliação contínua é a abordagem para manter o desenho em constante evolução e garantir que todos os participantes […]

  7. […] mapeamento desses interesses na jornada de avaliação contínua garante a antecipação de possíveis interferências na condução do Roadmap. Os interesses da […]

Deixe um comentário