專案管理與企業智商4（轉）

　■ 以軟體專案為例

　　現代管理由一種趨向，即從偏愛目標管理轉向偏愛過程管理。按德魯克的觀點，企業的R&D部門，是知識型組織結構的創新典範，特別是軟體開發組織。而軟體工程的過程屬性可以說是現代專案管理的典範。

　　軟體工程可以說是最忠實地在專案管理、工程方法的路線上艱苦求索的領域。但令人苦惱的是，軟體工程似乎每每遭遇失靈的窘境。自從1969年“軟體危機”成為一個學術術語以來，克服軟體危機的努力一直在“工程專案管理”的認識框架下進行，比如結構化軟體方法，原型化軟體方法和麵向物件的軟體工程方法。

　　人們普遍認為，軟體的開發效率、可用性和質量，最終取決於軟體的需求分析。如果對一個系統的需求描述有缺陷，那麼軟體無論如何也不可能實現預期的目標。

　　認為軟體是一個按照需求分析的結果所建立的模型進行設計的過程，無疑是一種工程方法。工程方法的最大特徵就是，先有設計，然後有作品。

　　軟體工程管理引起廣泛注意源於20世紀70年代中期。當時美國國防部曾立題專門研究軟體專案做不好的原因，發現70%的專案是因為管理不善而引起，而並不是因為技術實力不夠，進而得出一個結論，即管理是影響軟體研發專案全域性的因素，而技術隻影響區域性。這個結論非常重要。到了20世紀90年代中期，軟體工程管理不善的問題仍然存在。

　　軟體專案失敗的主要原因有：需求定義不明確；缺乏一個好的軟體開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟體過程；對軟體構架很不重視；軟體介面定義不善且缺乏合適的控制等等。在關係到軟體專案成功與否的眾多因素中，軟體度量、工作量估計、專案規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。

　　雖然軟體工程管理和其它工程管理相比有其特殊性。比如，軟體是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟體系統複雜程度也是超乎想象的。但軟體專案管理的工程特徵並沒有改變，軟體工程的分析-綜合架構並沒有改變。

　　如果在這個層面看待專案管理，的確沒有任何可以激動的地方。一切只不過是幹起來更加迅速，整合度更高、複雜性更高而已。發現過程的重要性，只相當於重新審慎地注意到了細節。

　　應當說，MIT於20世紀80年代提出的“軟體能力成熟度模型CMM”，把注意力引向了正確的方向，即專案賴以存在、展開的組織的成熟度。這是一個全新的視角。工程問題很容易被簡化為工具是否銳利的問題，即簡化為一個根據目標演繹的過程。工程失敗也可以從專案管理上尋找原因。但組織的成熟水平，的確是一個好的探索方向。

　　CMM首先不是單純地考察專案，而是考察組織，以及組織的演進。一個組織如果透過專案獲得了能力的提升，比如越來越標準化、一致化的軟體過程；越來越可以預測的軟體過程；軟體專案的最佳化是一個持續最佳化的可感知的過程等等，都體現了組織的成熟性。

　　CMM強調的是組織的能力，而不是專案管理過程中一些更多地以規則、方法面目出現的東西，比如IDEAL模型，概括了建立一個成功的過程改善專案的必要步驟，其中I代表Initiating(啟動)、D代表Diagnosing(診斷)、E代表

　　Establishing(建造)、A代表Acting(措施)、L代表Learning(學習)。

　　軟體工程的探索把軟體專案關注的焦點，從工程本身轉向了實施工程的組織，這就是現代專案管理的靈魂所在。專案管理不再僅僅是工具，而是關於組織、關於組織的成熟程度、關於組織的能力、關於組織的智商的學科和技術。
組織行為的改善，可以視為種群習性的遷移，其意義遠遠大於一次孤立的獵食行動（專案）。

[@more@]