國內軟體專案失敗的根源分析

中國人與歐美人的思維習慣存在較大的差異。當一件事情做砸了後，中國人一般傾向於去反思個人犯了什麼錯誤，並往往得出結論，如果換另外一個水平高一點的人，應該就不會搞砸了；而換作是歐美人的話，則會去反思做事情的方法存在什麼問題和不足，他們的結論正好相反，如果做事情的步驟不對，換其他水平再高的人，同樣很有可能搞砸。歐美人總是希望找到一種方法，能夠讓普通智力的人就可以將事情做好。

分析上述這個在國內很常見的典型案例，我們可以發現，案例中的專案經理首先想到的是依靠能人或高手來成功完成這個專案，這應當出自於其以往的專案經驗，這種心理本身並沒有錯；然而，專案經理顯然缺乏足夠的工程素養，他沒有認真地去分析專案的性質、並思考專案到底該如何去做，而這家軟體企業也沒有建立相應的機制，將以往成功專案的經驗傳遞給專案經理；於是這個專案完全是憑藉專案組成員自發的想象來推進。

專案經理的開發思路是：大家從學校所學到的軟體工程知識，能夠記得的好像就是需求、設計、測試什麼的，而設計從來就沒做過，大部分人最拿手的還是編碼；而專案的工作量擺在那兒，肯定要靠大夥兒共同來分擔，這樣就必須劃分任務；架構設計雖然做不了，需求中的功能模組還是能分出來的，於是按模組分配任務就是自然而然的事兒了。純粹依據功能模組來劃分開發任務，在業界早已被證明是種不好的開發模式，經過這麼多年的努力，業界已誕生了更為合理與有效的開發過程。另外，案例中後期出現的需求變更直接導致了專案的失敗，這完全是可以避免的；當代企業應用的軟體開發過程規定，在做需求之前還有業務建模的環節，如果開發組與客戶先認真地就業務達成一直認識的話，遺漏一些對業務非常重要的功能是不大可能發生的。不幸的是，專案組沒有采用這些正確的軟體過程與方法，或者他們壓根就不知道應當這樣去做專案。

總而言之，這個案例中的專案執行與書中所列的軟體專案執行步驟是背道而馳的。