Trabalho prévio ao plano de Confiabilidade

Fluxo do Framework para o time ProdOps

Plano de Confiabilidade

O fluxo básico 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 produto.

A gestão de produtos digitais consegue observar a jornada do produto a partir de uma perspectiva muito acima das capabilidades técnicas e da qualidade necessária que consome tempo imperceptível afetando o equilíbrio do Roadmap.

Falhas na Gestão do Produto

O Plano de Confiabilidade é a peça principal do time de ProdOps para corrigir as falhas na gestão de produtos provocadas basicamente pelo ruído de informações necessárias para a tomada de decisão sobre a priorização de itens fundamentais para o sucesso deste produto, itens tanto de entrega de serviços diretamente a seus consumidores, como atividades necessárias – pelo rigor literário – para uma melhor qualidade que afeta diretamente o Lead Time e compromete o Time To Market.

Assessment Contínuo

O ProdOps cria uma jornada paralela de avaliação contínua para desenvolver o plano que vai sempre minimizar o ruído e alinhar as expectativas da empresa, do cliente, do time e dos gestores do produto.

Para produzir este plano, é necessário um trabalho de mapeamento do Produto (a peça), do fluxo (as jornadas do ciclo de vida da peça sob o ponto de vista do produto e do time que opera) e do time que controla o ciclo de vida.

O importante do plano não é desdobrar ou estimar aquilo que já está mapeado e endereçado, é principalmente complementar e descobrir aquilo que invariavelmente vai aparecer pelo percurso e que vai consumir tempo suficiente para mudar o Roadmap ou atrair riscos iminentes.

Organizar leva tempo e alinhamento entre muitos envolvidos, os requisitos básicos que precisam ser capturados pra isso são:

1. Mapeamento de todas as peças do produto (como aplicações e dependências)
2. Captura das demandas de todas as áreas sobre o tema que se deseja trabalhar (iniciativas não desdobradas e solicitações não atendidas)
3. Identificação de todas as equipes necessárias sobre o tema, na maior parte das vezes a entrega e operação não são realizadas somente pela equipe dedicada ao produto e isso vai levar a desalinhamentos e tempo não mapeado.

Desta forma, um modelo operacional é produzido, o time de ProdOps consegue criar cadência para complementar os gestores de produtos com:

1. Loop de Feedback para evolução contínua
2. Autonomia com o rigor necessário pelo momento do produto
3. Identificação das lacunas na Release

Com isso teremos um modelo que trabalha na mitigação dos riscos do Roadmap desequilibrado e clareza sobre:

1. Acúmulo reall de débitos técnicos
2. Incidentes possivelmente previstos
3. Visibilidade ampla e integrada

Pre Work

O Setup básico inicia a partir de um trabalho prévio do mapeamento do produto, desenvolvemos no Framework ProdOps um artefato chamado Product Deck que vai estampar a fronteira básica da peça, qual a arquitetura específica, mesmo que seja parte de uma plataforma maior, o time e o que esse produto faz.

Product Deck

O trabalho de descoberta e construção do Product Deck por si só pode ser demorado.

Iniciamos muitas vezes com Diagramas de Serviços (Blueprints) por falta de documentação e conhecimento no detalhe de como a arquitetura mínima de entrega do serviço ao consumidor existe e é operada em produção. Muitos gestores de produtos sequer já tiveram contato com esta operação e muitas dependências são desconhecidas até que um incidente ocorra ou apareça a necessidade de mudanças.

A partir da Blueprint, conseguimos extrair realmente que arquitetura importa, em muitos casos, em grandes plataformas, a arquitetura do produto se perde e não sabemos que fronteira e serviços exatos temos a dependência.

Extraímos então uma matriz de confiabilidade a partir da arquitetura, com todas as dependências entre aplicações e seus componentes. Em diversas situações, o time precisa investigar em código para descobrir que tipo de dependência existe.

Com todos os componentes necessários descobertos, podemos avaliar a maturidade de cada um, respeitando o momento do produto e do negócio do produto.

Jornadas e Avaliação

Existem jornadas paralelas, perpendiculares, faseadas e complementares, descobrir a fragilidade em cada uma requerer múltiplas especialidades além dos times de produtos. O time de ProdOps complementa nas companhias a falta de um papel que faça esse alinhamento. A avaliação contínua é a jornada que avalia as jornadas.

O trabalho prévio requer esse cuidado em avaliar cada uma das aplicações por cada capabilidade de cada uma das jornadas e descobrir o ideal em vez da utopia do perfeito, respeitando os objetivos do momento.

Desta forma o time de ProdOps está pronto, com esse trabalho feito, para conduzir a confeção do Plano de Confiabilidade.

Dado a dificuldade de encontrar todas as informações em tempo hábil, o time ProdOps vai desenvolver a capacidade de descobrir o momento adequado em preparar planos específicos e eficientes de forma faseada, não necessariamente para todo o produto ou para todos os serviços.

Timebox e QuickWins

Uma recomendação associada para iniciar o modelo é usar a própria Sprint (em times que fazem Scrum) como mecanismo para começar a aprender e criar o modelo iterativo e incremental.

Antes de cada Sprint, um plano modesto para melhorar as capabilidades do produto junto ao time de produto e entregar valor em conjunto, potencializando a entrega sobre o valor de negócio e a qualidade desejada no produto. Qualidade aqui no sentido mais amplo, como o entendimento de melhoria da maturidade de cada capabilidade.

Com ambições mais curtas, utilizando a Sprint por exemplo, fica mais fácil estabelecer os critérios de Pre-work necessários para se chegar ao objetivo do plano que deveria conversar com objetivo da Sprint diretamente. Com essa receita, introduzimos uma cerimônia que une todos os envolvidos para essa união de objetivos.

A Premortem é a cerimônia que o Framework ProdOps propõe para a construção do Plano de Confiabilidade, o Pre-work é o que vai trabalhar com o necessário para alimentar essa Premortem.

Dentro do Framework ProdOps, usamos esse mesmo modelo de Pre-work como ProdOps Solo, um circuito que os gestores de produtos podem realizar em caso da ausência de um time dedicado para o ProdOps e demonstrar valor de forma frequente.

O problema que acontecerá rapidamente é que o gestor do produto vai ter grande dificuldade muito em breve em conciliar o próprio trabalho de gestão de seu Roadmap com o trabalho de mapeamento e avaliação proposto nesta abordagem.

De qualquer forma, os benefícios imediatos do ProdOps Solo darão subsídios para a solicitação de um time dedicado com argumentos sólidos e demonstráveis.

Nova turma do curso de ProdOps

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