Ciclo de vida de feature

lifecycle

Em um artigo anterior, expliquei as 4 etapas de um produto de software:

  • Inovação: dos 4 estágios do ciclo de vida de um produto de software, a Inovação é a que detém a maior quantidade de dúvidas. É também a fase que tem a maior quantidade de livros. Qualquer livro sobre inovação e startups é útil quando o seu produto estiver nesta fase. O objetivo principal é criar um produto que atenda problemas e necessidades de um grupo de clientes.
     
  • Crescimento: Na fase de crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar com a forma de gerir o produto durante o seu crescimento. Uma vez que, durante a fase de inovação, nós construímos um MVP para alcançar nosso objetivo de encontrar o fit do produto com o mercado, nosso produto certamente será bastante incompleto, então devemos ter um plano descrevendo quais funcionalidade vamos construir mais a motivação para construir cada funcionalidade e as métricas que irão nos mostrar que estamos cumprindo a motivação para construir cada funcionalidade como descrevi em um dos meus artigo sobre roadmap.
     
  • Maturidade: Após o crescimento, vem a maturidade. Nesta fase, nosso produto atingiu seu mercado potencial e, conseqüentemente, não cresce tão rápido quanto cresceu na fase anterior
     
    .
  • Fim de vida: Após a maturidade, ou quando o produto é desenvolvido, mas não encontra o fit do produto com o mercado, vem o cenário conhecido como o fim da vida de um produto de software.

Este ciclo de vida de 4 fases pode ser aplicado não só a um produto, mas também às principais funcionalidades.

Para dar um exemplo, vamos imaginar que nosso produto é o Linkedin. Vamos supor que decidimos desenvolver uma nova feature para o Linkedin, por exemplo, o recurso de publicação de artigos que uso para escrever artigos no Linkedin. Durante a fase de inovação característica, teremos que encontrar o encaixe entre produto e mercado, o famoso product market fit. Neste caso, o que estamos procurando é o encaixe será a funcionalidade e mercado e, nesse caso, o mercado é toda a base de usuários do Linkedin.

Se pudermos encontrar o fit da funcionalidade com os usuários do produto, então é hora de aumentar o uso da funcionalidade, ou seja, implementar funcionalidades adicionais para o funcionalidade de publicação que acabamos de lançar para que ele possa ser uma funcionalidade cada vez mais completa para ser usada pelo número máximo de usuários possíveis.

Após o crescimento da adoção da funcionalidade de publicação na base de usuários do Linkedin vem a maturidade do recurso. Nesta fase, o recurso de publicação estará completo em termos de suas possibilidades e, como é utilizado pela maioria da base de usuários, seu crescimento diminui.

Então, após o crescimento, vem o estágio de fim de vida para o recurso de publicação. Pode acontecer se o Linkedin como todo entrar nesta fase, ou se o recurso for substituído ou descontinuado por qualquer motivo.

Na próxima vez que você decidir desenvolver e lançar uma nova funcionalidade importante para o seu produto, você pode aplicar a visão do ciclo de vida do produto para ajudá-lo a gerenciar o ciclo de vida desta nova funcionalidade importante.

Ano novo, trabalho novo: venha trabalhar na ContaAzul!

Somos movidos pela crença de que todo dono de negócio merece o sucesso.

contaazul-drone

Movidos por esse propósito, estamos construindo nossa plataforma de negócios fácil de usar, na nuvem, que conecta o dono do negócio ao seu contador e a tudo o que ele precisa para ter liberdade para realizar e atingir o seu sucesso.

Para construir essa plataforma, precisamos dos melhores profissionais para compor nosso time de desenvolvimento de produto que, como expliquei nesse artigo, é composto por UX, product owners (PO) e engenheiros de software.

Para ver todas as vagas que temos em aberto, acesse nosso site de carreiras em:

http://contaazul.com/carreiras

Indeciso ainda? Conheça um pouco de nossa cultura e veja como é trabalhar aqui:

Além de trabalhar com um propósito incrível, que pode melhorar significativamente a vida de milhões de pequenos empreendedores e a economia do Brasil, com pessoas top numa empresa que tem uma cultura sensacional, você poderá se mudar para Joinville, uma das melhores cidades brasileiras para se viver. Perto de ótimas praias de Santa Catarina e montanhas lindas. Eu me mudei de São Paulo para cá há 1,5 ano, com esposa e filha, e posso atestar como essa mudança foi excelente!

Então, o que você está esperando, junte-se a nós!

Gestão de Produtos em alta!

Esse fim de semana que passou a Gestão de Produtos de Software estava em alta em São Paulo. Rolou na sexta e sábado o ProductCamp SP. Foi lá na sede do Nubank e reuniu 250 pessoas interessadas no tema. O pessoal da ContaAzul foi em peso!

logo_product_camp

Eu infelizmente não pude ir, mas por uma boa causa: estava dando o 4º módulo da formação de Product Manager na Gama Academy.

Gama-Academy

Essa já é a terceira turma, e a quarta já está marcada, será de 2 a 24 de março do ano que vem. Garanta já a sua vaga!

logo_gamaacademy

O curso é dado em 4 semanas (sextas, das 19:00 às 22:00 e sábados, das 09:00 às 17:00) e é composto por 4 módulos:

  • No primeiro módulo, Will Sertório, da Funeel, explica como ir de um problema até um produto. Sobre a importância de entender bem o problema antes de começar a pensar em soluções. Como descobrir problema e público, solução e canais de venda.&nbsp
     
  • No segundo módulo, Diego Pereira, da Resultados Digitais, vai fundo no tema métricas e mostra como conectar métricas de negócio à dados do produto. Como encontrar oportunidades a partir das métricas de produto e como, através da métricas do produto, influenciar as métricas do negócio.&nbsp
     
  • No terceiro módulo, Ronaldo Marciano, da Creditas, mostra como transformar a ideia de um produto em um produto de verdade. Scrum, Kanban, MVP, Discovery, Delivery e vários outros temas são cobertos nesse módulo.&nbsp
     
  • No quarto e último módulo, eu faço ao mesmo tempo uma recapitulação de conceitos básicos como o que é um produto de software, o que é gestão de produtos, como é composto um time de desenvolvimento de produtos e apresento alguns tópicos mais avançados tais como o que é plataforma e qual a diferença entre gerir um produto e uma plataforma. Como gerir gestores de produto. Qual o impacto da cultura organizacional no sucesso do seu produto. Diversificação ou foco, qual é a melhor estratégia. Como gerir um portfólio de produtos.&nbsp
     
  • Por fim, os alunos apresentam na tarde do último sábado o TCC, transformando conceito em concreto, onde cada aluno conta como vai colocar em prática o que aprendeu no curso.

As turmas têm sido muito bacanas, e bem diversas. Sempre tem gente de empresas cujo core é tecnologia como QuintoAndar, Buscapé, Huggy, Truckpad, iClinic, Telefonica e Vista.ai. Também tem pessoas de empresas como Estadão, Printi, Netshoes e ePeliculas, que não tem como core business desenvolver e vender software, mas usam o software como parte essencial no processo de servir seus clientes. Nessa 3ª turma tinha uma pessoa do Sebrae que, como todos sabem, não tem produtos tecnológicos, mas estava lá para aprender sobre gestão de produtos de software e para usar essas técnicas para gerir seus produtos.

Se vc está procurando por um curso de gestão de produtos de software, essa pode ser uma boa opção. Garanta já a sua vaga!

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

  • Definições e requisitos
  • Ciclo de vida de um produto de software
  • Relacionamento com as outras funções
  • Gestão de portfólio de produtos
  • Onde usar gestão de produtos de software

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!

A importância do contexto no desenvolvimento de software

Nesse artigo quero propor um experimento mental. Vamos usar da empatia, principal característica de um gestor de produtos de software, para nos colocarmos no lugar de um desenvolvedor de software que recebeu do gestor de produtos do seu time a seguinte história para ser implementada:

Quando chegar em 39, deve soar um alarme.

Apesar de parecer ter informação suficiente, quando você começar a implementar, verá que está faltando informação. O que são esses 39? Quando chegar em 39 vindo de 38 ou vindo de 40? Ou nos dois sentidos?

Vamos agora ver a mesma história, só que com o devido contexto:

Estamos fazendo um sistema que monitora temperatura corporal e esse sistema deve soar um alarme quando a temperatura subir e passar de 39ºC.

Com o contexto fica bem mais fácil de entender o que são os 39 e porque foi pedido para soar o alarme. Sabendo disso fica bem mais fácil escrever o software certo.

Por isso, em sua próxima sessão de planejamento com o time, invista um tempo em explicar o contexto das histórias. Com isso você aumentará as chances de sucesso de seu software!

Roadmap ou OKR?

Um dos artigos mais lidos aqui no blog é “O que é um roadmap?“. Contudo, no início de 2016 eu escrevi sobre como os OKRs estavam substituindo roadmaps na Locaweb. Naquela época, meu entendimento era que, eventualmente, os roadmaps não seriam mais necessários e os OKRs substituiriam roadmaps.

Se esse entendimento é correto, por que meu último artigo no Linkedin foi sobre roadmaps? E por que um dos artigos mais lidos aqui no blog é “O que é um roadmap?“? Roadmaps ainda são úteis? Ou roadmaps estão em extinção, sendo completamente substituídos por OKRs?

roadmap_or_okr_2

Em agosto de 2016, após 11 anos liderando o desenvolvimento e gerenciamento de produtos na Locaweb, decidi mudar para a ContaAzul, uma empresa de Joinville que desenvolve um produto de ERP online, para ajudá-los a escalar sua equipe de desenvolvimento de produtos. Quando cheguei à ContaAzul, percebi que eles também usavam OKRs para toda a empresa, incluindo a equipe de desenvolvimento de produtos. No entanto, além de usar OKR, eles também usam roadmaps e não pareceu possível parar de usar roadmaps e gerenciar todos os esforços de desenvolvimento de produto usando apenas OKRs. Isso me fez refletir se OKR pode realmente substituir roadmaps ou se há circunstâncias em que ambas as ferramentas podem ser usadas em conjunto. Se isso for verdade, quais são essas circunstâncias?

Ao discutir este tópico com pessoas da indústria de desenvolvimento de software, ficou claro para mim que o uso do roadmap ou OKR depende do estágio do ciclo de vida do produto. Eu falei sobre os 4 estágios do ciclo de vida de um produto neste artigo.


lifecycle

4-phases

Conforme descrito no artigo, o ciclo de vida do produto de software tem 4 estágios:

  • Inovação: dos 4 estágios do ciclo de vida de um produto de software, a Inovação é a que provoca a maior quantidade de dúvidas. É também a que mantém a maior quantidade de livros. Qualquer livro sobre inovação e startups é útil quando o seu produto estiver nesta fase. O objetivo principal é criar um produto que atenda problemas e necessidades de um grupo de clientes. Por esta razão, durante esta fase, há apenas um Objetivo, achar o product-market fit e, para medir esse Objetivo, podemos usar os Key Results que demonstram o engajamento e a satisfação do cliente. Na etapa de inovação, devemos usar a estrutura MVP (Minimum Viable Product) de build-measure-learn para alcançar o objetivo de encontrar o product-market fit.
     
  • Crescimento: Na fase de crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar com gerir o produto durante o seu crescimento. Uma vez que, durante a fase de inovação, nós construímos um MVP para alcançar nosso Objetivo de encontrar o product-market fit, nosso produto estará bastante incompleto. Por esse motivo devemos ter um roadmap descrevendo quais features vamos construir, qual a motivação para construir cada feature e as métricas que irão nos mostrar que estamos cumprindo a motivação para construir cada feature como descrevi nesse artigo. Motivação é outra palavra para Objetivo e Métricas é o mesmo que Key Results. No estágio de crescimento, devemos usar Roadmaps juntamente com OKR.
     
  • Maturidade: Após o crescimento, vem a maturidade. Nesta fase, nosso produto atingiu seu mercado potencial e conseqüentemente não cresce tão rápido quanto cresceu na fase de crescimento. Quando um produto atinge este estágio, ele possui todos as features necessárias e não há mais necessidade de roadmap. Na fase de Maturidade, devemos usar apenas OKRs para gerenciar o desenvolvimento do produto, pois nesta fase estaremos otimizando o produto para atingir seus Objetivos.
     
  • Fim de vida: Após a maturidade, ou quando o produto é desenvolvido e lançado mas não encontra o product-market fit, vem o cenário conhecido como o fim da vida, ou sunset, de um produto de software. Nesta fase, como na fase de Maturidade, roadmap não é necessário, uma vez que não faz sentido investir em construir quaisquer features adicionais. Se o seu produto atingiu a fase de fim de vida após a fase de maturidade, ele já possui todos as features que precisa ter. Se o seu produto atingiu a fase de fim de vida logo após a fase de Inovação por não ter encontrado o product-market fit, você não deve investir nenhum esforço na construção de quaisquer features adicionais. Na etapa de fim de vida do produto, devemos usar apenas OKRs para gerenciar o desenvolvimento do produto, pois nesta fase o nosso único Objetivo é parar de oferecer o produto.

Por esta razão, fica claro que os OKRs substituem Roadmaps em todas as fases do ciclo de vida do produto, exceto para o estágio de crescimento em que ter um roadmap é muito útil para entender para onde seu produto está indo, ou seja, para entender o futuro do seu produto. No estágio de crescimento, devemos usar Roadmaps e OKRs em conjunto para gerenciar o desenvolvimento do produto.

Uma vez que o estágio de crescimento é a fase mais longa de um produto, normalmente durando anos, os roadmaps serão usados ​​durante um bom período do ciclo de vida do produto e por isso é muito importante entender o que é um roadmap de produtos e como o construir.

A importância da diversidade no sucesso do seu produto

Tenho visto com cada vez mais frequência manifestações sobre diversidade. Não sou muito de assistir TV, mas outro dia acabei vendo um pouco de TV Globo. Peguei o final do Jornal Nacional e o início da novela. No Jornal Nacional uma matéria sobre a PUC de São Paulo inaugurando banheiros unissex, lembrando que PUC = Pontifícia Universidade Católica, ou seja, uma universidade ligada à religião Católica. Em seguida, na novela apareceu uma atriz que estava contando para os pais e familiares que ela nasceu no corpo errado, que ela era um homem que havia nascido num corpo de mulher, ou seja, que ela era transgênero. Em seguida, durante o intervalo, veio a campanha da Globo intitulada “Tudo Começa Pelo Respeito” sobre respeito à identidade de gênero:

Isso é muito bom! Aceitar e respeitar as diferenças é a base para evoluirmos como sociedade e construirmos um futuro cada vez melhor para nós, para nossos filhos e para toda a humanidade.

Quando faltam o respeito e a capacidade de aceitar a diversidade, podem acontecer situações muito ruins, como, por exemplo, pais rejeitando o próprio filho. Fiquei bastante impressionado quando li o relato da Daniela Andrade, consultora sênior da ThoughtWorks, onde ela conta que:

Como fui expulsa da casa dos meus pais, por ser transexual — e aqui eu digo que a primeira grande violência que sofremos é dentro de casa — há muitos anos não tenho parentes com quem contar em momentos de necessidade, todos deram as costas para mim.

Como é possível um pai rejeitar a própria filha? Sou pai e sei como o amor de pai é algo muito intenso, capaz de passar por cima de qualquer problema para podermos sempre ajudar e suportar nossos filhos. Estava conversando outro dia com minha esposa sobre esse relato e sobre a dificuldade das pessoas em aceitarem as diferenças, ao ponto de fazer com que pais rejeitem seus próprios filhos. Foi nesse momento que minha esposa disse uma frase que me marcou. Ela disse que em última instância, todas as pessoas são diferentes. Transgênero, cisgênero, heterosexual, homosexual, bisexual, assexual, negro, branco, amarelo, jovem, adulto, meia-idade, terceira idade, brasileiro, canadense, francês, vietnamita, fluminense, mineiro, paulista, carioca, belo-horizontino, corredor, ciclista, nadador, engenheiro, arquiteto, advogado, quem gosta de música pop, rock, jazz, clássico e assim por diante. Mesmo gêmeos idênticos são diferentes.

Se todas as pessoas são diferentes, aceitar e respeitar as diferenças não é só desejável, é necessário e obrigatório para que possamos viver em sociedade de uma forma mais harmônica e sustentável. São valores que devem ser ensinados para todas as pessoas desde o berço.

E o que diversidade tem a ver com gestão de produtos de software?

Além do importância de aceitar e respeitar as diferenças para ajudar a criar uma sociedade mais harmônica e sustentável, a diversidade irá ajudar a criar produtos de software cada vez melhores por dois motivos:

  1. Diversidade traz novos pontos de vista. Ter um time de desenvolvimento de produtos mais diverso traz novos pontos de vista e novas maneiras de pensar, o que ajudará a desenvolver um produto melhor. Não é à toa que o time de desenvolvimento de produtos é composto de engenheiros de software, designers de experiência do usuário e gestores de produto. Cada um tem visões diferentes do que é um bom produto e essas diferenças, quando bem trabalhadas pelo time, é o que ajuda a criar um produto melhor.
     
  2. Da mesma forma que o grupo de clientes que usa o seu software é diverso, seu time também deveria ser. Normalmente os times de desenvolvimento de produto de software é composto em sua maioria por homens, só que a população do Brasil é mais diversa. Tanto na ContaAzul como na Locaweb, mais 88% do time é composto de homens. Para ilustrar melhor esse ponto, imagine um produto tipicamente feminino, por exemplo, um vestido de festa sendo desenvolvido por um time só de homens. Ficará enviesado, com características mais importantes para os homens sendo mais trabalhadas no vestido. Agora imagine se fosse desenvolvido por um time só de mulheres. Também ficaria enviesado, com apenas o ponto de vista de mulheres. Até mesmo produtos que serão usados por um público menos diverso, como nesse exemplo de um produto feito para o público feminino, se beneficiará de ter um time composto de mulheres e homens.

diversidade_brasil

diversidade_lw

diversidade_ca

Por isso é tão importante para o sucesso do seu produto refletir e conversar sobre o assunto diversidade. Só assim você poderá pensar em questões tão essenciais para o sucesso do seu produto. Como melhorar a diversidade do seu time de desenvolvimento de produto? Como fomentar discussões que trazem diferentes pontos de vista e ajudam a enxergar sob novos ângulos o seu produto e os problemas que ele ajudam a resolver?

Data science, machine learning e gestão de produtos

Nos últimos anos tem aparecido de forma recorrente e abundante os termos data science, machine learning e artificial inteligence. Esses termos são bastante importantes para os gestores de produtos. Não é à toa que dedico 5 capítulos do livro de Gestão de Produtos a assuntos relacionados a dados e métricas.

ds_ml

Como comentei nesse artigo, o gestor de produtos deve ser um data geek, ou seja, uma pessoa que está sempre pensando em como aprender mais com dados. Qual é o comportamento de uma pessoa nos meses e dias antes de cancelar a assinatura de seu produto? E o comportamento de uma pessoa que faz upgrade? Qual é o comportamento de um usuário que se diz satisfeito com seu produto? E do que se diz muito satisfeito? Se seu produto tem várias funcionalidades, qual é a mais popular? Qual gera maior satisfação? Qual é o padrão de uso típico de seu produto? Se aparecer um padrão de uso atípico, o que isso quer dizer? Esses são exemplos de algumas perguntas que o gestor de produtos pode fazer e que terão suas respostas nas métricas do produto. E a cada nova resposta obtida é muito provável que o gestor de produtos vai querer fazer mais perguntas.

Para achar as respostas às suas perguntas, é importante que o gestor de produtos conheça técnicas de data science e saiba como extrair ele mesmo as respostas para suas perguntas, quer seja por meio de ferramentas de extração e visualização de dados, quer seja rodando queries de SQL na base de dados do produto. Se o gestor de produtos não tiver essa independência, e precisar que outras pessoas extraiam os dados para ele, isso poderá atrapalhar a evolução do produto.

À medida que esse aprendizado a partir dos dados for acontecendo, é provável que o gestor de produtos comece a perceber oportunidades para inserir esses aprendizados dentro do produto. Por exemplo, um gestor de produtos de um software de CRM pode perceber, após fazer análises com dados de uso e engajamento do produto, que clientes acabam cancelando menos quando estão utilizando a funcionalidade de geração de propostas comerciais. Uma vez feita essa descoberta, ele pode promover uma mudança em seu produto para tornar mais fácil e imediato o uso dessa funcionalidade e, com isso, diminuir o churn de clientes por deixá-los mais engajados. Essa é uma forma de inserir data science em seu produto.

Machine learning, que nada mais é que uma forma de implementação de artificial inteligence, é quando programamos as máquinas para aprenderem com os dados e, quanto mais dados a máquina tiver em suas mãos, mais ela vai aprender. É uma maneira de inserir data science no produto para torná-lo melhor. Quanto mais você usa um determinado produto, mais dados estão à disposição do time que desenvolve o produto para conhecer seu usuário e como ele usa esse produto. Por exemplo, quanto mais compras você faz em uma loja virtual, mais ela aprende sobre seus hábitos de compra e mais fácil fica para o software da loja fazer recomendações que lhe interessem. O mesmo acontece com as sugestões do Netflix e do Spotify. Nesses casos é comum a loja comparar seu uso com o uso de pessoas que mostram comportamento similar para fazer sugestões do tipo “quem comprou esse item também comprou esses outros itens”.

É por isso que o gestor de produtos e todo o time que desenvolve o produto deve conhecer e saber usar data science, machine learning e artificial inteligence no seu dia a dia. São ferramentas poderosas para o ajudar a aumentar as chances de construir um produto de sucesso.

Saiu a edição atualizada do livro Gestão de Produtos

Essa semana ficou pronta a edição atualizada do meu livro Gestão de Produtos: como aumentar as chances de sucesso do seu software! \o/

gestao_produtos_linkedin_atualizada

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

A primeira edição deste livro é razoavelmente recente, publicada em outubro de 2015. De lá para cá, são “só” 22 meses. Mesmo assim, senti a necessidade de atualizar o livro, pois continuei aprendendo muita coisa sobre gestão e desenvolvimento de produtos de softwares. Tenho publicado esses aprendizados aqui no blog Guia da Startup, mas senti a necessidade de incorporá-los ao livro para deixá-lo mais completo.

Nesse changelog, registrarei o que mudou desde a edição anterior. Assim, se você já leu o livro, pode ir direto para os novos textos!

  • Ao longo de todo o livro, inclui mais exemplos, tanto da Locaweb como da ContaAzul, para ajudar a ilustrar os conceitos abordados no livro.
     
  • Coloquei uma sessão nova no capítulo Gestor de produtos ou Product Owner?, explicando as diferenças entre BA (Business Analyst), PO (Product Owner) e PM (Product Manager). São papéis similares, mas com aumento de responsabilidades.
     
  • Adicionei um capítulo sobre como gerir gestores de produtos. Nem sempre um bom gestor de produtos se torna um bom gestor de gestores de produtos. Esse capítulo explica o que devem ser os objetivos de um gestor de gestores de produtos.
     
  • Na fase de Inovação, no capítulo Muitas oportunidades, inclui uma seção sobre uma pergunta que ouço com frequência: devo perseguir novas oportunidades, ou é melhor focar o time em implementar melhorias no produto existente?
     
  • Também na fase de Inovação, no capítulo Como obter retorno com seu produto de software, inclui mais uma opção de obter receita paga por alguém interessado em seu software: a venda de serviços de terceiros aos seus usuários.
     
  • Na fase de Crescimento, no capítulo O que é um roadmap?, inclui um seção intitulada OKRs, o futuro dos roadmaps, onde falo sobre OKRs (Objective and Key Results), framework usado por várias empresas (como LinkedIn, Google, Amazon, dentre outras) para ajudar na gestão das iniciativas da empresa como um todo e que são um ótimo complemento aos roadmaps.
     
  • Na fase de Crescimento, no capítulo Como priorizar o roadmap, inclui mais duas técnicas que aprendi recentemente: o Sequenciador de features, criado pelo Paulo Caroli, da ThoughtWorks; e o RICE, método de priorização adotado pelo time de desenvolvimento de produtos da ContaAzul.
     
  • Também na fase de Crescimento, inclui uma seção ao capítulo Crescimento: engajamento e churn intitulada Data science, machine learning e gestão de produtos. Nela explico os conceitos de data science e machine learning, e a sua importância para o sucesso do seu produto de software.
     
  • Inclui o capítulo O que é e como criar a visão e a estratégia do produto? no final da fase de Crescimento. Nele explico o que é e para que serve a visão e a estratégia do produto, ferramentas úteis para as tomadas de decisão sobre qual será o futuro do seu produto. Neste capítulo, apresento algumas técnicas e ferramentas para ajudar na criação da visão e na elaboração da estratégia de seu produto de software.
     
  • No capítulo Engenharia de produtos e gestão de produtos, incluí a seção Não dá mais, precisa reescrever tudo…, falando sobre reescrita de sistemas ou de parte de sistemas. Qualquer pessoa que trabalha com desenvolvimento de software vai se deparar com o momento em que surgirá a discussão da necessidade de reescrita. Qual o papel do gestor de produtos nessa discussão?
     
  • No capítulo Organizando para o foco e para a diversificação, inclui alguns parágrafos nos quais conto sobre as motivações que fizeram o time da Locaweb a não ter times separados de QA e de front-end, e sobre a razão de eu não ter mencionado BAs no capítulo sobre organização de times.
     
  • Inclui o capítulo Como quadruplicar a produtividade na Parte 4 do livro, no qual mostro como quadruplicamos a produtividade do time de desenvolvimento de produtos da Locaweb, sem aumentar a quantidade de pessoas no time e com impacto positivo na qualidade.
     
  • Inclui um capítulo na Parte 5 do livro, intitulado E se pararmos de tratar desenvolvimento de software como projeto?, em que proponho deixarmos de chamar desenvolvimento de software de projeto e passarmos a tratá-lo como produto.
     
  • Na conclusão, inclui uma seção intitulada O que é preciso para ser um bom gestor de produtos de software? para responder essa pergunta que me fizeram algumas vezes.

Relembrando, quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

Não dá mais, tem que reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão com 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.

Na Locaweb tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de email marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que a base de dados crescia, o sistema ficava cada vez mais lento. Por isso foi necessário reescrever o produto para usar PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes, ou seja, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000 clientes) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho. Contudo, durante esses seis meses o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado no reescrita. Se essa opção não existisse, teríamos que encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrever software, o time deixa de fazer coisas novas para o usuário do software, como mostrei acima no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso eu gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores irão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (_model_, _view_, _controller_) separando o código do software em camadas de acordo com sua função. Mais recentemente foi criado o conceito de microserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs, facilitando a manutenção. Se, a cada nova tecnologia que aparecer, formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
     
  • Reescrever software tem que ter uma motivação clara de negócio, ou seja, deve de alguma forma atender os objetivos estratégicos da empresa que é dona do software e deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
     
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, ou seja, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a co-existência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicado?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Novas oportunidades vs melhorias no produto existente

    Essa é uma dúvida bastante frequente. Devo perseguir novas oportunidades? E o que faço com as dores dos clientes atuais? Devo desenvolver um novo produto ou uma nova funcionalidade? Ou devo resolver dores dos clientes atuais desenvolvendo melhorias em meu produto? Como fazer para balancear entre perseguir novas oportunidades e implementar melhorias no produto existente?

    melhorias-ou-oportunidades

    Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem que ser tratada de um jeito. O ideal é que sejam tratadas até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time tem que saber separar claramente o trabalho no produto existente vs o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente, uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Atenção: não é time de bugs

    Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times. Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.

    Oportunidades vs melhorias

    Antes de investir em uma nova oportunidade é muito importante entender porque está se investindo nessa nova oportunidade. Uma ótima ferramenta para isso é a análise de oportunidades. Sem um claro entendimento e correto engajamento de todos os envolvidos pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.

    Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, ou seja, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software. Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produtos dedicadas a essa nova oportunidade. Essa nova oportunidade irá ser um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento irá cuidar de seus bugs e melhorias.

    Enquanto isso, o outro time cuida do produto atual, ou seja, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.

    Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Como saber se é uma melhoria ou uma nova oportunidade?

    É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?

    Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui-la. Lembre-se que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para perseguir essa nova oportunidade. Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para manter esse algo? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.