No mundo do software, o conceito de "projeto" já me traz lembranças de algumas experiências.

Projeto tem começo meio e fim.

Projetos que chegaram pra mim onde eu fazia entregava e sumia são ok. Parecem construção de casa, ou uma reforma. O cliente pede uma raquinagen pontual, fica feliz e some.

Projetos dentro de uma empresa, com times separados pela hierarquia que conhecemos hoje, com gestores, pmo, time de produtos, devs, infra, dba. Esses são uma merda, ineficiência mascarada por faturamento alto.

Esse formato transforma desenvolvedor em "coding monkeys" ou "organismo que transforma café em código".

Ainda sonho em poder trabalhar em algum cenário onde aceitam a lei de Conway e aplicam Team Topologies. Trabalhei um período em um formato parecido e foi uma experiência muito boa. Como sempre, a gestão incompetente estragou tudo no final.

Software tende a ser vivo, que muda com o tempo, tratar como projeto não aceito como melhor opção na maioria dos casos.

Alguém postou aqui no tabnews anúncio de vaga da Embraer disfarçada de texto técnico.

Aquele cenário acredito que pede projeto. Uma vez entregue, com maestria, não tem evolução, no máximo correção de bugs. Qualquer melhoria, pede um projeto novo, ao invés de modificar o existente com puxadinhos como acontece na maioria das firmas.

O cenário que seu texto descreve, é de projeto com task bem definida vs projeto zoneado.

Na minha experiência, projetizar desenvolvimento de software é uma triste herança do modelo industrial, e não é a solução mais eficiente na maioria dos casos.