Acho que você chegou a um ponto super importante e que nunca deve ser esquecido: Como associar os benefícios de desenvolver usando “melhores práticas”, ao retorno para quem não conhece o que são “melhores práticas”.

Não adianta pedir, implorar e até mostar o é bom, se isso não estiver associado a retorno para a área/empresa.

Com a crise muitas, e eu conheço muitas assim, concentraram seus esforços em dois tipos de projetos: Os que aumentam ou lucros, e os que reduzem os gastos. Simples assim. Não importa o que o projeto faz ou como é feito. Temos que provar que alcançaremos um dos dois objetivos usando boas práticas de desenvolvimento e trabalhando bem.

Parece fácil, mas é um desafio imenso uma vez que quem assina o cheque, muitas vezes, “fala” uma língua diferente.

Quem souber ser um bom comunicador será bem sucedido. Ou pelo menos terá mais chances Esse é o nosso desafio.

Abs.

Recentemente, e de alguma forma três de nós (comentaristas), estivemos envolvidos com um projeto de escopo “bem fechado”, e que apesar disso variou tanto durante o seu desenvolvimento que está beirando aos 2 anos de prazo de entrega…

Mais recentemente, recebemos a incumbência de uma aplicação extremamente simples (upload de imagens para um site corporativo).

Deveria ser uma aplicação cujo protótipo estaria pronto em menos de um mês, mas foram necessários 4 (quatro) para que tivessemos um protótipo totalmente funcional, sendo que numa plataforma de armazenamento diferente da do projeto final.

Motivos? – O usuário define a plataforma. Os recursos envolvidos (originalmente 3 agora apenas 1) não podem dar foco na aplicação, pois são constantemente envolvidos em outros projetos e atividades que não são fim (acredito que nem servem de meio, tipo preencher formulários burocráticos, criar “documentação exigida” na base da “engenharia reversa” do que já foi implementado, calcular pontos de função!).

É como diz o poeta: “assim caminha a humanidade, com passos de formiga e sem vontade”.

Mas, deixa pra lá, se tudo der certo, daqui mais uns 2 ou 3, ou 4 meses essa aplicação está em produção, e podemos começar tudo novamente.

No twitter poderiamos categorizar: Projeto #FAIL

E quando da M é que a adrenalina sobe, os arquitetos aparecem, e os outros rezam! hehehehe
Concordo contigo que não da pra pagar as contas sonhando com o ótimo.
O bom ou até mesmo o regular é que acaba pagando. Fazer o que.
Mas é sempre bom ter o ótimo como meta, mesmo que um pouco distante as vezes

Concordo em parte contigo, até porque também ganho dinheiro realizando a idéia dos outros. Mas vamos combinar que é muito complicado para um cliente, fechar a contratação de um trabalho, onde ele não sabe quanto vai custar e nem quando vai terminar.

Infelizmente, com estas dúvidas já fechei projetos (desenvolvimento de sistemas) onde com certeza tive prejuízo, mas também já tive lucro, acho que o negócio é entrar no sistema, vender com uma margem boa, porque no final das contas vai dar M.

[]s,

O cliente conhece seu próprio negócio, mas não conhece o software que será feito pra apoiar o negócio.
Até pq ele não existe ainda.
Por isso o mais aconselhável é desenvolver de forma iterativa.
Assim ambos, cliente e fornecedor, vão aprendendo juntos a criar o software.
Quando o custo, o prazo e o escopo são fechados, trabalhar de forma iterativa se torna impossível.
Seria “conversa pra boi dormir” se eu fechasse o custo, o prazo e o escopo previamente e mesmo assim dissesse que o projeto vai ser conduzido de forma iterativa.
Por incrível que pareça, isso acontece muito.
São os famosos projetos com tudo fechado previamente, mas que sofrem change requests a todo momento.

Pensei em postar um comentário para cada observação, mas como já é o final do dia eu estou muito cansado para tal. Por enquanto irei comentar uma parte apenas:

“…O cliente não tem muitos detalhes do que vai solucionar o problema dele…”

Se tem alguem que conhece o negócio e o problema citado é o cliente. Nunca ache que o cliente não conhece seu próprio negócio, se não o conhecesse ele (empresa/área) não existiria, ou pelo menos já teria outro gerente.

E se o problema for entender o negócio, não deve ser a metodologia de gerência de projetos a solucionar o problema.

Por hora,

[]’s

Uma simples comunicação com a API de um gerenciador de conteúdo.