Responsabilidades como alocação de equipes, controle de recursos financeiros, desenvolvimento de cronogramas e elaboração de enormes Planos de Projetos passaram a ser responsabilidades de outros papéis.

Alavancado pelo uso das metodologias ágeis, o conceito de gestão distribuída tem levado uma nova característica aos times: mais autonomia para tomar decisões de negócio, cuja participação do time no direcionamento de um produto tem sido essencial para que a mudança constante, inerente desse ambiente, tenha menor impacto sobre a qualidade do projeto.

Então, eu lhe pergunto: com o empoderamento dos times nas organizações, onde foi parar o Gerente de Projetos com perfil “manda-chuva”? Para ficar mais claro o que quero dizer com esse termo, imagine o tradicional gestor de uma estrutura funcional e hierarquizada, onde funcionários, coordenadores, gerentes, diretores e presidente se baseiam no conceito comando-controle e estes respondem diretamente ao seu gerente funcional.

Diagrama representando uma estrutura funcional

O dinamismo, a necessidade de adaptação rápida e resposta às mudanças, embasadas pelo modelo de gestão ágil, fez com que os profissionais da antiga estrutura funcional se adequassem aos times multidisciplinares focados na entrega de valor, que saibam responder imediatamente à imprevisibilidade deste ambiente e que se adaptem constantemente a novos contextos.

O papel do tradicional Gerente de Projetos pode ser comparado ao papel exigido pela necessidade requerida nesse novo ambiente: o Gerente de Produto, Product Manager, ou qualquer nome da moda que se dê ao cargo do responsável pela evolução do produto. Limito-me aqui a chamar de Gerente de Produtos. O que faz esse tal Gerente de Produtos então, se não cobrar e exigir produtividade?

O Gerente de Produtos deve ter como objetivo ser a sustentação e prover o suporte necessário ao time de desenvolvimento. Se o time tem que ser capaz de tomar as decisões e se auto-organizar para desenvolver e entregar o máximo de valor nas entregas ao cliente, o Gerente de Produtos deve ser o canal de comunicação entre o time e os interessados pelo projeto (stakeholders), definir os objetivos e visão estratégica, construir um roadmap sólido dos entregáveis, priorizar as demandas e intermediar a integração e o entendimento das principais áreas de desenvolvimento de um produto: UX, Business e Tecnologia.

Papel de um gerente de produto

Diferentemente do tradicional Gerente de Projetos, o Gerente de Produtos deve focar no “o que deve ser feito” e menos em “como deve ser feito“, sendo essa responsabilidade compartilhada com o time, o que inclui definir processo de desenvolvimento, remover impedimentos, tomar decisões sobre mudança de escopo e detalhar requisitos das tarefas. Os times que antes eram considerados times de desenvolvedores, passaram a ser times de produto com membros multidisciplinares, responsáveis por validar, testar e desenvolvê-lo, como uma “mini-startup”.

Assumindo este como sendo o rumo que o papel do Gerente de Projetos tem tomado, é fato que o engajamento e a participação do time têm se tornado cada vez mais importante, o que mostra também o quanto os princípios ágeis têm influenciado na transformação desse papel nas empresas que trabalham com desenvolvimento de software.  

Para aprofundar um pouco mais nesse assunto, recomendo dois blogposts que foram escritos aqui na Plataformatec sobre definição de objetivos e priorização de features e projeção de entregas.

The post Onde foi parar o Gerente de Projetos? first appeared on Plataformatec Blog.

Desenvolver uma visão que possibilite enxergar e compreender o todo por meio da análise das partes que o formam é um grande desafio ao lidar com ambientes de incerteza.

Uma das formas de compreender e analisar o sistema de trabalho de uma equipe ágil se dá através das métricas de processo (há uma coletânea de conteúdo bacana sobre o assunto aqui no blog da Ptec).

Entender o fluxo a partir dos dados é uma maneira pragmática de incorporar uma filosofia de melhoria contínua, sem mudanças abruptas e caóticas e de forma transparente para todos que estão envolvidos no contexto (equipe, stakeholders, área de produtos, gestores, etc.). Parafraseando a comunidade Kanban, medir é uma ferramenta que ajudará a evoluir e não revolucionar um processo já existente.

Pessoalmente, eu gosto de quantificar o processo quando estou mapeando a realidade de uma equipe, pois exponho fatos (dados) para discussão e análise. Na minha experiência com equipes de desenvolvimento de software, venho percebendo que ter esse tipo de conduta ajuda a diminuir uma carga subjetiva que possa existir na equipe e é um jeito de confrontar crenças como “não precisamos melhorar”, “não temos problemas no processo” e “atuamos de forma colaborativa”.

No blog post de hoje, compartilharei uma coleção de métricas que ajudarão você a diagnosticar a saúde do proceso de uma equipe ágil.

Premissas

Antes de qualquer coisa, preciso deixar algumas ressalvas quanto ao uso das métricas.

Métricas devem ser usadas para evoluir o processo e não para gerar cobranças e comparações destrutivas.

Não caia na tentação de comparar equipes e medir o desempenho de um indivíduo. Se você ou a empresa no qual trabalha estão interessados em premiar resultados individuais, formulem um método que proponha avaliar o desempenho da pessoa a partir da opinião dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indivíduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de métricas que não tenham relação direta com o resultado do negócio (ex: do que adianta a equipe ter entregue um número de funcionalidades no semestre sendo que o produto não teve um aumento de receita?).

Compartilho essa premissa para que você e sua equipe não se comportem de acordo como estão sendo medidos. Afinal, já diria Goldratt: “diga-me como serei avaliado e eu lhe direi como me comporto”.

Números sem contextos são perigosos.

Qualquer análise feita sem compreender as variáveis que compõe um cenário se torna superficial, enviesada e pobre. Se alguém lhe contar que o número de funcionalidades entregues em uma equipe é de 10 itens por semana, é possível concluir algo? Tal métrica é boa ou ruim? Qual o significado de entregue para aquela equipe? É software em produção ou entrega em um ambiente de homologação? Bem, pelos questionamentos anteriores é possível concluir que um número solto nada mais é do que um símbolo privado de qualquer significado.

Procure tendências e fuja da precisão. Dada a complexidade que é criar um produto de software, não busque ser determinístico em um mundo que é receptivo por natureza a uma realidade probabilística.

A lógica por trás da última premissa é: vivemos em um ambiente onde há risco, isto é, existe a probabilidade de insucesso em função de algum acontecimento incerto, cuja ocorrência não depende exclusivamente da vontade da equipe. Portanto, é pouco provável que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao invés de nos enganarmos com prazos que ratificam que as entregas acontecerão sempre na mesma data e na mesma forma, passemos a analisar o histórico de dados da equipe para projetarmos a chance de entregarmos algo.

As premissas compartilhadas ajudarão você a utilizar as métricas de forma efetiva. O Lucas Colucci escreveu um texto muito importante que apresenta alguns erros comuns ao utilizar métricas de processo.

Diagnóstico do processo

Dada as premissas compartilhadas acima, vamos ao que de fato interessa. As métricas listadas a seguir servirão para você mapear como está a saúde do processo de uma equipe. Como agilista, considero que as visualizações abaixo compõem o painel de análise (cockpit) de um fluxo de trabalho e devem estar disponíveis para que as equipes utilizem como material para a promoção de melhorias no processo (ex: uso das métricas em retrospectivas, análise do processo em reuniões diárias, etc.).

Trabalho em progresso

Monitorar o trabalho em progresso ajudará a equipe a ter consciência de qual é o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualização, pois ela demonstra, por exemplo, se as equipes estão respeitado uma política de limite do trabalho em progresso.

No exemplo acima, temos uma situação onde a equipe estava com a quantidade de itens em progresso próximo de 10 por semana até que em determinado momento houve uma reconfiguração no número de pessoas, o que fez com que a quantidade de trabalho em progresso diminuísse. Um insight aqui é que essa visualização apresenta um histórico interessante da equipe, ajudando a identificar momentos em que ocorreram mudanças na estrutura do time, mudanças de rumo (as famosas pivotadas), impedimentos, etc.

Visando estabilizar o processo a partir da capacidade produtiva, é importante que o número de itens em WIP não entre em uma tendência de crescimento. Caso isso esteja acontecendo, é bem provável que a equipe precise de otimizações para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiará você a reverberar o seguinte mantra com a equipe: “vamos parar de começar e comecemos a terminar”.

Uma outra análise de WIP que tenho começando a fazer diz respeito ao tempo de vida dos itens que estão em WIP dentro de uma determinada semana. Essencialmente, a visualização leva em consideração os itens que estão em progresso naquela semana e contabiliza há quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gráfico, faço um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) até uma semana em WIP; (3) de 1 à 2 semanas em WIP; (4) de 2 à 3 semanas em WIP; (5) de 3 à 4 semanas em WIP; (6) acima de 4 semanas em WIP.

Ainda sobre a estrutura da visualização, para as semanas que já passaram, é feita a contabilização e a classificação dos itens que estão em WIP no final do período. Já para a semana corrente, é realizada uma análise dos itens que estão em WIP no momento.

Aplicando em um exemplo, é possível perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam há mais de um mês dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade estão crescendo é bem provável que um gargalo esteja se formando em alguma etapa do processo e uma intervenção será necessária.

Tenha em mente que WIP representa esforço e energia que ainda não foram validados e quanto mais tempo a equipe passar carregando-o, menos feedback será recebido, mais lento será o processo de validação das hipóteses por detrás das iniciativas que originaram o trabalho e maior será o risco da empresa estar perdendo uma oportunidade de mercado.

Caso queira saber mais sobre WIP, não deixe de ler post Um estudo mais profundo sobre Limites WIP

Tempo de entrega

O lead time é uma métrica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas têm levado para concluir um item de trabalho. Além disso, equipes que desenvolvem a habilidade de analisar tal métrica conseguem identificar situações que geraram variabilidade no processo (ex: problemas em ambientes, saída de membros da equipe, falta de critérios de aceite claros nas demandas).

A primeira visualização que recomendo estar disponível para a equipe é o gráfico de dispersão do lead time. Ele oferecerá uma ideia se o tempo para que os itens sejam entregues está diminuindo ou não ao longo do tempo.

Conforme ilustrado no gráfico acima, gosto de combinar nessa visualização as seguintes informações: itens finalizados (representados no gráfico pelos pontos em azul) e em progresso (representados no gráfico pelos pontos em vermelho); a média móvel que leva em consideração os últimos 5 itens entregues (esse é um parâmetro totalmente arbitrário); e as informações de percentil 50 (mediana), percentil 75 e percentil 95.

Tais medidas de referência são úteis, pois, a partir do exemplo, trazem a tona constatações como:

• A média móvel tem variado ao longo do tempo.
• Baseado no histórico de itens concluídos, 50% deles foram finalizados em até 10 dias, 75% levaram até 16 dias para serem finalizados e 95% foram concluídos em até 34 dias.

Além disso, o gráfico de dispersão pode gerar respostas para questionamentos como:

• O que a equipe está fazendo para tratar os itens em progresso que estão se tornando casos extremos de lead time?
• O que é possível melhorar no processo para que haja uma diminuição no lead time?

Outra visualização benéfica para entender o tempo de entrega é o gráfico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informação sobre o comportamento da distribuição.

Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indagações do tipo:

• Qual tem sido o lead time mais frequente?
• Os casos extremos de lead time são muito frequentes?
• Qual o formato da distribuição? Há uma concentração do lead time a esquerda ou a direita da distribuição? Existe mais do que uma moda? Geralmente distribuições bimodais representam fluxos de equipes que lidam com mais de um tipo de demanda em seu processo, pois apresentam concentrações semelhantes em diferentes categorias de lead time.

Ritmo das entregas

Medir e visualizar o throughput (vazão) é importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um período de tempo (exemplo: semana, quinzena, mês), bem como para que ela identifique se há a criação de uma tendência de aumento no número de entregas. Ao perceber que o throughput está em queda, a equipe pode buscar entender quais fatores estão afetando a vazão do processo.

Recomendo sempre que possível a quebra da visualização do throughput por tipo de demanda. Dessa forma, fica explícito para todos se a equipe está conseguindo:

• Equilibrar o número de entregas de valor (ex: funcionalidades) com demandas de falha (ex: bugs).
• Lidar com o urgente de forma sustentável. Volta e meia me deparo com equipes que classificam todo tipo de demanda que entra no fluxo de trabalho como urgente e atuam em cima delas, deixando de lado itens que serão importantes para o negócio no médio prazo.

No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de história do usuário com correções de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas críticos que estavam afetando a operação da empresa e por isso entregou apenas correções de bugs.

Análise da taxa de entrada e saída do fluxo

Além do uso do gráfico de CFD (escrevi um blog post completo para falar sobre essa visualização), gostaria de apresentar uma análise que não tenho visto muitos agilistas fazerem: relação entre as taxas de entrada e saída do fluxo de trabalho. Basicamente essa visualização compara a quantidade de itens que a equipe se comprometeu entregar com o número de itens entregues ao longo do tempo.

O que esse tipo de visualização pode trazer de insight? Vamos analisar um exemplo.

Baseado na imagem acima é possível fazer algumas deduções:

• Das 27 semanas analisadas, 10 delas tiveram uma taxa de entrada (itens que a equipe se comprometeu) maior do que a quantidade de itens entregues.
• Na semana 17 a equipe teve um pico de itens comprometidos para serem entregues. Isso ocorreu pelo fato da pessoa que era PO da equipe estar em vias de entrar de férias. Falando em estoques, sugiro a leitura do blog post do Guilherme Fré sobre o assunto.

Analisar a taxa de entrada e saída do processo apoiará a equipe no entendimento de se o ritmo de entrega está acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfiança dos stakeholders pelo fato da equipe entregar menos do que é pedido e frustação da equipe por nunca conseguir entregar “tudo”.

Em um sistema perfeitamente estável, a taxa de entrada e saída deveria ser a mesma. Se você e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e saída iguais), isso demonstrará maturidade do fluxo de trabalho e representará um contexto altamente previsível.

Conclusão

Incorporar uma cultura que traga dados para sua equipe fará com que você monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que está sendo construído ou mantido.

Além disso, propor melhorias e evoluções baseadas em dados é um excelente caminho para a remoção de análises subjetivas e, até certo ponto, vazias. No fundo, espero que com esse blog post você, agilista, estimule que as pessoas utilizem menos o recurso do feeling quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.

Se você busca um material avançado em métricas, recomendo o livro que escrevi sobre o assunto Métricas Ágeis – Obtenha melhores resultados em sua equipe. Aproveite para dar uma olhada nas revisões feitas por quem já leu 

E você? Quais métricas tem utilizado para acompanhar a saúde do processo? Deixe suas experiências nos comentários abaixo!

jQuery( document ).ready(function() {
new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
});

The post Guia de um Agilista: Analisando a saúde do Processo first appeared on Plataformatec Blog.

É comum no ambiente de equipes que trabalham com a construção ou evolução de produtos a necessidade da definição de objetivos, a projeção de resultados esperados e o planejamento de entregas. Se você convive com tais desafios, confira a seguir uma dinâmica na qual obtive ótimos resultados no processo de concepção de OKRs.

O que é OKR e para o que serve

Bom, antes de escrever sobre o assunto, vale a pena definir o termo OKR.

Segundo definição do pessoal da Lean Performance, OKR — do inglês Objectives and Key Results –, utilizado no Silicon Valley por empresas como Google, Facebook, Linkedin, Intel etc, é um framework para definir metas. Trata-se de um sistema simples para criar alinhamento e engajamento em torno de metas mensuráveis e dinâmicas, tipicamente definidas trimestralmente.

OKRs são uma ótima forma das organizações criarem e comunicarem objetivos e resultados. Seu maior propósito é promover conexão entre os objetivos da empresa, do time e dos indivíduos a partir de resultados mensuráveis, fazendo com que todos se movam na mesma direção.

Em resumo, utilizar OKRs adequadamente auxilia no aumento do alinhamento e do engajamento entre as pessoas, e torna o processo de planejamento estratégico mais ágil, com maior cadência de revisão, adaptação e participação de toda a equipe.

O alinhamento e engajamento entre as pessoas aumentam, pois o time passa a fazer parte do direcionamento do produto, gerando maior senso de pertencimento em cada um.

Certa vez, no projeto de um dos nossos clientes, após a equipe definir os OKRs, fui informado pelo QA que o bug que estava ocorrendo no ambiente de produção iria impactar diretamente um dos OKRs, se não fosse corrigido imediatamente. Esse fato me deixou realmente surpreso, pois jamais veria uma ação assim se não compartilhassemos a responsabilidade com todo o time.

Com a aplicação de OKRs, ganhamos mais uma ferramenta na priorização do backlog e, mais importante, temos o escopo direcionado para um objetivo comum.

Ao aplicar dinâmicas de OKRs, espera-se que a empresa, equipe ou pessoa tenha em mãos:

1. Objetivos: Possuem, por essência, característica qualitativa, inspiracional, com prazo definido e apontem para metas, ou seja, dizem para onde se deve ir.
2. Key results: Quantificam toda a ideia inspiracional. Devem ser atingíveis, mensuráveis e realistas. Em outras palavras, indicam como será possível atingir os objetivos.

Beleza Raphael, entendi os conceitos e percebi que isso pode ser útil, mas você pode dar um exemplo?

Objetivo: Aumentar o número de clientes a partir de melhor experiência de uso do aplicativo.

Período: Primeiro trimestre de 2017.

Key results:

• Aumentar a taxa de conversão mobile global de 5% (último trimestre de 2016) para 10%.
• Aumentar o volume de sessões entrantes de 161 mil (último trimestre de 2016) para 240 mil.
• Vender 10.000 mil licenças básicas.
• Vender 500 licenças premium.

De onde vamos tirar esses indicadores?

Aqui vai um ponto importante: para definir bons key results, que sejam mensuráveis e reflitam a situação real, é essencial que a organização seja orientada a dados e indicadores. Basicamente, a empresa deve possuir métricas de produto que assegurem uma tomada de decisão assertiva, dando a real noção de direção e esforço; e não somente baseada em intuições e experiências. Esses dados ajudam a definir as estratégias do próximo período com maior segurança e a otimizar os recursos empreendidos.

Os dados devem direcionar as seguintes questões:

• Quais desafios temos à frente? Quais indicadores estão ruins? O que devemos fazer para melhorar tal indicador? Ex: Diminuir o churn, aumentar prospects e leads, melhorar os processos operacionais etc.
• Qual frente do produto precisamos melhorar para atingir o objetivo X da organização?
• Quais riscos esses dados evidenciam e onde devemos manter a atenção?

Feita essa introdução, vamos para a dinâmica de definição dos OKRs para que você possa aplicá-la e aprimorá-la.

Parte 1 – Compreendendo o negócio

O primeiro tópico a ser discutido diz respeito a revisão ou criação do modelo de negócios do produto.

Baseado nas personas, a equipe poderá analisar os canais, formatos de relacionamento com o cliente, fontes de receita, atividades chave, recursos chave, parceiros chave e estrutura de custo.

Para levantar tais informações, sugiro que você leve as seguintes perguntas:

• Personas: qual o perfil de clientes que utilizam o produto?
• Canais: como os clientes chegam ao produto, geralmente?
• Formatos de relacionamento: como ocorre o relacionamento dos usuários com o produto atualmente?
• Fontes de receita: quais são as fontes de receita atuais?
• Atividades chave: quais as principais atividades que precisam ser realizadas no dia a dia da operação para que o produto possa entregar o valor que se propõe?
• Recursos chave: o que o produto possui de diferencial competitivo?
• Parceiros chave: quais parceiros ajudam a empresa a viabilizar/alavancar o produto?
• Custos: qual a estrutura necessária para tornar a operação do produto viável?

Assim, a equipe terá maior clareza sobre o estágio atual do produto. Caso o produto não possua um modelo de negócios, não deixe de desenvolver um. Uma dica de leitura para que você possa construir um é o livro Business Model Generation.

Após a revisão do modelo de negócio, o próximo passo será analisar as principais métricas do produto. Cada pessoa da equipe poderá explorar o produto a partir de:

• Informações financeiras: churn, ticket médio, custo de aquisição do cliente etc;
• Comportamento de acesso: número de acessos, taxa de saída, tempo despendido nas páginas do fluxo de venda, origem do tráfego, dispositivo utilizado para acessar o fluxo de venda etc;
• Perfil do cliente: dados demográficos, nível de serviço contratado, faixa etária etc.

A partir das métricas de produto, cada membro da equipe deverá identificar pontos de melhoria e pontos onde o produto aparenta estar bem.

Parte 2 – Definindo os OKRs

Feita a análise das métricas de negócio e do modelo de negócio, levante com a equipe os potenciais objetivos que serão trabalhados no período de tempo (exemplo: próximo trimestre).

Se você estiver facilitando a discussão, tenha em mãos as seguintes dicas antes da equipe determinar os objetivos:

• Tenha poucos objetivos (de 3 a 4). Motivo? O trimestre, por exemplo, é curto para se assumir muitos objetivos.
• Relacione os objetivos do produto com os objetivos da empresa.
• Relacione os objetivos com problemas e necessidades reais.
• Utilize as métricas de negócio para definir os objetivos.

Caso os objetivos levantados sejam complexos ou grandes, vale a pena fomentar discussões para que a equipe simplifique. O mantra que deve ser pensado aqui é: pequenos incrementos que geram valor econômico para o negócio.

Para medir os objetivos, a equipe deverá elencar quais serão os key results que serão acompanhados ao longo do período. Para que a equipe tenha um norte:

• Defina poucos key results (de 3 à 4). Motivo? Se o objetivo precisa de muitos itens para ser medido é provável que ele seja complexo demais.
• Os key results devem ser expressos através de números.
• Quais resultados garantirão que alcancemos nossos objetivos?

Parte 3 – Definindo um roadmap

Dado que os objetivos e os key results estão definidos, a equipe pode se questionar: bom, e agora, o que vamos fazer para atingir nossos OKRs?

Sugiro como última parte da dinâmica o desenvolvimento de um roadmap, a fim de identificar entregáveis macro e quando eles deverão ser entregues ao longo do período (ex: trimestre).

Técnicas de brainstorming e story mapping ajudam a ter uma ideia de cronologia e dependência entre as possíveis funcionalidades que serão construídas para alcançar os OKRs.

Antes que alguém me crucifique dizendo que não estou sendo lean, gostaria de deixar algo claro. O roadmap criado será uma referência que COM CERTEZA (repita, C-O-M C-E-R-T-E-Z-A) sofrerá alterações ao longo do tempo por conta das mudanças e experimentações que acontecerão para atingir os objetivos e key results definidos.

Conclusão

A estrutura de OKR pode ser replicada no nível empresa, equipe e, até mesmo, indivíduo. Uma dica que sempre compartilho é: comece com poucos objetivos e trace em torno de 3 à 4 key results. O motivo? Foco. Quanto mais direcionado, mensurável e acionável for a sua estrutura de OKR, maiores serão as chances de alcançar o planejamento desenvolvido.

Lembre-se que os OKRs devem ser revistos com frequência para que o time possa tê-los sempre em mente e, juntos, decidirem onde despender esforços para caminharem na direção correta.

É essencial que a empresa possua uma cultura questionadora, desapegada de ferramentas e soluções revolucionárias e tenha um ambiente que promova aprendizado com as falhas, pois certamente haverão erros no início.

A dinâmica que apresentei teve como objetivo conectar negócio, resultados atuais e futuro (OKRs + funcionalidades).

E você, como tem aplicado dinâmicas de OKR? Compartilhe os resultados e desafios.

Até próximo dilema

Algumas referências:

• Metas Ágeis com OKR
• The Art of the OKR
• OKRs
• The Basics of OKR – Google’s Secret Sauce

The post Dilemas de PO: como definir OKRs em equipes ágeis first appeared on Plataformatec Blog.

• Como priorizá-las?
• Quando elas serão entregues?

Neste blog post, teremos a oportunidade de discutir algumas abordagens que poderão ajudar você a responder tais questionamentos (neste ano, falarei mais sobre o assunto aqui no blog).

Tenho observado um movimento de gestão de produtos que vem concretizando os princípios por trás do Lean Startup que diziam: construa, meça e aprenda. A partir da ótica de medir e aprender, é perceptível que gestoras e gestores de produto começam a levantar hipóteses de negócio a partir de métricas como taxa de conversão, recorrência mensal, taxa de evasão, análise da interação dos usuários nos fluxos críticos da aplicação, etc.

Voltando para a primeira pergunta que abriu o texto, nos deparamos com atributos quantitativos que nos permitem priorizar o que precisamos construir. Tal ferramental sustenta a ideia de que estamos interessados em melhorar os resultados do produto a partir de números.

Antes que alguém me crucifique, nem só baseados em números devem ser os fatores para a priorização de novas features dos produtos que trabalhamos. Caso você tenha a possibilidade de se aproximar do seu usuário para perguntá-lo o que ele deseja, você também estará aumentando a probabilidade de construir algo que traga valor para ele. Dados qualitativos podem ser coletados através de questionários online, pesquisas de campo, análises de interação a partir de protótipos, etc.

Ao priorizarmos uma funcionalidade, estamos em busca de gerarmos uma solução que traga valor para nossos usuários, clientes, acionistas e empresa. Em outras palavras, podemos dizer que estamos em busca de encontrarmos uma relação positiva na equação de valor que nada mais é do que a diferença entre o valor criado pela solução menos o preço pago por ela #maisvalorporfavor.

Quadro de abordagens quali e quantitativa

Dado que priorizamos aquilo que é mais importante para a saúde do produto e para os usuários, um segundo questionamento que por vezes fica na cabeça é: quanto tempo levaremos para entregar essa nova feature?

Partindo do pressuposto que vivemos em um contexto incerto (sim, acredite, desenvolver software não é algo determinístico), trabalhar com cenários de entrega passa a ser uma abordagem mais confiável. Ao utilizar projeções você passa a calcular ou predizer um evento futuro a partir da análise dos dados disponíveis (passado).

Para que isso seja possível, sugiro que você e a sua equipe passem a monitorar uma métrica de processo: lead time (número de dias entre o início e o fim do processo de entrega de uma história do usuário, um bug, etc.).

Em outras oportunidades tivemos a chance de discutir formas de analisar o lead time (“Looking at Lead Time in a different way” e “Why we love metrics? Learning with Lead time”), porém, gostaria de compartilhar como o percentil pode ser uma referência útil para desenhar cenários futuros a partir de referências do passado.

Se você não conhece, percentil é uma medida que divide a amostra ordenada (por ordem crescente dos dados) em 100 partes, cada uma com uma percentagem de dados aproximadamente igual. Traduzindo e relacionando com uma distribuição de lead time, é como se analisássemos o lead time das demandas que foram entregues e discutíssemos qual o percentual de chances de um determinado valor ser atingido a partir do percentil.

Em um projeto recente utilizamos a informação de percentil para projetar possíveis prazos de entrega de uma demanda de negócio que havia sido priorizada pelo Product Owner (PO) da célula em que trabalhamos.

Histograma de lead time

A equipe utilizou o histograma acima e passou a seguinte análise do cenário ao PO:

• 50% das demandas levaram até 6 dias para serem concluídas (mediana).
• 75% das demandas levaram até 12 dias para serem concluídas ou seja apenas 25% levaram mais do que tal limite para serem concluídas (percentil 75).
• 95% das demandas levaram até 18 dias para serem concluídas, o que nos leva a afirmar que apenas 5% delas levaram mais tempo do que isso para serem finalizadas (percentil 95).

A partir dos dados acima, o time demonstrou confiança de entregar a demanda entre 6 e 12 dias. Com tal informação em mãos, o PO traçou o plano de comunicação e promoção do novo recurso do produto. Se você ficou curioso em saber, a demanda foi entregue em 8 dias.

Ao utilizar tal abordagem de projeção, o time e o PO se sentiram mais confortáveis e confiantes. Caso o PO tivesse imposto para o time que a nova demanda deveria ser entregue em 3 dias, com posse das informações de percentil, o time teria insumos para dizer que seria muito difícil entregá-la pelo simples fato de que apenas 25% das demandas entregues foram concluídas no prazo determinado (percentil 25).

Fecho esse texto com algumas sugestões:

1. Crie hipóteses através de fatos que podem ser originados por dados quanti ou qualitativos.
2. Projete cenários de entrega a partir de uma referência (histórico do time).
3. Desenvolva pequenas entregas de valor, pois elas permitirão que você mude de direção mais rápido.
4. Não acredite que métrica de produto ou processo é algo burocrático, pois elas servem como uma base para você construir um futuro melhor.

E você? Como tem priorizado e projetado suas entregas? Quais métricas e abordagens tem utilizado? Compartilhe sua opinião nos comentários abaixo. Estou curioso para aprender com o seu exemplo.

Se está interessado saber mais como lidar com prazos de projetos de software não deixe de conferir nosso e-book gratuito sobre o assunto.

The post Dilemas de PO: priorizar features e projetar entregas first appeared on Plataformatec Blog.