Diagrama de Serviço (Service Blueprint)

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 do seu produto acontecer.

O Service Blueprint, apresentado por G. Lynn Shostack no artigo Designing Services That Deliver (Harvard Business Review, 1984), traz um conceito poderoso para mapear toda a jornada de entrega de um serviço. Essa abordagem permite visualizar e identificar todas as cadeias de valor envolvidas no processo, facilitando a detecção de pontos-chave que tornam o serviço possível.

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.