실패한 프로그래밍 프로젝트를 처리하는 방법?

프로젝트가 실패하는 것은 드문 일이 아닙니다.

프로그래머는 실패한 프로젝트를 어떻게 처리합니까?

실패에 대한 몇 가지 정의 :

• 마감일이 누락되었습니다.
• 코드와 기능은 예상대로 작동하지 않습니다.
• 소프트웨어는 기본적으로 제공 할 수없는 수증기 또는 끝없는 단계가됩니다.

또는 실패에 대한 고유 한 정의가있을 수 있습니다.

손가락을 가리 키기 시작합니까? 요구 사항, 기술, 관리, 고객 등 자신을 비난합니까? 당신은 팀으로 수업을 배운 수업을합니까?

모든 프로젝트에 대해 배우고 실패했거나 성공한 교훈을 수행해야합니다. 좋은 프로젝트에서 배울 것이 많습니다.

진정한 실패한 프로젝트는 매우 드물었습니다. 무슨 일이 일어 났는지 이해하는 것 외에도, 나는 근본적인 원인을 찾기 위해 "왜 5 번 물어봐"일을합니다. 내가 무슨 일이 일어나고 있는지 알지 못하고 그것에 대해 무언가를하거나 적어도 나가는 이유에 대한 문제도 있습니다.

고객, 기술, 비즈니스 문제, 방법론, 팀원, 언어, 플랫폼, 아침에 커피를 마시는 방식까지 모두를 비난하는 것이 모든 사람의 첫 번째 입장이라고 생각합니다. 회고에 대한 좋은 점은 (자신의 머리에서만 발생하더라도) 그러한 요인 중 일부 또는 전부와 조정하여 문제가 아님을 인식 할 수있는 기회입니다.

지난 30 년 동안의 유일한 실패에서 프로젝트는 문자 그대로 몇 년 동안 요구되었습니다. 요구 사항이 해결되었습니다. 하나는 관리 부서에서, 수백 명은 최종 사용자에게서 나왔습니다. 우리는 코드, 많은 코드, 일부는 훌륭했습니다. 테스트 및 수락 테스트, 변경 및 인수, 변경 요청 및 무급 노동 및 유급 노동, 막판 볼트 및 초현실적 유머 및 VP 및 그 모든 직원에 대한 에스컬레이션이있었습니다. 결국 그것은 모든 종류의 정지로 넘어졌다. 실패한 이유는 단일 관리 요구 사항이 최종 사용자에게 허용되지 않기 때문입니다. 그리고 그들이 얼마나 많은 일을했는지에 상관없이, 그들은 그 것을 지나칠 수 없었고 결코 시스템을 받아들이지 않았습니다. 그러나 경영진은 다른 방법을 가지고 있지 않을 것입니다. 그래서 그게었고 우리는 많은 돈을 얻었지만 결국은

나는 여전히 그 기술에서 일하고 있으며, 여전히 그 프로세스를 사용하며 여전히 같은 사람들과 일하고 있습니다. 나는 그 고객을 위해 또 다른 프로젝트를 할 것입니다. 그러나 최종 사용자가 자신의 관리가 요구 사항에 주입 한 것을 좋아하지 않는다고 말하면 작동하는 좋은 코드를 작성해도 실패한 프로젝트로부터 당신을 보호하지 못한다는 것을 기억할 것입니다. 그리고 1 년 또는 2 년이 지나서 그것에 대해 무언가를 할 것입니다.

중요한 일을 피하면서 며칠에서 일주일 동안 나쁜 놈을 쫓아 내고 무엇이 잘못되었는지 다시 알아 내지 못하게하십시오.

죽음의 행진이라는 주제에 관한 훌륭한 책이 있습니다 : http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

나는 당신이 그것을 읽는 것이 좋습니다. 많은 설명에서 프로젝트를 인식 할 수 있습니다.

정치를 포함하여 조직의 많은 복잡한 구성 요소에 크게 의존하므로 단일 답변이 없습니다 ...

나는 나를 제외한 모든 사람을 비난했다. 나는 "Mea Culpa"문서를 작성하고 "내가 한 것"이 잘못되었다. 어쩌면 그 프로젝트에 도움이되지 않지만 같은 실수를 반복하지 않는 좋은 방법입니다.