CMM的一些想法

        CMM是過程流派的產物. 而OO的思想是傾向於目標式的思維方式. 有人認為兩者是風馬牛, 但程式員自己設計的時候用的是OO思想, 而被管理的時候是過程化的. 而且要寫這麼多羅索的文檔, 推行起來有困難很正常. 我通常會打個比方, 我們的程式出問題了, 而又不知道問題在哪一定是用工具 Debug, 但複雜的系統通常只能用 Log. CMM倡導的各種文檔就是相當於 Log. 有了這些文檔才能做項目改進分析.

    對於我所在的公司來說沒必要過CMM, 只是借用它的思想和辦法. 首要的問題就是CMM的界限, 邊界. CMM是對項目整個生命週期進行過程跟蹤. 它抹殺了個人英雄, 但也在一定程度上會抑止一些創造性的火花. 通常以技術為主或者產品不是很固定的公司難以實現這種管理方式. 而在那些應用為主的公司則非常重視. 對於創造性較強的項目, 就應該減少過程化管理的程度, 在項目趨於穩定時, 加強這方面的管理以提高產品的品質. 就我所在公司的情況, 一半是前者一半是後者. 我們對於新的項目有比較完整的文件管理. 穩定以後, 只在系統遷移的做文檔記錄. 對於搶時間的項目, 我們通常只進行最基本的文檔記錄, 重點是資料庫字典. 其它文檔一律後補. 這樣保證以後能維護而又使項目準時完成. 明確 CMM 才能正確的使用它.

    其實軟體改進過程裡面最重要的還是人. 特別使中小型的公司, 能把握住人, 公司才能生存. 畢竟文檔都是人寫的. 把人培養好, 公司甚至可以沒有管理. 當每個員工都積极參与公司事務時, 管理制度就消失了. 我在第一家公司的時候, 曾經一度呈現這種狀態. 那時候, 公司深恐待薄員工, 員工都珍惜自己的崗位. 回頭思考, 發現有很多問題當時都在上層沒有發現的時候解決了. 當一個問題出現時, 很快就會傳播到每個下層員工的耳裡. 問題解決後, 同樣的傳播開. 初看好像耽誤一些員工手裡的活, 其實從整個公司的效率來看絕對是很高的. 當時真有點無為而治的感覺. 所以, 首先有好的管理員模式和用人機制, CMM 才能發揮作用. 而管理的關鍵在於知. 篇幅有限, 就寫到這.