Eis o Segundo Cérebro Um manual de referência sobre Gestão e Liderança de Produtos Digitais

Contextualizando melhor a questão de produtos versus projetos

Projeto não é produto. Mas o processo de monitorar e avançar com projetos está contido dentro do processo de produto em muitas formas.

De acordo com o Cambridge Dictionary[1], se traduzirmos a definição da palavra "projeto", temos:

É um trabalho planejado ou uma atividade que é finalizada em um período que pretende atingir uma proposta particular.

Isso quer dizer que você pode fazer um projeto tanto para construir um prédio quanto um software. Para deixar mais tangível, geralmente um projeto tem três pontos cruciais:

  • Escopo: O escopo é tudo o que o projeto contempla. É o que deveria ser entregue ao final do deadline;
  • Deadline: O deadline é a data limite de finalização do projeto;
  • Budget: O budget é o limite financeiro para a execução desse projeto.

Quando vamos fazer uma obra ou construir um novo modelo de carro, é importante nos atermos ao escopo definido, nos planejarmos para não estourarmos o deadline e, principalmente, manter o budget sob controle. Em projetos desse tipo, há um começo, um meio e um fim bem definidos. Você sabe quando um prédio fica pronto e também sabe quando um carro fica pronto. Mas, se levarmos isso para o mundo do software, a coisa fica mais complexa. Por quê?

Causalidade

Como seres humanos, nós acreditamos que as coisas sairão como planejamos, pois entendemos que podemos prever o que acontecerá no futuro com base em eventos que acontecem no presente ou que já aconteceram. E isso realmente faz sentido. A ciência funciona com base na causalidade como uma das regras para prever quais serão os próximos fenômenos, levando em consideração eventos e comportamentos passados da natureza. É assim que preveem tão corretamente quando o cometa Halley vai passar para dar um “Olá” ou qual será o próximo eclipse.

Em desenvolvimento de software, isso também pode ser real. As equipes escrevem e mudam seus códigos porque entendem bem o ambiente em que o software ficará hospedado e sabem a quais processos e mecanismos esse código será submetido. A causalidade nos diz claramente o que poderá acontecer futuramente com base em coisas que aconteceram antes. Você sabe que algo pode dar certo ou errado porque você já experimentou ou porque aprendeu com a experiência de outra pessoa.

Mas nem sempre podemos contar com a precisão da causalidade. Por exemplo: mesmo sabendo o histórico de rendimentos da bolsa, nós não conseguimos prever quando ou de quanto será a próxima onda de alta (ou quando virá um Coronavírus). Mesmo sabendo os possíveis eventos que podem ocasionar a alta, você não tem como saber quando esses eventos acontecerão. É quase imprevisível. Várias crises já foram previstas, mas ninguém pode provar que uma crise realmente acontecerá, até acontecer.

Se você tem um produto, você não consegue prever quantos usuários passarão a usá-lo a partir do momento de publicação. Embora você e o time de Research tenham feito testes com usuários reais, a amostra sempre será muito pequena para saber se as pessoas usarão seu produto como o planejado. Mesmo com base em métricas e experiências de outras empresas e times de produto, não conseguimos saber com exatidão o que poderá vir a acontecer.

Ambiente complexo

Ao construir um software (e, sim, seu produto é um pedaço de software), estamos atuando em um ambiente complexo. As pessoas usam as palavras complicado e complexo como se fossem a mesma coisa, mas não são.

You’ve successfully subscribed to diegoeis.com
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.