Projetos sempre existiram e existirão sempre. Nem tudo é feito de tecnologia e por isso tem uma maneira de gerir diferente. De acordo com o Cambridge Dictionary, a definição da palavra projeto é:
"a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose."
Isso quer dizer que você pode fazer um projeto para construir um prédio ou um software. Para deixar mais tangível, geralmente um projeto tem 3 pontos cruciais:
1. Escopo. O escopo é tudo o que o projeto contempla. É o que deveria ser entregue ao final do Deadline;
2. Deadline. O deadline é a data limite de finalização do projeto;
3. Budget. Já o budget é o limite financeiro para a execução deste 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 projeto desse tipo, é sabido que 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 de software, a coisa fica mais complexa. Mas por que?
Causalidade
Como seres humanos, nós acreditamos que as coisas sairão como planejamos, pois entendemos que podemos prever o que irá acontecer no futuro se baseando em eventos que aconteceram no presente e no passado. E isso realmente faz sentido. Uma parte muito pequena da ciência funciona baseada na causalidade como uma das regra para prever quais serão os próximos eventos e fenômenos se baseando em eventos e comportamentos passados da natureza. É assim que preveem tão corretamente quando o cometa Halley irá 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 quais os processos e mecanismos que esse código será submetido. Causalidade nos diz claramente o que poderá acontecer futuramente se baseando 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.
Se você tem um produto, você não consegue prever quantos usuários passarão a usar seu produto a partir do momento de publicação. Embora você e o time de Research tenham feito testes com usuários reais, a amostra é muito pequena para saber se as pessoas usarão seu produto como o planejado. Engraçado como mesmo tendo 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. E é aí que entendemos que a coisa é mais complexa do que imaginávamos.
