國內軟體專案的典型歷程

老闆將專案任務下達後，專案經理便開始拉攏公司中的幾個能人，經過跟老闆的一番討價還價，總算將其中的兩個受歸麾下；而作為平衡，另外的人選老闆則塞了幾個菜鳥過來。

於是，專案就這麼開始了，專案經理先帶隊跑到客戶那裡呆了兩星期，經歷了若干次與客戶的猜拳喝酒之後，終於拿到了一份客戶簽字認可的需求。此後，專案經理召集組員們開會，將需求中的功能劃分出若干模組，然後據此開始分配任務；大家又是一番吵鬧，在專案經理的威逼利誘之下，重要的模組總算壓給了兩個能人，剩下一些較容易的模組則理所當然地被菜鳥們瓜分一空。

在組員們每天按時上下班，輕鬆了一個月後，專案經理在老闆的壓力下，終於露出了猙獰的面容，組員們只好開始加班。隨著菜鳥們不斷宣佈有新的功能模組被完成，專案經理臉上也露出了久違的笑容，並催促那兩個能人加快進度；慌亂之下，兩個能人終於提交了幾個關鍵的模組。

專案經理決定將這些模組整合起來，給老闆做次彙報演示。這時侯風雲突變，一大堆bug突然冒了出來；更麻煩的是，有幾個模組就是無法跟核心模組一起聯調成功。專案經理發現這幾個模組正是菜鳥們最先提交的那批成果。被逼無奈，專案經理請兩個能人吃了頓飯，飯桌上，被灌醉了的能人們拍了胸脯——一定幫哥們將菜鳥們的模組搞定。經歷一番痛苦的加班加點，專案經理跟兩個能人一道修改了菜鳥們的模組，總算將軟體整合成功，但是新的問題又出現了。

在給老闆演示彙報的現場，源於對專案經理的無比信任，老闆將客戶也請了過來。客戶興奮地嘗試了一下操作，不料有個功能，客戶出乎意料地輸入了比較複雜的資料，結果等了半天系統也沒有響應。客戶不快地走了，第二天打電話給老闆說，有幾個主要的功能好像沒有按他們原來要求的那樣做。

老闆第一次將專案經理叫到辦公室單獨談了一上午。專案經理於是耐心地與客戶做了溝通，發現客戶提到的那些功能，有的根本就沒有寫在需求上，當然也有幾個是開發組與客戶理解出現了不一致。客戶不能接受專案經理的說法，認為要讓他的業務能夠運轉，沒有寫在需求中的那幾個功能恰恰是必不可少的，並指責專案經理不懂他的業務。專案組只好接受了這些需求變更，並組織組員們修改程式碼來實施變更，同時還決定要一併改進程式碼的執行速度。

過了幾天，其中一個能人跑來跟專案經理說想要調到其它專案組去。磨蹭了半天，能人才據實相告，因為事先沒有設計好，客戶要求的需求變更很難實現得了；另外改進程式碼執行速度的工作量比預想的要大很多，幾乎所有的模組都要改。過了不久，這個專案最終被宣告失敗。