契约式沟通
（王咏刚 2004 年6 月）
1 问题引入
在软件开发项目里，除了少数自以为是的家伙以外，
没有人会否认沟通的重要性。但人们往往在重视沟通效果
的同时，忽略了对沟通技巧和沟通方法的学习。比方说，
我自己就经历过一次不折不扣的沟通失败，如果我当时对
沟通的了解再多一些，现在就没必要可怜巴巴地在这里怨
天尤人了。
事情发生在三年以前。在一个美丽的海滨城市近郊，
坐落着一所造型前卫得可以和宇航中心媲美的建筑。它背
山面海，毗邻一家高尔夫球场和一条著名的汽车赛道。驾
车从旁边的高速公路上飞驰而过的人们很难想到，这所漂
亮、别致的建筑竟是一家大型国有银行投资创建的软件开
发中心。
当时，我有幸在这里参加了一个软件项目的开发工作。
我所说的“参加”是指，我带领我们公司的一个团队，常
驻在这家软件开发中心，并与该中心的一个研发部门组成
联合项目组，合作开发一套将在全行范围内推广的软件产
品。这个项目涉及我们公司和开发中心的两个团队，有两
个主管领导——我和开发中心的部门经理老H，同时也牵
涉到我们公司、开发中心以及开发中心的东家——大型国
有银行三方面的利益。现在想来，在这样一个错综复杂的
环境中开发软件，出现任何沟通上的问题都再正常不过了。
事情起因于两个团队关于软件架构方案的争执。我们
要开发的软件产品必须为该银行分布在全国的几百家分行
提供服务，同时也要保证数据的绝对安全和可靠。根据我
们以往的经验，这样的软件最好采用集中部署的架构，即
只在该银行全国数据中心的一台高性能服务器上部署服务
端软件，分布在全国各地的用户都通过安全的远程访问机
制完成业务操作。但令我们大为不解的是，开发中心以老
H 为首的所有技术人员竟异口同声地反对集中式架构，他
们建议采用分散部署的模式，即在全国每家分行的机房里
都安装一台服务器，所有服务器相互关联，共同完成数据
采集、分发、同步和查询操作。
需要声明一点，我讲述这个案例的目的在于讨论软件
开发中的沟通问题，而不是辨析不同的分布式系统架构孰
优孰劣。事实上，无论是分散式架构还是集中式架构，它
们并没有先进和落后的区别，只有适用和不适用的问题。
我相信，如果读者了解我们这个项目的具体需求和软件的
实际运行环境，大多数人都会同意，集中部署是最适合于
此项目的架构方案。但当时我所遇到的情况是，我们公司
的技术人员无论从何种角度分析，都觉得对此软件而言，
分散部署的方案实现难度大、运行效率低、维护成本高、
不容易确保数据安全，可开发中心的团队就是对我们的分
析结果视而不见，一味地坚持分散式架构。架构分析期间，
作为合作双方的代表，我和老H 在项目会议、私下闲聊、
电话沟通、电子邮件、工作晚餐等多种场合反复争论，却
始终无法找到一丝一毫的共同点。我摆出了无数条绝对站
得住脚的技术理由，以证明集中式架构在此项目中的优越
性，而老H 却总是简单地、差不多毫无根据地断定我们的
方案愚蠢、幼稚，并说分散式架构是唯一可行的解决方案。
至今我仍然清楚地记得，我和老H 在半个多月的时间里，
用各种口头的和书面的交流方式，把类似下面这样的对话
过程重复了30 多遍：
沟通时，如果我说：“根据我们的计算，集中式架构可
以节省500 多台硬件设备。”
老H 就会说：“老兄，我们开发的是软件，不是硬件。
分散式架构是唯一的选择。”
如果我说：“集中式架构无需开发数据同步模块，这可
以节省两个人月的工作量。”
老H 必定会说：“那就多花两个人月好了，因为分散
式架构是唯一的选择呀。”
这时我一般会说：“使用集中式架构，管理者可以更容
易地监控甚至动态修改系统的业务流程。”
老H 则会说：“只要我们足够努力，分散式架构也可
以实现你说的功能，因为..分散式架构是唯一的选择，
你为什么老是不承认这一点呢？”
每次讨论我必说的一句话是：“集中式架构可以减少各
分行安装和管理服务端软件的麻烦。”
而老H 的回答也必然是：“真的很麻烦吗？可你知道
不知道分散式架构是唯一的选择呀。你不承认分散式架构
的优点，这不是在自讨没趣儿吗？”
说实话，当时的我还年轻气盛，也多少有些倔强和认
死理儿的坏脾气。我无法容忍别人在近乎胡搅蛮缠的30
多次讨论中，次次都把我称作“自讨没趣儿”的家伙。终
于，在最后一次关于软件架构的讨论会上，我再也无法按
捺激动的心情，站起来大声对老H 说：
“我们到这里来，是诚心诚意与你们合作开发软件的。
设计软件的架构时，我们的的确确是从开发中心及银行的
利益出发来考虑问题的。此外，我们也在技术层面反反复
复地向你们说明了集中式架构的优越性。可我实在不明白
你们到底在想什么。你们坚持分散式架构的理由都不值一
驳，你们关于分散式架构是唯一选择的说法也荒谬可笑。
按说，你们都是做技术出身的人，为什么这一次会这么冥
顽不化呢？”
我不知道这番话在老H 心里激起了多少波澜，我只知
道，说完这番话的我被开发中心列入了“最差合作者”的
黑名单，我们公司和开发中心在这个项目上的合作也不得
不到此为止。一个月后，开发中心与另一家公司签约，并
基于分散式架构合作开发同样的软件产品。显然，这起事
件是以我和我们公司的彻底失败而告终的。
如果说现在的我还对三年前这起事件懊悔不已的话，
我想，最值得我反思的东西就是我当时对沟通的粗浅认识
了。现在，大家不妨帮我总结总结，当面对老H 等不讲“技
术道理”的合作者时，我们是不是还有其他更好的交流技
巧可以使用？我的意思是说，我们能不能通过有效的沟通，
既保持与开发中心的合作关系，又不像后来那家公司一样
委曲求全、迁就于开发中心那套明显不合时宜的分散式方
案呢？
2 一些题外话
国内好几家大型国有银行都在最近几年里先后创建了
相对独立的软件研发机构（在电信、能源、电力等其他行
业也有类似的现象）。很多人对此困惑不解：银行又不是软
件企业，为什么需要专门的开发中心？如果银行的软件都
由开发中心来开发，那还要其他软件开发商干什么？
据说，这个问题的答案和几年前曾一度流行的“IT 外
包”的论调有关。以前，国有银行中的IT 人才主要集中在
总行和各分行的科技部门，他们负责行内IT 系统的维护及
一部分软件开发工作。银行内部使用的软件主要通过外购
（核心业务系统和技术难度较大的外围应用）和自研（包
含个性化业务流程的系统和技术难度较小的外围应用）两
种途径解决。曾几何时，国内IT 界一度盛传：大型企业只
有将IT 系统的研发与管理完全外包，才能最大限度地节省
成本和提高IT 水平，才能在加入WTO 后有充足的实力与
国外企业竞争。
不过，对于大型国有企业，尤其是大型国有银行来说，
IT 外包是一件说起来容易，做起来困难重重的事情。且不
说国内银行是否敢于像某些早已实现了IT 外包的外国银
行那样让其他企业管理自己的机密数据，单是大型国有银
行里动辄成千上万的IT 职员的去留问题，就会让所有侈谈
外包的人叫苦连天。于是乎，国内的银行纷纷摸索出了一
条有中国特色的IT“外包”之路：先投资建设独立经营、
独立核算的软件开发中心，把银行内部水平较高的IT 人才
聚集在一起；然后，循序渐进地让开发中心承担起大部分
自用软件的研发工作，统一全行的软件版本；等到时机成
熟时，直接将软件开发中心的牌子换成“某某软件公司”，
实现银行的IT 业务整体外包。
这个思路看起来天衣无缝，也为今后的发展留下了足
够的余地——即便将来不再需要IT 外包的运营模式，银行
也可轻易将开发中心变回总行直辖的IT 部门，继续以传统
方式维持它的运转。唯一美中不足的是，这样的软件开发
中心（或未来的某某公司）一下子变成了所有混迹在金融
行业的软件公司和系统集成商的竞争对手——这是极其恐
怖的一件事，因为在其他条件相当的情况下，外人无论如
何也竞争不过银行自己的亲骨肉呀！
幸好，最恐怖的一天还没有降临。在不少银行的实际
操作过程里，类似的开发中心都成了行内闲散IT 职员安置
和分流的最好去处。这样做的结果是，许多开发中心的管
理方式承袭了国有企业的不少沉疴痼疾，外行领导内行的
现象屡见不鲜，开发人员的技术素质和工作效率也着实堪
忧，开发中心的整体研发水平离最初的设想相去甚远。正
因为如此，一些与银行关系不错，也有相当技术实力的企
业才获得了和开发中心合作开发软件产品的机会，开发中
心与其他公司的竞争也没有立刻导致行业垄断现象的出
现。
不知道以上解释能否对读者理解本文案例的背景提供
一些帮助。本文的主旨在于讨论软件开发过程中的沟通技
巧，但在案例分析之前，读者最好能够知道：案例中的“我”
是合作公司的一员，“老H”是开发中心的代表，而开发中
心又是银行（也就是待开发软件的实际客户）所创立的独
资机构，这种合作本身就是一种不平等的合作关系。简言
之，在类似的合作过程里，开发中心可以随时炒合作伙伴
的鱿鱼，而我们这样的公司却无法随心所欲地炒掉开发中
心——除非我们再也不想做这家银行的任何生意。
3 案例分析
无论我们怎样强调沟通在软件开发中的重要性都不算
过分，因为今天的软件开发归根结底是一种团队协作的过
程，而有效的沟通恰恰是保证团队目标和行为一致性的最
佳手段。
事实上，几乎所有重量级的和轻量级的软件工程理论
都为项目过程中的沟通设计了不同的方法和模型。举例来
说，微软解决方案框架（MSF）中给出的沟通模型如图 1
所示①。
图 1 MSF 项目沟通模型
在图 1 中我们可以看到，软件开发项目里的沟通至少
包括以下类型：
程序管理
开发
测试
发布管理
产品管理用户体验
业务视角
技术视角
最终用户
最终用户客户
运营和支
持部门
项目发
起人
技术委员会
项目组
.. 项目组内部的沟通——项目组内不同工作角色
（MSF 建议的基本工作角色有6 种）之间的沟
通，这包括：
.. 与业务相关的沟通：
.. 项目组成员间就产品规划和产品管理
所做的沟通；
.. 就软件需求和规格说明所做的沟通；
.. 就软件的功能测试所做的沟通；
.. ..
.. 与技术相关的沟通
.. 开发人员内部的沟通；
.. 项目管理人员和开发人员之间的沟
通；
.. 开发人员和软件发布人员之间的沟
通；
.. 开发人员和技术支持人员之间的沟
通；
.. ..
.. 项目组外部的沟通——项目组各工作角色与项
目组外部相关人员的沟通，这包括：
.. 与业务相关的沟通：
.. 与客户的沟通（讨论业务流程、软件
交付方式等主要需求）；
.. 与项目发起人和管理者的沟通（讨论
项目进度和项目结果）；
.. 与最终用户的沟通（讨论软件的操作
方式等需求细节）；
.. ..
.. 与技术相关的沟通：
.. 与公司内的技术委员会或技术负责人
的沟通（技术评审）；
.. 与运营和支持部门的沟通（软件发布
和支持事宜）；
.. 与最终用户的沟通（为最终用户提供
技术支持和帮助）；
.. ..
尽管不同的软件工程理论对项目沟通的分类不尽相
同，但以MSF 的项目沟通模型为依据，我们大体可以知道：
在一个常见的软件开发项目里，开发者必须妥善地处理好
项目组内部、项目组外部等不同类型的沟通工作；对于不
同的沟通对象（如项目组内部的不同工作角色和项目组外
部的不同利益体），开发者也必须能够区别对待，用不同的
技巧和方法解决沟通方面的问题。
结合这里给出的分类体系，考察我在本文案例中描述
的沟通过程，我们不难发现，我和开发中心老H 的沟通其
实并不仅仅是项目组内不同角色或不同管理者之间的沟
通。事实上，老H 既是项目组的管理者之一，又是我们的
合作伙伴，还同时是软件的客户（银行）所创立的研发机
构的一员。老H 身份的复杂性决定了我们之间的沟通既涵
盖了项目组内部的沟通，又涵盖了项目组外部的沟通。如
果我自始至终用同一种沟通方式与老H 交流，我们的沟通
就必然会遇到麻烦——很显然，这是我在案例中沟通失败，
并最终丧失了与开发中心的合作机会的重要原因之一。
那么，我们到底该如何有区别地应对不同类型的沟通
需求呢？
沟通是人与人之间的交流方式，人是参与沟通的主体。
沟通类型的不同主要体现在参与沟通的主体不同，而不同
的主体在沟通的过程中都会有不同的行为特征和个性需
求。
这段话听上去颇为费解，喜欢钻研技术的程序员可能
不喜欢这样的讲述方式。没关系，我们可以用一个与软件
开发有关的例子来说明问题。
如果我们把软件内部的每个单元都看成是有灵性的个
体，那么，在软件运行过程中，软件内部也存在相当频繁
的沟通行为（当然，软件也有外部沟通行为，比如软件的
用户界面和操作者之间的沟通，但我们在这里只讨论软件
内部的沟通）。比如说，服务程序和客户程序间的每一次消
息传递，应用服务对数据库的每一次交易请求，界面代码
每一次调用图表控件的绘图操作，流程定义程序用XML
语言记录并传递给工作流引擎的每一个业务模型..它们
都是一次软件内部的沟通。一个优秀的软件总能保证所有
内部沟通行为的顺利进行，而一个失败的软件却总会在某
个沟通的环节中阻碍信息的正常交流。从这个意义上说，
只要我们能用某种技术手段定义和管理软件内部的沟通过
程，确保沟通渠道的畅通无阻，我们开发出来的软件就一
定能在实际运行环境中有上佳的表现。
在这个思路的指引下，许多技术手段都可以起到强化
软件内部沟通的作用。比如，我在《从“魔力整合针线”
谈起》一文中谈到过软件接口设计的问题②，其实，软件接
口就是我们为软件组件、模块或子系统之间的沟通定义的
行为规则，接口设计的优劣与否主要在于该接口能否保证
沟通双方对沟通目标及行为规则有一致的理解和认识。再
比如，当我们仔细研究面向对象代码中的类与类之间，方
法与方法之间的沟通问题时，我们不难发现，如果能为每
个类或方法定义出一套完整的沟通规则，比如详细描述类
和方法的外部接口，定义它们在沟通前后必须满足的逻辑
规则，给出一旦出现沟通障碍时的补救措施，同时用规范
的、可被计算机理解的语法将它们记录下来，我们不就能
在最大程度上保证软件内部沟通的顺畅，并最终提高软件
的质量和可用性了吗？更进一步地说，假如用一个生活中
常见的术语（例如“契约”）来称呼这种形式化的沟通规则，
我们不就得到了一种全新的设计理念——契约式设计
（Design by Contract）了吗？
千万别误会，我绝不是在冒充契约式设计的发明人
Bertrand Meyer，我的意思其实是说，契约式设计并没有我
们想象的那么神秘，它只是对软件内部沟通规则的一种描
述方式而已。在契约式设计的最佳诠释者——Eiffel 语言
里，一份典型的契约代码（也就是我所说的沟通规则）如
下所示：
class
COMMUNICATION
feature
sample is
require
-- 方法执行（沟通）前必须满足的条件
do
-- 方法执行（沟通）过程
ensure
-- 方法执行（沟通）后必须满足的条件
rescue
-- 方法（沟通）出现问题时的补救措施
end
end
Eiffel 语言定义的契约体现了类与类或方法与方法之
间的沟通规则，如果把这样的契约形式移植到人与人的沟
通过程中，它是不是仍能发挥作用呢？应当说，Eiffel 语
言中与契约和异常处理相关的语法同样反映了人际沟通中
的某些基本准则，这主要包括：
第一，沟通双方在正式沟通之前，应满足某些前提条
件，如双方对将要讨论的议题表示认可，双方都对讨论对
象非常熟悉等等。这些前提条件大致相当于Eiffel 语言中
的require 代码块。拿本文案例来说，我和老H 之间的沟
通基本满足这一原则，因为我们当时都对分散式或集中式
的架构方案相当了解，讨论时也有大家认可的议题——确
定软件的架构方案。
第二，沟通过程应有既定的步骤和双方认可的沟通渠
道。Eiffel 语言中每个方法的do 代码块就是对沟通渠道和
步骤的定义。我和老H 的沟通也有既定的渠道和步骤，因
为我和老H 都有项目管理的经验，使用会议、闲聊、电子
邮件等不同的沟通渠道时也不存在任何障碍。
第三，沟通双方应尽量保证此次沟通的结果满足某种
既定条件——该条件是确保今后沟通顺利进行的充分必要
条件。这一准则可以对应于Eiffel 语言中的ensure 代码块。
在本文案例中，我在每次和老H 沟通时都必须确保的一个
重要条件是，我们公司和开发中心的合作关系不会就此破
裂；而老H 作为客户方的开发人员，就无需确保此条件
100%成立。这类似于Eiffel 中两个相互调用的方法，其中
一个有颇为繁复的ensure 代码块，而另一个则丝毫不用考
虑方法执行的后果。在这种不对等的沟通过程里，我最终
因为忍无可忍而错误地选择了与老H 分庭抗礼的沟通方
式，破坏了自己既定的沟通底线，这是我沟通失败的直接
原因。
最后，沟通双方应对可能出现的沟通问题有足够的思
想准备，并预先设计好补救措施。这相当于Eiffel 语言中
的rescue 代码块。案例中的我显然对沟通过程中可能出现
老H 等人不按技术常理思考问题的情况准备不足，当不正
常的沟通重复了30 多次后，我的异常处理代码（其实是我
以前积累的人际关系处理经验）彻底崩溃，并最终导致沟
通失败。实际上，如果在讨论之前多准备一种应急预案（例
如，当对方胡搅蛮缠时，一面暂停沟通，一面要求公司里
的相关销售代表到现场做协调工作），我可能就不会那么被
动了。
总之，Eiffel 语言提醒我们，在人际沟通之前，参与
沟通的双方最好能针对不同的沟通对象、不同的沟通渠道，
制定出最合理的沟通契约，并在沟通时将其付诸实践。比
方说，案例中的老H 既是我们的合作开发伙伴，也是客户
方的技术代表，又是项目的管理者，他的多重身份对沟通
的影响力不言而喻。我必须在沟通前对各种可能发生的情
况做好准备，否则就会在沟通中迷失方向。
但是，我和老H 的沟通失败仅仅是由于我在沟通前的
准备不足吗？其中是不是还有更深层的原因呢？没错，我
和老H 沟通失败的例子反映出了人际沟通的一个重要特
质：
参与沟通的每个人都会有自己特定的目标或利益关注
点。
这个特质在Eiffel 语言中找不到对应的语法。原因很
简单：Eiffel 语言的契约是为软件单元之间的沟通服务的，
而软件单元只会按照程序员给定的流程或规则工作，而不
会像活生生的人那样有自己的利益诉求。我们从来也没有
听说过哪个OCX 控件会在响应WM_PAINT 消息时，根据
自己的阶段性目标（如在1 小时内占据所有CPU 资源或赢
得另一个OCX 控件的青睐）来选择背景颜色，但我们却
经常见到沟通中的某个人既要借东西又怕丢面子，不得不
使用拐弯抹角的沟通方式③。
也就是说，除了上面已经谈到的一般契约以外，我们
在人际沟通时还必须注意对方的真正意图。如果一定要用
类似Eiffel 语言的形式来描述完整的人际沟通契约，那我
们多半要为Eiffel 语言添加一个purpose 关键字，形成下面
这样的“Human Eiffel”语言（仿照Bertrand Meyer 的做法，
我们可以把由此定义的沟通过程称为“契约式沟通”）：
class
COMMUNICATION
feature
sample is
purpose
-- 沟通主体的真实目标
require
-- 沟通前必须满足的条件
do
-- 沟通的渠道和步骤
ensure
-- 沟通后必须满足的条件
rescue
-- 沟通出现问题时的补救措施
end
end
在这里，之所以说purpose 代码块体现的是沟通主体
的“真实”目标，这是因为，任何一个具有独立思维能力
的人，都会在沟通过程中选择对自己有利的沟通方式，并
或多或少地隐藏自己的真实意图。当然，是否暴露沟通目
标也和每个人的文化背景及生活习惯有关，外国人大都喜
欢在技术交流时直抒己见，而中国人则往往会采取委婉或
折中的表达方式。从这个角度说，我们这些中国程序员在
与人沟通时，更应当留意对方的真实动机，免得自己在一
无所知的情况下走向失败。
在本文的案例中，我之所以无法说服老H，就是因为
我根本不了解他的真实意图。我当时完全从技术角度出发
考虑问题，满以为是为银行和开发中心的利益着想。但在
无数次与老H 据理力争的时候，我竟从未想过，老H 是不
是也像我一样，除了技术问题以外心无旁骛。即便在我已
经发现老H 是在胡搅蛮缠的时候，我也没有往技术以外的
因素上多想一想。实际上，当我自认为理直气壮并站起来
与老H 当面争论的时候，我的目标（开发最优秀的软件产
品）已经与老H 的目标不知相差几千里了！
事后，经过我们公司一名销售人员的深入调查，我才
完全弄明白了老H 当时的真实想法：开发中心沿袭了不少
国有企业的弊端，老H 等中层经理要想出人头地，必须在
确保学历和资历的情况下，不犯任何错误，并尽量讨取领
导的欢心；对于我们开发的软件项目，老H 的一位直接领
导已经在马来西亚考察过某银行的一个类似系统，该系统
使用的就是分散式架构；那位不大懂行的领导回国后，仅
仅说了几句赞扬分散式架构的话，懂行的老H就立刻认定，
分散式架构是唯一的选择；其实，与其说分散式架构是唯
一的选择，还不如说，分散式架构是保证老H 的前程绝对
安全的唯一选择。
唉，现在的我真是追悔莫及！如果我和老H 沟通时，
懂得揣摩对方的真实动机..当时我有30 多次机会打探
老H 的想法，但我竟把所有时间都浪费在无谓的技术讨论
中了！哪怕我多问自己几个为什么，哪怕我在发现老H 胡
搅蛮缠时，请求相关的销售人员和老H 拉拉关系，套一套
他的心里话，我们的项目就不会以失败而告终。而且，当
得知老H 的真实意图后，如果运作得当，我们甚至可以改
变老H 及其领导对分散式架构的认识。例如，只要让销售
人员安排老H及其领导参观我们在其他银行实现的集中式
架构的成功案例，告诉他们使用集中式架构的风险更低，
更容易保证系统顺利上线（这句话的潜台词是集中式架构
对他们的前程更为有利），我们提出的集中式方案就完全可
能成为开发中心首选的架构方案。这种一举两得的事情，
为什么我连试都没有试过呢？
总而言之，一旦在技术沟通中出现龃龉，且问题的根
源无法被归入技术范畴，我们就需要深入了解对方在沟通
时到底持有什么样的态度，或怀有什么样的目的。只有这
样，我们才能设法将沟通参与者各自持有的不同目标引导
到一个共赢的道路上。沟通的最终结果必然是妥协，而妥
协的前提是了解所有参与者的真实意图。用心理学的术语
来讲，这种沟通技巧其实是一种在“同理心（Empathy）”
指导下的沟通，即在发生冲突或误解的时候，当事人如果
能依据“人同此心，心同此理”的思维方式，站在对方的
角度想一想，也许就可以更容易地了解对方的初衷，找到
最佳的沟通方法了。
当然，这里说的“妥协”并不是无原则的迁就，研究
对方的意图也不是要我们在沟通时极尽钩心斗角之能事。
任何技术沟通的目的都是协作和共赢，而非指摘和攻讦—
—无论我们的沟通对象是同事、客户还是合作伙伴，我们
都应时刻铭记这一点。
4 补充说明
本文在讨论沟通时，更多地谈到了人际沟通的准则和
特质。在实际软件开发项目的沟通过程中，我们还必须努
力学习各种具体的沟通方法。比如，安排和举行电话会议
的方法，用PowerPoint 等展示工具向客户介绍软件产品的
方法，用客观的对比数据说服自己老板购买某种开发工具
的方法，使用电子邮件激励项目组成员的方法等，都需要
我们仔细总结和归纳。
另一个和沟通紧密相关的小问题是：在技术沟通之前，
沟通双方应确保对技术名词和技术术语的认识完全一致。
名不正则言不顺，统一认识显然是任何沟通都要具备的前
提条件了。GoF 的《设计模式》一书已经指出，对23 个
设计模式的统一命名有助于提高技术人员的沟通效率④，这
从另一个侧面证明了统一的名词术语表对于沟通的重要
性。
事实上，我就见过一次因为术语不一致而导致的沟通
混乱。当时，两个系统分析员一起讨论某个软件应包含多
少个子系统。系统分析员甲因为经常开发分布式系统，他
脑海里的“子系统”概念实际上可以直接对应于分布式系
统中某个可独立部署的组件；系统分析员乙则对使用面向
对象的方式开发单机软件较为熟悉，他脑海里的“子系统”
其实是一组拥有特定接口、职责相似的类的集合。就这样，
两个人各自带着对子系统的不同认识，就所谓的“子系统
数量”问题争论个不亦乐乎，没完没了。直到有旁观者发
现他们的争论根本就是驴唇不对马嘴时，他们才恍然大悟，
原来在技术沟通之前，还有必要交流一下各自的“行话”
或“俚语”呢。
5 总结一下
.. 沟通也需要遵循某些既定的规则；
.. 沟通中最重要的是要了解对方的真实意图；
.. 沟通的终极目标是协作和共赢。
① Microsoft. MSF Team Model.
http://www.microsoft.com/msf/, 2003
② 王咏刚. 从“魔力整合针线”谈起. 程序员. 2003 年8 月.
③ Rexmen. 人与人的相处.
http://mis.im.tku.edu.tw/~rex14a/p&p/, 2004
④ Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns:
Elements of Reusable Object-Oriented Software. Reading,
Mass.: Addison-Wesley, 1995
本文地址：http://com.8s8s.com/it/it24824.htm