Table Of Content© Casa do Código
Todos os direitos reservados e protegidos pela Lei nº9.610, de
10/02/1998.
Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem
autorização prévia por escrito da editora, aseja quais forem os meios: fo-
tográficos, eletrônicos, mecânicos, gravação ou quaisquer outros.
Edição
Adriano Almeida
Vivian Matsui
Revisão e diagramação
Bianca Hubert
Vivian Matsui
[2015]
Casa do Código
Livro para o programador
Rua Vergueiro, 3185 – 8º andar
04101-300 – Vila Mariana – São Paulo – SP – Brasil
www.casadocodigo.com.br
Sobre gestão de
produtos de software
Já chegamos àquele ponto no qual há software em lugares em que, há
alguns anos, jamais imaginaríamos que haveria necessidade e utilidade
de ter um software: televisão, geladeira, fogão, carro, relógio de pulso,
óculos, roupa, fechadura, mesa, cadeira, equipamento médico e por aí
vai. Isso sem falar no mais óbvio, o telefone que está em nossos bolsos
ou bolsas e do qual estamos nos tornando cada vez mais dependentes.
A ubiquidade do software é hoje uma realidade, o software permeia
inúmeras atividades e objetos de nosso dia a dia. Acredito que se pos-
sa dizer que 100% da população mundial tem suas vidas afetadas por
software, e boa parte dessa população tem contato frequente com
software. De acordo com o relatório We Are Social de 2015 (www.sli-
deshare.net/wearesocialsg/digital-social-mobile-in-2015), mesmo re-
giões pouco desenvolvidas como a África já têm mais de 25% de sua
população ativa na internet.
Mesmo com essa evidência de que o software está cada dia mais fa-
zendo parte da vida de todas as pessoas do planeta, ainda tenho a im-
pressão de que não damos a ele a devida atenção e cuidado. Pense em
todas as vezes em que você usou um software nos últimos sete dias.
5
Você teve alguma experiência frustrante com ele? Tenho certeza de
que sim.
Eu tenho experiências frustrantes com software diariamente. Mes-
mo softwares feitos por quem consideramos experts no assunto de
desenvolver software – como Google, Facebook e outras empresas
que nasceram e cresceram fazendo-os e que são frequentemente ci-
tadas como referências do processo do seu desenvolvimento – nos
causam frustração.
POR QUE ISSO ACONTECE?
O desenvolvimento de software evoluiu muito ao longo dos anos. Em
termos de processo, antigamente tínhamos o waterfall, em que cada
fase do desenvolvimento de software acontecia de forma sequencial.
A distância entre a necessidade que gerou a demanda de desenvolver
o software e o software propriamente dito era enorme.
No início deste milênio, começamos a experimentar as metodologias
ágeis, que transformaram o processo de desenvolvimento de sof-
tware em um ciclo com interações curtas que promovem o feedback
contínuo. Isso ajudou consideravelmente a diminuir a distância entre
a necessidade que gerou a demanda de desenvolver o software e o
software propriamente dito.
Do ponto de vista dos aspectos levados em consideração no desen-
volvimento de software, também evoluímos bastante. Os primeiros
6
softwares eram desenvolvidos por times compostos exclusivamen-
te por desenvolvedores de software. Aliás, não era raro esses times
serem compostos de uma única pessoa. Cada vez mais vemos times
multidisciplinares trabalhando juntos no desenvolvimento de softwa-
re; o que é muito bom, pois traz novas visões para o software que está
sendo desenvolvido.
De um lado, a preocupação com o usuário, seus objetivos ao usar o
software e sua interação com esse software são cuidados por profis-
sionais de experiência do usuário, ou UX (do inglês User eXperience).
Do outro lado, a preocupação com a operação do software – ou seja,
onde esse software vai rodar e que performance e disponibilidade ele
precisa ter – trouxe profissionais de administração de sistemas, os Sy-
sAdmins (do inglês System Administrators), mais próximos do processo
de desenvolvimento de software. Essa aproximação da operação do
software com o seu desenvolvimento é o que deu origem ao termo e
à cultura DevOps.
Ou seja, entregamos software mais frequentemente, e trouxemos UX
e SysAdmins para o desenvolvimento de software; mas será que isso
é suficiente? Como vamos contar para o mundo, ou melhor, para as
pessoas que podem ser beneficiadas com esse software, que esse
software existe? Como vamos cuidar das suas questões jurídicas?
Quando o usuário tiver um problema com o software, como vamos
ajudá-lo? Como vamos gerenciar o retorno que ele trará? Como ga-
rantir que esse software atenda os objetivos de seu dono ao mesmo
tempo em que atenda a necessidade de seus usuários?
7
GESTÃO DE PRODUTOS DE SOFTWARE
Pensando nessas questões, algumas empresas que são consideradas
experts no tema desenvolvimento de software começaram a adotar uma
nova função em seu processo de desenvolvimento de software, a Ges-
tão de Produtos de Software. Essa função tem por objetivo garantir
que um software sendo desenvolvido atenda aos objetivos de seu dono
ao mesmo tempo em que atenda à necessidade de seus usuários.
Além disso, essa função tem de pensar em todos os aspectos do softwa-
re que citei anteriormente. Algumas metodologias ágeis, como o Scrum,
têm o papel do Product Owner, que tem como principal responsabili-
dade priorizar os itens a serem desenvolvidos. De uma certa forma, a
Gestão de Produtos de Software é isso, mas ainda é um pouco mais.
É sobre isso que vou falar neste livro. :-)
PARA QUEM É ESTE LIVRO?
A resposta a essa pergunta é bem simples. Este livro é indicado para
qualquer pessoa que trabalhe com software. Ele serve para pessoas
que são gestoras de produto, pois todo gestor de produto sabe que
sempre há muito por aprender. E mesmo aqueles que já conheçam
bem todos os temas apresentados aqui poderão tirar proveito revendo
algum assunto.
Este livro também é indicado para qualquer pessoa que esteja que-
rendo entrar na carreira de gestor de produto. Acredito que ele possa
8
tirar um pouco da ansiedade de quem estiver pensando em se tornar
gestor de produto, e não sabe ao certo o que fará e o que as outras
pessoas esperarão dele.
Lembro uma vez de um amigo meu que era desenvolvedor de software
e decidiu virar gestor de produtos. Ele disse que, nos primeiros meses,
ele não entendia o que estava fazendo. Acostumado a medir o pro-
gresso do seu trabalho com código em produção, ao assumir a gestão
de produtos, ficou perdido sem entender como medir se ele estava de
fato entregando algo. Chegou inclusive a pensar em voltar a ser de-
senvolvedor de software. Já vi casos de pessoas que experimentaram
por dois ou três meses e voltaram à função anterior.
Acredito que mesmo as pessoas que não são e não pretendem ser gesto-
ras de produto também poderão tirar proveito deste livro, entendendo
o que essa função faz e como ela deve se relacionar com as outras
áreas.
Note que eu disse que este livro é indicado para qualquer pessoa que
trabalhe com software. Mesmo empresas que não tem software como
seu core business utilizam software no seu dia a dia e, não raro, desen-
volveram algum software que tem interface com seus clientes como,
um site ou um aplicativo mobile, por exemplo. É importante para essas
empresas entenderem a função de gestão de produtos de software,
para elas poderem gerir melhor esse software e aumentar suas chan-
ces de sucesso.
Vale lembrar de que este livro não tem a pretensão de cobrir de for-
ma extensiva todos os temas que serão abordados, mesmo porque, se
9
o fizesse, provavelmente teria de ser em uma coleção de livros. Meu
objetivo é falar sobre os principais temas relacionados com gestão de
produtos de software, aprofundando em alguns temas específicos e
fornecendo várias dicas de leitura adicional.
Em alguns lugares do livro, farei referências sobre as metodologias
ágeis de desenvolvimento de software e o papel de PO (product owner).
Acredito que o conhecimento desse processo de desenvolvimento e
dos diferentes papéis envolvidos nele não seja necessariamente um
pré-requisito para a leitura deste livro, mas é certamente um saber
que ajudará a aumentar as chances de sucesso do seu software. Caso
você queira se aprofundar no tema, recomendo o livro Agile: Desenvol-
vimento de software com entregas frequentes e foco no valor de negócio,
do André Faria Gomes. Além de explicar os princípios por trás da cul-
tura ágil, ele também fala sobre Scrum, XP e Kanban (as três metodo-
logias ágeis mais conhecidas), e sobre como espalhar essa cultura por
toda a empresa. Leitura recomendada.
ESTRUTURA DO LIVRO
Escrevi o livro seguindo a seguinte estrutura:
• Definições e requisitos: para começar, farei uma rápida introdução
às metodologias ágeis. Algumas das pessoas que leram os primeiros
rascunhos acharam que poderia ser útil fazer esta introdução, já que
falo sobre seus determinados aspectos em alguns pontos do livro. Em
seguida, definirei algumas palavras-chave como software, produto,
plataforma, gestão de produtos, entre outras. Nesta parte, falarei tam-
10
