[quote=felipefranz][quote=Daniel_MV][quote=felipefranz]Escopo e aberto são antônimos agora preço fechado é algo que deveria ocorrer.
Você compra um carro sem saber o preço que vai pagar nele? Porque num projeto tem que ser diferente? Se o cliente solicitou X, e não pedir X+1 ele deveria saber o quanto deve pagar para ter X, sem quaisquer tipos de problemas. A questão é que a área de softwares é relativamente nova e ainda não temos processos muito bem definidos, toda hora surgem novos, assim como acontecia com engenharia de produção há tempos e além disto temos pouca automatização e ferramental muito fraco ainda. O trabalho braçal na área de softwares ainda é algo absurdo, aí colocamos a desculpa que a área é diferente e por isso temos que entregar primeiro uma roda para o cliente ver se é isso mesmo, depois o capô e assim vai até finalizar o frankstein.[/quote]
Desculpe mas a comparação não tem cabimento, primeiro pq carro é um produto e projetos de software, bem, como o próprio nome sugere, são projetos.
Mesmo em projetos de engenharia ou outras áreas com mais maturidade, as mudanças ocorrem, querer definições 100% precisas em projetos de software com a área do jeito que está (em relação a tudo, metodologias, profissionais, exigências, etc…) é uma tremenda ilusão, é necessário certo pragmatismo. Não é besteira afirmar que nesse universo, escopo não existe.
[/quote]
Claro que ocorrem, mas são controladas. O desenvolvimento de um carro é considerado um projeto, assim como qualquer evolução dele, o ciclo de vida de um produto está associado ao ciclo de vida de um projeto.
Se não existe escopo, não existe projeto, você está fazendo uma operação ou processo. Isto vem do próprio conceito de projetos. Não tem como desenvolver um software sem saber os requisitos dele, e grande parte dos problemas nas entregas está totalmente relacionada a má definição dos requisitos, que são transformadas no escopo do projeto. Pragmatismo é uma coisa, má gestão é outra. As pessoas confundem muito isto, como tu vai desenvolver algo que não sabe o que é?[/quote]
Claro que existe, só que pode mudar muita coisa durante o desenvolvimento do projeto e isso é normal. O que não é normal é não definir nem planejar nada e deixar o projeto nadar aos gostos do cliente sem um gerenciamento adequado. Muita gente confunde que utilizando metodologias ágeis você não precisa planejar escopo nem tempo nem custos, mas é o contrário. Elas são uma forma dinâmica de gerenciar o projeto.
Metodologias incrementais não impedem que haja mudança, só facilitam o gerenciamento delas. No seu caso, mesmo que o escopo não tenha sido bem definido no começo e por causa disso o cliente tenha ficado meio perdido pedindo coisas sem parar, é uma ótima oportunidade de você aplicar conhecimentos em gestão e metodologias ágeis, definindo entregas incrementais pra você conseguir que o cliente compreenda o custo delas e junto com você e a equipe montar um fluxo de trabalho.
O PMBok cita que as únicas duas certezas em um projeto são que vai haver mudanças e que vai haver conflitos. hehehe[/quote]
Claro que existe escopo ehehhe, é necessário um ponto de partida, eu apenas generalizei dizendo que esse tal de escopo que gerentes de projeto adoram arrotar por ai, escopo fechado, sem alterações, etc…isso é lenda.
Sua primeira frase MarcosAlex, já soa meio contraditória: “Claro que existe, só que pode mudar muita coisa durante o desenvolvimento do projeto e isso é normal.”
Ou seja, será que ainda estamos falando de escopo? Melhor dizendo, será que o escopo inicial ainda é válido?
Claro que são perguntas que dependem de muitos fatores, depende da rigidez com que se enxerga o escopo, depende da abordagem, da política tanto da fornecedora quanto do cliente, etc…
Mas é fato, não adianta renegar as alterações, elas virão por bem ou por mal, o bom é sempre negociar no ganha ganha.