這篇文章用來總結一下2013，同時也分享一下我對中國IT專案現狀的一些看法。
我先從專案說起。這裡的專案主要是指的軟體開發專案。我們分別從專案中的甲方和乙方談談，看看這兩者對於專案、對應IT的認識和觀點。
甲方
這是個很簡單的事情
“不就建幾個表的事情嗎？，怎麼讓你說的那麼複雜！？”--現在甲方都知道什麼是表了
我們的需求很明白！就這“兩頁紙”
“已經很明確了，領導就是這個意思，開始弄吧！”-- 確實是“很明確”
“還不清楚啊？我們其實就是要個ERP！” -- 厲害了，3個月要開發一個ERP
合同金額一定可以再少一些“便宜點吧！沒問題的！”--砍價吧，總會有乙方的
專案一定會在合同規定的時間內，用很低的成本，較高的效率完成
“這事交給你們我放心！好好幹！”--乙方其實真的不好乾啊
通用手段 --“拖”字絕
“先等等吧，領導最近忙啊！”
“不急啊，我們有些東西還沒想清楚！”
“最後一次，最後一次了，改完就給你們打款！”
“真的是最後一次了！”
我是“甲方”，我是“爺”
“我們的需求變更是合理的啊！”
“我們這是細化啊！不可能一步到位啊！”
“別廢話了，合同都簽了，趕緊幹活！”--不能問太多，因為甲方很忙
乙方
為了節約成本，大量使用應屆生、外包、轉包等現象時有發生
為專案失敗埋下了隱患
虛構自己的專案經驗、人員水平
為了拉到專案，“虛構現實”
有合同就籤
“沒辦法啊，不籤專案，這麼多人等著吃飯呢！”
“籤吧，走一步是一步，實在不行尾款不要了！”
需求變更是最頭疼的問題
因為領導的意見“太明確了”，導致變更成了一個填不滿的黑洞
不是乙方不懂“需求變更控制”，真是沒法控制
合同前期我忍，合同後期我撤
很多時候當“孫子”確實不容易，一直到忍無可忍的時候乙方就會選擇退出
上面是一個現實情況的簡單重現，我們從解決問題的角度出發，看看怎麼來減少或避免專案失敗。
首先，甲方要足夠重視專案。依據我的經驗，一個專案的成敗在很大程度取決於“一把手”是否真的重視！我這裡說的“成功”是指一個專案滿足了使用者的大部分需求、並真正的投入使用、改善或提高了甲方的工作效率。與此同時乙方要安排合適的人員參與專案、並積極學習甲方的業務知識。
第二點，甲乙雙方都要認識到軟體專案和傳統的專案有很大的區別。讓甲方花100萬去採購硬體失敗的機率是零，但是如果是100萬的軟體專案，是否成功要依賴雙方的通力合作。軟體專案依賴於需求是否明確、管理及開發人員的水平和經驗、專案的規模和複雜程度、乙方對甲方需求的瞭解程度等等。
第三點，避免中國式的專案需求。很多時候甲方專案負責人（接洽人）的職位比較低，在溝通的過程中他並不能（也不會）站在更高的層次上去思考問題，這就給雙方帶來了麻煩。比如一個專案經理負責接洽，初次稽核是科長，第二次稽核是處長，最後驗收時又跑出來個局長，這就很要命！每次都站在一個更高的層次是去考慮問題，帶來是無窮盡的需求變更，甚至是對專案致命的摧毀。基於這種現象，雙方都要盡最大努力讓最關鍵的人物儘早出現，避免需求黑洞的出現。
第四點，雙方最好都按“分段交付”的規則來監控專案，這裡也可以說是“里程碑”式的規則。甲方千萬不要當甩手掌櫃，定期評審專案能及時的發現問題並改正，避免在deadline時dead掉,用milestone確保雙方都在正確的路上行進--其實milestone就是我們的指路牌。
第五點，關於“需求變更”。“需求變更”是一個令人頭疼的問題，他給參與專案的人員帶來的痛苦只有經歷過的人才能體會的到。但是這是一個沒人能夠迴避的問題。
約定甲方和乙方的是合同，但是如果完全按照合同約定的需求去實現軟體，估計專案不會真正的成功。我們要找到一個合適的平衡點來協調“需求變更”。甲方要儘可能的在專案初期把需求細化，比如：讓儘可能多的人員參與到需求調研中；使用“頭腦風暴”的方式提出需求；基本需求確定後讓相關部門的負責人確認簽字；找到合適的乙方，聽取乙方的建議；對於乙方來說也是一樣，要引導甲方儘可能的完善需求。用一句話概況一下“前期多說，後期少變，避免說變就變”！
第六點，關於“後期維護”。這裡我主要談談“後期維護”對乙方的好處。首先，它可以讓專案更加完美，更加貼近使用者習慣。其次，它可以讓乙方和甲方保持良好的溝通並改善雙方的關係。最後，它可以給乙方帶來下一個專案。所以乙方要足夠重視“後期維護”，不要讓它成為合同裡的一句空話！
以上是我的膚淺認識，如有不妥之處，還請大家多多指教，謝了！