O que é um produto?

O conceito de desenvolvimento de produto é fundamental no Agile e, se você trabalha em um Time Scrum, certamente sabe que deveria ter um Product Backlog e um Product Owner.

Mas o que é realmente um produto?

Para alguns times, essa é uma pergunta essencial. Afinal, organizações não conseguem identificar Product Owners, times ou papéis adequados sem saber antes quais são seus produtos. E se cada produto deve ter um Product Backlog, precisamos saber quais são nossos produtos antes de criar um Product Backlog para cada um deles.

Na maioria dos casos, identificar os produtos de uma organização parece bastante simples. Fabricantes de relógios de pulso, por exemplo, poderiam considerar cada item que vendem como um produto. No entanto, essa forma de pensar pode simplificar demais as coisas e, em algumas organizações, identificar produtos simplesmente não é tão fácil assim.

Quais são os produtos de uma companhia aérea?

Vamos usar uma companhia aérea como exemplo. Há alguns anos, trabalhei com uma companhia aérea quando surgiu a pergunta sobre o que realmente é um produto. Algumas pessoas achavam que uma companhia aérea faz apenas uma coisa: levar pessoas de A para B. Por isso, argumentavam que deveria existir apenas um único produto – mesmo em uma empresa com mais de 40.000 colaboradores.

Outros, porém, achavam que havia muitos produtos diferentes nessa empresa. Por exemplo, havia um site que os passageiros podiam usar para fazer reservas, fazer check-in ou verificar o status do seu voo. Além disso, havia um sistema para monitoramento e agendamento da manutenção das aeronaves e outro que permitia aos membros da tripulação escolher seus próprios voos de acordo com a antiguidade.

Isso tudo também eram produtos?

Definição e exemplo de um produto

Defino um produto como algo (físico ou não-físico) que surge através de um processo e oferece um benefício a um mercado.

Assim, uma cadeira seria um produto. O Microsoft Office também seria um produto. Um serviço de consultoria seria um produto. Uma pintura seria um produto. Um produto pode ser algo tangível (a cadeira). Pode ser um produto digital (Microsoft Office, e-books ou streaming de vídeo). Mas também pode ser um serviço (consultoria numa transição ágil).

Até uma ideia pode ser um produto (um algoritmo patenteável ou o segredo de como conseguir que mais pessoas deslizem para a direita no Tinder).

Cada um destes exemplos surge através de um processo ou, fundamentalmente, através de uma ou mais atividades. Alguém serrou a madeira para a cadeira e montou-a. Para o Microsoft Office, foi criado um design, o código foi escrito e os testes foram realizados. O processo pelo qual um produto surge não precisa de ser particularmente formal ou rigorosamente definido. Em algumas circunstâncias, as pessoas envolvidas nem sequer têm consciência deste processo. No entanto, para cada produto é necessário algum tipo de atividade.

Produtos podem ser definidos recursivamente

Também dentro de um produto podem existir outros produtos. Uma caneta esferográfica pode ter, por exemplo, cartuchos de tinta substituíveis. A caneta esferográfica é um produto. Mas os cartuchos de tinta na caneta também são.

Até numa cadeira existem subprodutos. O fabricante e vendedor da cadeira pode ter adquirido as pernas já prontas de outra empresa. As pernas da cadeira seriam, portanto, um produto separado.

Produtos podem ser definidos recursivamente. Uma empresa de exploração florestal abateu as árvores para obter madeira – o que já é um produto por si só. Numa serraria, foram então feitas pernas de cadeira a partir da madeira. Outra empresa montou depois as cadeiras com o seu próprio design usando essas pernas pré-fabricadas. Produtos podem, portanto, existir dentro de outros produtos.

Produtos oferecem um benefício

Quando identificamos diversos subprodutos dentro de um produto maior, precisamos de garantir que cada um destes subprodutos também oferece um benefício para o mercado. A definição acima não diz que algo precisa de ser comprado para ser um produto. No entanto, algo precisa de satisfazer um desejo ou uma necessidade para ser considerado um produto.

Tanto as pernas de cadeira pré-fabricadas como os cartuchos de substituição para canetas esferográficas cumprem este critério. Quando se definem produtos – e, portanto, também Product Owners e Product Backlogs em Scrum – é importante definir cada produto de forma a que ofereça um benefício para o mercado.

Aplicação desta definição de produto ao exemplo da companhia aérea

Se os produtos surgem através de um processo e têm um benefício para o mercado, serão os componentes de software produtos?

Para responder a esta pergunta, vamos olhar novamente para o exemplo da companhia aérea. Como pode o conhecimento de que os produtos surgem através de processos e devem oferecer um benefício para o mercado ajudar uma companhia aérea a identificar produtos?

Primeiro, é bastante fácil reconhecer que transportar pessoas de um lugar para outro é um produto. Esta atividade oferece um benefício a um determinado mercado de pessoas, e elas pagam com prazer pela possibilidade de voar para um determinado destino.

Mas e o sistema de monitorização e agendamento da manutenção de aeronaves? Afirmo que isso também é um produto.

Surge através de um processo e oferece um benefício a um determinado mercado. Mas a que mercado?

Bem, pode-se ir tão longe e dizer que aeronaves bem mantidas e seguras são benéficas para os passageiros. Se focarmos ainda mais no desenvolvimento do produto, os funcionários da companhia aérea também podem beneficiar da manutenção e agendamento assistidos por computador, já que não precisam mais de fazer tudo isso manualmente em papel.

O mesmo se aplica ao website da companhia aérea, que permite aos passageiros fazer reservas. Também para isso existe um mercado.

A companhia aérea tem, portanto, um produto principal – e muitos subprodutos. Tudo dentro desta empresa que oferece valor a um mercado é um produto.

Aplicação desta definição de produto a componentes de software

Vamos tentar manter tudo isto em mente e aplicá-lo a componentes de software. Se uma equipa desenvolve software que é utilizado por outra equipa, pode isso ser chamado de produto? Imagina que uma equipa desenvolve um widget de calendário. Oferece um benefício a um determinado mercado: as outras equipas que vão usar este widget. Também neste caso, afirmo que um componente para outras equipas é um produto.

No entanto, para esses widgets (ou outros componentes) que são usados apenas por uma equipa, eu traçaria uma linha. Claro que um mercado pode existir com apenas um único cliente. Uma pintura, por exemplo, é vendida apenas a uma pessoa.

No entanto, quando se fala de desenvolvimento de produtos (como em Agile), pode ser bastante perigoso chamar algo de produto quando é usado apenas por uma pessoa ou um grupo. Isso poderia levar a que se veja código como um produto porque é entregue a um mercado de testers. Isso não é apenas um passo atrás para o desenvolvimento sequencial, é também uma forma de subotimização.

Evitar a subotimização de produtos

Segundo o professor de economia Thayer Watkins da Universidade Estadual de San Jose, subotimização significa "focar-se num componente de um todo, querer melhorá-lo através de mudanças… e ignorar os efeitos sobre os outros componentes".

Embora as organizações devam sempre tentar definir todos os seus produtos para gerir o seu trabalho da melhor forma possível, não devem fixar-se tanto nos pequenos detalhes individuais a ponto de não conseguirem ver o panorama geral. Por esta razão, as organizações devem definir os seus produtos individuais da forma mais ampla possível.

Como vimos anteriormente com a companhia aérea, também pode haver algo como uma definição demasiado ampla de um produto. Se um produto é tão abrangente que serve vários mercados, prefiro vê-lo como vários produtos pequenos para os respetivos mercados individuais.

Por exemplo, seria bastante fácil ver o Microsoft Office como um único produto. No entanto, o Office consiste numa série de produtos que oferecem diferentes funcionalidades e servem mercados ligeiramente diferentes (e que se sobrepõem).

Por isso, vejo o Word, Excel, PowerPoint, etc., cada um como produtos individuais. Cada um destes produtos deve, portanto, ter o seu próprio Product Owner e Product Backlog. Só o verificador ortográfico poderia ser um produto, pois esta função oferece um benefício a um mercado (as outras equipas que não precisam de desenvolver o seu próprio verificador ortográfico).

No entanto, não definiria funções como calcular uma soma ou uma média, ou a função de contagem, etc., como produtos. São únicas para o Excel e servem, portanto, apenas um único cliente. Seria simplesmente demasiado arriscado dar a cada uma destas coisas o seu próprio Product Owner e Product Backlog fora do mundo do Excel. Reduzir o pensamento subótimo ao trabalhar com diferentes produtos não se consegue apenas evitando produtos para um único cliente, mas também nomeando um Chief Product Owner. O Chief Product Owner é um papel estratégico e responsável por criar uma visão que inclua todos os subprodutos. No Microsoft Office, o Chief Product Owner consideraria como os produtos individuais afetam a suite como um todo.