Tive a sutileza de usar o termo “pessoa de produto” para fugir de nomenclaturas como Product Owner, Product Manager, Product Success Manager etc. Minha motivação para escrever o texto veio de uma frase que escutei recentemente e que dizia o seguinte: “aqui na empresa, as pessoas de produto são como mini CEOs”. Será que o fato de a pessoa lidar com múltiplas disciplinas (negócio, tecnologia, pessoas, experiência do usuário etc.) ela está habilitada a estar no patamar de ser a CEO de um produto?

Dando uma resposta simplista, minha opinião é não. O cargo que está mais próximo do CEO é o de CPO (Chief of Product Officer), o qual se reporta diretamente a ele e é responsável por todas as atividades do produto dentro da organização. Tais pessoas atuam na definição da estratégia global do produto projetada para alcançar os objetivos estabelecidos pelo CEO e os membros do conselho.

O que faz uma pessoa de produto?

O que uma empresa deve esperar de uma pessoa de produto é alguém conectado com os estímulos do mercado, atento ao feedback dos usuários e clientes, preocupado com o propósito do produto, responsável pela priorização e especificação do trabalho que é empregado pelas equipes de tecnologia, bem como pelo desenvolvimento, comunicação e execução da visão e estratégia do produto.

Além disso, a pessoa deve saber justificar a relação entre a solução tecnológica proposta e as métricas de negócio (ex: aumento de receita, diminuição do churn, aumento do ticket médio, diversificação do portfólio de produtos etc.) e garantir o melhor atendimento ao cliente.

Ocasionalmente, a pessoa de produto terá de contar com o apoio das áreas de marketing e de negócios com o objetivo de realizar as atividades necessárias para o sucesso do produto.

Em resumo: é uma pessoa articulada dentro da organização que compreende o que acontece fora dela (ex: desejo e necessidades dos clientes, posicionamento dos concorrentes, ambições dos investidores etc.), focada em gerar bons entregáveis e organizar a fila de trabalho das equipes para que elas desenvolvam produtos que apoiarão a estratégia da empresa.

Cabe ressaltar que há vários níveis de pessoas de produto, com responsabilidades muitas vezes diferentes e, frequentemente, compartilhadas. Por exemplo, nada impede a existência de um Product Owner e um Product Manager no mesmo contexto, pois, cada pessoa atuará em níveis diferentes da cadeia de valor do produto e com granularidades diferentes das iniciativas.

O que faz um CEO?

Retomando a provocação colocada no início do texto, volto a questionar: qual a semelhança entre a descrição que fiz de uma pessoa de produto e o trabalho de um CEO? Bem, antes vale a pena compartilhar o que é a função de um CEO dentro de uma organização.

Segundo uma definição do Investopedia, o CEO é o executivo de mais alto escalão em uma empresa e suas principais responsabilidades incluem: tomar decisões corporativas importantes; gerenciar as operações e recursos gerais de uma empresa; e atuar como o principal ponto de comunicação entre o conselho de administração e as operações corporativas.

Na minha opinião, o CEO de uma empresa é a pessoa que:

• Desenha e direciona a estratégia da empresa: a equipe pode ter autonomia em ajudar no planejamento da estratégia, os investidores podem aprovar o plano de negócio e o conselho pode pedir algum tipo de revisão em um plano de negócio, porém, a pessoa que terá completa autonomia e responsabilidade pela execução da estratégia da empresa será o CEO.
• Modela e direciona a cultura, valores e comportamento da empresa: as atitudes e decisões do CEO terão total impacto na construção e no reforço dos valores, crenças e normas da empresa.
• Desenvolve e lidera o time de líderes da empresa: é papel do CEO desenvolver e liderar um grupo de líderes para que sejam transparentes entre si, se sintam seguros para se expressar, busquem o conflito produtivo, tenham clareza dos resultados esperados, estejam engajados em um mesmo objetivo (mesmo que não haja 100% de consenso) e foquem nos resultados coletivos em vez dos resultados individuais.
• Aloca capital para as prioridades da empresa: geralmente assessorado por alguma pessoa de finanças, o CEO é a pessoa da grana. É ele quem toma decisões quanto aos orçamentos dentro da empresa. Ele financia iniciativas (produtos e projetos) que apoiam a estratégia e reduzem as iniciativas que não geram resultado ou que estão desalinhadas aos objetivos de negócio.

Por que uma pessoa de produto não é um mini CEO?

Esperar que uma pessoa de produto exerça as atribuições discutidas anteriormente pode gerar 4 disfunções, sendo elas:

• Frustração: as pessoas acreditam que terão autonomia total para alavancar o produto, controlar o budget, mudar a cultura da equipe, alocar as melhores pessoas para trabalhar no produto, repensar a estratégia do negócio, mas esquecem de se articular com os objetivos estratégicos da empresa. Os primeiros indícios de frustração aparecem quando as pessoas de produto começam a receber as primeiras negativas para as sugestões oferecidas na forma como foi estruturado o orçamento da empresa, em como organizar as equipes e em como solucionar os desafios culturais. No meu ponto de vista, tal disfunção pode ser resolvida no momento da contratação, ao deixar claro o que é e não é esperado da pessoa que for responsável pelo produto dentro da empresa.
• Foco perdido: dificilmente uma pessoa de produto terá uma visão holística da estratégia da organização como o CEO. Ao tentar envolver-se com questões estratégicas que não estão conectadas com o produto (ex: participar de reuniões que não tenham relação com temas que ajudarão na alavancagem do produto), afastam o responsável do produto da equipe, o que aumenta a chance da criação de soluções que não suportarão os objetivos do negócio (desperdício). Uma das formas de resolver tal disfunção se dá a partir da construção de uma visão clara de como os objetivos estratégicos estão relacionados ao produto e uma ferramenta útil para isso é o OKR. Lembre-se: se você é uma pessoa de produto, você existe para ajudar o negócio, portanto, foque nisso.
• Queda no desempenho da equipe: quando uma pessoa de produto se encontra extremamente atarefada por gerenciar a equipe, operar o produto, garantir o atendimento ao cliente, acompanhar métricas de negócio ou pelo fato dela exercer múltiplos papéis (ex: head de inovação, head de tecnologia, head de produto, executivo de marketing etc.), o efeito de tal sobrecarga é a queda do desempenho das equipes. Geralmente tal disfunção é causada por: retrabalhos; indefinições; centralização no processo de tomada de decisão no que diz respeito ao produto; e baixa qualidade no processo de priorização.
• Atividades básicas ficam abandonadas: quando uma pessoa de produto não sabe claramente o que é esperado dela uma série de atividades “básicas” são negligenciadas, como: gerenciar e priorizar o escopo de trabalho da equipe; dar suporte para a equipe em dúvidas sobre negócio; ter uma boa comunicação com os stakeholders da empresa; analisar as métricas de produto; compreender o negócio e o cliente em profundidade; compreender o modelo de negócio, o processo, a necessidade do cliente e a experiência do usuário. Quando a pessoa de produto delega alguma das atividades listadas acima para a equipe, ela está se omitindo do seu trabalho.

No contexto de uma startup, é bem provável que o CEO do negócio exerça o papel de uma pessoa de produto, mas como tentei apresentar ao longo do texto o contrário não parece ser correto. Deixo a dica de um ótimo podcast sobre o assunto no blog Seeking Wisdom. Qual é a sua opinião? Deixe seus comentários abaixo!

The post Pare de chamar Product Owners e Product Managers de mini CEOs first appeared on Plataformatec Blog.

• Será que temos capacidade produtiva suficiente para operar a quantidade de iniciativas (evoluções nos produtos atuais e criação de novos produtos) que foram definidas para suportar a estratégia da empresa?
• Os critérios de priorização das iniciativas estão claros para os diferentes níveis da empresa? Todos compreendem as motivações pelas quais as iniciativas foram organizadas do jeito que estão?
• Como está a saúde do portfólio de produtos da empresa? Todos os produtos estão operando eficientemente e gerando resultado financeiro positivo?

Neste blog post, compartilharei uma técnica que temos utilizado na Plataformatec e que vem ajudando nossos clientes a terem visibilidade sobre em que estágio os diferentes produtos do seu portfólio se encontram.

Premissas para uma boa gestão de portfólio de produtos

Antes de aprofundar na descrição da técnica, gostaria de compartilhar três premissas importantes que apoiam uma gestão de portfólio de produtos inteligente:

• Estabeleça resultados de negócio: um erro comum que tenho observado nas empresas que atuam com produtos digitais é uma obsessão pela entrega de funcionalidades (features) e pouca discussão sobre como o entregável de fato está contribuindo para um melhor resultado no negócio (aumento da receita, diminuição da evasão de clientes, aumento no número de clientes ativos, etc.). Sendo assim, para que o portfólio de produtos seja administrado de forma inteligente, é fundamental que todos da empresa estejam engajados em como ajudar o negócio a gerar melhores resultados.
• Colete e divulgue as métricas de negócio: para que todos tenham consciência do impacto que o seu trabalho tem no resultado da empresa, se faz necessária a coleta e a disseminação das métricas do negócio (para mais informações sobre o assunto, não deixe de ler o blog post O que seriam boas métricas para produtos digitais?). Neste sentido, desenvolver rotinas que garantam visibilidade sobre a saúde do negócio se torna algo primordial para que as pessoas criem uma cultura orientada a dados. Algumas formas inteligentes que tenho observado e recomendado são: envio de uma mensagem diária através de um canal assíncrono (ex: email) com os principais indicadores do negócio; criação de uma plataforma analítica com as métricas do negócio disponíveis para consulta; reuniões quinzenais sobre como as funcionalidades construídas estão impactando os resultados dos produtos; reuniões mensais sobre como está a saúde financeira do portfólio de produtos e para a definição de planos de ação; reuniões trimestrais para a definição de OKRs (há um tempo atrás escrevi um blog post sobre como definir OKRs em equipes ágeis).
• Equilibre os investimentos: expandir o negócio atual e explorar novas oportunidades é algo tentador, principalmente em empresas que acabaram de captar montantes consideráveis de dinheiro. Porém, lembre-se que manter e desenvolver o território atual do negócio da empresa é algo que garantirá uma saúde financeira no curto prazo. Portanto, balancear a carga de recursos (financeiros, pessoas, tecnologia, pesquisa, etc.) investidos garantirá que a empresa olhe para o curto, médio e longo prazo, a partir da combinação de evoluções nos produtos atuais, em inovações para o mercado atual e na exploração de um mercado futuro.

Analisando os diferentes estágios dos produtos

Vamos ao que interessa. Com objetivo de analisar o portfólio de produtos em uma empresa, tenho utilizando um modelo que leva em consideração três estágios de um ciclo de vida que são:

1. Discovery: neste estágio, a empresa identificou uma oportunidade de mercado, desenvolveu um modelo de negócio, definiu uma estratégia comercial, criou uma solução tecnológica mínima que entrega valor aos usuários e estruturou um processo, mesmo que ineficiente, para sustentar a operação do produto. É muito comum acontecerem mudanças e desperdícios, pois há o desafio de descobrir uma solução que o mercado enxergará valor. Além disso, o estágio de descoberta exige um maior investimento e geralmente é mais estressante.
2. Refinamento: neste estágio, o produto já se encontra em operação e o modelo de negócio precisa ser refinado para que a operação se torne viável. Evoluções na plataforma tecnológica, intensificação na promoção através das estratégias em marketing e a identificação de novos canais de vendas são temas corriqueiros no dia a dia de produtos neste estágio. O produto ainda está descobrindo a melhor forma de gerar resultado e qualquer estímulo do mercado (ex: concorrência, clientes, preço de venda, etc.) pode ser crítico para que ele se torne um player de expressão.
3. Market share: o último estágio do modelo tem como objetivo garantir que o produto esteja gerando lucro para a empresa em um horizonte de curto, médio e longo prazo e, pode ser dividido em duas frentes:

• Eficiência operacional: as evoluções e melhorias no produto têm como foco o ganho através da escala. Redução no custo de aquisição por cliente, redução no custo de atendimento aos clientes e diminuição nos custos de infraestrutura tecnológica são exemplos de direcionadores que garantirão uma maior eficiência operacional para a empresa.
• Inovação: as evoluções têm como cerne a criação de um diferencial competitivo que torne o produto cada vez mais valioso, raro, difícil de ser imitado e insubstituível. Para que a empresa promova a inovação no produto é importante que ela compreenda as necessidades dos clientes, promova rotinas que estimulem soluções “fora da caixa” e pense em maneiras de expandir o mercado atual.

Conclusão

A visualização dos produtos a partir dos estágios apresentados anteriormente tem os seguintes benefícios:

• Quando tudo é prioridade, nada é prioridade. Dar visibilidade aos diferentes stakeholders sobre o número de produtos que a empresa está operando e criando e, ajudar a repensar a estratégia caso a relação entre a capacidade de entrega e o número de demandas seja elevadamente desproporcional.
• Questione a crença de que todos os produtos dão o mesmo resultado. Estruturar e acelerar o processo de tomada de decisão no caso de produtos que estejam há um tempo sem gerar resultado para a empresa, bem como dar clareza sobre os critérios utilizados para a manutenção do atual portfólio de produtos.
• Promova o desapego nas decisões. Equilibrar os investimentos e a alocação das equipes sem ficar preso a desenhos organizacionais, mas sim com base na necessidade de aceleração dos resultados do negócio.

E você? Os estágios apresentados acima fazem sentido para o contexto de produtos da sua empresa? Deixe seu comentário abaixo.

Ps: Caso você trabalhe com serviço, saiba que estamos aplicando no portfólio de serviços da Plataformatec todos os conceitos apresentados neste blog post

The post Avaliando os estágios do portfólio de produtos em uma empresa digital 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.

Então, no meio do seu sprint, o P.O. descobre que as features D e E foram lançadas por um concorrente e que vocês estão perdendo usuários por isso. Pensando nisso, a P.O. decide despriorizar a história C. Isso seria apenas um exemplo de como um card pode ser despriorizado no meio do seu desenvolvimento. Mas, e agora, o que acontece com a história C?

Para responder isso, deixe-me fazer um paralelo com uma companhia de perfumes a base de álcool.

Na coluna de backlog, a companhia tem a garrafa pronta mas sem fluído algum. Quando a garrafa começa a ser enchida, o card é passado para “in progress”. Após a garrafa estar cheia, ela é lacrada e o card vai para “done”.

O que acontece então se outro perfume tem sua prioridade elevada a um nível maior do que o que está sendo abastecido? Bom, como sabemos, fluídos com base em álcool são voláteis e, com o tempo, evamporam totalmente, sendo necessário que se reabasteça o recipiente.

O mesmo acontece com uma história e seu código. Com o tempo, o código que compõe tal história se torna obsoleto e desnecessário, perdendo o valor que tinha outrora. Neste caso, o que fazer com a história despriorizada depende dos seguintes pontos:

• Quanto tempo a história C continuará no mesmo estágio?
  • Se a história permanece muito tempo no mesmo estágio, alguma parte do trabalho já feito pode se tornar desnecessário, portanto, você poderia apenas removê-la da coluna e colocá-la de volta ao backlog, já que algum refinamento pode ser necessário para que essa história seja desenvolvida novamente.
  • Se a história vai ficar por um curto período de tempo em tal coluna, você pode optar por deixá-la lá e, quando sua hora chegar, pode continuar aproveitando o que já havia sido desenvolvido.
• Qual o valor que a história C vai gerar quando pronta?
  Digamos que o retorno gerado pelo desenvolvimento de tal feature seja pequeno. Será que vale a pena pausar seu desenvolvimento e ter o risco de investir ainda mais dinheiro no seu desenvolvimento em outro momento? O retorno gerado será maior do que o tempo total de desenvolvimento gasto?

Para que isso seja verdade, o seguinte precisa acontecer (observado na imagem abaixo):

• $ gasto com o desenvolvimento inicial + $ gasto com o resto do desenvolvimento < retorno da história C
  • A quantia gasta com o resto do desenvolvimento aumentará com o tempo, já que o desenvolvimento feito anteriormente vai perdendo valor.
• Caso o retorno seja menor do que o gasto, é melhor ignorar a funcionalidade. No entanto estes cálculos não são tão simples como parecem… Você precisa levar em conta riscos, aumento na receita, aumento no número de usuários, etc… Então tenha cuidado com essa ação.

Portanto, baseado no que já foi dito, você pode ter as seguintes ações a respeito do card C:

• Mantenha-o na coluna “in progress” e recomece o trabalho quando sua prioridade for retomada
  Essa pausa será rápida e não afetará o desenvolvimento da feature. Neste caso é importante deixar visível de alguma forma no quadro que essa história está “bloqueada” por motivos de priorização.

• Ponha-o na coluna de backlog novamente, e recomece quando necessário
  A pausa será longa e o card precisará de um novo refinamento.

• Termine-o primeiro, antes de começar outra história
  O card está quase pronto e, caso você pare seu desenvolvimento, quando pronto, seu valor será menor do que o gasto no seu desenvolvimento.

• Cancele o seu desenvolvimento
  A história está muito longe de ser terminada, e seu valor final é muito pequeno para pagar o tempo que ela ficará pausada.

É importante também notar que isso NÃO deve ser algo comum em seu processo. Se coisas como essa estão acontecendo frequentemente, você pode precisar melhorar suas priorizações!

O que acha do que foi discutido aqui? Deixe seus comentários abaixo!

The post A user story em desenvolvimento foi despriorizada, e agora? 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.