计算机软件开发对建筑工程项目管理的启示

易 嘉

（上海朗诗规划建筑设计有限公司，上海 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 结束语

综上所述，计算机软件开发的复杂度和难度并不亚于建筑工程项目，由于计算机软件的不可见性，以致其开发难度甚至超过建筑工程项目。因此，适用于计算机软件开发的原则和方法，也能移植到建筑工程项目管理中，通过采取项目管理的文档化、工程设计的可视化、团队协作的层级化和职责权限明晰化等策略，可以有效地防止项目管理走向无序，促成建筑工程项目实施的稳定性和可持续发展性。