易 嘉

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

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

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

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

1.1 焦油坑

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

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

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

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

1.2 人月神話

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

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

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

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

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

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

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

1.3 外科手術團隊

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

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

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

1.4 貴族專制、民主政治和系統(tǒng)設計

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

圖6 法國蘭斯大教堂外景

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

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

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

1.5 為何巴比倫塔會失敗

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

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

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

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

圖7 全通道式溝通

2）不需要反饋的共享項目信息，應由項目經(jīng)理直接書面通知項目組全體成員，例如：項目圖簽信息、項目暫?；蜓悠谕ㄖ㈨椖渴艿姜剳偷?，屬于輪式溝通，如圖8 所示。

圖8 輪式溝通

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

圖9 環(huán)式溝通

1.6 沒有銀彈

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

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

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

1.6.1 復雜度

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

圖10 子系統(tǒng)增加對協(xié)同工作量的影響

1.6.2 一致性

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

1.6.3 可變性

在市場經(jīng)濟為主導的大環(huán)境中，建設方要隨市場而動才能獲取利潤，由此引發(fā)產(chǎn)業(yè)鏈下游的設計、施工、材料緊隨其變，唯一不變的就是改變。

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

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

2 結(jié)束語

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