計算機軟件開發對建筑工程項目管理的啟示

易 嘉

（上海朗詩規劃建筑設計有限公司，上海 200092）

《人月神話（The Mythical Man-Month）》[1]一書是被譽為美國計算機軟件工程之父的弗雷德里克·布魯克斯對于大型計算機軟件開發經驗的論著，其中講述了布魯克斯在1961—1965 年間身為IBM OS/360 計算機操作系統開發的項目經理，是如何理解項目設計和管理的。該操作系統耗資超過5 億美元，總計約有100 萬行代碼，投入超過2 000 名軟件工程師，總工作量約5 000 人年，拉開了計算機軟件工程的序幕。

布魯克斯的觀點除了被計算機專業工程師所熟知外，也吸引了諸如醫生、律師、建筑師等其他領域的讀者群，因為其觀點以人和團隊為導向，闡述了項目設計和管理的通識和忠告，可為跨專業的工程人員提供借鑒和參考。

1 計算機軟件開發對建筑工程項目管理的啟示

1.1 焦油坑

焦油坑是一種瀝青湖，從地層中冒出來的石油干涸后，只留下半固態的焦油瀝青，在烈日的照射下，焦油變軟，無論什么東西接觸到它，都會永遠地陷在其中。在歷史的長河中，恐龍、猛犸象、劍齒虎這些曾經主宰地球的巨獸，都無法逃脫焦油的束縛，掙扎得越猛烈，焦油糾纏得越緊，最后都沉到了坑底。

布魯克斯在其論著的開篇，用“焦油坑”比喻大型軟件系統開發的艱難：各種團隊，大型的或小型的，龐雜的或精干的，一個接著一個淹沒在了“焦油坑”中，雖然其中大多數團隊開發出了可以運行的系統，但只有極少數項目滿足了目標、進度和預算的要求。表面上看好像沒有任何一個單獨的問題會造成困難，每個問題都能獲得解決，但是當其相互糾纏在一起的時候，團隊的行動就會變得越來越慢，整合協同的難度呈非線性快速增長的趨勢。

在建筑工程設計領域也不能幸免，單個專業遇到的問題似乎解決起來并不難：建筑外表皮要賞心悅目、內部空間要便于使用、結構構件需要具有足夠的強度和穩定性[2]、建筑應滿足消防安全的要求[3]、給排水系統需要滿足最小排水坡度的要求[4]、電氣系統要負載均衡[5]、通風空調系統要節能減排[6]及室內裝飾要平易近人。但當上述分系統合成的時候，各種矛盾便顯露出來，如結構構件和設備管線與室內空間凈高的矛盾、建筑空間與設備管線轉換的矛盾、建筑外立面效果與采暖通風能耗的矛盾等，項目整合協同的難度快速增大以至于淹沒在“焦油坑”中，建筑最后成了“遺憾的藝術”，如圖1 所示。

圖1 某商業辦公樓地下1 層全專業管線綜合BIM 模型

1.2 人月神話

所謂“人月”，指的是計算機軟件開發的工作量統計，即一種計量單位。例如，某個系統開發使用了6 個人，花了4 個月的時間完成，則該開發系統的工作量是6×4=24 人月。由此很容易引發聯想，如果已經估算出工作量，能否用反算的方法來調節所需的人員或工期呢？例如，增加2 個人，是否能使工期由4 個月縮短為24÷（6+2）=3 個月呢？

布魯克斯認為在系統開發中，人和月不具備互換性，理想中的用增加人手來縮短工期的辦法具有欺騙性，只是一個遙不可及的“神話”。究其原因，不像割小麥或者收獲棉花那樣獨立作業，新增的人員之間需要進行相互交流和協同工作，以及通過必要的培訓來熟悉項目，期間所消耗的時間已經抵消了對原有任務分解所產生的有利作用，“向進度已然落后的計劃中添加更多的人力，只會使進度更加落后”。如圖2—圖5所示。

圖2 人月關系1：完全可以分解的任務

圖3 人月關系2：無法分解的任務

圖4 人月關系3：需要溝通的可分解任務

圖5 人月關系4：關系錯綜復雜的任務

對于建筑工程項目設計實踐，項目管理者曾經嘗試過在項目行進過程中增加人力，但效果并不理想，例如：建筑專業后期增加人員設計樓梯大樣、墻身大樣等詳圖，但由于該類詳圖需要與整體建筑圖相互匹配及同步調整，雖然減少了整體建筑圖設計人員設計詳圖的時間，但卻增加了其協調和溝通的時間，最后即使項目能夠按時完成，也會留下或多或少的圖紙不一致缺陷，為后期施工服務埋下隱患。

1.3 外科手術團隊

如何組建一個既有分工又具備總體協同能力的團隊呢？布魯克斯認為最理想的是團隊應類似于“外科手術團隊”，主要成員包括外科醫生、副手、麻醉醫師和護士等輔助職員角色，其中外科醫生需要極高的天分、豐富的經驗、大量的系統知識和應用知識，負責實施手術；副手是外科醫生的后備，應能完成任何一部分工作，僅是相對經驗較少，其主要作用是作為思考者、討論者和評估人員，外科醫生可試圖與之溝通，但不受其建議的限制；輔助職員的工作則是按照外科醫生的指令給予必要的協助。

以建筑工程設計的各方角色做類比，則建設方類似于“病人”，存在著林林總總的需求；設計項目經理類似于主刀外科醫生，負責獲取建設方的需求信息，并經過濾、整理后分發給各專業技術負責人；各專業技術負責人類似于外科醫生的副手，接到設計項目經理的信息后做出技術評估，如果可行，則將設計指令下達至設計人員；設計人員類似于輔助職員，接到專業技術負責人的設計指令后，按部就班地執行。

但值得注意的是，上述職責的劃分，不存在利益的差別，設計人員在深化設計過程中，遇有技術困難也可以向專業技術負責人反饋，整個設計過程不是單向不可逆的，而是不斷迭代反饋和修正。

1.4 貴族專制、民主政治和系統設計

法國蘭斯大教堂經歷了8 代擁有自我約束和犧牲精神的建筑師們的努力才得以建成，其中每個人都犧牲了自己的一些創意，以獲得更純粹的設計，如圖6所示。

圖6 法國蘭斯大教堂外景

布魯克斯借用蘭斯大教堂的設計建造來比喻系統設計的“概念完整性”（此處計算機科學家跨領域從建筑學獲取靈感，其共同之處是任務被分成了若干人完成），主張：“在系統設計中，概念完整性應是最重要的考慮因素，寧可省略一些可能很好的設計，也不提倡獨立和無法整合的系統。”

布魯克斯認為，概念完整性必須由一個人或者非常少數互有默契的人員來實現，而犧牲其余具體編碼人員的部分創意。正如貴族的專制統治一樣，這是一種“無須任何歉意的貴族專制統治”，相比多頭統帥的民主政治，更容易凝聚項目團隊士氣，統一前進目標。

在建筑工程項目設計領域，特別是建筑方案設計及緊接其后的施工圖設計，兩者的關系很像專制統治的貴族及辛勤勞作的平民百姓，前者獲取建設方需求后，對整體建筑風格、內部功能布局、主要材料選用和總體技術經濟指標等做出了方向性的約束；后者則在前者的概念方案基礎上進行深化設計，力求從工程上實現前者的概念構想，方案設計圖的每根線條是設計師用筆繪制出來的，工程實體的每根線都是用建筑材料施工而成的。從另一個角度講，施工圖設計也并非毫無創意可言，為了實現概念方案，通過多種技術措施的比選以降低施工難度、節約材料用量，同樣可以實現技術、質量和經濟相協調的創新設計[7]。

1.5 為何巴比倫塔會失敗

“巴比倫塔”又名“通天塔”，源于《圣經·創世紀》，故事講述了很久以前地球的人類只講同一種語言，他們試圖建造一座通往天國的通天塔，上帝知道后大為震驚，于是打亂了人類的語言，使之不能聽懂他人的話語，以至于被迫停止建造通天塔。

布魯克斯引用這則故事，說明交流協作對于系統設計的重要性。對于大型項目，如果有n 個工作人員，則有種相互交流的接口，有近2n 個必須合作的潛在小團隊，因此，項目組織者需要進行人力劃分并限定各層級成員的職責范圍，通過樹狀層級結構來減少龐雜的網絡化交流，提高溝通的效率。

在工程設計過程中，每個項目會有m 個單位工程（建筑單體），每個單位工程又至少有5 個專業協同工作，每個專業設置1 名專業負責人及n 名設計人員，項目經理采取何種信息傳遞策略對于項目推進具有很大的影響，其溝通交流的方法可以使用諸如會議、電話、即時信息、社交媒體和視頻會議等方式[8]，溝通的原則應如下。

1）日常技術交流或信息咨詢，可以采用無約束的口頭討論方式，不受職責范圍和層級的約束，屬于全通道式溝通，如圖7 所示。

圖7 全通道式溝通

2）不需要反饋的共享項目信息，應由項目經理直接書面通知項目組全體成員，例如：項目圖簽信息、項目暫停或延期通知、項目受到獎懲等，屬于輪式溝通，如圖8 所示。

圖8 輪式溝通

3）需要技術決策的項目信息，應由項目經理書面通知各專業負責人，各專業負責人經討論形成解決方案后，交由設計人員執行，屬于環式溝通，如圖9 所示。

圖9 環式溝通

1.6 沒有銀彈

所謂“銀彈”，是指在古老的傳說里，狼人是不死的，但可以用銀制的子彈將其殺死，故常用“銀彈”比喻解決難題的靈丹妙藥。

布魯克斯以“沒有銀彈——軟件工程中的根本問題和次要問題”一文作為《人月神話》結尾，稱“在未來十年內，無論在技術上還是管理方法上，都看不出有任何突破性的進步，能夠保證大幅度提高軟件生產率、可靠性和簡潔性”，原因在于現代軟件系統中無法回避的內在特性：復雜度、一致性、可變性和不可見性。這些特性是現代軟件系統與生俱來的，憾江山易，改本性難，故稱“沒有銀彈”。

布魯克斯描述的現代軟件系統中無法回避的4 個內在特性中，除了不可見性外，其余3 個特性基本可以直接用于描述現代建筑工程設計的根本困難。

1.6.1 復雜度

相比古代建筑以結構建筑為主體，現代建筑的子系統逐漸增多：強弱電系統、采暖通風系統、消防系統、保溫系統和幕墻系統等，在原有的n 個系統基礎上每增加1 個系統，就會增加n 種系統間的相互協調工作，每增加m 個系統，組合數就會增加f（m）=C2（n+m）- C2n=種系統間的相互協調工作，可見其協同工作的增速是非線性的，呈快速上升的拋物線型。令n0=2，表示最初只有建筑和結構2 個子系統，則f（m）=，如圖10 所示。

圖10 子系統增加對協同工作量的影響

1.6.2 一致性

對于建筑工程而言，一致性包含了單專業自身設計的一致性（如平立剖面和大樣圖一致、計算模型與設計參數一致、系統圖和平面布線圖一致等）和多專業碰撞檢查，是協同工作無法回避的問題。雖然可以嘗試采用基于AutoCAD 的二維協同平臺來減少圖紙錯漏碰缺，但此舉僅是解決了設計人員整合圖紙的意識問題，由于二維圖紙相互獨立，不具備自相關性和同步更新性，故未能實質性解決圖紙自身的邏輯對應問題，常常由此埋下施工隱患，參見圖1 所示。

1.6.3 可變性

在市場經濟為主導的大環境中，建設方要隨市場而動才能獲取利潤，由此引發產業鏈下游的設計、施工、材料緊隨其變，唯一不變的就是改變。

布魯克斯作為計算機科學家，但其觀點和解決問題的方法卻不局限于計算機學科，而是博采眾長，由此積累的經驗也令其他領域工程師受益，為了獲得工程的概念完整性和一致性，項目團隊中需要有靈魂人物；為了團隊能齊心協力，需要建立高效的溝通機制。

唯獨在應對項目根本困難上，布魯克斯沒有給出令人期待的答案，認為“沒有銀彈”。在建筑工程領域，BIM 技術具有集成化、智能化、數字化及模型關聯性等優點[9]，可架起工程建設溝通的橋梁，令建設方、施工方、設計方和材料供應商在統一的信息模型下協同工作，有希望成為“銀彈”，再造工程項目建設的“巴比倫塔”。

2 結束語

綜上所述，計算機軟件開發的復雜度和難度并不亞于建筑工程項目，由于計算機軟件的不可見性，以致其開發難度甚至超過建筑工程項目。因此，適用于計算機軟件開發的原則和方法，也能移植到建筑工程項目管理中，通過采取項目管理的文檔化、工程設計的可視化、團隊協作的層級化和職責權限明晰化等策略，可以有效地防止項目管理走向無序，促成建筑工程項目實施的穩定性和可持續發展性。