Como lidar com projetos de programação que falham?

Não é incomum que projetos falhem.

Como programador, como você lida com projetos que falham?

Algumas definições de falha:

• Perde o prazo.
• Código e funcionalidade não fazem o que deveriam.
• O software se torna um vaporizador ou um número infinito de fases, essencialmente não entregues.

Ou talvez você tenha suas próprias definições de falha.

Você começa a apontar os dedos? Você se culpa, os requisitos, a tecnologia, a gerência, o cliente, etc? Você faz uma sessão de lições aprendidas em equipe?

Você deve fazer as lições aprendidas para todos os projetos, com falha ou com êxito. Há muito a aprender com um bom projeto.

Os verdadeiros projetos fracassados ​​têm sido muito raros para mim. Além de entender o que aconteceu, faço a pergunta "por que cinco vezes" para tentar chegar às causas subjacentes. Há também a questão de por que eu não notei o que estava acontecendo e fiz algo a respeito ou pelo menos saí.

Acho que a primeira posição de todos é culpar tudo - o cliente, a tecnologia, o problema de negócios que está sendo enfrentado, a metodologia, os membros da equipe, a linguagem, a plataforma, até mesmo a maneira como tomamos o café pela manhã. O bom de uma retrospectiva (mesmo que isso aconteça apenas em sua cabeça) é a chance de se reconciliar com alguns ou todos esses fatores e perceber que não era esse o problema.

No meu único fracasso real dos últimos 30 anos, o projeto exigia literalmente anos quando chegamos. Nós temos os requisitos resolvidos. Um veio da gerência e centenas dos usuários finais. Nós escrevemos código, muitos códigos, alguns brilhantes. Havia testes e testes de aceitação e mudanças, argumentos e solicitações de mudança, trabalho não remunerado, trabalho remunerado e boletins de última hora, humor surreal e escalações para os vice-presidentes e tudo mais. Eventualmente, tudo meio que tropeçou em uma parada. O motivo da falha foi que o requisito de gerenciamento único era inaceitável para os usuários finais. E não importa quantas coisas eles tenham feito, eles não conseguirão superar isso e nunca aceitarão o sistema. Mas a gerência não teria outra maneira. Então foi isso e, embora tenhamos recebido muito dinheiro, no final,

Ainda trabalho nessa tecnologia, ainda uso esses processos e ainda trabalho com as mesmas pessoas. Eu faria outro projeto para esse cliente. Mas quando os usuários finais disserem que não gostam de algo que seu próprio gerenciamento injetou nos requisitos, lembrarei que escrever um bom código que funcione não o protege de um projeto com falha. E farei algo sobre isso então, nem um ou dois anos depois.

Afaste-se, vadia por alguns dias a uma semana, enquanto evito fazer coisas importantes, depois tento descobrir o que deu errado e como não deixar que isso aconteça novamente.

Há um ótimo livro sobre o assunto chamado Marcha da Morte: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Eu sugiro que você leia. Você pode reconhecer seu (s) projeto (s) em várias descrições.

Não existe uma resposta única, pois depende muito de muitos componentes complexos da sua organização, incluindo política ...

Eu culpei todo mundo, menos eu .... haha, estou brincando. O que faço é escrever um documento "Mea Culpa", com todas as coisas que "fiz" erradas. talvez não ajude nesse projeto, mas é uma boa maneira de não repetir os mesmos erros