Quando programadores ou analistas constroem a sua interpretação de resolução, surge a máxima: o cliente não sabe o que quer.
Mais do que problemas de comunicação e interpretação, o fato de que um problemas pode ser resolvido de N maneiras faz com que as decisões sejam direcionadas a quem tem mais poder e não necessariamente a quem tem mais técnica. Se eu pedi e paguei eu sei o que é melhor. Se eu estou fazendo eu decido o que é melhor. Não quero esquecer que, em grande parte, desenvolvimentos são contratados no modelo de prestação de serviços e o cliente passa a enxergar o mesmo como um serviço contínuo e evolutivo e não como um produto. Tal possibilidade induz muitos desenvolvedores a buscarem táticas de previsão de problemas e acontecimentos que não foram solicitadas pelo cliente, mas que seriam cobradas como erro e não como definição mal estruturada.
Este pressuposto, no entanto, induz ao pensamento de que há uma forma eficaz de se definir um modelo eficazmente. E há: resolvendo apenas problemas que existem agora.
Modelos fabris partem da premissa de que é possível prever o comportamento do maquinário, do ser humano em função do maquinário e da variação comportamental decorrente de alguma surpresa no ambiente. Tal modelo é facilmente vistos em simulações em que por mais que hajam variáveis, as mesmas são previsíveis.
Como prever o comportamento de uma idea ou de uma esperança? Se o cliente espera que um sistema hoje faça A, pode perfeitamente querer que faça B em função de uma nova experiência adquirida ou promovida. O que não invalida a veracidade da necessidade do mesmo. Porém, ao longo dos anos, eu pessoalmente, descobri que não é possível o desenvolvimento baseado na esperança ou em idéias insólitas. É preciso apenas e simplesmente desenvolver por fatos.
Ainda assim não há subsídio para a "serialização" do desenvolvimento. Uma vez que o conjunto resultante é orientado a questões individuais e únicas, mesmo que para resolver problemas comuns.
Hoje entendo que há uma série de bons métodos, mas que estes estão limitados a sua contemporaneidade (palavra difícil), ou seja, foram criados para solucionar questões de um dado tempo tecnológico. Mas estamos em constante evolução e nem sempre as metodologias acompanham. O surgimento de novos frameworks de alta produtividade nos fazem rever conceitos de engessamento de escopo, iterações com clientes, mais tempo de dedicação a estudo e menos tempo desenvolvendo.
Nenhuma receita mágica ou fórmula fundamentalista será capaz de resolver todos os problemas. Assim como a indústria teve seu tempo, surge o momento da Tecnologia da Informação adaptar-se a incorporar-se ao ambiente tecendo suas diretrizes enquanto indústria. E rever conceitos é a "única rotina" que deveria ser aceitável em desenvolvimento de software.
Hoje na era da informação, vivemos em constante mudança. As profissões que teremos daqui 10 anos nem devem existir hoje em dia e as necessidades futuras não aão as mesmas de hoje.
Paula Nascimento, CSM, membro Equipe Desenvolvimento, GPE Ltda	no 08 de junho de 2012 a partir do 10:38 hrs.	
Achei bastante interessante o seu post porque acredito mesmo que ainda existe essa ideia de que o ideal é trazer o modo de desenvolvimento fabril para a TI. Mas o fato de projetos de software serem bastante suscetíveis a mudanças impede que sistemas desenvolvidos dessa forma aconteçam do modo como foram planejados no início do desenvolvimento. Acredito que em alguns casos esse modelo se encaixa perfeitamente, mas, para a maioria, a melhor forma de desenvolver um software é ir criando junto com o cliente, passo a passo, o que ele deseja. E não deixar nunca de ser aberto a mudanças. Isso apenas mostra que o produto está sendo usado, é bem visto pelo cliente e novas necessidades estão surgindo.