Papéis e Funções
Publicação da série sobre as diversas funções e posições em uma equipe de ProdOps, juntamente com as adaptações que o ProdOps faz no fluxo e na estrutura organizacional:
Literatura preliminar
Hierarquia de Cargos e Papéis
Expansão do Squad com Times Fixos e Times Virtuais
Especialidades ProdOps
Product Operations Tracker
Product Operations Specialist
Product Operations Manager
Product Reliability Engineer
Tech Product Manager
Problemas que deram origem ao ProdOps
Conforme apontado pela pesquisa “Agile in the Enterprise Survey” de 2019 do Gartner, a aceleração na entrega de produtos e a sincronização entre TI e negócios emergiram como as principais motivações para a adoção do Agile. Em meio ao cenário desafiador caracterizado por conceitos como mundo VUCA e BANI, a gestão de produtos digitais tornou-se notoriamente mais complexa.
A problemática identificada pelo Gartner destaca a influência do tempo perdido e do ruído gerado pela intricada natureza desse ambiente. Compreender completamente o ciclo de vida do produto torna-se uma tarefa árdua diante dessa complexidade.
Para mitigar esses desafios, o Framework ProdOps propõe a abordagem da Avaliação Contínua Essa jornada visa alinhar as equipes e equipar os tomadores de decisão com indicadores que identificam e abordam os elementos que consomem tempo e geram atritos no Roadmap.
Esta avaliação é para garantir que o produto (a peça), a entrega (o fluxo, além dos suas jornadas) e o time sejam mapeados e conhecidos no detalhe possível, para isto, o papel fundamental que precisa ser disseminado e construído em um time ProdOps é o Tracker.
Origem do Papel
O Framework ProdOps resgata um dos papéis mais importantes na origem do movimento ágil, o papel do Tracker (rastreador), responsável por tornar a comunição sempre flúida, o alinhamento garantido e a linguagem ubíqua para todos os participantes e envolvidos de um produto.
O Tracker acabou desaparecendo na indústria de Software e praticamente é desconhecido na literatura atual de gestão de produtos digitais por algum motivo obscuro.
Kent Beck, o principal nome por trás do método Extreme Programming (XP), escreveu sobre esse papel no seu livro “Extreme Programming Explained” desde a primeira edição em 1999.
Trechos no livro (em tradução livre):
“O tracking precisa acontecer sem muita sobrecarga…
Certos papéis devem ser preenchidos para que uma equipe extrema funcione – programador, cliente, Coach e Tracker.
(Como Tracker) Você é o historiador da equipe. Você mantém um registro das pontuações dos testes funcionais. Você mantém um registro dos defeitos relatados, quem aceitou a responsabilidade por cada um e quais casos de teste foram adicionados em nome de cada defeito.
O que a maioria das pessoas pensa como gestão, é dividido em duas funções no XP: o Coach e o Tracker (podem ou não ser desempenhados pela mesma pessoa).
O tracking é o outro componente principal do gerenciamento no XP. Você pode fazer todas as estimativas que você quer, mas se você não medir o que realmente acontece com o que você previu que aconteceria, você nunca aprenderá.
O Tracker precisa conhecer as regras do jogo friamente e estar preparado para aplicá-las mesmo em situações emocionais (o planejamento é sempre emocional).”
Extreme Programming Explained
Kent Beck, 1999
Outro baluarte do XP, Bill Wake, em seu livro Extreme Programming Explored escreveu e detalhou a relação do papel Tracker com demais papéis que existiam ou ganhavam popularidade no período:
O Tracker ajuda a equipe a saber se eles estão no caminho certo para o que prometeram entregar; esta normalmente não é uma função de tempo integral.
O Coach ajuda a equipe a usar e compreender a abordagem XP, orienta a equipe e ajuda a equipe a voltar aos trilhos se entrarem “no mato”.
O Tracker lida com a mecânica de medição do progresso da equipe. (Algumas equipes combinam o Tracker com o Manager).
Extreme Programming Explored
O Tracker pode atuar como uma parte desinteressada, com pouco “Skin” in the game[sic]. Esta é uma força. Eu já estive em posições onde já fui 95% Tracker e 5% Programmer. Surpreende-me o quanto ter uma tarefa na TRACKING LIST interfere na minha percepção.
Willian C. Wake, 2001
Ron Jeffries liderou a obra Extreme Programming Installed e comentou sobre a dificuldade de estabelecer o papel:
Recomendamos que as equipes tenham um Tracker. No entanto, todas as equipes com as quais trabalhamos tiveram problemas para conseguir alguém que se encaixasse no cargo.
O Tracker precisa ter uma abordagem não ameaçadora para obter informações, precisa ser sensível à linguagem corporal e outros comportamentos não-verbais e precisa estar disposto e ser capaz de rastrear regularmente.
Extreme Programming Installed
Ron Jeffries, Mike Hendrickson, Ann Anderson, Chet Hendrickson, 2000
O papel foi evoluindo ao longos dos anos, o relato fo Jeffries salienta a dificuldade de obter informações principalmente quando se trabalha em uma cultura Projeto/Sustentação com silos entre áreas.
O Kent Beck junto ao Martin Fowler, outra figura muito importante ligada ao desenvolvimento de aplicações em geral e gestão de Software, escreveram o seminal Planning Extreme Programming:
…O Tracker fica de olho nas tarefas realizadas e quanto resta nas tarefas pendentes. Seu trabalho é alertar a equipe sobre os problemas que podem surgir: ter muito a fazer, muito pouco a fazer, pessoas comprometidas demais ou insuficientemente. Todos os dias, a equipe tem uma pequena reunião Stand-up para que todos possam ver o que os outros estão fazendo. Isso ajuda a manter a comunicação fluindo por toda a equipe.
…O papel do Tracker é, na verdade, fazer perguntas simples e apontar possíveis problemas…
Planning Extreme Programming
Kent Beck, Martin Fowler, 2000
É perceptível que o papel do ScrumMaster no framework Scrum deveria abranger também as responsabilidades do Tracker. Surpreendentemente, muitas pessoas desconhecem o fato de que o Scrum estava inicialmente integrado ao Extreme Programming (XP). Na verdade, Kent Beck solicitou a colaboração dos criadores do Scrum para desenvolver o que ele chamava de “Planning Game”. O resultado foi a fusão de elementos de ambos os métodos no XP.
No entanto, apesar de essa integração sugerir implicitamente que o papel do ScrumMaster deveria incluir atribuições relacionadas ao Tracker, o Scrum não formalizou essa extensão de responsabilidade. Como resultado, essa faceta do papel do ScrumMaster ficou muitas vezes negligenciada na maior parte da literatura Agile, especialmente após a consolidação do Scrum como o principal método no mercado.
Apoio na Gestão do Roadmap
Diante dos desafios abordados pelo Framework ProdOps, a estratégia central é a comunicação integrada, seguida pelo alinhamento, visando assegurar que o Roadmap incorpore todas as mudanças necessárias que escapam à visão do Product Manager.
É praticamente impossível para o Product Manager mapear integralmente todas as influências sobre o Roadmap. Nesse cenário, o Tracker desempenha um papel crucial, mantendo uma lista atualizada de dúvidas, riscos e oportunidades que circundam o Roadmap. Essas informações alimentam a Narrativa ProdOps, fundamentando a construção de Planos de Confiabilidade. Esses planos, por sua vez, elevam a maturidade do produto e contribuem para a criação de uma cultura apropriada, refletindo diretamente no desenvolvimento do Roadmap.
Em determinados cenários, devido ao volume significativo de trabalho envolvido, esse papel pode evoluir para uma posição fixa, enquanto em outras situações, isso pode ser uma designação temporária para períodos específicos ou atividades particulares. Independentemente da forma que assume, esse papel representa a base para todos os outros papéis dentro de uma equipe ProdOps.
Deixe um comentário