Um antipadrão é uma resposta comum mas ineficaz e contraproducente a um problema. Esse termo foi criado por Andrew Koenig em 1995, inspirado no livro de 1994, Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de design: Elementos reutilizáveis de software orientado a objetos) escrito por Gamma Erich, Helm Richard, Johnson Ralph e Vlissides John, que lista uma série de padrões de design de desenvolvimento de software que seus autores consideraram simples, sucintos e eficazes para os problemas mais comuns.

Mas o termo foi popularizado pelo livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Antipadrões: Refatorando software, arquiteturas e projetos em crise), de 1998, escrito por Raphael Malveau, William Brown, Hays McCormick e Thomas Mowbray, que estendeu seu uso além do campo do design de software para se referir informalmente a qualquer solução ruim para um problema.

Na Wikipedia em inglês, o termo lista mais de 70 antipadrões. Vou listar a seguir os antipadrões que encontrei com mais frequência na minha carreira. Esses antipadrões que cito acontecem quando a liderança da empresa não tem experiência suficiente em desenvolvimento de produtos e é assessorada por pessoas que foram bem-sucedidas em gestão de desenvolvimento de software no passado, mas que não se atualizaram.

Como expliquei na introdução, desenvolvimento de software é uma ciência muito nova, especialmente se comparamos com outras ciências como astronomia, medicina, matemática, química etc. A primeira vez que um computador armazenou um software em memória e o executou com sucesso foi às 11 horas do dia 21 de junho de 1948, na Universidade de Manchester, no computador Manchester Baby. Isso significa que desenvolvimento de produtos de software está engatinhando. Se um profissional não se mantiver atualizado, o conhecimento e experiência que o fez bem-sucedido no passado pode não ser o mais adequado para fazê-lo bem-sucedido no futuro.

Documentação

Uso excessivo de documentação vai sem dúvida desacelerar o time de desenvolvimento de produtos. Não é à toa que no Manifesto Ágil, escrito em 2001, dizemos que valorizamos “Software em funcionamento mais que documentação abrangente”. Para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.

A última vez que escrevi um PRD (Product Requirement Document ou Documento de Requisitos de Produto) foi em 2005, logo quando eu entrei na Locaweb. Foi um trabalho bastante demorado, onde documentei em detalhes tudo o que precisávamos implementar no software. Passada para a engenharia, a implementação foi feita com vários erros porque os engenheiros acabaram não entendendo o que estava escrito em algumas partes e decidiram implementar como acharam melhor. A partir disso passamos a diminuir o uso de documentação extensa e aumentamos a interação entre gestores de produto, designers de produto e engenheiros.

Marty Cagan tem um artigo muito bacana chamado How to write a good PRD (Como escrever um bom PRD – https://svpg.com/assets/Files/goodprd.pdf) onde ele comenta logo no começo:

“Forneço este documento aqui principalmente para fins históricos. Foi escrito em 2005 para refletir melhores práticas das décadas anteriores.

Não tenho defendido o uso de PRDs por muitos anos, começando aproximadamente em 2007. Não é que os PRDs sejam tão ruins. Contudo, se o gerente de produto está gastando seu tempo escrevendo o PRD, então é improvável que ele ou ela esteja fazendo o trabalho real de discovery de produto.”

Padrão recomendado: é só seguir o manifesto ágil, produto na mão de clientes traz mais valor para os clientes e para a empresa do que documentação abrangente e detalhada.

Foco em dados

Acontece quando o head de produtos e outros líderes só tomam decisões se houver abundância de dados, relatórios, gráficos. Há dois perigos com esse antipadrão:

• Tempo: às vezes para juntar todos os dados necessários leva-se muito tempo. É a situação conhecida como analysis paralysis ou paralisia da análise. Nada acontece enquanto os dados não são meticulosamente obtidos e analisados. Muitas vezes, após uma primeira análise, mais dados são pedidos e mais tempo é investido na busca desses novos dados, e esse ciclo pode se repetir por inúmeras vezes. E, enquanto esse ciclo se repete, nenhuma decisão é feita. Daí a paralisia da análise.

• Erros: quando confiamos somente e exclusivamente nos dados, há grandes chances de incorrermos em erros. Como podemos ter certeza de que temos todos os dados necessários para concluir algo? Como podemos ter certeza de que os dados estão corretos? É comum ouvir que as decisões devem ser data-driven, ou seja, baseadas em dados. Contudo, os dados podem estar incorretos e/ou ser insuficientes para descrever uma determinada situação. Pensando nisso, mais recentemente surgiu o conceito de decisões data-informed, ou seja, que são baseadas em dados, mas não somente em dados. Levam em conta, além dos dados, informações qualitativas, experiência prévia e intuição.

Padrão recomendado: procure tomar decisões com dados, mas sempre entendendo que os dados são incompletos, e leve sempre em consideração informações qualitativas, experiência prévia e intuição.

Grande reescrita

Toda empresa tem um sistema legado. Mesmo a startup que acabou de ser criada, em poucos meses, poderá olhar para sua base código como legado e algo que precisa ser melhorado. Nesse momento aparecem frases como:

• Está cada vez mais difícil mexer no código.
• Se fosse fazer do zero, seria muito mais rápido.
• Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

E nesse momento nasce a grande solução da reescrita. E essa grande reescrita vai, em algum momento causar aquele congelamento de evolução do produto. Por que escrever algo para o legado, se o novo sistema vai substituí-lo? E tem também a migração ou transição. Como vamos do sistema legado para o novo?

Normalmente nas estimativas iniciais a reescrita vai levar uns 2 ou 3 meses e quando avançamos percebemos que vai ser um pouco mais longo, podendo levar anos. Na Locaweb tomamos a decisão de reescrever o sistema central que tinha o cadastro de clientes e fazia a cobrança. O projeto original era de 9 meses e acabou levando mais de dois anos. Além disso, quando o novo sistema entrou, nossa cobrança de clientes não funcionou durante uns 2 meses e ficou mais uns 6 meses rodando de forma incorreta até terminarmos todos os ajustes necessários. Ou seja, a reescrita que originalmente levaria 9 meses acabou levando 3 anos.

Padrão recomendado: evite grandes reescritas a todo o custo. Na grande maioria das vezes haverá formas de substituir o sistema legado de forma gradual e progressiva, sem causar disrupções para a empresa e para os clientes.

Lista de desejos

Quando uma nova head de produto se junta a uma nova empresa, é comum durante o processo de onboarding, durantes as inúmeras conversas com pessoas de várias áreas da empresa, ouvir uma série de pedidos e de reclamações em relação ao produto de que essa nova head vai cuidar. Para “marcar pontos” com essas pessoas, que eventualmente vão dar feedback sobre seu trabalho, pode ser tentador construir sua lista do que fazer baseado nesses pedidos e problemas reportados. É a “lista de desejos” da empresa. Em seguida, essa head de produto vai priorizar essa lista ou até mesmo terceirizar essa priorização para algum líder da área de vendas ou de negócios da empresa. Já vi situações em que o head de produto coletava a “lista de desejos” e apresentava em uma reunião com líderes de várias áreas da empresa, dizendo “agora preciso que vocês priorizem o que querem que o time de desenvolvimento de produto faça primeiro”.

Apesar de ser algo tentador, pois a “lista de desejos” vai de fato ajudar o head de produto a marcar pontos com líderes das outras áreas, esse comportamento fará com que o time de desenvolvimento de produto se torne um mero cumpridor de ordens, inibindo o potencial de inovação que ele pode trazer para o negócio. Quando o head de produto foca o time em atender a “lista de desejos”, acaba focando o time em ser um implementador de soluções que são dadas por outras pessoas, tirando o foco dos problemas a serem resolvidos. É a diferença entre o time implementador de soluções que já vêm prontas das outras áreas da empresa versus um time focado em encontrar as melhores soluções para resolver problemas da empresa. Vou falar mais desse assunto na próxima parte do livro, sobre princípios.

Padrão recomendado: time de desenvolvimento de produto trabalham em entender problemas para depois avaliar soluções possíveis. Procure então descobrir a lista de problemas a trabalhar, e não a lista de coisas que as outras áreas querem que o time de desenvolvimento de produto faça.

Resumindo

• Antipadrões são respostas comuns mas ineficazes de se resolver problemas. Existem muitos antipadrões bem documentados no mundo do desenvolvimento de produtos digitais. Os 4 antipadrões mais comuns em liderança de desenvolvimento de produto são documentação, foco em dados, grande reescrita e lista de desejos.
• Documentação, que deveria ser mantida em um mínimo, para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.
• Foco em dados é quando toda e qualquer decisão tem que ser tomada com dados, sem levar em conta informações qualitativas, experiência prévia e intuição.
• Grande reescrita acontece quando uma nova head de produto encontra um sistema escrito há algum tempo e identifica que será melhor reescrever do zero um novo sistema do que aprimorar o atual.
• Lista de desejos vem da necessidade de o novo head de produtos de agradar a todos os stakeholders, focando o time de desenvolvimento de produtos a apenas implementar o que é pedido, delegando a priorização para as outras áreas da empresa.

Com este capítulo terminamos a parte 1 sobre os conceitos necessários para entender os papéis e responsabilidades de um head de produtos. Na próxima parte vamos ver quais princípios devem nortear o trabalho de uma head de produto e de seu time.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

• Gestão de produtos: Como aumentar as chances de sucesso do seu software
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis