A imagem acima conta a história de um grupo de homens cegos e um elefante. É uma história famosa sobre um grupo que discute sobre o que eles encontraram, o problema é que cada um é exposto a uma pequena parte do elefante.

Esse elefante é como se fosse um produto. Se cada pessoa olhar apenas para o seu umbigo o produto vai estar fadado ao fracasso. Afinal, não adianta nada ter várias ideias conflituosas. Essa história é como se fosse o dia a dia de um Gerente de Produto e seus stakeholders.

Se essas definições não forem feitas com muita cautela por alguém que só pensa nisso diariamente, as chances de você estragar o seu produto aumentam muito. No final das contas, o Gerente de Produto, ou como no caso do VivaReal, um grupo de Gerentes de Produto, precisa se organizar pra agradar ao máximo todas as partes interessadas (outros funcionários, usuários, fundadores, investidores e etc).

Então como construir uma boa estratégia?Pra começar é necessário definir duas coisas: i) Definir uma visão para o seu produto ii) Gerenciar ele baseado nessa visão. É a partir dessa visão que você cria uma série de regras que devem ser seguidas pra manter a casa em ordem.

Ué, como assim? Como definir uma visão? Veja alguns exemplos

  • Amazon: “Ser a empresa mais centrada do mundo; construir um lugar onde as pessoas podem encontrar e descobrir qualquer coisa que queiram comprar online.”
  • Google: “Organizar a informação do mundo e torná-la universalmente acessível e útil. “
  • Twitter: “Ser o pulso do planeta.”
  • VivaReal: “Ajudar as pessoas a encontrar a casa dos seus sonhos”

Isso é muito importante para que o seu produto se mantenha relevante. Observe que o Twitter não fala nada sobre apps e tweets, o Google não menciona busca, o VivaReal não fala sobre anúncio de imóveis e a Amazon não fala sobre livros. A visão tem que ser robusta e duradoura. Tecnologias, redes sociais e coisas da moda sempre mudam. Então pense sobre isso quando for definir uma visão pra sua empresa e/ou produto.

Escolhendo o caminho

Você lembra do filme Alice No País das Maravilhas? Tem uma cena muito interessante no qual ela pergunta pro gato qual caminho deve seguir. O gato pergunta pra onde ela quer ir e ela diz que não sabe. A partir desse momento o gato retruca dizendo que então não importa o caminho que ela seguir, como ela não sabe pra onde vai, qualquer caminho serve.

Se você não sabe pra onde vai, então qualquer caminho serve — Alice No País das Maravilhas. O problema é quando você chega nesse ponto com o seu produto. Nessa hora entra o importante papel do Gerente de Produto, ele precisa ser o responsável por criar uma visão específica pro produto.

Como a visão é importante pro dia a dia da empresa

A visão é algo a longo prazo, que, obviamente, não está escrito em pedra e pode mudar. Mas é a partir dela que você cria metas, e então você pode definir estratégias pra atingir essas metas e em seguida você faz seus planos e então cria as atividades do dia a dia.

Aqui um exemplo prático de como estamos aplicando isso no VivaReal. Temos uma visão bem clara e abrangente. Já estamos num tamanho relativamente grande e por isso, após as metas, temos que definir uma estratégia diferente pra cada produto — essa parte pode variar muito do tamanho da empresa e da velocidade que as coisas precisam ser entregue.

Por exemplo, alguns times trabalham mais focados em alimentar a nossa base de dados de anúncios. Esse conjunto de times são chamados de “Plataforma de Anunciantes”, que é basicamente um time de integração de Carga através de um arquivo XML e o VivaPro, que é um CRM para anunciantes do VivaReal. Com os OKRs esse conjunto de times conseguem seguir a mesma direção na maioria das vezes.

Mas nem tudo são flores

O objetivo é dar a maior autonomia possível para cada bloco. Mas, na prática, sabemos que o mundo não é perfeito assim. Mesmo assim ainda existe dependência entre os squads que estão em diferentes blocos, e estamos trabalhando constantemente em encontrar uma fórmula que minimize ao máximo as dependência dos squads.

Para ajudar com esse problema, nós regularmente mapeamos todas as dependências entre os squads, e mapeamos se essa dependência apenas vai deixar o desenvolvimento mais lento ou se vai bloquear ele por completo. Nós então discutimos maneiras de eliminar essas dependências problemáticas, especialmente o bloqueio de dependências de squads de blocos diferentes. Isso muitas vezes faz com que seja preciso redefinir as prioridades, mudar alguma arquitetura ou até mesmo solução técnica.

Em artigos futuros podemos dar mais detalhes de como funciona esse processo de mapeamento de dependências e como trabalhamos em produto pra resolver alguns problemas que citei aqui. Espero que esse artigo ajude outras empresas de tecnologia que ainda não estão na fase de tração. Também espero que tenha ficado claro quão importante é ter um Gerente de Produto olhando pra visão e o quão importante é definir ela o mais cedo possível — de preferência antes de começar a ter tração.

Usando a abordagem Working Backwards

Durante minha carreira de gerente de produto sempre procurei abordagens diferentes pra facilitar a vida de todos (stakeholders, desenvolvedores e etc.). E então acabei conhecendo uma abordagem chamada “working backwards”, que é muito utilizada na Amazon. Não sei se eles inventaram o método, mas com certeza foram os que popularizaram.

O desenvolvimento de um produto deve sempre começar com as necessidades e benefícios que pode ser gerado para o cliente

A ideia principal de qualquer boa especificação é sempre focar no cliente, fazendo com que a feature seja totalmente centrada nele. Dai surgiu a ideia de especificar ao contrário. Esse método pode ser usado para tomar qualquer decisão específica de um produto, mas a eficácia da técnica vai variar do contexto que você está inserido — se for um contexto mais técnico que envolva integrações talvez não faça tanto sentido.

Mas, mesmo assim, recomendo usar a abordagem para o desenvolvimento de novas funcionalidades ou produtos que vão ser criados do zero.

Por onde começar?

Então se você, gerente de produto, vai lançar algo novo o que você faz por último? Escreve uma release pra divulgar o que foi feito e quando vai ser lançado. Então, utilizando a abordagem working backwards, é a partir da release que você deve começar. O público alvo dessa release vai depender do contexto que você está inserido — pode ser uma release interna caso seja uma funcionalidade voltada para os seus colegas de trabalho, ou pode ser uma release externa que você pode testar com alguns usuários para ter um feedback imediato.

Essas releases devem ser focados no problema central do cliente (interno ou externo). Nela você deve mostrar como as soluções atuais não suprem o problema e como o novo produto ou funcionalidade vai resolver isso. De preferência coloque algumas screenshots que pareçam com a funcionalidade final — crie mockups bem reais.

Depois de montar a release

A dinâmica é simples. Se os benefícios não parecerem interessantes para os clientes, então talvez não seja mesmo. É claro que isso vai dar apenas indícios, não quer dizer que a falha da release seja uma resposta definitiva. Por isso você deve continuar iterando essa release até que essas novas funcionalidades pareçam benefícios reais e encante todo mundo.

Exemplo de uma boa release Como escrever uma boa release:

  • Título — Nome do produto ou funcionalidade escrita de uma maneira que o cliente possa entender assim que ele bater o olho no título.
  • Sub-título — Descreva os usuários que vão usar a funcionalidade e os benefícios que ela vai oferecer. Tente colocar em uma sentença logo abaixo do título.
  • Resumo — Faça um resumo do produto/funcionalidade ressaltando os benefícios. Assuma que o leitor não vai ler nada além disso. Então esse parágrafo tem que ser impecável.
  • Problema — Descreva o problema que você está resolvendo.
  • Solução — Descreva, de uma maneira elegante, como você está resolvendo esse problema através dessa funcionalidade ou produto.
  • Citação de alguém da empresa — Uma citação rápida de você ou alguém importante na sua empresa. Ressaltando as vantagens.
  • Como começar a usar a nova funcionalidade — Descreva como é simples começar a usar.
  • Citação de algum cliente — Crie uma citação hipotética de algum usuário que usou a funcionalidade e ficou feliz
  • Resumo final e Call to Action — Considerações finais rápidas e um botão bem grande como Call to Action
Dicas
  • Se o release tiver mais de uma página ele provavelmente é muito grande
  • Faça 3–4 sentenças por parágrafo
  • É uma boa prática incluir um FAQ que responda todas as dúvidas de negócio para que a release seja focada no usuário final
  • Se a release é difícil de escrever, provavelmente é porque o produto não vai ser bom
  • Escreva a release de uma maneira simples que até sua mãe consiga entender. Sem “tecniquês”
  • Vai ajudar se você conversar com alguns clientes antes de fazer essa release
Ok. Release feita. E agora?

Após começar o desenvolvimento do projeto, depois de ter definido, testado e iterado a release, ela pode servir como um guia. Com ela a equipe vai poder sempre perguntar “Estamos criando coisas que foram definidas na release?” E isso é uma pergunta muito importante! Afinal, muitas equipes costumam perder tempo criando software que não está definido ou não possui um objetivo claro (overbuilding). Caso isso aconteça, a equipe precisa sentar e entender porque isso está acontecendo.

Assim a equipe consegue se manter focada em criar coisas que de fato vão beneficiar os usuários e não criar coisas que demoram muito e/ou não estavam previamente definidas.

No capitulo 11 do livro Getting Real da 37 Signals você pode ver mais detalhes sobre como escrever uma release. Isso com certeza vai ajudar você no processo de working backwards.

Acredito que escrever uma release focando nos benefícios dos usuários é um excelente exercício pra qualquer gerente de produto. Essa abordagem inclusive serve pra se manter alinhado com stakeholders e até mesmo com os clientes. Você já usou essa técnica? Não gostou e prefere outra? Comente pra gente discutir.

ualquer pessoa minimamente familiarizada com agilidade sabe o que é uma user story. O problema é quando algumas pessoas acham que basta “especificar” uma user story que, em alguns dias, o software vai se materializar e estar pronto pra ser usado.

Quem dera o desenvolvimento de software funcionasse dessa forma.

Dependendo do seu contexto, ter uma história muito grande e/ou com vários cenários diferentes é problemático. Especialmente em startups que precisam ser sempre ágeis. Já vi muita gente usando o famoso Gherkin Style, hoje em dia eu procuro não trabalhar com isso pra tentar ser mais ágil. Por isso resolvi escrever esse artigo pra ajudar gerentes de produto ou analista de negócios a serem mais ágeis e menos burocráticas.

Cena clássica entre Gerentes de Produto e Desenvolvedores

Você recebe uma demanda e então escreve a User Story e chega pra falar com os desenvolvedores“13 pontos?!”, você exclama.

“Tem muita coisa que precisa ser feita pra concluir essa história, e ainda assim nós não temos tanta certeza do que vai acontecer quando implementarmos essa parte X. Nós nunca fizemos alguma coisa desse porte com esse software. Precisamos quebrar mais as histórias!”, respondem os desenvolvedores

Você: “Por que eu faria isso? Eu preciso da funcionalidade toda! Tudo!”Mas você, como um ótimo gerente de produto que precisa zelar pela sua imagem e pela imagem do produto não pode colocar no ar uma funcionalidade feita pela metade, não é o mesmo? Ainda mais com os desenvolvedores dando estimativas altas. Ferrou! Você nunca vai ver a sua funcionalidade.

E aí o caos começa, brigas, discussões calorosas e etc. Se você viu isso acontecendo é provavelmente porque o gerente de produto da sua equipe não está com o mindset lean.

Se isso acontecer, você provavelmente tem em mãos um épico. Ou seja, uma grande User Story. Um épico deve ser composto por várias User Stories pequenas para facilitar o desenvolvimento. Vamos entender passo a passo como fazer isso.

Menos é mais! Pequenas User Stories são melhores que grandes User Stories.


Vantagens
  • Através de pequenas iterações você está sempre entregando valor para o usuário. Seja externo ou interno.
  • Os desenvolvedores conseguem estimar com mais precisão
  • Sua velocidade de entrega não fica variando muito
  • A funcionalidade como um todo acaba sendo entregue mais rápido
  • Ninguém merece ficar trabalhando na mesma história por uma semana, nem você como cara de produto nem os desenvolvedores.

Exemplo — Como quebrar uma grande user story em várias histórias pequenas

Toda a história deve, por si só, entregar valor para o usuário. Histórias muito detalhadas ou técnicas demais normalmente não entregam valor para o usuário. Esse é um erro que eu já vi se repetir várias vezes. É um erro que eu já cometi e é muito comum. Mas ser comum não deixa de ser um erro terrível.

O exemplo abaixo mostra uma abordagem diferente que ajuda a evitar esse tipo de problema.Exemplo ruim (toda funcionalidade em uma história)

Como um usuário que está deletando e-mails, quando eu clico em “Deletar” em um email:
Então uma confirmação que o e-mail foi removido deve aparecer na minha tela
E o e-mail deve ser movido para a lixeira
E o contador de emails na lixeira deve aumentar
E o contador de emails da caixa de entrada deve diminuir
E o e-mail deve ficar na lixeira por 30 dias e depois ser deletado automaticamente

Eu poderia fazer infinitos “E”. Nesse exemplo nós podemos quebrar em, no mínimo, 6 histórias diferentes.

Bom exemplo (quebrando a funcionalidade em várias histórias)

  1. Usuário deleta email
  2. Usuário recebe mensagem com confirmação que o e-mail foi deletado
  3. Usuário vê contador de emails na lixeira aumentar
  4. Usuário vê contador de emails na caixa de entrada diminuir
  5. Usuário vê os e-mails deletados quando clica na lixeira
  6. O sistema apaga automaticamente os emails que foram deletados há 30 dias

Com essa abordagem, você pode liberar a funcionalidade principal (deletar e-mails) e depois ir iterando o software pra otimizar a experiência do usuário.

NOTA: Como você é um cara bacana, você pode pensar em dividir suas histórias em Front-end e Back-end pra deixar os desenvolvedores mais felizes. NÃO FAÇA ISSO! Lembre-se que a User Story precisa entregar valor para o usuário. Fazer front-end e back-end não entrega valor pra ninguém. Pense comigo, o que o usuário iria dizer se ao clicar no botão “Deletar” o e-mail não fosse deletado?

Cenário feliz vs Cenário ruimUm cenário feliz é composto pelas ações que o usuário faz pra concluir uma tarefa. Ele faz tudo certinho e sem errar nada. Mas quem dera todo usuário fosse esperto assim! Por isso existe o cenário ruim, que são todas as exceções de caso.

Para resolver isso, em vez de escrever várias histórias que listam todos os casos de uso possíveis, quebre elas em casos específicos.

Exemplo ruim
  • História: “Como usuário eu devo conseguir fazer login no sistema perfeitamente”
  • Cenário: Usuário acessa o site quando o login e senha estão corretos
  • Dado que eu sou um usuário com login e senha corretos
  • E eu clico em “Entrar”Então eu devo acessar o meu perfil
  • Cenário: Usuário não acessa site com login e senha corretos
  • Dado que eu… (você entendeu o exemplo)
Bom exemplo

Crie histórias individuais pra cada cenário

  • Usuário acessa o site com login e senha corretos
  • Usuário vê mensagem de erro quando tenta acessar com login incorreto
  • Usuário vê mensagem de erro quando ele não confirmou sua conta
  • Usuário vê mensagem de erro quando conta não existe


… E assim por diante. Muito mais fácil de entender. Mais rápido de implementar e até mais fácil de escrever!
O que você achou? Concorda? Discorda? Possuí uma técnica mais interessante? Vamos discutir. É só comentar.

Garantir entregas com qualidade em empresas de tecnologia é definitivamente uma das áreas, que as empresas em geral, têm mais dificuldade em fazer direito. Normalmente quando se cria uma área de QA os custos aumentam e a produtividade e velocidade da área de TI inteira cai.

Eu tentei muitas vezes ter um QA nas minhas equipes. Só que isso acabou sempre sendo um desastre. E os motivos eram:

  1. Os desenvolvedores tendem a entregar tarefas que nunca foram testadas para o QA e isso aumenta muito a iteração de feedback entre os dois. Por consequência aumenta o tempo e a complexidade do processo;
  2. A produtividade da equipe diminui;
  3. A cultura da culpa começa a se instalar;
  4. A equipe tende a se tornar menos enxuta ao longo do tempo;
  5. Os desenvolvedores começam a prestar menos atenção ao detalhes;
  6. Remove a responsabilidade de entregar tarefas com qualidade dos desenvolvedores;
  7. Não é escalável;
  8. A agilidade sofre com isso;
  9. Fazer uma gestão da sprint torna-se bastante complexa;
Solução:

Na minha visão o que determina um bom programador não é só a qualidade do código, estrutura e capacidade de encontrar soluções para os problemas. O que é mais importante é a qualidade da entrega. Isso é algo que eu sempre tento trabalhar e é onde a maioria dos desenvolvedores tem dificuldade.

A maioria dos desenvolvedores tendem a olhar para as tarefas com apenas algumas perspectivas. E às vezes eles perdem a perspectiva de que estão fazendo e qual é o objetivo em questão. Um desenvolvedor não deve só se preocupar em escrever código, na verdade, no último caso, eles devem estar focados na entrega e na qualidade dela. Se um bom desenvolvedor entrega com qualidade geralmente o código por trás tem padrões elevados.

A maioria dos desenvolvedores não gostam dessa abordagem, afinal, eles preferem escrever código sem ter que testar as coisas — especialmente aqueles desenvolvedores que se divertem muito em desenvolver software. Eles são os que não querem testar e costumam reclamar sobre a falta de um QA. Isso é um pouco difícil de aplicar em equipes de tecnologia, mas com persistência a equipe vai começar a perceber que é muito em importante testar em cada entrega e isso se torna natural pra todo mundo.

No final das contas, se o processo de QA for adotado pela equipe de desenvolvimento o número de bugs adicionados em cada sprint pode ser reduzido de 60% a 80% depois de algumas sprints. Isso aumenta a disponibilidade da equipe de desenvolvimento em implementar coisas importantes que levam a empresa pra frente.

Artigo originalmente publicado em inglês no Pulse pelo Ricardo Parro.

Dentro da Manufatura Enxuta existem os famosos 7 desperdícios de produção que você deve evitar de qualquer maneira. Já no meio digital, principalmente em Startups, também é necessário evitar alguns desperdícios. Nesse caso são os 6 desperdícios que normalmente são cometidos por inúmeras Startups.

Infelizmente muitas Startups cometem um ou mais desses erros e acabam quebrando. Foi o que aconteceu comigo duas vezes seguidas e só assim aprendi a lição. Seria muito bom ter tido alguém pra me falar tudo isso alguns anos atrás, então aproveite a chance que você tem de aprender esses erros normais.

Erros que toda startup comete e você deve evitar

Superprodução — Você pode criar um produto pronto e só depois disso descobrir que ninguém quer ele. Primeiro desperdício.

Má Qualidade — Sem testar apropriadamente o seu produto, você pode entregar uma versão final cheia de bugs ou com recursos que ninguém realmente vai usar. Isso vai afastar os seus cliente. Segundo desperdício.

Movimento nas operações — Alguns exemplos comuns são a procura por equipamentos, peças, documentos, tecnologia e etc. Não faça nada disso. Não procure a linguagem perfeita, o banco de dados perfeito e nem nada parecido. Apenas crie o seu MVP e entre no ciclo de feedback Criar-Medir-Aprender para não perder tempo.

Espera — Geralmente ocorre quando uma equipe precisa aguardar por alguma pessoa terminar de desenvolver algo ou qualquer coisa semelhante. A espera é considerada um gargalo e um grande desperdício, ou seja, acrescenta tempo desnecessário à todo o processo do negócio. Quarto desperdício.

Processamento — Esse desperdício é crucial para qualquer tipo de negócio. Você precisa evitar processos desnecessários ou incorretos, afinal, eles aumentam os custos independente do seu negócio ser digital ou físico. De modo geral esse tipo de desperdício é apenas percebido no momento da mensuração da produtividade, mas agora você já pode pensar nele de antemão.

Estoque — Se o seu negócio for inteiramente digital, essa regra não se aplica. A não ser que você esteja trabalhando com algo que envolva hardware. Nesse caso, você não precisa fazer um estoque de produtos acabados ou semiacabados maior que o mínimo necessário. Isso gera o sexto desperdício, o que acaba ocupando grandes áreas.

Ao visualizar essas perdas a sua Startup pode reduzir significativamente as chances de não dar certo. Lembrando que cada desperdício varia de Startup pra Startup e você vai encontrar eles em diferentes estágios da sua Startup.
*Originalmente publicado por mim no dia 4 de outubro de 2014..