Como o PBB ajuda com a agilidade na área operacional de TI

O Fábio Aguiar criou o Product Backlog Building (PBB) para responder perguntas comuns para o desenvolvimento de produto, semelhantes a “Como definir o backlog do produto?”, “Como fazer o que realmente tem valor” e “Como definir o que é prioridade para o cliente”. A ferramenta é um CANVAS que orienta na descoberta, quebra, estimativa e priorização do backlog de uma forma lógica e intuitiva.

Gostei da ferramenta desde o primeiro contato e por coincidência passei a trabalhar em um local onde tive a oportunidade de utilizar o PBB como uma ferramenta disponível para a gestão do backlog das equipes.

Comecei a atuar como agile coach em uma área operacional de ti que está construindo um ambiente inovador com times para atuar na operação de produtos e serviços. Nossos times precisam garantir a confiabilidades dos serviços da empresa mais que resolver incidentes e fazer atividades operacionais. A proposta é buscar e desenvolver mecanismos, melhorias sistêmicas e de arquitetura, revisão de processos, automação e automatização para manter e aprimorar a confiabilidade dos serviços. Para isto, estas equipes precisam buscar dedicar pelo menos metade do seu tempo em ações de engenharia de confiabilidade de sites / serviços. Para saber mais sobre esta proposta, recomendo buscar informações sobre SRE do Google (https://landing.google.com/sre/)

Estamos desenhando um processo evolutivo e que conta com um pre-game que tem o PBB como uma ferramenta para a construção do backlog do time.

O desafio foi adequar o PBB para nossa realidade. Para a definição do produto podemos ter um a vários produtos, podemos ter serviços ou podemos ter canais. Isto ocorre pelo modelo organizacional atual.

Para problemas e expectativas, peço para o time se colocar no lugar do cliente destes produtos, serviços ou canais e anotem em post-its de forma individual e depois agrupamos. Para as pessoas que atuam nesta área ainda é desafiador ter a visão do cliente, porém já podemos percebem a evolução neste sentido.

Costumo conferir com o time se as expectativas estão associadas aos problemas de alguma forma. Já usei algumas vezes um identificador, como um número que coloco no problema e relaciono com expectativas.

Quando vamos levantar as personas, na nossa realidade é frequente aparecerem os clientes finais, a área e também TI como um todo. Faz sentido pois tem problemas e expectativas associadas ao ponto de vista do cliente final e também há quem tem um objetivo de manter um serviço.

Na etapa de identificar as atividades e objetivos das personas, é comum para personas do tipo área operacional e TI frequentemente terem atividades como “monitorar” e objetivos como “disponibilidade” e confiabilidade, já para personas de “negócio” são atividades e objetivos tradicionais, como “fazer reembolso” e “pagar o solicitante” consecutivamente.

Já quando tratamos de Feature, estas atividades / funcionalidades tem como problemas / necessidades questões de sustentação / operação, mesmo que para uma feature de usuário, assim como resultado / benefício.

Em várias situações aparecem problemas associados com ações como “disponibilidade para executar o pagamento do reembolso dentro do prazo”, sendo a parte em negrito a resposta a problemas, isto normalmente não seria colocado em uma demanda evolutiva de sistema, porem nossa realidade demanda uma adaptação. Já o benefício poderia aparecer como “diminuir o tempo de processamento”, pelo mesmo motivo.

É comum para uma feature de “monitoramento” de uma persona “TI” quebrarmos em histórias semelhantes a “fazer monitoramento do módulo x”, porem uma história parecida com esta também pode aparecer para um feature como “cadastro do cliente” pelo mesmo motivo de termos o foco em questões não funcionais e de sustentação.

Nossa área tem um objetivo muito claro com relação a disponibilidade e usamos isto para ajudar os times a definirem onde devem atuar.

Estes times usam o PBB somente para ações de evolução / valor (não usam para incidentes e tarefas operacionais). Podemos considerar que, como itens de backlog, seriam classificados como habilitadores, problemas e histórias em alguns casos.

Já experimentei usar mapa de calor para priorizar personas e features com um bom resultado. Também já usei ao final o voto de decisor, sendo alguém responsável pelo backlog.

Depois das features, o uso é totalmente aderente na sua forma original, usando ARO e CORG.

Desta forma o PBB se mostrou para nossa realidade uma ferramenta extremamente útil e flexível. Não exigimos que os times continuem usando o CANVAS, porem nenhum time abandonou a ferramenta até hoje. Eles o mantem preso na parte de traz dos seus painéis e periodicamente revisão.

A evolução atual mais impactante foi a adoção de OKRs para nossos times operacionais. Agora eles partem dos OKRs para a construção do Backlog do serviço. Se quiser saber mais sobre OKR, sugiro https://felipecastro.com/. O uso de OKRs está ajudando no foco no cliente, alinhamento com os planos estratégicos e táticos, além de caminharmos para uma linguagem comum entre TI e negócio, passo fundamental para maior transparência e confiança.

Estou iniciando a adequação ao modelo remoto. Criei um Canvas de PBB em uma virtual board e estou disseminando entre os times. Caso queira baixar e experimentar a board virtual, vou deixar aqui o link. Ao acessar você pode fazer uma cópia e usar a vontade: https://forms.gle/WkPcRmwksB231qCB7.

Fiz um vídeo apresentando o Canvas PBB virtual. O exemplo que passo também é de operação:

Para saber mais sobre o PBB, acesse o site oficial, o Fábio disponibiliza vários materiais e informações para os interessados: http://www.productbacklogbuilding.com.br/index.php