Há algumas semanas conversei bastante sobre gestão de produtos com o Fernando de la Riva, fundador e CEO da Concrete Solutions, uma empresa de consultoria de TI. Ele estava bastante fascinado com a descoberta que ele fez sobre a importância da gestão de produtos no ciclo de vida do desenvolvimento de software, tanto que acabou escrevendo um post bem interessante sobre como uma consultoria de software “descobriu” a gestão de produtos. Essa conversa me motivou a voltar a escrever sobre o tema. Como o Fernando disse no final de seu post:

Temos um ecossistema de engenharia de software de primeira linha (pequeno, mas de classe mundial), temos investidores maduros que entendem como ninguém como lidar com volatilidade e temos um mercado grande e quase virgem.

Nosso calcanhar de Aquiles é uma incrível incapacidade de entender como se faz produtos digitais, como ciclar rápido e produzir coisas como o Whatsapp, o Netflix e o Google Glass ou como manter times realmente multidisciplinares trabalhando de forma ótima durante 24 ou 26 meses até produzir produtos que as pessoas amem. O desafio é enorme, mas o prêmio também é.

Por isso me vejo com o dever de repassar o que aprendi ao longo desses anos de gestão de produtos. Minha ideia é ter um livro brasileiro sobre o tema, que reflita essa nossa realidade, que mostre para nossa indústria de software qual o papel da gestão de produtos no ciclo de desenvolvimento de software, e que motive mais pessoas a estudar o tema e incluir essa função em seus projetos de desenvolvimento de software.

Já escrevi a definição de gestão de produtos num outro post, mas vou repeti-la aqui, com alguns ajustes:

Gestão de Produtos é a função responsável por todos os aspectos de um produto de software, desde os objetivos estratégicos até os detalhes de experiência do usuário. É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do software que deve ao mesmo tempo ajudar a empresa a atingir seus objetivos estratégicos enquanto soluciona os problemas e as necessidades dos clientes.

Uma maneira de visualizar essa definição é por meio da imagem abaixo:

Gestão de Produtos (na teoria)

Mas, como todo mundo sabe, na prática a teoria é outra. Uma imagem que traduz melhor a gestão de produtos é a imagem abaixo, de Louis Cyr, que chegou a ser reconhecido como “o homem mais forte do mundo”, onde ele segura dois cavalos, cada um puxando para um lado:

Gestão de Produtos (na prática)

Como é de se imaginar, nem sempre os objetivos estratégicos de uma empresa estão bem alinhados com os problemas e necessidades dos clientes. Buscar esse alinhamento é a função da gestão de produtos.

Gestão de Produtos para sistemas que não são produto?

Gestão de Produto não é só para sistemas que se tornarão produtos, mas para qualquer sistema, desde que este sistema tenha usuários. O papel da Gestão de Produto é a ligação entre usuários do sistema e o time que construirá o sistema. É diferente do papel de analista de negócios, que é mais focado no negócio e nos donos do sistema. E é diferente do papel de Desenho de Experiência de Uso, que é mais focado em como o usuário interage com o sistema.

A Gestão de Produto é responsável por conversar com usuários reais do sistema, entendendo a dor que o sistema deve resolver para estes usuários, e ajudando a definir o que precisa ser desenvolvido. Note que um sistema sempre será propriedade de uma empresa, que irá te pagar para desenvolver esse sistema, por exemplo um sistema de ticket, um internet banking ou um sistema de e-commerce. Essa empresa vai te pedir um conjunto de funcionalidades para que o produto atinja certos objetivos de negócio. Mas a coleta de requerimentos estará incompleta se nós não ouvirmos os usuários reais, que normalmente serão os clientes da empresa que é dona do sistema.

Se você tem um ótimo grupo de desenvolvedores, QAs e analistas de negócio, todos veteranos no uso de Agile, Lean, Testes, DevOps e Entrega Contínua, tudo isso será inútil se você não for capaz de definir qual é o conjunto mínimo de características que podem criar valor para o cliente na primeira entrega. E subsequentemente definir as características mínimas a serem desenvolvidas e implantadas que traga o melhor valor para os usuários reais. O movimento Lean Startup chama isso de MVP – Minimal Viable Product, ou Produto Mínimo Viável. Mark Denne e Jane Cleland-Huag, autores de “Softwares by Numbers”, publicado em 2003, cunharam outro termo para este grupo mínimo de características. Eles chamaram de MMF – Minimal Marketable Feature.

O Manifesto Ágil diz que nós deveríamos valorizar “a colaboração do cliente antes da negociação do contrato” e define como seu primeiro princípio que “nossa maior prioridade é satisfazer o cliente por meio da entrega rápida e contínua de software de valor”. O problema com essas duas sentenças é que elas assumem que o cliente, que é o proprietário do sistema, sabe o que é “software de valor”. Só que o cliente, o dono do sistema que vc vai desenvolver, sabe o que é “software de valor” para ele, ou seja, ele sabe quais são os objetivos de negócio que ele quer atingir com o sistema. O problema é que o cliente não conhece seus próprios clientes/usuários o suficiente para definir os requisitos que devem ser desenvolvidos, ou seja, o cliente não sabe o que é software de valor para seus próprios clientes/usuários.

É papel da Gestão de Produto entender os usuários de um produto/sistema, o problema que os usuários têm, e trazer essa informação de volta para os desenvolvedores. Assim, eles podem em conjunto gerar um produto/sistema que resolve o problema dos usuários e, ao mesmo tempo, faz com que os objetivos de negócio do dono do sistema sejam atingidos.

Então a gestão de produtos é o “porquê” de fazermos software?

Não! Mas a gestão de produtos é responsável por saber o “porquê” estamos fazendo software e de relembrar o time durante todo a vida do software desse “porquê”. Quais os objetivos de negócio que o dono desse software tem que atingir? Quais problemas e necessidades do usuário esse software deve resolver? Durante toda a vida do software, desde a concepção, passando por cada nova funcionalidade, cada correção de bug, ajuste ou mudança em arquitetura, até a decisão de descontinuar esse software, a gestão de produtos deve sempre ter em mente esse “porquê” e usar isso como guia para todas as decisões.