Mais vale um produto na mão do que um backlog voando
Se não for o maior, este é claramente um dos maiores desafios do trabalho de alguém que é responsável pela entrega de um produto. Aqui na Ignus chamamos essas pessoas de Estrategistas de Produto e elas bem sabem o quão difícil é a tarefa de manter o time alinhado quanto às prioridades e garantir que no fim do ciclo as entregas aconteçam.
Não vou esconder o jogo, já tivemos alguns casos emblemáticos de projetos que tivemos enorme dificuldade para entregar o backlog dentro do prazo que havia sido acordado inicialmente. Lógico que cada situação possui um contexto e aprendemos com todas elas. Mas escrevo aqui por saber que isso não é algo exclusivo da nossa realidade.
O que tenho notado é que o problema quase nunca tem a ver com “imprevistos acontecem”, como é esperado pelo desenvolvimento ágil. O problema geralmente está na forma como desempenhamos o nosso papel quanto desenvolvedores de produtos digitais.
Antes de continuar, quero deixar um termo alinhado previamente. Utilizarei demandante do produto para me referir a cliente, PO (product owner) e stakeholder. Sempre dependerá do contexto, mas em suma essa figura se configura em um desses três perfis.
A entrega ideal
Poderia discorrer por alguns bons minutos aqui sobre a tendência que temos de sempre buscar a perfeição, mas esse não é o meu objetivo com esse texto.
Uma coisa que parece estar enraizado em algumas culturas de times de desenvolvimento é a tendência de realizar entregas mais complexas do que necessárias. As duas principais hipóteses — ditas já como causa certeira — são:
- A demandante do produto queria algo muito mais complexo do que o acordado inicialmente.
PS: em um próximo texto abordo sobre a atuação de clientes e stakeholders no desenvolvimento de um produto digital. - O projeto não foi bem vendido. Aquela ideia de que o comercial só quer vender e não se importa com a entrega. Quem sabe numa próxima oportunidade falaremos sobre isso também.
Na minha humilde vivência tenho percebido que ambas hipóteses são verdadeiras, mas longe de serem as determinantes. Afinal, o próprio time muita das vezes pode se opor a tais exageros. Mas o que acontece é que frequentemente o próprio time entra na onda e pega o tubo — e no final toma o caldo.
Dois comportamentos são combustível para essa fogueira que é tornar as coisas mais complexas do que o necessário:
- As pessoas que programam (“devs”) gostam de desafio técnico. Fazer o simples ou o repetido é monótono. O negócio é solucionar de forma ímpar.
- As pessoas que projetam a experiência (“designers”) gostam de colocar toda a teoria na prática. É um interesse genuíno de projetar experiências fluidas e com a usabilidade ideal.
O que muita das vezes era para ser apenas uma trilha no meio do mato que levasse uma pessoa do ponto A ao ponto B se torna um portal tridimensional com serviço a bordo, espumante francês e TV a cabo. 😓
As referências que jogam contra
Sempre que rola aquela conversa sobre uma funcionalidade que precisa ser feita, é inevitável alguém levantar a bola com um “é tipo que nem o ____”. Preencha esse espaço com qualquer aplicativo ou plataforma que você considera uma referência. O empecilho é que essa moeda tem dois lados.
Se por um lado essa referência — como o próprio nome diz — é uma “tangibilização” do que pode ser feito, por outro ela gera uma expectativa que potencialmente será frustrada. Quando alguém diz que o login poderia ser igual a de um aplicativo de banco com touch ID ou com dupla autenticação, não faz ideia da complexidade que é implementar isso. Fica aquela impressão traiçoeira de “se alguém já fez, não deve ser difícil”. Na boa? Sempre é mais complexo do que parece. SEMPRE!
Lidar com a frustração é preciso
Nem todos os produtos que iremos desenvolver serão casos de sucesso dignos de uma apresentação no palco central do ILA ou de qualquer outro congresso do porte. A publicidade já se perdeu na cobiça desenfreada de ter toda e qualquer campanha concorrendo a um Cannes Lion.
Precisamos encarar a realidade de que um produto também para de pé com funcionalidades super simples e até com pequenos problemas. Sim, é aquele login com e-mail e senha que dependendo do tempo disponível não tem nem recuperação de senha automatizada. Gol feio também conta.
“Poxa, mas essa solução é bem simples”. Sim, ela é. “Mas da pra fazer melhor”. Sim, é possível fazer melhor. Na verdade “é possível fazer melhor” é uma afirmação que tende ao infinito. Entretanto, o tempo e a verba são finitos.
Vale lembrar que os grandes produtos digitais que conhecemos hoje já foram um dia um baita de um patinho feio que mal sabia andar. Vale lembrar que as primeiras versões do Facebook e do Twitter eram extremamente rudimentares — para não dizer horríveis.
Cada um por si e o cliente contra todos
Nada pior para um time de desenvolvimento do que o individualismo. E ele aparece de forma sutil e, acredito eu, se estabelece como um mecanismo de defesa frente às expectativas mal gerenciadas com a pessoa que demanda pelo produto.
Alguns sintomas que podemos observar são comentários como “o cliente está pedindo muita coisa e vai ficar difícil entregar”. Depois parte para o “não posso participar da retro, pois preciso focar na entrega”. Quando você menos espera, acabará escutando duas falas que provavelmente tipificam que o escudo está totalmente armado: “temos reuniões demais e pouco tempo para produzir” e — a derradeira e mortal — “pelo menos eu fiz a minha parte”.
Trabalhar com desenvolvimento de produtos é trabalhar com pressão constante da demandante do produto — sendo o mais transparente possível. Mas isso não deve ser tratado como um cabo de guerra e muito menos como um salve-se quem puder. Na verdade, é na hora da pressão que o time precisa ser de fato um time e atuar junto. Para reforçar que a união faz a força — e também o açúcar — trago um dos doze princípios do manifesto ágil:
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Fazendo aquilo que estou afim
Quem nunca, no seu trabalho, priorizou algo que estava disposto a fazer frente aquilo que precisava ser feito? Algumas vezes— ou em sua maioria — isso é também conhecido como protelação ou procrastinação. Posso falar por mim que estou nesse momento escrevendo esse texto enquanto deveria estar fazendo outras coisas. 🤭
Para falar bonito, podemos chamar isso de momento de inspiração. Mas funciona apenas quando se trabalha sozinho, que não é o caso dos times de desenvolvimento conforme já falamos. Muitas das tarefas que estão ali no quadro de kanban na coluna de para fazer (doing) foram alinhadas entre todo o time. Algumas, se uma pessoa simplesmente atrasar ou deixar para depois, pode prejudicar em muito o lead time da entrega.
Quando você menos espera o limite do WIP em “fazendo” já foi completamente ignorado e uma mesma pessoa possui ali 4 ou 5 tarefas. Obviamente que ela não está lidando com todas ao mesmo tempo, mas sem dúvidas não está focado em entregar e sim em fazer.
Mas o cliente que pediu
Ok, a demandante do produto realmente costumar pedir um monte de coisas. Mas sejamos sinceros com nós mesmos:
“Nosso trabalho é entregar o que o cliente precisa e não o que o cliente quer”.
Essa afirmação, verbalizada dias atrás pelo Roberto, sócio aqui da Ignus, me trouxe uma clareza impressionante. Essa é a mentalidade que tem que ser predominante em um time de desenvolvimento. E na boa, o Robert não inventou a roda nessa frase. Afinal, quem não conhece a famosa frase de Henry Ford sobre cavalos e carros?
Simplifique!
No fim das contas, como conseguir contornar os desejos dos clientes e manter o time centrado no que precisa ser entregue?
Passo 0 : Sedimentando as bases
Antes de discutir a simplificação de uma entrega, é fundamental que todo o time (a demandante do produto faz parte do time) tenha claro e alinhado qual é o objetivo do produto.
O passo 0.5 é o time ter mapeado a jornada do usuário e seus objetivos ao longo dos momentos. Aqui usamos o conceito de jornada + intenções do MVS (minimum valuable service). Sem essas bases, as chances de se perder no mundo fantástico da inovação é gigante.
Passo 1: Abrindo as possibilidades
Um dos passos da nossa Conceituação (etapa do trabalho que definimos o que será o produto) é olhar para a jornada atual e expandir. Sim, pensar todas as possíveis soluções, sem restrições. Na sequência todas essas possibilidades serão encapsuladas em épicos e funcionalidades.
Não, você não leu errado. É fundamental fazer esse trabalho de olhar lá na frente para entender para onde a demandante do produto está mirando.
Sim, eu falei aqui que referências podem jogar contra. Mas calma, vamos seguir com a lógica por aqui…
Passo 2: Cortando o não essencial
Confronte agora os objetivos dos usuários — ou as intenções — com as funcionalidades até aqui imaginadas. Basta fazer a seguinte pergunta:
Sem essa funcionalidade o usuário e o negócio continuam atingindo seu objetivo?
Se sim, funcionalidade é colocada na caixinha de icebox — conhecida como a caixa de “um dia, lá na frente, no momento oportuno, a gente olha para ela”.
Passo 3: Simplificando
Com as funcionalidades restantes, agora olhamos para cada uma delas e nos perguntamos:
Como é possível fazer essa funcionalidade de uma forma mais simples?
Repita-a 3 vezes. Não é feitiçaria e tão pouco é tecnologia, é procedimento — e um pouco de perseverança.
Passo 4: Analisando os impactos
Nesse momento, se seguir os passos até aqui, você terá um backlog com funcionalidades ultra simples. Todos nós sabemos que funcionalidades muito simples possuem contra partidas. E agora precisamos entender quais são.
Se for feito assim, quais passivos teremos para resolver no futuro?
É fundamental ser pragmático nesse momento. Vai gerar um débito técnico? Vai, e daí? Melhor ter um débito técnico mapeado e consciente do que não ter um produto de pé. No fim das contas tudo é uma hipótese e é natural que algumas funcionalidades tidas inicialmente como essenciais se tornem descartáveis na hora que o usuário passa a fazer uso do produto.
Passo 5: Fechando o backlog e o roadmap
Com as funcionalidades essenciais já simplificadas e mapeadas em relação aos ganhos e perdas, temos então o backlog inicial do produto. Mas é preciso ainda uma rodada de perguntas em cada item:
Essa funcionalidade depende de alguma outra do backlog?
Parece óbvio, mas não é. Algumas funcionalidades precisam ser executadas primeiro para não criar gargalos pela falta de um planejamento mínimo.
Pronto, aquele portal tridimensional passa a ser uma trilha de areia rudimentar que tem mosquitos e entra areia no sapato, mas atende ao objetivo de ir do ponto A para o ponto B.
Clientes se frustram, sempre
Vamos supor que depois de tudo o backlog do produto esteja composto por 15 funcionalidades (não vou falar em épicos por enquanto). Eu posso apostar uma tubaína que, independente de quantas entregas sejam feitas, a demandante do produto irá se frustar.
Vamos imaginar dois cenários possíveis:
- O time entrega as 15 funcionalidades, porém todas elas são simples e possuem inúmeros pontos de melhorias e ajustes.
Resultado: demandante frustrada pelo produto “meia-boca” 😅 - O time entrega 4 ou 5 funcionalidades beirando à perfeição, da forma como a demandante sempre imaginou — se é que isso é possível.
Resultado: demandante frustrada por não ter o produto pronto e muito provavelmente sem dinheiro para fazer o restante.
Perceba que é um beco sem saída. Mas qual dos dois temos a possibilidade de satisfazer a demandante mais rapidamente?
O cenário 1 vai nos gerar um monte de ajustes e melhorias, mas podemos mapear todas elas e então agir conforme uma priorização. Estamos no controle.
O cenário 2 ainda será preciso desenvolver mais de 60% do backlog e corremos o risco de ter que beirar a perfeição em todas elas novamente.
Parece que a resposta é simples, não? E tenha fé, toda primeira versão é de alguma forma brochante ou você se empolgaria com o Twitter em 2006?
“Mas eu vou me queimar com meus clientes com um produto ruim”
Eu mesmo já defendi a ideia de que um produto de usabilidade ruim é queimar a base de clientes atuais ou potenciais. Bom, eu uso o Guia Bolso há mais de 1 ano e meio, pelo menos. Lá atrás ele era horrível, as coisas não funcionavam direito a ponto de eu deixar de utiliza-lo recorrentemente por um bom período. Hoje ele evoluiu e consigo ter minhas necessidades melhor atendidas. Não, ainda não é 100%.
Complicado eu fazer uma constatação de caso único, mas o Guia Bolso não me perdeu como potencial usuário mesmo com a péssima usabilidade por conta da minha necessidade latente. Outros aplicativos como Todoist e Picpay não tiveram a mesma sorte comigo. Usabilidade ótima, mas não atendiam às minhas necessidades.
Além disso, em novos produtos é possível fazer um lançamento nichado com usuários dentro de um perfil específico e ir aprimorando até ter um produto robusto o suficiente para lançar para o restante do mercado. E sendo mais sincero ainda, poucos são os produtos que possuem uma base tão grande de usuários. A maioria se encontra ainda na mão dos visionários (early-adopters) da curva de adoção.
Se seu caso for um produto que será desenvolvido uma nova versão, essa estratégia é ainda mais fácil de aplicar. Você mesmo já deve ter experimentado versões beta de algumas plataformas por algum tempo antes do lançamento oficial.
Confie no processo
Como em uma sessão de ideação, confie no processo! Deixe a frustração da demandante rolar e não se sinta uma pessoa que não consegue gerenciar um time de desenvolvimento para fazer suas entregas.
Sabemos o quanto clientes que vivem na ansiedade — e não são poucos — dificultam o trabalho, mas isso é papo para um outro texto.
Se você tem alguma outra forma de fazer, se quiser compartilhar sua opinião sobre o que escrevo aqui ou até mesmo mandar um alô, só venha e escreva!
Uma menção honrosa à Beatriz Sanabio, pois algumas das coisas aqui descritas nasceram do nosso bate papo ao rever os aprendizados em um projeto. Também agradeço um verdadeiro trabalho de redatora da Tati Batista Lang que apontou várias correções aqui do texto, além da Kelly Tzung, do Raphael Ozawa e do Roberto Morais que enriqueceram minhas reflexões com algumas conversas e feedbacks após a escrita da primeira versão desse texto.
