Uma ferramenta fundamental no Framework ProdOps é o Service Blueprint, um diagrama para identificar e estabelecer pontos de contato com os usuários do produto e toda a complexidade do ecossistema que faz o serviço acontecer.
Identificar Aplicações e Componentes
Seja um serviço novo ou mapear um já existente, a idéia do Service Blueprint é começar a visualizar quais aplicações e serviços de Software fazem parte do fluxo. Um modelo simplificado com pelo menos o ponto de contato, o serviço de software que ele aciona e a aplicação que entrega este serviço.
Esse diagrama é importante para recortar um retrato funcional dentro de uma estrutura complexa de infraestrutura e aplicações, como analisar grandes plataformas de Ecommerce, por exemplo. Ter um desenho simples e ir avançando com detalhes conforme a investigação se aprofunda.
O Service Blueprint é ideal para construir desenhos de serviços que produzem matrizes de confiabilidade específicas para a montagem de Product Deck e identificar produtos fisicamente dentro das plataformas.
O modelo de System Design Blueprint é um bom ponto de partida a partir de uma padronização e vai enriquecendo com contexto de produto.
Identificar Times e Dependências
A partir de um recorte de produto, conseguimos identificar quais aplicações ou componentes são órfãos de equipe, quais são compartilhados, quem são os donos e quem pode dar assistência.
A dependência de outros times, para um gestor de produto, afeta diretamente no planejamento de entrega e principalmente no acionamento para investigação de incidentes e degradações. Ainda ajuda também na identificação de formatos de equipes, sejam divisões ou agrupamentos.
A combinação entre time, aplicações e seus componentes, permeia o conjunto de informações necessárias para a entrega de Releases em um Roadmap e ajuda a definir as fronteiras do produto dentro de plataformas maiores.
Identificar APIs e Contratos
Avançando um pouco mais, seguindo os princípios de uma boa engenharia de produtos, podemos começar a estudar e especificar melhores contratos de API entre os produtos com identificação de cenários não mapeados ou invisíveis no processo.
Uma boa gestão de versionamento é fundamental para controlar a evolução de um produto e não cair no caos do acompanhamento, prejudicando o planejamento e aumentando o ruído de informações sobre responsabilidade do produto e de dependencias nos mesmos serviços.
Somente com um produto bem documentado e esta documentação atualizada a cada interação que o time de produto consegue ter visibilidade suficiente para uma tomada de decisão assertiva de como simplificar, eliminar o ruído e definir responsabilidades para os agentes certos,
Esta é só uma das práticas utilizadas no Framework para apoiar tanto um ProdOps Solo quanto o “Pre work” de uma Premortem, mas recomendada para a efetividade do processo.
Deixe um comentário