Eu já quase me afoguei no meu próprio backlog… e você?

Esse artigo dá o tom para uma série de palestras que vou ministrar na próxima semana no evento online e gratuito que o Software Zen está promovendo. Saiba mais após a leitura.

Alguns dizem que uma das características da sabedoria é saber o que não fazer. Leia esse artigo antes de desenvolver a próxima funcionalidade no seu produto.

Dê uma olhada no seu backlog atual. Analise-o. Quantas funcionalidades novas ainda estão previstas para o seu produto? E as adequações nas que já estão lá? Muitas? Como o software está crescendo? Menus gigantescos? Opções para configurar e permitir todo o tipo de situação? Já perdeu a conta do número de relatórios?

Quando o seu software caminha para crescer a ponto de conter um grande número de funcionalidades é uma boa hora para parar e refletir. A verdade é que não há limites para o crescimento potencial de um produto de software.

Se você deixar, ele vai crescer até você não conseguir mais administrá-lo. Vai colocar seu ambiente de desenvolvimento em estado de caos. Será sempre difícil deixá-lo estável o suficiente a ponto de você ir dormir sem aquele medo de que, de uma hora pra outra, as coisas entrem em alguma forma de colapso irreversível. Ao chegar nesse ponto, talvez você se pergunte quando e como você caiu nessa armadilha. Esse artigo vai te ajudar a elucidar essa questão.

Eu conto essa história e faço essa análise porque já estive lá. Gabava-me das mais de mil funcionalidades e opções de menu que meu produto possuía. Criava listas intermináveis de coisas que meu produto fazia para comparar com os meus concorrentes e demonstrar a minha posição vantajosa no mercado. Como falei, a gente ganha certa dose de sabedoria depois que descobre o que não fazer. Nesse caso, foi isso que aconteceu.

Features (ou funcionalidades) são as características do seu produto. É o que ele faz. A verdade é que os seus clientes — ou usuários — não querem as features que o seu produto tem. Não há valor intrínseco em features. O que elas são, de fato, é um obstáculo para o seu cliente. Isso mesmo, um obstáculo! As features são o que está entre o seu cliente e o problema que ele quer ter resolvido. Em outras palavras, para ter o que ele quer, ele precisa pagar o custo de operar um certo painel de funções que o ajudará a chegar lá. Esse painel de funções é o seu software.

O painel é, assim, uma espécie de ponte entre um problema e sua solução. Atravessar a ponte é o esforço que seu cliente precisa fazer para chegar no lugar que ele quer. O fato é que, como desenvolvedores, somos muito criativos. Somos tão criativos que a maioria das pontes que construímos são bem mais difíceis de atravessar do que realmente precisariam.

Na comparação entre dois produtos que resolvem o mesmo problema, sábios serão aqueles que optarem pelo que resolve o dado problema com menos features. Afinal, menos funcionalidades te levam a um menor custo de operação; menor custo de aprendizado e treinamento; menor custo de manutenção e por aí vai. Mais simples e mais barato. E aí fica bom pra todo mundo.

Entretanto, se o objetivo é minimizar o número de features, porque nossos backlogs estão abarrotados delas? Por que nossos produtos incham tanto e se tornam monstros gigantes e difíceis de domar? Bom, há todo um processo histórico, psicológico e comercial que explica esse fenômeno. Primeiro, Features são o que temos de mais próximo de “coisas” em produtos de software. Podem ser enumeradas, listadas, explicadas e apresentadas uma a uma. Há uma percepção de valor natural do ser humano em coisas tangíveis e as features cumprem bem esse papel no nosso mundo.

Desenvolvedores de software não costumam ser bons vendedores ou normalmente não estão habituados a fazer o marketing dos seus produtos. O que é uma pena, porque essas são as áreas de maior importância em qualquer negócio. Essa falta de preparação nas áreas de marketing e vendas, leva-o a acreditar que seu sucesso comercial está associado ao que o seu produto faz ou a quantas “coisas” ele tem. Isso está muito longe da verdade.

Um produto de software deve ser avaliado de acordo com a sua capacidade de solucionar com eficácia um problema real de uma pessoa real. Ele deve levar o cliente do problema que ele tem à solução que ele precisa via o caminho mais curto e mais barato possível.

Bons produtos são iguais a árbitros de futebol: os melhores são aqueles que você nem percebe que estão ali.

Repare que é um processo de transformação, não de uso. Você está transformando alguém que tem o problema X, em alguém que está livre do problema X pra fazer Y. O valor não está na coisa, mas nessa percepção de mudança de estado obtida pelo cliente.

O produto de software mais usado no mundo, o Google Search, tem apenas duas telas, um campo de texto e um botão. Quantas features são necessárias para resolver com extrema eficácia um problema extremamente complexo como colocar a informação certa a seu alcance no menor tempo possível? O Google Search é eficaz na medida em que transforma alguém desinformado sobre X, em alguém com a informação necessária sobre X para fazer Y. Novas features só farão sentido no Google Search se forem capazes de tornar essa transformação mais rápida ou mais barata.

Com a pretensão de aumentar o valor percebido de seus produtos; de absorver mais clientes para sua carteira; ou de entrar em outros nichos de mercado; nós, desenvolvedores, levamos nossos produtos a crescerem horizontalmente. Eles crescem no número de coisas que fazem, ao invés de no quão bem fazem uma determinada coisa. Nossa falta de preparação em marketing e vendas, aliada ao grande pré-conceito em torno dessas duas áreas, nos leva a não dar a devida importância à necessidade de buscar pelo cliente certo, pelo cliente que realmente precisa do que oferecemos.

Ao invés disso, tentamos trazer para o barco todo e qualquer cliente que esteja disposto a pagar e, pra dar conta dos problemas que eles têm e nós não resolvemos ainda, corremos atrás para preencher o gap. O jogo se inverte. Ao invés de estarmos à frente desenhando pró-ativamente o que nosso produto precisa para fazer melhor o que faz, ficamos atrás, lutando para desenvolver o que falta no produto para atender aos últimos clientes que entraram. Deixamos de ser designers de soluções para nos tornar aqueles que apenas atendem aos legítimos pedidos de clientes que caíram na armadilha de comprar mais do que queriam e menos do que precisavam.

Todos esses processos históricos, psicológicos e comerciais que citei até aqui se incorporam rapidamente à cultura da empresa. Quanto mais o tempo passa, maior se torna a pressão por mais desse crescimento horizontal do produto. Mais features em produção também potencializa a necessidade de ajustes, adaptações ou customizações. O número excessivo de mudanças e intervenções degrada intensamente a qualidade do código. Erros e bugs se tornam comuns. O backlog se expande: inúmeras novas features solicitadas, ajustes a serem feitos, bugs a serem corrigidos. Chegamos a um ponto onde muitos dos itens nunca sequer serão feitos. Ficarão ali… pra sempre.

Nesse momento, quanto mais você faz, mais coisas chegam pra você fazer. Você passa a viver uma dinâmica sistêmica, aparentemente irreversível, que se desdobra sutilmente até que você se vê em uma espécie de “areia movediça”. Quando mais você se mexe, quanto mais se debate, mais se afunda em um backlog que te afoga lentamente.

A verdade é que nos habituamos a tratar software como um “algo” e não como uma ponte de encaixe entre um problema e uma solução.

Adotamos o modelo de “restaurante”. Como garçons eficientes, anotamos os pedidos e levamos para a cozinha preparar enquanto o cliente espera sentado tomando um bom vinho. E somos nós que os levamos a esse modelo. Somos nós que os convidamos a sentar oferecendo o cardápio. O que temos pra hoje? uma nova opção aqui, uma nova tela ali, um novo relatório acolá. E lá na cozinha, onde os pratos são preparados, nos acostumamos a usar aliases confusos para identificá-los: “solicitantes”, “demandantes”, aqueles que têm desejos a serem atendidos. Por que você está fazendo isso? — “Porque o cliente pediu”.

Se esse é o tipo de relação que você está construindo com o seu cliente, prepare-se para perder o domínio sobre a eficácia do seu produto. Prepare-se para conviver com a ameaça de se afogar no seu próprio backlog por um longo tempo. É hora de mudar. É hora de adotar uma nova cultura, a cultura da eficácia: fazer melhor ao invés de fazer mais.


Esse assunto, além de vários outros, serão tratados em mais detalhes e serão recheados por ideias e conceitos práticos na série de palestras online que vou ministrar nos dias 24, 26 e 30/01/2017.

Inscreva-se gratuitamente nessa página…


Alisson Vale fundou o Software Zen para ajudar desenvolvedores de software, gestores, líderes de equipe e outros agentes de mudança a sair dessa areia movediça em que o backlog os coloca. O Software Zen te ajuda a construir um novo caminho para seus produtos com uma gestão intensamente baseada em eficácia.