Gestao de produtos de software - Como aumentar as chances de sucesso do seu software - Casa do Codigo

Gestao de produtos de software - Como aumentar as chances de sucesso do seu...

(Parte 1 de 3)

© 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: fotográ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 w.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 possa 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 (w.slideshare.net/wearesocialsg/digital-social-mobile-in-2015), mesmo regiõ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 fazendo parte da vida de todas as pessoas do planeta, ainda tenho a impressã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.

Você teve alguma experiência frustrante com ele? Tenho certeza de que sim.

Eu tenho experiências frustrantes com software diariamente. Mesmo 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 citadas como referências do processo do seu desenvolvimento – nos causam frustração.

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 software 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 desenvolvimento de software, também evoluímos bastante. Os primeiros softwares eram desenvolvidos por times compostos exclusivamente 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 software; 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 profissionais 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 SysAdmins (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 garantir que esse software atenda os objetivos de seu dono ao mesmo tempo em que atenda a necessidade de seus usuários?

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 Gestã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 software que citei anteriormente. Algumas metodologias ágeis, como o Scrum, têm o papel do Product Owner, que tem como principal responsabilidade 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:-)

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 querendo entrar na carreira de gestor de produto. Acredito que ele possa 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 progresso 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 desenvolvedor 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 gestoras 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, desenvolveram 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 chances de sucesso.

Vale lembrar de que este livro não tem a pretensão de cobrir de forma extensiva todos os temas que serão abordados, mesmo porque, se 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: Desenvolvimento 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 cultura ágil, ele também fala sobre Scrum, XP e Kanban (as três metodologias ágeis mais conhecidas), e sobre como espalhar essa cultura por toda a empresa. Leitura recomendada.

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- bém sobre as características de um bom gestor de produto, e darei algumas dicas para gestores de produto sobre liderança e cultura organizacional.

• Ciclo de vida de um produto de software: nesta parte, descreverei como é o ciclo de vida de um produto de software e quais são as fases deste ciclo: inovação, crescimento, maturidade e fim de vida. Ainda, falarei sobre o que é inovação, como encontrar um problema a ser resolvido, como descobrir se ele é de fato uma oportunidade a ser perseguida e como obter retorno com seu produto de software. Na fase do crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerenciar o produto durante seu crescimento, ou seja, como gerenciar o feedback? O que é um roadmap? Como priorizar as demandas? O que fazer com pedidos especiais? Como dizer não? Que métricas acompanhar? Após esse crescimento, vem a maturidade. Nessa parte, vamos entender quando acontece a maturidade e o que fazer se o produto chega nessa fase. Depois da maturidade, ou quando o produto é desenvolvido mas não dá certo, chega a fase conhecida como fim de vida de um produto de software. Veremos como detectar e o que fazer nessa fase do ciclo. No final, quando já conhecermos todas as fases do ciclo de vida de um produto, mostrarei qual a diferença entre startup e gestão de produtos de software.

• Relacionamento com as outras funções: como o gestor de produtos deve se relacionar com as diferentes funções da empresa, como engenharia, UX, marketing de produtos, gestão de projetos, vendas, jurídico, financeiro e atendimento?

• Gestão de portfólio de produtos: por que algumas empresas decidem ter mais de um produto? Como elas fazem para gerenciar esse portfólio de produtos? Por que outras empresas preferem se focar em um único produto? Foco ou diversificação, qual é a estratégia mais apropriada? Como organizar o time de desenvolvimento de produtos de acordo com a estratégia escolhida? Esses temas são os quais considero tópicos avançados de gestão de produtos de software, e é o que veremos nos capítulos que compõem esta parte do livro.

• Onde usar gestão de produtos de software: será que gestão de produtos de software só pode ser usada por empresas que comercializam produtos de software e somente nos times de desenvolvimento que desenvolvem softwares comercializados como produtos? Ou será que outros tipos de empresa se beneficiariam ao pensar em seu software como um produto e ao usar as técnicas de gestão de produtos para aumentar as chances de sucesso dos softwares que desenvolvem? E onde devemos colocar a gestão de produtos de software em uma empresa? No marketing? Na área técnica? Esses serão os temas dos capítulos finais do livro.

Essa sequência tem uma ordem lógica de assuntos, e alguns capítulos referenciam temas abordados em capítulos anteriores. Por esse motivo, recomendo a leitura sequencial do livro. Contudo, eles também podem ser lidos isoladamente. Se você estiver muito curioso para ler sobre um determinado tema, pode pular direto para o respectivo capítulo.

Boa leitura!

Quem é esse cara para falar sobre gestão de produtos de software?

Acho a sua pergunta bastante pertinente e apropriada; por isso, aqui vai um pequeno histórico. Acredito que minha experiência com gestão de produtos de software vem da época das primeiras linhas de código que escrevi, em meados da década de 1980. Desde desses primeiros programas, já me preocupava com facilidade de uso.

Naquela época, elementos de interação como menus, janelas e mouse estavam começando a ficar populares com as primeiras versões do Microsoft Windows e do Mac OS. Isso me mostrou que software não era composto apenas de um conjunto de instruções para a máquina executar. Para fazer um bom software, era (e ainda é) preciso pensar em como esse software deve interagir com seus usuários, se ele atende os objetivos de quem o desenvolveu, e assim por diante.

No final de 1992, quando estava terminando a faculdade de Engenharia da Computação no ITA, um tio meu me falou que ele conheceu um negócio muito bacana de computadores chamado BBS (Bulletin Board System). Ele não entendia nada de computadores, mas disse que tinha algo a ver com redes, e que se eu achasse interessante, nós podíamos abrir um negócio juntos. Com mais dois sócios, meu tio e eu criamos a Dialdata BBS, que depois viria a ser um dos primeiros provedores de acesso à internet do Brasil, em 1995.

Durante esses anos na Dialdata, escrevi muitas linhas de código que se transformaram em softwares, que eram disponibilizados para os usuários da BBS usarem. Também escrevi o sistema de cobrança, utilizado pelos funcionários da Dialdata, para fazer a cobrança dos clientes. A interação com usuários internos e externos me ensinou muito sobre desenvolvimento de software. Não basta só ter uma ideia na cabeça e um computador na mão para sair codando o software. É preciso entender o que o usuário espera do software, e o que você e sua empresa planejam obter com ele.

Em 1998, a Dialdata foi vendida para uma empresa americana chamada VIA NET.WORKS, que estava comprando provedores de serviços de internet em vários lugares do mundo para criar um provedor global de serviços de internet, para fazer um IPO (Initial Public Offering, ou oferta pública inicial de ações em uma bolsa de valores). Nessa época, fui convidado para trabalhar com gestão de produtos na VIA NET.WORKS.

Foi a primeira vez em que tive contato com o termo e a função de gestão de produtos. Minha responsabilidade era criar um portfólio global de produtos a partir das diferentes ofertas de produtos das empresas que foram sendo adquiridas pela VIA NET.WORKS. Foi aí que comecei a entender a importância desse papel em empresas de tecnologia em geral e, especificamente, nas empresas de desenvolvimento de software.

Em 2005, Gilberto Mautner, que também estudou no ITA, me convidou para ajudá-lo a melhorar o processo de desenvolvimento de produtos na empresa dele, a Locaweb. Hoje, temos na Locaweb um portfólio de mais de 30 produtos e um time de mais de 10 gestores de produtos. O time completo de desenvolvimento de produtos – incluindo gestores de produto, designers de UX e engenheiros de software – conta com mais de 100 pessoas. Aprendemos muito ao longo desses anos, mas o processo de aprendizado não acabou e acho que nunca acabará; ele é constante e contínuo.

(Parte 1 de 3)

Comentários