Mais sobre priorização de roadmaps

Como comentei em meu artigo anterior, priorização é uma das principais tarefas de um PO e de um PM, e é o diferencia um PO de um BA. Escrevi um artigo sobre as várias formas de priorização e sobre como dizer não aos inúmeros pedidos que recebemos tanto dos clientes quanto das pessoas de dentro da empresa.

priorizacao

Como o passar do tempo aprendi mais maneiras de se priorizar um roadmap e queria compartilhá-las aqui.

Sequenciador de Funcionalidades

O Sequenciador de Funcionalidades foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

O Sequenciador de Funcionalidades ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o sequenciador de funcionalidades irão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

secuenciador-2

De acordo com Paulo Caroli, em seu livro Direto ao Ponto, Criando produtos de forma enxuta, o Sequenciador de Funcionalidades funciona da seguinte forma:

Feature é a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: imprimir nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrição de uma feature deve ser o mais simples possível. O usuário está tentando fazer uma coisa. O produto deve ter uma feature para isso. Que feature é essa?

Cada cartão de feature possui uma cor representado o nível de incerteza, e marcações para o nível de esforço e o valor de negócio. Por exemplo, a figura acima mostra features em index cards, nas quais foram adicionadas marcações de $, $$ ou $$$, respectivamente, para valor de negócio alto, muito alto e altíssimo, bem como E, EE, ou EEE, respectivamente, para nível de esforço baixo, médio e alto. O nível de incerteza é representado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente.

O nível de incerteza da Feature refere-se ao grau em que a Feature é incerta, a partir do ponto de vista do entendimento de negócio e do entendimento técnico. Isso é indicado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente. O entendimento da Feature de acordo com os desafios técnicos, e os requisitos de infraestrutura. Você já fez isso antes? Você sabe como fazê-lo? Um sim bem firme indica elevado nível de entendimento técnico. A clareza do objetivo da Feature, o benefício para o negócio e o que deve ser feito. O que fazer? Uma resposta direta e clara indica um alto nível de concordância.

Esforço da Feature

O nível do trabalho que precisa ser feito para a Feature. O entendimento da equipe de acordo com a dificuldade e o trabalho que vai ser necessário para completar a Feature.

Valor do Negócio da Feature

O valor de negócio, o ROI (Return On Investment) associado a Feature, uma medida do negócio sobre o valor previsto para tal feature. Qual é o retorno no investimento ou a economia que a Feature vai trazer?

As regras do sequenciador de features

Features serão adicionadas a cada onda. A seguir, as seis regras para adicionar features às ondas. Tais regras foram definidas depois de aplicar esta forma de planejamento e priorização inúmeras vezes.

  • Regra 1: Uma onda pode conter no máximo 3 features.
     
  • Regra 2: Uma onda não pode conter mais de uma feature em cartão vermelho.
     
  • Regra 3: Uma onda não pode conter três features, somente em cartões amarelos e vermelho.
     
  • Regra 4: A soma de esforço das features não pode ultrapassar 5 Es.
     
  • Regra 5: A soma de valor das features não pode ser menos de 4 $s.
     
  • Regra 6: Uma onda tem de conter no mínimo 2 features.

A regra 1 limita o número de features que estão sendo trabalhados ao mesmo tempo. Isso evita o acúmulo de features parcialmente completas, aumentando o foco para as poucas features priorizadas por onda. As regras 2 , 3 e 4 evitam um período de trabalho desequilibrado com muita incerteza, ou muito esforço. As regras 5 e 6 garantem o foco constante na entrega de alto valor para o negócio.

Os MVPs no sequenciador de features

Além dos cartões de features (sequenciados), o sequenciador de features mostra claramente o agrupamento de features para cada MVP. Isto é representado por post-its no canto direito sobre a linha que delimita uma onda.

As ondas não terão necessariamente uma relação de um para um com os MVPs. O intuito é de organizar features em ondas para entregar valor o mais rápido possível, entretanto respeitando as dependências entre as features

RICE

Quando cheguei na ContaAzul me deparei com outro método de priorização adotado pelo time de produtos, o RICE.

RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa irá alcançar num determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100%, para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

A melhor ferramenta de priorização

Tanto o índice RICE quanto o sequenciador de funcionalidades são excelentes ferramentas para o gestor de produtos poder ter mais confiança em sua priorização. Contudo, como eu disse no meu primeiro artigo sobre o tema:

…existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. Ou seja, o que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que priorização de roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas, mas sempre que esse método falhar em um determinado item que temos certeza que seria melhor fazer antes ou depois do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso, ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

E por que é preciso incluir o bom senso como mais uma ferramenta de priorização? Porque para priorizar é preciso entender os objetivos dos usuários de seu produto de software e do dono do software. Esse objetivos podem ser conflitantes e, provavelmente, existem mais variáveis do que alcance, impacto, confiança, esforço, retorno, valor, custo, satisfação e necessidade para ajudar a quantificar esses objetivos. Como se não bastasse a grande quantidade de variáveis e os objetivos conflitantes dos usuários do produto de software e do dono de software, há ainda a variável tempo, ou seja, esses objetivos podem mudar ao longo do tempo.

Toda priorização é uma decisão e todo processo decisório é composto de incertezas. As ferramentas acima ajudam a remover um pouco das incertezas. Contudo, com essa grande quantidade de variáveis, é muito difícil, diria até que impossível, remover 100% das incertezas. Por esse motivo, para fazer uma boa priorização, pode ser útil usar uma ou mais dessas ferramentas descritas, mas é importante usar também o instinto, a experiência e o bom senso.

BA, PO e PM

Escrevi em julho de 2014 sobre as diferenças entre gestor de produtos ou product owner, onde comento que gestor de produtos e product owner são dois lados da mesma moeda. Enquanto o papel de gestão de produtos é focada no resultado, ou seja, no software que está sendo feito e nos objetivos desse software, tanto para o dono do software quanto para seu usuário, o papel de product owner é focado no processo pois todas a metodologias ágeis tem seu foco no processo de desenvolvimento de software.

Em um outro artigo, de março de 2016, comento que “BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários”.

Algum tempo depois…

Esse dois artigos foram escritos baseados em minha experiência na Locaweb, onde tínhamos somente o papel de gestor de produtos, que chamávamos indiscriminadamente de PO ou de PM e em conversas que tive com pessoas de outras empresas onde elas me contavam sobre suas estruturas e divisões de papéis e responsabilidades.

Em agosto de 2016 assumi a gestão da gestão de produtos na ContaAzul e quando aqui cheguei me deparei com business analysts (BAs) e product managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações de essa estrutura ter sido criada. Após essas conversas, ficou mais claro para mim a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na imagem abaixo.

ba-po-pm

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Ou seja, existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO e depois para PM.
     
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação.
     
  • Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
     
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá que se preocupar com gestão de pessoas.
     
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs, ou seja, se houver BAs e ou POs numa determinada organização, minha recomendação é por tratar esse papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que com essa imagem consegui deixar mais claro as diferenças e similaridades das funções de BAs, POs e PMs.

Churn negativo, o santo graal das empresas de produtos de software por assinatura

Santo Graal é uma expressão medieval que designa normalmente o cálice usado por Jesus Cristo na Última Ceia, e onde, na literatura, José de Arimateia colheu o sangue de Jesus durante a crucificação. O Santo Graal também está presente na história do Rei Arthur. É o objetivo da busca dos Cavaleiros da Távola Redonda. Há quem atribua a esse cálice poderes como prover felicidade e juventude eterna em abundância infinita. Por esse motivo chamo o churn negativo de o Santo Graal das empresas de produtos de software por assinatura. É algo buscado arduamente por essas empresas para alavancar seu crescimento, mas bastante difícil de atingir.

santo-graal

Contudo, antes de falar sobre churn negativo, vale relembrar o conceito de churn. Escrevi uma definição de churn em um artigo antigo meu intitulado “Seja uma data geek“, quando falei sobre um pedaço do funil de conversão que normalmente é pouco comentado:

Quantidade de usuários e clientes que deixaram de ser usuário ou cliente: eventualmente alguns usuários e clientes deixaram de ser seu usuário ou cliente. É importante saber quantos são, e os motivos por que isso acontece, pois aqui você descobrirá muito informação para melhorar seu produto web.

Pronto, está aí em cima a definição de churn, é a quantidade de clientes que deixam de ser seu cliente. Simples assim.

Esse número é muito importante em qualquer empresa que tem por modelo de negócio o uso contínuo, principalmente aqueles baseados em assinatura. Ele costuma ser medido como um percentual da seguinte forma:

churn mensal = quantidade de clientes que cancelou no mês / total de clientes do último dia do mês anterior

Existe também o churn anual que se calcula da mesma forma, só que dividindo a quantidade de clientes que cancelaram em um determinado ano pelo total de clientes do último dia do ano anterior.

É um número que contém muita informação mas, por ser somente um único número, ele deixa várias perguntas em aberto. Já vi discussões do tipo “se o churn está em 20%, em cinco meses não teremos mais clientes, então não vale a pena investir em divulgar esse produto”. Uma frase como essa não tem muito sentido pois mesmo que o churn se mantenha a 20% durante vários meses, até mesmo mais de 5 meses, a quantidade total de clientes pode continuar crescendo. Como? Basta ter uma quantidade maior de ativações do que de cancelamentos. Veja o exemplo abaixo:

exemplo_churn

Apesar de todos os meses o churn ser maior do que 20%, o crescimento no ano foi de 73 novos clientes.

Note que a quantidade de novos usuários (coluna “ativaram”) cresce ao longo dos meses. Por isso a quantidade de usuários ativos cresce apesar do churn de 20%.

Um exemplo real, os dados de novos assinantes e cancelamentos do ContaCal, experimento de startup que iniciei em julho de 2011 com o objetivo de avaliar se era possível criar do zero, sem nenhuma marca forte por trás, um produto web que desse algum retorno.

churn_exemplo_real

Como dá para ver acima, mesmo tendo churn superior a 20% e, em alguns meses, a 30%, há um crescimento da quantidade total de assinantes. Houve queda do total de assinantes em 3 meses, julho, agosto e dezembro. Em janeiro, mesmo tendo um churn de quase 36%, foi o mês em que o ContaCal mais cresceu.

Churn é um limitador do crescimento

Suponha que você tenha um churn mensal de 20% e que a quantidade de novos usuários por mês é 40. Com esses números, seu limite de crescimento será 200 usuários. Por quê? Simples, 20% de 200 é igual a 40. Você consegue 40 novos clientes todos os meses mas. Como seu churn é de 20% ao mês e você tem 200 usuários, você perde 40 usuários por mês. Ou seja, entram 40 novos clientes todos os meses, mas você perde 40 cliente todos os meses. Para voltar a crescer, você tem duas opções, diminuir o churn e aumentar a quantidade de novos usuários. O mais adequado é se focar nas duas opções, para aumentar sua chances de crescimento, pois só uma pode não ser suficiente. E há uma terceira opção, que comentarei mais abaixo.

Churn e o tempo de vida dos usuários

O churn varia de acordo com o tempo de vida do usuário, ou seja, varia de acordo com quanto tempo ele já é seu usuário. É comum ter casos onde o churn é alto no primeiro mês, pois o cliente não gostou do serviço e decidiu cancelar logo de cara. Ou no terceiro ou sexto mês, se sua cobrança for trimestral ou semestral. Algumas pessoas chamam esse churn de churn prematuro.

O churn prematuro, apesar de ser comum, é algo que pode ser diminuído. você faz isso:

  • alinhando a expectativa que o cliente tem alinhando a sua divulgação do produto com o que ele vai encontrar quando passar a usar seu produto.
     
  • garantindo que as primeiras experiências de uso de seu produto sejam muito boas e que seu cliente consiga atingir seus objetivos nesses primeiras experiências. Isso é conhecido como processo de onboarding do seu cliente.
     
  • mantendo seu produto útil para o seu cliente ao longo dos meses e dos anos, investindo em entender seu cliente e seus problemas e em atualizar seu produto para que ele continue resolvendo os problemas de seu cliente.

Veja o gráfico abaixo de idade do churn do ContaCal:

Idade do churn

Idade do churn

Separei o churn em 3 curvas, o churn total, o churn de boleto e o churn de cartão. Veja como o churn de cartão é uma curva suave, com números altos nos 3 primeiros meses, mas caindo para menos de 5% a partir do 5º mês. Isso me dá a impressão que o ContaCal é um pouco parecido com matrícula em academia. É algo que a gente sabe que precisa fazer, mas que nem sempre temos vontade e disposição de fazer.

A curva do boleto já tem mais picos pois durante algum tempo fiz o período mínimo de assinatura com boleto ser 3 meses e em outro período ser 6 meses, daí os picos de cancelamentos nos 3 e nos 6 meses de idade.

No ContaCal tenho apenas um plano e um preço. Você pode criar diferentes planos em seu produto e com isso terá que entender o churn de cada um desses planos separadamente.

Churn de receita

Além do churn de quantidade de clientes, existe também o churn de receita que é a quantidade de receita que você deixa de receber quando um cliente “churneia”, ou seja, quando deixa de ser seu cliente.

Ele também é um percentual e seu cálculo é feito da seguinte forma:

churn de receita mensal = receita mensal dos clientes que cancelaram no mês / total de receita do mês anterior

E aqui está a terceira opção para crescer apesar do churn, buscando formas de aumentar a quantidade de receita gerada por cliente. Como isso é possível? Há duas formas:

  • Cross-sell: é quando você oferece para seu cliente mais um produto que ele tem interesse em comprar.
     
  • Upsell: é quando seu cliente decide comprar um plano maior, ou quando decide comprar add-ons, funcionalidades extra de seu produto que você decidiu vender separadamente.

Por exemplo, suponha que você vende um produto para fazer lojas de ecommerce. Você criou seus planos baseados na quantidade de produtos vendidos na lojaQuerent:

  • 50 produtos: R$ 50,00 por mês
  • 500 produtos: R$ 200,00 por mês
  • 1000 produtos: R$ 300,00 por mês

Além disso, você criou add-ons e produtos para oferecer para seus clientes:

  • funcionalidade de multi-idioma e multi-moeda: R$ 200,00 or mês
  • 50 produtos adicionais: R$ 15,00 por mês
  • Email marketing: R$ 100,00 por mês para 5000 mensagens enviadas.

Você faz upsell quando um cliente está no plano de 50 produtos e decide ir para o plano de 500 produtos. Ou quando ele compra o aumento de limite de 50 produtos adicionais por R$ 15,00 por mês. Ou ainda, quando ele decide fazer a loja dele ser multi-idioma e multi-moeda, para que ele possa vender em outros países.

Você faz cross-sell quando vende o produto de email marketing para seus clientes de loja.

Com o churn de receita é possível ter o Santo Graal das empresas de produto de software por assinatura, o churn negativo. Churn negativo nada mais é do que quando a receita dos clientes que ficam na sua base aumenta, devido a upsell e cross-sell, mais do que a quantidade de receita dos clientes que “churnearam”.

Concluindo

Para ter um produto de software com um crescimento saudável e sustentável é preciso se focar em três fatores muito importantes:

aumentar a quantidade de novos clientes por mês;
diminuir a quantidade de clientes que “churneiam”, ou seja, que deixam de ser clientes, e;
aumentar a receita paga pelos clientes da sua base de clientes.

Como quadruplicar a produtividade de desenvolvimento de software sem aumentar o time e sem queda de qualidade

Escrevi há algum tempo atrás um artigo sobre como organizar times de desenvolvimento de produto e algumas mudanças que fizemos nos times de desenvolvimento de software da Locaweb.

Temos nos focado bastante, desde o ano passado, em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb podem produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico abaixo mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver no gráfico, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

produtividade_800

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, ou seja, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como dá para ver abaixo, mesmo com o aumento de produtividade, a quantidade rollbacks foi reduzido em 40%!

rollbacks_por_semana_800

Como conseguimos isso?

Não há bala de prata, foram várias ações que tomamos e temos certeza de que ainda há mais ações que poderão ser tomadas para aumentar ainda mais. Aqui vai uma lista do que fizemos.

  • Medir: antes de mais nada, para melhorar qualquer coisa é preciso medir, para poder saber se essa coisa está melhorando! Fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos então a comunicar toda a empresa sobre as entregas da semana. Cada gestor de produtos me manda na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico mais acima. A partir do momento que começamos a medir, ficou mais claro o nível em que estávamos e as ações que passamos a fazer começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, ou seja, algo na linha de “olha que interessante no seu gráfico, como vcs conseguiram aumentar esse indicador?”
     
  • Kanban vs sprint: outro ponto que mexemos foi a mudança de Kanban para sprint. Antes, todos os times rodavam com Kanban. Só que no Kanban, quando um item tem um impedimento, ele não pode ser mexido, e o time não pode fazer mais nada, o time fica travado. Contudo, às vezes acontecia de o time, por estar impedido mover um item de “doing” para “to be done” e pegar outro item para fazer o que não deveria ser feito. Uma vez em “doing” a tarefa só pode ir para “done”, não pode voltar pra “to be done” pois perde-se o controle da produtividade. Com sprint, o time organiza as próximas duas semanas de trabalho, colocando vários itens para serem trabalhados. Assim, se algum item tiver impedimento, o time pode começar a mexer em outro item e, com isso, consegue entregar mais no mesmo intervalo de tempo.
     
  • Discovery e delivery: o que o designer de UX e o gestor de produtos fazem pode ser chamado de discovery, ou seja, descobrir o que é preciso ser feito. Já o que engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem que ser feito. Essa separação de papéis parece óbvio, mas não deixar isso explícito nos times pode atrapalhar o processo de desenvolvimento de software. Por quê? Por alguns motivos. O primeiro é que se o discovery não é visto de forma explícita, não é claro o que é feito nessa fase e nem o que motiva certas decisões sobre o que deve ser implementado no software. É díficil fazer alguma coisa sem saber porque se estáfazendo aquilo. O segundo motivo é que quando essa separação não é explícita, itens podem ir e voltar de delivery para discovery e vice-versa sem critério. Não raro a gente via nos times algo sendo implementado pelos engenheiros e UX e gestor de produtos, ao verem sua especificação implementada, desejarem mudar algo, no meio do desenvolvimento. Com a separação clara entre discovery e delivery, definimos que, uma vez indo para delivery, não se mexe mais. Se quiser mexer de novo, deve passar por novo discovery para só então ir para delivery.
     
  • Tamanho das entregas: uma discussão que temos já há alguns meses é sobre o tamanho das entregas. Em alguns casos nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios de agilidade, reforçado pela técnica de entrega contínua. É só procurar no Google para encontrar inúmeros exemplos de empresas de primeira linha que fazem múltiplos deploys por dia, com algumas fazendo centenas de deploys por dia! :-O Para fazer isso, é preciso os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em hostórias menores. Isso é trabalho deo gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, ao invés de entregar uma história grande estaremos entregando a mesma coisa só que dividido em pequenas histórias. Parece ser a mesma coisa, mas ao invés de entregar algo grande depois de semanas ou até mesmo meses, a gente acaba entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo, ao invés de esperar semanas ou meses. Além disso, ao colocar em produtção todos os dias, já podemos aprender com o feedback e ajustar entregas futuras. E ainda há um benefício adicional, o fato de colocar em produção todo dia algum código faz desse processo de colocar código em produção algo mais simples, exatamente pelo fato de ser feito diariamente. Então, entregar uma história grande num período de semanas ou meses não é a mesma coisa que quebrar essa história em pequenos pedaços e entregar um pedacinho todos os dias. Há ganhos claros de produtividade em se entregar pequenos pedaços com frequência.

Além desses pontos acima, estamos começando a experimentar mais alguns pontos que certamente têm impacto na produtividade:

  • Primeira solução vs solução mais simples: é da natureza humana querer resolver problemas. Assim que um problema aparece, a primeira reação é pensar em uma solução e sair implementando essa solução para resolver o problema. Só que nem sempre a primeira solução é a melhor solução, tanto do ponto de vista do cliente, quanto do ponto de vista de quem implementa a solução. Por esse motivo temos preferido não começar a resolver imediatamente cada novo problema que aparece. Buscamos antes verificar se há mais soluções possíveis, analisamos todas as soluções e só aí escolhemos uma solução e partimos para a solução. Investir mais tempo pensando em outras possíveis soluções, sempre tendo claro qual a questão a ser resolvida e porque precisamos resolver essa questão. Saber o porquê ajuda a encontrar soluções simples. Uma solução simples (1 semana de implementação) que resolve 70% a 80% do problema é melhor do que uma complicada (1 mês de implementação) que resolve 100% e, na maioria das vezes, resolver 70% a 80% do problemaé mais do que suficiente. Às vezes a solução mais simples é não fazer nada!
     

    Exemplificando, na Locaweb o serviço de hospedagem e de email pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o email estão ligados, que é pago anualmente para o Registro.br, pode não ter sido renovado e, quando ele não é renovado, os serviços associados a esse domínio deixam de funcionar, mesmo que tudo esteja operando perfeito na Locaweb. Recentemente a Registro.br disponibilizou uma forma de a Locaweb cobrar o domínio do cliente em nome da Registro.br. A princípio a ideia parece boa, com a gente cobrando a gente garante que o cliente sabe que tem pagar esse domínio para manter os serviços no ar. Só que, analisando um pouco melhor, vimos que essa solução pode gerar mais problemas. O cliente vai receber duas cobranças pela mesma coisa, o registro de domínio, pois o Registro.br iria continuar cobrando o domínio. O que acontece se ele pagar as duas cobranças? E se ele pagar só a da Registro.br? E se ele pagar só a da Locaweb? Além disso, implementar um novo tipo de cobrança, onde iremos cobrar pelo serviços de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam que ser desenhados. Começamos então a pensar se não existiriam formas mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar por seu registro de domínio na Registro.br. Como para poder cobrar pela Registro.br é necessário acessar a informação de que o domínio está para expirar, pensamos na seguinte solução, vamos implementar uma régua de comunicação com esse cliente avisando-o da importância de pagar o Registro.br, para garantir que o serviço continue funcionando, solução essa bem mais simples que duplicar o processo de cobrança. Se a Registro.br fornecer tb link direto para a cobran;ca do domínio, podemos mandar esse link na comunicação e as chances de resolver o problema aumentam ainda mais. E uma régua de comunicação é bem mais simples de implementar do que uma cobrança duplicada.

  • Escolha da ferramenta mais apropriada: aqui o tema são ferramentas para implementação da solução, ou seja, linguagem de programação, frameworks e bancos de dados. Cada ferramenta tem suas características e essas características as fazem mais apropriadas para resolver certos tipos problemas. Escolher a ferramenta certa para cada problema vai impactar a produtividade. Esse é um tema que estamos começando a estudar agora. Hoje usamos Rails para quase tudo, mas tem alguns problemas para os quais a implementação de solução usando outro framework ou outra linguagem pode ser mais simples e rápido. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que tem que ser feitos. Será que o martelo é a melhor ferramenta para apertar um parafuso? Será que Rails é a melhor ferramenta para gerenciar filas?

Temos confiança de que com os dois pontos acima, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! \o/

E com certeza há ainda pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.

Conclusão

Como disse acima que não há uma bala de prata, mas tem uma ação específica que fizemos que tem impacto crucial nesses resultados: transformamos produtividade em tema importante em nossas conversas. Todos passaram a conversar sobre produtividade, o que pode impactar e como endereçar esses pontos. Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento, coloque essa tema como tema central de suas conversas e experimente bastante. Vc verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

OKRs, o futuro dos roadmaps

Já escrevi vários artigos sobre roadmap:

  • O que é um roadmap? Nesse artigo explico que o roadmap é uma ferramenta útil para gestores de produto pois com ele é possível planejar e comunicar a visão de futuro que vc tem para o seu produto.
  • Como fazer um roadmap? Nesse artigo conto que para fazer um roadmap é preciso saber bem os objetivos estratégicos da empresa, os problemas e necessidades dos clientes e o que dá para fazer. De posse dessas informações é possível criar um bom roadmap.
  • Como priorizar um roadmap? Parte 1 e parte 2. Esses dois artigos contém várias técnicas que ajudam o gestor de produtos a definir as prioridades de seu roadmap.
  • Roadmap = motivação + métrica. Nesse artigo da série sobre roadmaps, falo sobre o quão importante é ter em seu roadmap não só o que se quer fazer como também a razão pela qual se quer fazer e quais as métricas que mostram que o que se fez está de fato atendendo a razão pela qual se quer fazer esse item.

Desde 2012 temos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre fazemos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram entregues, quais não foram e quais as razões de sucesso ou insucesso.

Esse último artigo sobre motivação + métrica foi escrito em meados de 2014. Ele foi fruto de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre mas não estar sempre claro a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época começamos experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 sub-itens, o que fazer, por que aquilo tinha que ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discusões acabavam girando mais em torno do “o que fazer” do que sobre a motivação e a métrica.

No primeiro semestre de 2015 ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa onde esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são Linkedin, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma ténica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste num processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei um explicação sucinta. Os OKRs são compostos de duas partes, um objetivo e de 2 a 5 resultados chave (key results) que indicam que o objetivo foi atingido. Por exemplo:

Objetivo: Ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos
Key Result 1: Manter 80% das notas de pesquisa de satisfação acima de 8 numa escala de 0 a 10.
Key Result 2: Pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica, ou seja, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results pois quando há apenas um key result pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento) que hoje está em 8 minutos deve cair para 2 minutos. Uma forma de se atingir esse resultado chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido não caia.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão que ele era muito parecido com o que sempre quisemos fazer, nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que nos OKRs o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados chave, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados chave que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, da Lean Performance, consultoria especializada em implementação de OKR. Chamamos ele em junho de 2015 e começamos a implementação no 3º trimestre de 2015, com uma série de treinamentos internos sobre OKR, definicão de objetivos, métricas e metas. Em agosto fizemos uma sessão de planejamento “café-com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro fizemos nossa primeira sessão de planejamento de um trimestre completo, onde definimos os OKRs do 4º trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, ou seja, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1º trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, ou seja, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1º trimestre de 2016 e de planejamento dos OKRs do 2º trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente que durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

Lições aprendidas

Temos aprendido algumas valiosas lições nesse quase um ano em que estamos lidando com OKRs. Essas lições aprendidas são relembradas frequentemente para que possamos constantemente melhorar nossas definiçãoes de OKRs:

  • Entregas e medições mais frequentes ajudam a atingir objetivos. Se houver entregas e medições apenas mensais, o time só terá duas chances no trimestre para testar sua ideia de como mexer a métrica. Se houver entregas e medições semanais, são 12 oportunidades de avaliar e mudar o rumo se necessário.
     
  • Objetivos técnicos podem e devem entrar se necessário. Alguns times de desenvolvimento de produto podem ter optado por colocar em seus roadmaps apenas tarefas que entregam valor para o cliente e preferem não colocar histórias técnicas como “atualizar versão da linguagem de programação” ou “rever arquitetura para torná-la mais escalável”. Esse era o caso da Locaweb. Ao fazermos a transição de roadmap para OKR, surgiu a dúvida se faria sentido definir objetivos técnicos, já que tarefas técnicas não entravam nos roadmaps. Após algumas conversas, todos concordaram que sim, podemos e devemos colocar objetivos mais técnicos em nossos OKRs. Por exemplo, ter infra mais robusta e escalável é um objetivo técnico que pode ter como métricas MTBF, MTTR, SLA, filas, etc.
     
  • Objetivos e KRs podem ser modificados ou mesmo cancelados, desde que isso seja combinado. Algumas vezes, ao começar a trabalhar em alguma métrica nova, que nunca se trabalhou antes, pode-se descobrir que mexer aquela métrica é mais difícil ou mais fácil do que inicialmente imaginado. É possível, nesse caso, mudar a meta daquela resultado chave, desde que todas as pessoas interessadas estejam de acordo. Também pode acontecer de um determinado resultado chave ou mesmo de um determinado objetivo ser menos importante do que algo que surge após o planejamento dos OKRs do trimestre. Também não é problema remover o OKR para colocar um novo, desde que todas as pessoas interessadas estejam de acordo.
     
  • Cuidado com interdependências. Tarefas que podem influenciar os KRs e que dependem de outros times que tenham outras prioridades ou mesmo de fornecedor externo têm grande risco de atrasar. O ideal é que sejam feitas no início do trimestre, ou mesmo no trimestre anterior. Em caso de interdependência onde um time precisa fazer A para que outro time possa começar a fazer B, pode-se colocar A nos OKRs do primeiro time em um trimestre e o outro time inclui B como OKR no trimestre seguinte.
     
  • Cuidado com métricas muito genéricas. Esse é um dos aprendizados mais recentes. Métricas como NPS e TMA (tempo médio de atendimento) são muito genéricas, ou seja, podem ser impactadas por uma quantidade enorme de fatores. Por exemplo, o TMA pode ser influenciado por razões tão distintas quanto o sistema de atendimento é lento, o produto está com uma usabilidade que deixa o cliente confuso, turn-over de funcionários de atendimento muito alto e assim por diante. Nesses casos é recomendável transformar a métrica em objetivo, por exemplo, “queremos baixar o TMA em 3 minutos” e definir KRs específicos como, por exemplo, “diminuir o tempo de carregamento do sistema de 30 segundos para 3 segundos”.
     
  • Cuidado com o excesso de otimismo! Quando se começa a trabalhar com OKRs e se começa a definir metas para as métricas, pode acontecer com muita frequência de as pessoas do time subestimarem o esforço necessário para mover o ponteiro. Existe uma tendência natural a setar metas muito otimistas e, na retrospectiva, perceber que mover o ponteiro é mais difícil do que o imaginado inicialmente. Nesses casos, na próxima sessão de planejamento de OKRs, pode acontecer o contrário, ou seja, após ter exagerado no otimismo, o time pode ficar receoso e acaba colocando metas muito tímidas.
     

Concluindo

Como eu disse acima, em nossas reuniões de retrospectiva e planejamento de OKRs na Locaweb, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Durante a retrospectiva cada time comenta um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir e mudar o “o que fazer” como quiserem, desde que atinjam seus objetivos.

Por esse motivo, está cada vez mais claro para mim que os OKRs são o futuro dos roadmaps. É uma ferramenta que coloca os objetivos e as métricas no centro da discussão, deixando a decisão do que fazer mais fluída e flexível, dando aos times mais autonomia na decisão sobre o que fazer.

Principais características de um gestor de produtos

O que uma pessoa precisa ter para ser um bom gestor de produtos? Existem algumas características bem importantes e falarei sobre elas aqui, mas a mais importante de todas é, sem dúvida alguma, a empatia.

empatia

Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará o gestor de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto.

Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. O gestor de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas. Será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? Qual o impacto para a equipe de vendas, suporte, operações, financeiro e marketing? Até mesmo em relação ao time do produto, engenheiros e analistas de UX, como o produto interfere no trabalho desses profissionais?

A segunda característica mais importante é a comunicação.

comunicacao

Para poder ter empatia, é necessário que o gestor de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, estes que podem ser internos (dentro da empresa) ou externos (em conferências, grupos de usuários etc.).

Deve também ser bom de comunicação escrita (e-mail, blog, documentação, chat, redes sociais etc.), e ser capaz de discernir sobre qual a forma de comunicação mais apropriada para cada momento, público e meio de comunicação; e de se comunicar de forma a ser entendido pelos diferentes públicos: técnico e não técnico.

Como se isso tudo não bastasse, ele também precisa ser capaz de se comunicar passando segurança e confiança no que está comunicando; afinal, o gestor de produto é o porta-voz do produto.

Porém, não é só de falar que vive o gestor de produtos. Comunicação é uma via de mão dupla, ou seja, o gestor de produto tem de ser muito bom em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

A terceira característica mais importante é a gestão do tempo.

O dia a dia de um gestor de produtos pode se encher rapidamente de tarefas, e ele precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto. É muito fácil um gestor de produtos ver sua agenda repleta de reuniões, com pessoas de diferentes áreas para tratar dos mais diversos assuntos: backlog do produto, atendimento, comunicação de marketing, problemas operacionais, revisão de previsão de crescimento, questões jurídicas, cobrança, régua de comunicação etc.

Isso acontece pois o gestor de produto deve cuidar de seu produto por inteiro. Para o usuário, não existe engenharia, operações, financeiro, jurídico, atendimento e cobrança. Ele enxerga tudo isso como parte do produto que você cuida; e você tem sim de se importar com tudo isso. Contudo, importar-se não significa que você deva ir a todas essas reuniões. Se você fizer isso, poderá tirar o foco do que é mais importante para o seu produto.

Você, como gestor de produtos, precisa focar seu tempo em:

  • Com quantos clientes e usuários você falou essa semana?
  • Você tem uma estratégia e uma visão de longo prazo para o seu produto?
  • Como está e quais as últimas mudanças no cenário competitivo de seu produto?
  • Que insights você teve sobre o seu produto essa semana?
  • Você sabe qual a motivação e a métrica de cada item de seu roadmap?
  • Que novas tecnologias você vê aparecendo que podem influenciar, ou mesmo competir, com o seu produto?
  • Que novas habilidades você está procurando aprender?

As reuniões que mencionei anteriormente são importantes, e aconselho você participar delas quando puder. Apesar disso, você terá muito pouco a contribuir para essas reuniões se você não se focar nos 7 itens que acabei de listar. Procure bloquear um tempo em sua agenda para focar nisso, e você verá como sua participação nas reuniões será muito mais útil e produtiva.

Além dessas três características (empatia, comunicação e gestão do tempo), existem mais quatro que vão ajudar o gestor de produtos a fazer seu trabalho melhor:

  • Novas tecnologias: o gestor de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?
     
  • Business skills: o gestor de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, receita menos custos estão sob controle? Se o objetivo for só receita, como está o crescimento de receita? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, o gestor de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta o departamento jurídico? E como o departamento jurídico impacta o produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.
     
  • Curiosidade aguçada: o gestor de produto precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).
     
  • Tema do produto: por fim, mas não menos importante, o gestor de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, o gestor de produto deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. O gestor de produto do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto o gestor de produto da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Dá para perceber que essa lista é um conjunto de características que nem todas as pessoas têm. É comum casos de pessoas de outras áreas que resolvem experimentar a carreira de gestor de produtos, mas que, após algum tempo, percebem que não têm todas as características necessárias.

Se você é um gestor de produtos, ou deseja ser um, faça uma autoanálise para ver como você está em cada uma das características e, se alguma estiver aquém do desejado, foque em desenvolvê-la. Se você é responsável por identificar e contratar gestores de produto, use essa lista como guia para saber se o candidato tem as características necessárias para ter sucesso como gestor de produto.

Gerindo gestores de produto

Da mesma forma que nem todo bom desenvolvedor pode virar um bom gestor de desenvolvedores, o mesmo acontece com gestores de produto. Assim como as habilidades que uma pessoa tem que ter para gerir desenvolvedores de software é diferente das habilidades que um desenvolvedor precisa ter para ser um bom desenvolvedor de software, as habilidades que um gestor de gestores de produto precisa ter para gerir gestores de produtos é diferente das habilidades que um gestor de produtos produto precisa ter para gerir seu produto.

gestor_de_gestores

Então o que faz um gestor de gestores de produtos?

Um gestor de gestores de produtos tem basicamente duas preocupações, uma tática e outra estratégica:

  • Ajudar os gestores de produto a performarem melhor. Essa é a preocupação tática do gestor de gestores de produto. Ele deve ser capaz de ajudar o gestor de produto a desenvolver as principais características de um bom gestor de produto, empatia, comunicação, gestão do tempo, conhecimento de novas tecnologias, business skills, curiosidade aguçada e conhecimento sobre o tema do produto. Todas essas características são fundamentais para o sucesso do gestor de produtos e nem sempre o gestor de produtos consegue perceber o que precisa ser melhorado ou, se percebe, não sabe bem como melhorar. Aí entra o gestor de gestores de produto, que deve ajudar o gestor de produtos a ver quais características tem espaço para melhoria e como melhorar cada uma delas. Muitas vezes há mais de uma característica que precisa ser melhorada e aqui o gestor de gestores de produto pode mais uma vez ajudar a perceber prioridades, ou seja, qual característica deve ser trabalhada primeiro.
     
  • Ajudar os gestores de produto a criar a visão e a estratégia dos produtos. Essa é a preocupação estratégica do gestor de gestores de produto. Ele deve ser capaz de ajudar os gestores de produto a criar a visão e a estratégia dos produtos da empresa. Aqui é importante fazer uma distinção entre as duas opções de estratégia de portfólio de produtos que uma empresa pode escolher, foco ou diversificação. Em uma empresa que optou pelo foco, cabe ao gestor de gestores de produto coordenar o processo de criação de visão e estratégia do produto da empresa. Ele deve, em conjunto com seus gestores de produto, designers de UX, pessoal de engenharia e gestores de mkt de produto, criar a visão do produto da empresa e desenhar a estratégia para chegar nessa visão. Já em uma empresa que optou pela estratégia de diversificação de portfólio de produto, a responsabilidade do gestor de gestores de produto é ajudar cada gestor de produto a coordenar o processo de criação da visão e do desenho da estratégia de seu produto específico. Além disso em uma empresa que optou pela diversificação, cabe ao gestor de gestores de produtos fazer a gestão do portfólio de produtos, ou seja, garantir que o portfólio de produtos está alinhado com os objetivos estratégicos da empresa e garantir que cada produto tenha o devido investimento de desenvolvimento e de mkt de produtos.

Para ser um bom gestor de gestores de produto é importante que a pessoa já tenha sido gestora de produtos, ou seja, que ela já tenha colocado a “mão na massa” e tenha cuidado diretamente das questões táticas e estratégicas de um produto. Isso irá ajudá-la quando estiver gerindo o trabalho de outros gestores de produto. Contudo, é preciso tomar muito cuidado para não fazer o trabalho no lugar do gestor de produtos ao invés de ajudá-lo a se desenvolver e a fazer seu trabalho. Note que em ambas as preocupações que descrevi acima eu usei “ajudar os gestores de produto”. Por já ter sido um gestor de produtos, é tentador para o gestor de gestores de produtos, no momento em que algum gestor de produto sob sua gestão estiver com dificuldades, fazer o seu trabalho. Mas a função do gestor de gestores de produto não é fazer o trabalho de gestor de produto, mas sim ensinar e ajudar os gestores de produto a fazerem seu trabalho.

Caso vc não tenha experiência como gestor de produtos, mas se veja na situação de coordenar o trabalho de gestores de produtos, como pode ser o caso de um CTO ou um gestor de time de engenharia, valem as recomendações acima, ou seja, ajudar os gestores de produtos a performarem melhor e a criar a visã e a estratégia de seus produtos.

O que é e como criar a visão e a estratégia do produto?

Esse tema tem aparecido com alguma frequência não só na Locaweb mas também em outras empresas de software com quem eu tenho conversado. Por isso acredito que seja um bom momento para escrever um artigo sobre o tema.

O que é e pra que serve visão do produto?

Visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto. O que o que dá o contexto para o time de desenvolvimento do produto tomar decisões sobre o que priorizar em relação ao produto. Vale lembrar que quando falo “produto” estou me referindo a qualquer software que tenha usuários.

Lembrando da definição de gestão de produtos, um produto deve ao mesmo tempo atender aos objetivos estratégicos que o dono do produto tem para esse produto enquanto ele resolve problemas e necessidades de seus usuários. Pronto, esses dois elementos são o que você precisa para fazer a sua visão do produto.

Criando a visão do produto

A visão do produto será criada juntando esses dois elementos, o entendimento dos objetivos do dono do produto e os problemas e necessidades do usuário do produto.

Sendo assim, o primeiro passo para criar a sua visão do produto é ter bem claro quais os objetivos que o dono do produto tem para o produto. Por exemplo, um banco pode querer, com um sistema de Internet Banking, reduzir a necessidade de atendimento em agências. Um laboratório de análises clínicas e de imagem, com um sistema de consulta de resultados, pode querer diminuir os custos operacionais de manuseio e envio de resultados.

Em seguida é preciso entender dos usuários do produto quais são os problemas e necessidades que esse produto vai resolver, qual o contexto onde esses problemas e necessidades acontecem e qual a motivação que esses usuários têm para querer ter esse problema ou necessidade resolvido.

Uma ferramenta bacana para entender o usuário é o mapa de empatia.

empathy-map

Esse mapa ajuda a dar foco nas diferentes percepções que o usuário pode ter:

  • Vê? O que seu usuário vê? Como é o ambiente onde ele usa o produto? O que o mercado oferece?
  • Ouve? O que o seu usuário ouve? O que seus amigos dizem para ele sobre o seu produto? O que o chefe dele diz? O que os influenciadores dizem?
  • Diz e faz? O que o seu usuário diz e faz em relação ao seu produto? O que ele comenta com amigos e em redes sociais? O que ele consegue fazer graças ao seu produto?
  • Pensa e sente? O que seu usuário pensa e sente quando usa o seus produto?
  • Dores? Quais são as principais dores, medos, frustrações e obstáculos que o seu usuário encontra?
  • Ganhos? Quais os principais ganhos, desejos e necessidades resolvidas que seu usuário espera ter ao usar seu produto?

Outra ferramenta muito útil é a persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

  • Conhecer e entender clientes e usuários de produtos e serviços;
  • Trazer o usuário para o foco do projeto;
  • Tornar as decisões de design mais humanas e menos abstratas.

A figura a seguir mostra como construir uma persona:

persona-1

O primeiro passo é definir um nome e algumas características dessa persona. Isso ajuda nas conversas sobre o produto. No nome, é bacana já dar uma dica da característica principal. Por exemplo, Maria, a descolada ou Michelle, a ocupada.

Se você estiver fazendo um produto para Michelle, a ocupada e quiser inserir uma nova funcionalidade, vale a pergunta: “Será que Michelle, a ocupada vai conseguir usar essa funcionalidade? Ela a achará útil o suficiente para achar tempo para aprender a usá-la?”. Além do nome e características básicas, é importante também descrever seus comportamentos e seus problemas. Os exemplos a seguir deixarão mais claro o conceito de persona.

persona-2
Maria, a descolada

persona-3
Michelle, a ocupada

Maria, a descolada é uma das personas que usamos na Locaweb. Dados os diferentes produtos que temos em nosso portfólio, acabamos construindo oito personas. Contudo, para cada produto de nosso portfólio, temos uns 3 ou, no máximo, 4 personas, sendo que uma destas é a persona primária do produto, ou seja, para quem todas as suas decisões de seu produto de software são tomadas.

Como parte do entendimento do problema ou necessidade que seu usuário espera ver resolvido pelo seu produto é muito importante você mapear quais as alternativas que existem hoje para ele ter esse problema ou necessidade resolvido. No caso de produtos comerciais, são os concorrentes. No caso de produtos que são sistemas sem objetivos diretos de receita, como o internet banking ou o sistema de consulta de resultado de exames, são as alternativas existentes como ir ao banco ou ao laboratório, acesso ao banco por telefone, envio de resultados por correio, etc. Esse mapeamento de alternativas é muito importante para você entender como seu usuário se vira sem o seu produto e no que essas alternativas são melhores e no que elas são piores do que o produto que você cuida.

Tanto o mapa de empatia quanto a persona quanto o mapeamento de alternativas podem e devem ser criados em conjunto com pessoas de UX, de engenharia e de marketing de produtos.

Pronto, você já tem todos os elementos para criar a visão do seu produto:

  • Os objetivos do dono do produto.
  • Quem são os usuários e quais os problemas e necessidades esses usuários esperam resolver com seu produto. Ferramentas úteis para isso são o mapa de empatia, a persona e o mapa de alternativas.

Vale lembrar que para obter esses elementos o gestor de produtos terá que usar muita empatia para conversar com os donos do produto e entender seus objetivos e para conversar e entender o seu cliente.

Com esses elementos em mãos você está pronto para criar a sua visão que nada mais é do que deixar claro esses elementos. Simples, né? Seria algo mais ou menos assim:

O (nome do dono do software) decidiu ter esse software para (objetivos do dono do software em ter esse software). Esse software é usado por (descrição das pessoas que usarão o software) que, ao usar esse software, espera resolver (problema ou necessidade que o usuário espera resolver) de uma forma melhor do que (alternativas existentes). (Incluir mais informações sobre o problema ou necessidade, incluindo contexto e motivação para ver resolvido).

Por favor, não dê copiar + colar no texto acima! Crie sua própria visão do produto, que não precisa ser um texto. Pode ser uma apresentação ou um vídeo. Lembrando que a visão do produto é a razão de existir do produto. É o que deve nortear todas as decisões em relação a esse produto.

Estratégia do produto

Uma vez que você tem em mãos a visão do produto, provavelmente vem um pensamento a mente, algo na linha de “hum, acho que meu produto ainda está distante da visão” e a pergunta subsequente é “como fazer com que meu produto chegue mais perto da visão?”. É aí que entra a estratégia do produto, ou seja, que passos serão dados para aproximar o produto da visão.

Uma boa ferramenta para ajudar a construir a estratégia do produto é a análise SWOT, sigla em inglês para Strengths, Weaknesses, Opportunities and Threats, ou pontos fortos, pontos fracos, oportunidades e ameaças.

swot

Os pontos fortes e os pontos fracos são itens internos, ou seja, do seu time de desenvolvimento de produto, ou da sua empresa, sobre as quais você, seu time ou sua empresa têm algum controle, que ajudam ou atrapalham o seu produto atingir a sua visão. As oportunidades e ameaças são os elementos externos a organização, ou seja, sobre os quais a organização não tem controle, e que podem influenciar positiva ou negativamente o atingimento da visão do produto.

Preencher o SWOT deve ser também um trabalho de equipe, ou seja, o gestor de produto deve ter uma ou mais sessões junto com pessoas de UX, engenharia e marketing para construir o SWOT do seu produto. É provável que sua organização também tenha feito uma análise SWOT para a organização como um todo. É um ótimo input para o SWOT do seu produto.

Tendo em mãos o SWOT preenchido, é hora de desenhar a estratégia do seu produto. A estratégia do produto nada mais é do que um roadmap de curto, médio e longo prazo. Longo prazo? Você certamente está pensando que, como vcs adotaram metodologias ágeis na time de desenvolvimento de produto, não faz mais sentido ter um roadmap de longo prazo, nem de médio prazo. Na verdade, faz sim, mas não no sentido clássico de roadmap como lista de funcionalidades, mas sim usando o roadmap como lista de prioridades, lista de pontos de foco que devem ser vistos para fazer com que o produto se aproxime da visão.

Com o SWOT preenchido você deve, junto com o time (UX, engenharia, mkt de produto) olhar para cada um dos itens em cada um dos quadrantes e avaliar qual o impacto dele na visão de produto que vocês criaram. Existem pontos fortes devem ser reforçados? Se sim, quais devem ser reforçados primeiro? Existem pontos fracos a serem combatidos? Se sim, quais devem ser combatidos primeiro? Existem oportunidades a serem aproveitadas? Se sim, quais devem ser aproveitadas primeiro? Existem ameaças a serem combatidas? Se sim, quais devem ser combatidas primeiro? Essa análise irá te ajudar a definir as motivações, os objetivos, ou seja, os macro-temas do seu roadmap, lembrando que roadmap = motivação + métrica, o que agora está sendo popularizado com a sigla OKR (Objectives and Key Results), tema de um futuro artigo. Essa análise te ajudará a definir no que se focar agora e o que deixar para depois, sempre tendo por objetivo final chegar mais próximo da sua visão de produto. E isso é a estratégia do produto, o caminho que você e o time de desenvolvimento de produto irá percorrer para chegar na visão do produto.

Seu produto evolui, sua visão e estratégia também!

Um ponto importante é que seu produto evolui à medida que o time trabalha nele. Muito se aprende sobre os usuários do produto, seus problemas e necessidades. Novas alternativas podem aparecer para ajudar seu usuário a resolver seus problemas e necessidades. O dono do software também pode revisitar seus objetivos estratégicos e, consequentemente, revisitar os objetivos definidos para o software. Além disso, pontos fortes e pontos fracos podem mudar com o tempo, e oportunidades e ameaças podem aparecer ou sumir. Por isso é importante entender que nem a visão nem a estratégia do produto estão escritas em pedra. Elas podem e devem ser revisitadas periodicamente. Minha sugestão é que elas sejam revisitadas anualmente, ou quando algum evento relevante acontecer como, por exemplo, quando houver uma mudança nos objetivos estratégicos da empresa ou quando aparecer uma alternativa que resolve o problema ou necessidade do usuário de uma forma diferente da do seu produto.

The book is on the table

English version below…

A bem da verdade, não está em cima da mesa, mas está no LeanPub. O Paulo Caroli está trabalhando na tradução para o inglês do meu livro sobre gestão de produtos.

title_page

Nosso objetivo com essa tradução é aumentar a literatura disponível sobre o tema Gestão de Produtos. Há poucos livros sobre o tema, mesmo em inglês, e acreditamos que essa tradução pode ser útil para pessoas da indústria de software não só no Brasil, como em todo o mundo.

Ainda estamos nos primeiros capítulos, mas se vc quiser acompanhar a tradução e a publicação, basta visitar a página do livro lá no LeanPub.

Se vc tem amigos de outros países que não falam Português, mas que se interessam pelo tema Gestão de Produtos de Software, fique à vontade para indicar o livro Product Management: Delight your customers with your software. Ainda em Beta, mas já com conteúdo interessante. Feedbacks são muito bem vindos!

English version

“The book is on the table” is a phrase that every Brazilian who learns English is faced with when learning about use of preposition in English language. Hence the title of this article. :-)

However, the book is not on the table. The is at LeanPub. Paulo Caroli is translating my book on Software Product Management that I wrote in Portuguese and launched in Brazil last year.

Our main objective with this translation is to increase the number of books on Software Product Management available for readers all over the world. The are not many books on the topic, even in English, and we believe the content of this book is useful for people in the software industry not only in Brazil but anywhere in the world.

We are working on the first chapters but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub.

And if you have friends who don’t read in Portuguese but are interested in Software Product Management topic, please feel free to point them to Product Management: Delight your customers with your software. Still in beta but already with valuable content. Feedback is always welcome!

Sobre QA (e Front-end e BA)

No artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas, prometi que o próximo artigo seria sobre o papel de gestor de gestores de produto. Contudo, recebi alguns comentários sobre a falta do time e do papel de QA (Quality Assurance) na organização dos times, por isso resolvi mudar um pouco a sequência de temas e vou falar nesse artigo sobre QA (e Font-end e BA).

Disclaimer

Antes de mais nada, gostaria de citar uma frase muito bacana que ouvi certa vez e que deve ser lembrada sempre que conversas sobre pontos de vista distintos acontecem:

O fato de discordamos não significa necessariamente que um dos dois está errado.

Qual é o objetivo?

Na minha visão, processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

QA (e Front-end e BA) na Locaweb

Até meados do segundo semestre de 2015 tínhamos na Locaweb os times de engenharia de produtos, um time para cada um ou dois produtos, e tínhamos dois times funcionais separados desses times de engenharia de produtos, os times de Front-end e de QA. O artigo anterior foi extraído do meu livro e no livro o texto ainda contempla Front-end e QA separados da engenharia. No final do ano decidimos por não ter mais time de Front-end nem de QA.

Sobre o time de Front-end:

  • O time tinha 5 desenvolvedores, enquanto a Locaweb tinha 12 times de desenvolvimento de produtos e sistemas. Como desenvolvedores de back-end não mexiam com front-end, o time de front-end acabava virando gargalo.
  • O time havia desenvolvido, junto com UX, o Locaweb Style um framework front-end de comportamento e estilo que usamos em nossos produtos e disponibilizamos para que qualquer pessoa tb possa utilizar em seus projetos. O objetivo do Locaweb Style é facilitar o programação front-end das interfaces de nossos produtos. Com o Locaweb Style ficou mais fácil desenvolvedores de back-end fazerem front-end e diminuir o gargalo.
  • Com isso decidimos não ter mais o time de Front-end e os desenvolvedores de front-end foram para os times de produtos onde front-end é mais relevante. Os desenvolvedores de front-end passaram a tb mexer em back-end, assim como os desenvolvedores back-end passaram a mexer em fron-end. Sempre respeitando o Locaweb Style.
  • Diego Eis, que era coordenador desse time de Front-end, contou em um artigo como foi a mudança. Ele passou de coordenador de time funcional a coordenador de time de engenharia de um produto. Isso deu a ele a aos membros do time de front-end, que agora são desenvolvedores alocados em um time de produto, um senso maior de propósito, pois entregam um produto completo e não só a programação da interface.

Sobre o time de QA:

  • Quando existe a função de QA separada da função de desenvolvimento de software, é comum ouvir frases do tipo “a funcionalidade está pronta, agora está em QA”, o que denota uma cultura waterfall, o que pode aumentar consideravelmente o tempo de desenvolvimento e impactar negativamente a qualidade do software.
  • Quando existe a função de QA separada da função de desenvolvimento de software, também é comum ouvir frases do tipo “por que o QA não pegou esse bug?”, o que denota uma cultura de busca de culpados, que pode ser bem prejudicial para o clima do time e, consequentemente, impactar negativamente a qualidade do software.
  • Qualidade não deve ser a preocupação de uma pessoa ou de um time, deve ser uma preocupação de todas as pessoas que estão trabalhando no software.
  • Qualidade é um requisito não-funcional, ou seja, um requisito que especifica um critério para julgar a operação de um software, o que é diferente do requisito funcional, que especifica um comportamento do software. Performance, escalabilidade, “operabilidade”, “monitorabilidade” são alguns exemplos de requisitos não-funcionais de software que são tão importantes quanto a qualidade. Mesmo assim, não existem o papéis de perfomance assurance, scalability assurance, operability assurance e monitorability assurance. Por que qualidade é o único requisito não-funcional que tem uma função específica para assegurá-lo?
  • QA tem por foco garantir a qualidade do processo de desenvolvimento de software. Se é necessário um papel separado para garantir essa qualidade, por que não existe a necessidade de um papel separado para garantir a qualidade do processo de gestão de produtos, do processo de design de UX, do processo de marketing de produtos, do processo de vendas, do processo financeiro?
  • Na Locaweb tínhamos em torno de 12 QAs, alguns com perfil mais de desenvolvedor e outros com perfil mais de SysAdmin. Ao propormos a extinção do papel de QA, alguns dos QAs viraram devs de um produto enquanto outros assumiram o papel de sysadmins.
  • Existia entre os devs a preocupação de que, se o próprio dev agora vai ter que testar, as entregas vão demorar mais para ficar prontas. Essa preocupação existia pois os devs consideravam que seu trabalho terminava quando passavam a história para o QA testar. Contudo, essa visão de pronto do dev é incorreta, pois ele só passou a história para a próxima fase, o teste. Do ponto de vista do usuário do software, a história só está pronta quando o usuário pode utilizar a nova funcionalidade. E o que acontece quando a história não passa por QA e tem que voltar pro desenvolvimento?

Sobre BA:

Outro questionamento que recebi quando publiquei o artigo anterior foi sobre a ausência de BA (Business Analyst). Não coloquei explicitamente o BA pois BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários. Em algumas organizações pode acontecer de o BA estar focado exclusivamente no business, ou seja, em entender apenas quais são os objetivos de negócio, deixando de lado os problemas e as necessidades dos usuários. Nesse caso, é importante o BA passar a levar tb em consideração os problemas e as necessidades dos usuários do software, balanceado-os com os objetivos de negócio.

Concluindo

Com esse artigo espero ter esclarecido as perguntas sobre a ausência de QA e BA que ficaram do artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas. Vale lembrar que processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

No próximo artigo meu plano é falar um pouco sobre o papel de gestor de gestores de produto. Stay tuned!