O Framework ProdOps nasceu na experiência em construir um modelo de suporte para a gestão de produtos digitais (detalhes da história neste artigo) baseado na cultura de SRE/DevOps guiada pela Engenharia de Produto com o método Kanban.
O que é ProdOps
Product Ops (na visão do Framework ProdOps) não é sobre gerir produtos digitais e sim como habilitar a boa gestão e execução com a arquitetura, engenharia e processos que tornam a validação de hipóteses de forma frequente, iterativa e incremental para atingir o melhor Time to Market.
ProdOps permite a independência das equipes para promoverem suas aplicações, tanto experimentos quanto soluções finais, direto a seus clientes e usuários, decidindo o quando, como e para quem quiserem, respeitando a cultura, papéis, cargos, autoridades e políticas de cada companhia.
As duas novas jornadas
A idéia do ProdOps é não interferir no que já existe, utlizando um princípio do Kanban, usar o que tem. Para isto criamos duas jornadas paralelas que complementam as jornadas atuais.
Avaliação Contínua
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.
Em situações mais complexas como avaliar uma plataforma compostas por várias equipes e vários produtos, é necessário algumas equipes de ProdOps para a contrução de um plano efetivo dado o volume de iniciativas a serem mapeadas.
Tracker
O papel mais importante nessa jornada é o Tracker, um (ou mais, a depender do volume) responsável pelo Tracking List, artefato para coletar todas as perguntas necessárias sobre um produto e garantir que a resposta seja mapeada no Produck Deck.
A Tracking List deve ser criada para suportar o Product Deck com todas as informações necessárias para tomada de decisão.
Contribuição para o Discovery
Existem diversas abordagens interessantes e consolidadas para conduzir um Discovery de produto como Lean Inception, o livro do Paulo Caroli começa sem seu prefácio com:
“A visão mais ingênua sobre desenvolvimento de Software ágil e a que todo mundo chega e começa a escrever o código sem gastar um tempo inicial descobrindo o que fazer”
Lean Inception: Como alinhar pessoas e construir o produto certo
O mapeamento das capabilidades e o Product Deck já são artefatos construídos junto ao Discovery que auxiliam na avaliação de habilitação técnicas das hipóteses trabalhadas, os dois processos fluem melhor juntos.
Premortem
A cerimonia de Premortem possue um conjunto de técnicas para a construção do Plano de Confiabilidade neste modelo operacional acomplado.
O plano sai com com Backlog de todas as atividades referentes a observabilidade e entrega do produto, o principal artefato em observabilidade defendido pelo ProdOps é a Dashboard de Confiabilidade.
Refinamento na Planning
Com o Roadmap e Backlogs do(s) plano(s) de confiabilidade preparado(s), o refinamento para as atividades do time de produto devem ser realizados em suas próprias Planning, afinal o refinamento das atividades a serem direcionadas ao time de ProdOps já foram construídas em conjunto com os responsáveis técnicos de ambos.
Jornada de Diligência
Esta jornada é um habilitador da cultura Postmortem, retroalimenta todo o fluxo com o aprendizado da vida em operação do produto, sejam erros e degradações para atualizar o plano de confiabilidade, aprendizado de utilização para pivotar novos experimentos ou simplesmente validar o modelo e garantir que os Loops de Feedback acontençam.
Todo Tracking em tempo de desenvolvimento, entrega e produção é analisado e discutido na retrospectiva do time ou em uma cerimônia de Postmortem específica quando há a necessidade de unir vários times de produtos sob um mesmo plano.
Os detalhes aprofundados do ProdOps são discutidos no curso específico e serão temas de futuros artigos.
Deixe um comentário