Como lidar com cliente que exige muitas mudanças no projeto

Na empresa onde eu trabalho, há toda uma documentação para definir o Scopo da aplicação.

Nessa documentação há a definição e detalhamento de todos os casos de uso do sistema e seus respectivos protótipos de tela, desenhados, não implementados.

Após a aprovação da documentação do sistema por parte do cliente, não há alteração, quaisquer alterações são cobradas a parte como Melhorias.

A documentação de um sistema é o contrato entre vc e seu cliente.

Olá,

Este problema é bastante comum, conhecido na área como scope creep.

As causas normalmente estão relacionadas a requisitos mal definidos ou falta de um fluxo para solicitação de mudanças. Toda mudança solicitada deveria passar por um rigoroso controle de impacto, pois toda alteração de escopo tem alteração nos custos e no prazo, invariavelmente.

Ele pediu algo a mais? Sem problemas, mas o projeto atrasará um pouco e será cobrado mais caro. Se ele falar que está no escopo inicial e você achar o contrário, refere-se ao primeiro problema, requisitos mal definidos, aí é mais complicado porque o que começa mal tende a terminar mal, mas uma saída é fazer uma reunião e elicitar bem os requisitos, o escopo e principalmente o que não entra no escopo e você acha que ele pode pedir.

igor_henrique:

Na empresa onde eu trabalho, há toda uma documentação para definir o Scopo da aplicação.

Nessa documentação há a definição e detalhamento de todos os casos de uso do sistema e seus respectivos protótipos de tela, desenhados, não implementados.

Após a aprovação da documentação do sistema por parte do cliente, não há alteração, quaisquer alterações são cobradas a parte como Melhorias.

A documentação de um sistema é o contrato entre vc e seu cliente.

É isso mesmo.
Um produto entregue pela empresa server como referência as outras, mesmo que cobre valores bem altos referentes as melhorias, acaba por postergar uma versão do sistema e consequentemente, pode perder a oportunidade de agregar novos clientes. Sendo assim, dependendo a situação, vocês podem perder muito mais que tempo.

O correto é chamar o cliente para uma conversa formal, sentar, definir o escopo do projeto e o que vai ou não ter e definir a data de entrega. Isso tudo em contrato assinado por todas as partes envolvidas, dessa forma, quando o cliente solicitar algo, aquilo será cobrado á parte e somente após a entrega do projeto que foi definido em contrato e nada mais do que isso! Já passei por essa experiência e somente isso resolveu.

Entenda, nós gostariamos que o nosso Sistema Operacional tivesse mais isso, mais aquilo, que o brownser x tivesse uma funcionalidade extra, que a rede social y tivesse mais isso ou aquilo também, enfim, clientes são clientes mas não podemos antende-los sempre, pois nesse caso, ele vai pedindo e vocês fazendo, fazendo, e o clico vai levar muito, mas muito tempo para se encerrar , isso, se encerrar

rsrsrs … acho que isso é um anti-pattern já … escopo aberto e preço fechado. Particularmente, acho que tentar documentar tudo no começo do projeto e enrigecer mudanças é uma abordagem defensiva demais. Fatalmente algo não vai sair como esperado, e mesmo que a empresa não assuma o prejuízo, o cliente não vai ter o retorno esperado, o que não é bom.

Particularmente, não vejo melhor alternativa do que entregas iterativas. Você entrega o que foi combinado, e se o cara quer mudar alguma coisa ele espera a próxima iteração, e o cliente vai pagando por iteração. Quando ele entender que ele precisa priorizar o que vai ser entregue em cada iteração, pode ter certeza que ele vai pensar 2x no que vai ou não vai para a implementação e vai tentar ser mais claro nas exigências.

Em termos de sistema, se a toda hora pedem para incluir/excluir campos de relatórios, talvez seja o caso de criar um cadastro de relatórios e treinar o pessoal no iReport. Ou então, fazer um editor de relatórios simplificado, em forma de wizard por exemplo, e deixar para implementar somente os relatórios mais complicados.

rmendes08:

rsrsrs … acho que isso é um anti-pattern já … escopo aberto e preço fechado. Particularmente, acho que tentar documentar tudo no começo do projeto e enrigecer mudanças é uma abordagem defensiva demais. Fatalmente algo não vai sair como esperado, e mesmo que a empresa não assuma o prejuízo, o cliente não vai ter o retorno esperado, o que não é bom.

Particularmente, não vejo melhor alternativa do que entregas iterativas. Você entrega o que foi combinado, e se o cara quer mudar alguma coisa ele espera a próxima iteração, e o cliente vai pagando por iteração. Quando ele entender que ele precisa priorizar o que vai ser entregue em cada iteração, pode ter certeza que ele vai pensar 2x no que vai ou não vai para a implementação e vai tentar ser mais claro nas exigências.

Em termos de sistema, se a toda hora pedem para incluir/excluir campos de relatórios, talvez seja o caso de criar um cadastro de relatórios e treinar o pessoal no iReport. Ou então, fazer um editor de relatórios simplificado, em forma de wizard por exemplo, e deixar para implementar somente os relatórios mais complicados.

Mas o problema é que se não tiver documentado no começo, como provar que entendimento do cliente do escopo do projeto já não está incluso este novo pedido?

E como saber como isso vai impactar no projeto e em relação a múltiplos projetos com uma resource pool comprometida. Scrum é uma metodologia boa em determinadas situações, mas poucos clientes sentem-se confortáveis em iniciar um projeto sem os requisitos bem explicitados, que é o ponto forte do Scrum.

E a maior parte das empresas levam tornam a palavra ágil apenas uma desculpa para dizer que utilizam uma metodologia e não precisam se preocupar com o processo, é uma legitimação do caos.

Todas as empresas precisam se preocupar com pessoas, tecnologia e processos. O problema é quando as pessoas tem que compensar a deficiência das outras duas variáveis.

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.

Infelizmente a saída é sentar com o cliente mostrar o escopo inicial, revero que está errado e pedir para ele escolher qual das alteracões é mais importante para que seja executada dentro do prazo dado.

Não adianta empurrar com a barriga, sistemas desenvolvidos com muitas mudancas de requisito tendem a piorar ao ponto de virar um emaranhado de código que não serve pra nada. Tente fazer algo do tipo mas saiba escolher bem as palavras, ele pode até não gostar, mas com certeza vai entender.

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.

Depende. Se você chegar na concessionária e pedir um carro do modelo X, com opcionais 1 e 2 é fácil ter esse preço. Uma coisa bem diferente é pedir um carro que ainda não existe e saber quanto vai custar, e a maioria dos projetos de software entram nessa categoria.

Quando não se conhece o que vai ser feito, o máximo que se pode ter é uma estimativa, que pode ser mais ou menos assertiva, mas ainda assim é uma estimativa.

Com relação a processos, é impossível definir um processo que seja válido em todo lugar. A grande falácia do waterfall é essa. O melhor que podemos ter é um conjunto de ferramentas conceituais que possam ajudar a definir um processo. Isso é bem diferente.

Com relação a automação. Bem, na minha opinião, não automatiza quem não quer. Existem IDE muito boas, frameworks para automação de diversos tipos de testes (unitários, BD, GUI, aceitação) e automação de build. O que eu acho que não pega de jeito nenhum são geradores de código, já trabalhei com o tal do Genexus e particularmente, acho o resultado final muito ruim. Porém, também não acho que programador tenha que ficar fazendo o mesmo CRUD centenas de vezes no sistema. Um gerador de CRUD baseado em metadados não constuma sair muito caro.

Com relação ao projeto ser frankstein, não é porque as entregas são iterativas que a equipe tenha que abrir mão de projetar arquitetura. Aqui onde trabalho, temos um produto fechado, é o mesmo para quase todos os clientes, mas eles podem escolher os módulos que querem separadamente. O sistema sofre customizações quase todo dia, mas a arquitetura é a mesma há anos. Ou seja, para se ter uma boa arquitetura não é preciso conhecer todos os requisitos do sistema, apenas os mais relevantes. Essa abordagem não é exclusiva do Scrum, nem foi inventada pelo Agile. Isso vem lá do RUP.

Nossa, não sabia a pergunta ia gerar tantos comentarios, obrigado a todos por ajudarem

mas o problema é que a empresa aqui possui pouca documentação sobre o sistema que será gerado, possuo a documentação com os requisitos do cliente e um diagrama do banco de dados, mas que é inclusive antigo, pois devido as modificações, toda semana praticamente ele tende a mudar.

Na empresa onde estou, não foi criado nenhum caso de uso, nenhum prototipo de tela, foi feito apenas uma estimativa de custo do projeto baseado no tempo(horas) e salário dos envolvidos.

Esses prototipos de tela por exemplo, poderiam ser paginas em HTML sem nenhuma funcionalidade implementada? ou teria algo mais facil e agil de se fazer?

Os casos de uso, eu ainda sou estagiário na empresa e ainda estou cursando essa disciplina na faculdade neste semestre, logo não tenho muita experiência prática nisso, como seria o metodo mais facil pra cria-los, algum software especifico, ou fazer a base de lápis e papel mesmo.

Fiquei interessado em um gerador de CRUD, pois o que faço aqui é praticamente recriar um tela(que executa um crud) para cada tabela do meu banco de dados e liga-las com relacionamento, tem recomendação de algum gerador de CRUD?

Dá pra fazer um gerador de CRUD in-house. O que temos aqui é o seguinte, temos tabelas de metadados, onde são cadastradas as tabelas do sistema e os campos, inclusive com os tipos dos campos e as descrições. Quando o usuário do sistema entra no cadastro, por exemplo, “Cliente”, ele lê qual é a tabela da tela, e os seus campos. Daí o sistema lê os campos da tabela e vai gerando a tela, com formulário e grade, incluindo cada campo, gerando o componente apropriado de acordo com o seu tipo. Quando o sistema é pequeno o custo pode ser alto. Mas se tiver muitas tabelas e a tendência for cresce, vale a pena.

Hoje no nosso sistema, o usuário pode inclusive gerar sua própria tela de cadastro.

Olá…
Cara eu sou novo nesses assuntos, mas na empresa onde eu trabalho sou desenvolvedor, e nós utilizamos uma métodologia bem legal e muito eficiente.
Ela se chama Desenvolvimento Ágil, e nela se utiliza muitas ferramentas e métodos que ajuda a evitar esse tipo de problema e muitos outros. Eu recomendo, até agora sempre me ajudou e o bom é que você ganha tempo e eficiência se utilizada da maneira correta.

Nossa que bagunça, não existe gerente de projetos atuando nessa empresa não?

Esse é o famoso escopo “abrir as pernas”, nunca vi dar certo, o sistema fatalmente fica uma porcaria.

Outra coisa, o cliente precisa saber o que quer. Calma, antes que me xinguem, eu sei que isso é difícil senão impossível, mas pelo menos em algum nível ele precisa ter uma definição, ficar mudando toda hora as coisas inclusive coisas que já mudaram é um ótimo sinal vermelho para alguém bater na mesa e pedir um entendimento melhor do que precisa ser feito. A consultoria tem que tomar essa iniciativa muitas vezes, o cliente tem sempre a razão é ditado de boteco, em projetos de TI não passa nem perto.

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.

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.

Concordo com os posts do rmendes08 e porra, já tá na hora de implementar multi-quote aqui no GUJ, ter que ficar quotando post a post não dá né.

rmendes08:

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.

Depende. Se você chegar na concessionária e pedir um carro do modelo X, com opcionais 1 e 2 é fácil ter esse preço. Uma coisa bem diferente é pedir um carro que ainda não existe e saber quanto vai custar, e a maioria dos projetos de software entram nessa categoria.

Quando não se conhece o que vai ser feito, o máximo que se pode ter é uma estimativa, que pode ser mais ou menos assertiva, mas ainda assim é uma estimativa.

Com relação a processos, é impossível definir um processo que seja válido em todo lugar. A grande falácia do waterfall é essa. O melhor que podemos ter é um conjunto de ferramentas conceituais que possam ajudar a definir um processo. Isso é bem diferente.

Com relação a automação. Bem, na minha opinião, não automatiza quem não quer. Existem IDE muito boas, frameworks para automação de diversos tipos de testes (unitários, BD, GUI, aceitação) e automação de build. O que eu acho que não pega de jeito nenhum são geradores de código, já trabalhei com o tal do Genexus e particularmente, acho o resultado final muito ruim. Porém, também não acho que programador tenha que ficar fazendo o mesmo CRUD centenas de vezes no sistema. Um gerador de CRUD baseado em metadados não constuma sair muito caro.

Com relação ao projeto ser frankstein, não é porque as entregas são iterativas que a equipe tenha que abrir mão de projetar arquitetura. Aqui onde trabalho, temos um produto fechado, é o mesmo para quase todos os clientes, mas eles podem escolher os módulos que querem separadamente. O sistema sofre customizações quase todo dia, mas a arquitetura é a mesma há anos. Ou seja, para se ter uma boa arquitetura não é preciso conhecer todos os requisitos do sistema, apenas os mais relevantes. Essa abordagem não é exclusiva do Scrum, nem foi inventada pelo Agile. Isso vem lá do RUP.

Por isso que atualmente se paga através de pontos de função, casos de uso, etc.

Mas essas metodologias para análise de tamanho x complexidade ainda não estão bem sedimentadas, maior parte das empresas com Scrum ainda usam um planning poker sem muitos critérios para estimar antes de entregar um valor final para o cliente. Matriz de rastreabilidade mesmo é raríssimo, no exemplo do carro, por mais que você peça um carro que ainda não existe, dificilmente ele seria implementado sem todos os seus requisitos.

A idéia não é você simplesmente adotar um processo, mas sim adaptar uma metodologia que seja válida para sua empresa embasando-se nas existentes, isto é válido tanto para elicitação de requisitos, estimativas, gerenciamento de projetos e tudo mais. Eu sou totalmente contra coisas prescritivas, tudo depende de um contexto e a cultura empresarial conta muito neste ponto.

É justamente isto que eu digo, a automação de código ainda é muito ruim, as tecnologias e frameworks são muito instáveis, mas isto vem com o tempo. Agora que estamos utilizando conceitos de Kanban e Lean, praticamente não utiliza-se MCDA, a área de qualidade e segurança ainda é um pouco insapiente, dificilmente utilizamos alguns conceitos de estatística, design for six sigma. Há muita paixão na área, quem utiliza processo iterativo normalmente repudia waterfall (se bem que esta comparação nem é tão válida posto que pode-se utilizar as duas e novamente depende do contexto).

Há poucas pessoas na área olhando para os processos e qualquer documentação é quase vista como um sacrilégio, apologia a burocracia que vai contra o conceito de ágil. Isto causa muito retrabalho, geração de bugs, falta de informação para descontinuidade de um produto/projeto e informações para a alta administração e outros.

De duas uma:

Ou o cliente esta de sacanagem, enrolando e nao quer que anda seja entregue (acreditem, eu ja vi isso). Ou voces nao estao entendendo o que ele quer (o que eh bem comum acontecer conosco).

Se for o primeiro caso, voce deve levar a situacao a quem possa resolve-la.

Se for o segundo, voce vai ter que encurtar o feedback. Fazer algo e levar pra ele avaliar, prototipos pode ser uma boa pedida, se voce conseguir algo mais que isso, (levar algo de fato implementado em um prazo curto) vai ser melhor ainda.

Daniel_MV:

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.

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.

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 é?

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

Eu já trabalhei uma vez em uma empresa que não existia analise de requisitos e muito menos escopo nos projetos…
a analise de requisitos era feita atravez de printscrem de outros 3 sistemas de mercado(detalhe estes outros 3, eram sistemas que o cliente já havia adiquirido e não lhe adiantaram para nada…)
o projeto tinha que ser entregue tal dia, chegava o cliente e mudava praticamente todo o projeto porem a data continuava a mesma e ponto final. Sorte que já estou bem longe de lá…

luistiagos:

Eu já trabalhei uma vez em uma empresa que não existia analise de requisitos e muito menos escopo nos projetos…
a analise de requisitos era feita atravez de printscrem de outros 3 sistemas de mercado(detalhe estes outros 3, eram sistemas que o cliente já havia adiquirido e não lhe adiantaram para nada…)
o projeto tinha que ser entregue tal dia, chegava o cliente e mudava praticamente todo o projeto porem a data continuava a mesma e ponto final. Sorte que já estou bem longe de lá…

Existia escopo, só não era documentado.

felipefranz:

Daniel_MV:

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.

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.

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 é?

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

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.

Se o cara é gerente de projetos e diz que o escopo é sem alterações manda ele rever a carreira.

Duvido ele achar algum embasamento em livros para esse absurdo, uma coisa é ter controle de alterações outra é se iludir e se achar o suprosumo da quinta essência assumindo que o seu planejamento inicial com poucas informações é perfeito.

marcosalex:

luistiagos:

Eu já trabalhei uma vez em uma empresa que não existia analise de requisitos e muito menos escopo nos projetos…
a analise de requisitos era feita atravez de printscrem de outros 3 sistemas de mercado(detalhe estes outros 3, eram sistemas que o cliente já havia adiquirido e não lhe adiantaram para nada…)
o projeto tinha que ser entregue tal dia, chegava o cliente e mudava praticamente todo o projeto porem a data continuava a mesma e ponto final. Sorte que já estou bem longe de lá…

Existia escopo, só não era documentado.

Então da no mesmo que não existir… Se o cliente pode a qualquer hora alterar ele e não existe documentação e nem aumento de prazo muito menos era cobrado a mais do cliente para simplesmente alterar o projeto todo quando ele bem entender.

Toda alteração após o fechamento do escopo, pode ser definida como uma funcionalidade a parte para ser desenvolvida em breve?

Fechou o escopo, fechou o projeto.

Qualquer alteração depois deve ser tratada como novo projeto ou operação, isto vai depender dos critérios utilizados e do overhead de gestão aceito.