最近在反思這個問題，工業產品的質量管理大多都有標準。而我們的軟件研發卻只有少數情況能如期交付。更多的時候則像是一個人在以十公里的時速在叢林夜行。兩眼黑，走到哪算哪。
我反思爲何管理的項目有些能如期完成，有些則出現巨大的時間誤差---差距大到應該說是錯誤（只有可理解範圍內的偏差才能叫誤差）。
//待續
我反對過於臃腫的工程管理方式--這中方式嚴重製約事情的進展，而且容易流於形式。嚴格化的軟件工程產生的無數在其出生既被視爲垃圾的文檔絕對是每一個關係人的心頭刺。但是亦堅定反對放羊風格的工程管理。
1、工程的週期管理問題
工程的週期延遲的或多或少都與下面的情況有關
-
反覆的需求
-
錯誤的時間評估
-
執行者的執行能力
-
過渡設計與不設計
第一個原因我有深刻體會。
畢業工作的第一年，我在一個創業團隊當小兵（很感謝）。團隊是隨着互聯網泡沫一塊成長起來的，團隊人數從20多人在一年時間內膨脹到60人（兩年時間膨脹到130人）。當時的一個手機遊戲項目在做項目評審的時候，討論預計週期是2個月左右。7月份開工9月份左右上線。然而不幸的是，這麼簡單的項目都出現了一倍的延遲。項目到十一月下旬才上線。
我現在回顧當時的原因，很簡單：
反覆變化的需求。拍腦袋就能提一個需求，而拍腦袋的人不是執行者，最關鍵的是，執行者還必須要實現拍腦袋的人的那個idea---因爲他是老闆。投資人和PM/PMP的角色錯位交叉是災難性的，這嚴重違背了專業分工的發展趨勢。拍腦袋的需求多意味着沒有系統化整理的需求，另外也意味着沒有設計和工程管理。
第二、錯誤的時間評估
這條也可以說是第三條，或者第四條中的“不設計”原因造成的。關鍵還是看週期延遲的黑鍋誰來背。如果撇開因爲不設計和分析導致對項目的無知，無知評估產生的項目延期，負責人背黑鍋則是良心的做派。
第三、執行者的執行水平
我們撇開執行者的（相同類型項目）背景經驗不談，相同的事情給兩個人做肯定有快有慢。顯而易見的表現是，那麼多的招聘需求都有各種要求。閱歷越豐富的人越能在複雜情況中理出頭緒快速推進事情。如果說是這條原因導致的延期，我建議PM自己把黑鍋扛下來，因爲PM顯然是對團隊成員有一定程度的無知。
第四、過渡設計與不設計
這點不用看了，肯定是項目的技術負責人的問題。過渡設計實際上很少出現，縱使有些人可能憂慮的很多（整天擔憂項目能不能滿足性能和後期擴展需求，而且僅僅止步於擔憂，而不具體落實設計執行，這類人肯定缺乏經驗）。
2、績效管理
一說到績效，大家都能想到KPI。
爲什麼要績效管理？績效是管理者試圖規範化度量團隊的工作成績。這個真的很難考量。特別是大部門制的公司，或者大型項目組。
我對此也有很多的困惑，如果績效管理真能永葆一家企業的青春，則不會有那麼多跨國巨頭進入暮年，倒閉了。