按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
世界的通用语（ 当然，前提你的项目组也懂得这种语言） 。
在韩愈的《答陈生书》中，他因自己不会“速化之术”，
所以说陈生是“求道于盲”。然而他用了一个不恰当的比
喻：要知道盲人并非不知道路如何走，只是他不能象常人
一样描述他所知道的路。因此“问道于盲”是没有错误的，
真正错误的是你睁着眼睛问。
我们需要在正常人与盲人之间建立一种沟通的方式，
既然盲人不能睁开眼睛，那么你就闭上眼睛好了。
…48
…………………………………………………………Page 53……………………………………………………………
『大道至简』
UML 图在一些客户眼里无异于盲人的世界，如果需
要向他们做需求调研，你只能使用一种这些客户能够理解
和接受的方式，例如表格、流程图以及……更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种
方式是不是 UML ，以及用 UML 表达得是否正确。——客
户是因为他认为你理解了他们的需求，而在“需求确认书”
上签字，而不是因为你的 UML 画得是否精准。
现在来思考：为什么非要让客户看UML 图呢？如果
有能够满足“极限编程（XP） ”所要求的“现场客户① ”，那
当然可以不画用例图；相反，如果客户雇了一个专家组来
评审需求，那么你就老老实实地画用例图好了。
需要留意的是，专家组还要一种方式与客户沟通，这
有可能不是 UML 。——当然，客户愿意增加沟通成本，
那是他们的事。
一旦源头确定，你就可以接下来约定在项目组中要使
用的沟通方式。愚公——这个伟大的项目经理——所使用
的“聚室而谋曰”，就是很好的沟通方式。当然，如果客
户精通 UML ，那么我想愚公采用的项目沟通方式将会是
“聚室而论UML ”。我想一定会这样，因为愚公是很懂得
沟通的、伟大的项目经理。
① 这是极限编程的特征之一，指的是要求客户可以在程序员开发
的第一现场，随时可以向程序员确认完成功能的有效性，以及修
正需求或者先前的需求描述。
…49
…………………………………………………………Page 54……………………………………………………………
第 4 章 流于形式的沟通
3。 最简沟通
在 D 项目中，我向我的项目组员提出在需求阶段与
客户的沟通计划。这个计划只有三条：
） 在一个月中，只能跟客户作三次联系；
） 三次联系中，最多只能有一次面谈的机会；
） 一个月后，提交全部的需求调研报告、需求分析
和关于该项目的远景规划。
D 项目并不大，所以从主观上来讲，客户（代表） 并不
会为这个项目投入太多的精力。重要的是，我们在前期交
涉中已经发现：这个客户代表为大量其它的项目和工作所
困扰，他不会有时间来处理我们的问题。因此，减少沟通
和保障沟通质量的问题就显得非常突出。
在大多数的项目中，这样的问题都是存在的。真正能
满足极限编程（XP）所提出的“现场客户”的情形并不经常
出现。即使能将程序员送到客户现场中去，沟通问题仍然
是不可避免的。
因此在 D 项目中我提出了“最简沟通”。
我们开始在网络上查看相关的软件系统的特征以抽
取客户所关注的内容；了解该客户的公司、经营理念、组
织结构形式以及工作模式；了解同类公司的成功经验和优
秀的管理模式，以及客户的竞争对手在做什么和在关心什
么……
最后，我们开始综合以下两个方面的因素：
…50
…………………………………………………………Page 55……………………………………………………………
『大道至简』
） 客户在公司层面的外在表现、内部机制和运营管
理手段。
） 客户在项目中既已明确的需求和可能发生的需
求，以及客户围绕其公司行为（和方向）所提出的
需求。
这样我们就了解了客户项目中所有会产生需求的信
息点。
我们开始设计提问，每一个提问涵盖尽可能多的信息
点，尽可能的具有发散性以便形成更多的推论和假设。
我们把这些做成项目概要用 mail 提交给客户，并在
第二天电话回访他。他以口头的形式回复了这封 mail ，这
让我们尽可能地得到了项目在方向上修正。
我们确定了项目的实际目标，以及远期的方向。接下
来就是设计需求条目。
客户已经先期提供了一些关于项目的文档、报表和工
作数据。因此基于这些数据的需求分析，将是下一个沟通
前所进行的最坚苦的工作。项目组员被要求：
） 分析用户的每一个表格，以构建基础数据库；
） 分析每一条数据的含义以确定它的上下限，以及
数据间的相关性；
） 从工作文档中去了解客户的组织机构及其相互
关系，同时确定了每一类使用该系统的角色；
） 从报表中去了解客户关注的数据信息，以及被他
们所忽略掉的数据信息。
我们从数百条的需求条目中，整理出系统结构和模
…51
…………………………………………………………Page 56……………………………………………………………
第 4 章 流于形式的沟通
块，需求条目被映射到各个模块。我们很快画出了模块间
的相互关系图，并通过这个图分析了数据交叉关系，设计
了相应的数据索引并增加了一些新的关系性数据。
我们对用户角色、原始数据和系统结构进行了梳理之
后，我们花了很短的时间实现了第一个系统模型。当然，
很多的功能项目，我们都只是简单 show a dialog 。但我们
优化了每一个操作流程，以保证不同的用户（角色）在使用
时都尽可能流畅。
这一次的沟通我们使用了面对面的模式。我们很庆幸
的得到了与这个系统的每一类用户（角色）接触的机会，而
正好我们有一个模型，我们便让他们来操作并提出意见。
这一次我们终于有了一份详尽的的调研报告。
接下来的分析设计是顺理成章的事。我们在一个月后
完成了这个项目的需求分析报告，以及在这个分析上的一
些框架型的设计。还有，一个被用户所接受的原始模型。
——尽管，第三次的沟通中还发现了一些问题。但我
们终于有了一个好的开端。
应该清楚的是，保障每一次沟通的有效性都是最重要
的事。沟通不是打电话或者请客户吃饭那么简单的事。你
得到的每一次沟通机会，都是向客户了解更深层次的需求
的机会，因此最好在见到客户之前，你就已经设计了所有
的问题和提问方式。
吃饭并不是有效的沟通。大多数时候，那将以酒醉收
…52
…………………………………………………………Page 57……………………………………………………………
『大道至简』
场。
4。 为不存在的角色留下沟通的渠道
大多数人不会知道，我们中国的“五千年文明史”实
际上仅有三千年“有史可查”。
司马迁在史记中写道：“维三代尚矣，年纪不可
考，……于是略推，作三代世表”。也就是说，他在写史
记时“（夏商周）三代”的年代已经不可考了，因此只能做
“世表”；而其后十二诸候国的年代才可考证，因而有“（十
二诸侯）年表”。
世表和年表的准确性和可靠性有明显的差异，因此我
国古代编年史能追溯到的上限，就成了《史记·十二诸侯
年表》中记载的西周共和元年，亦即公元前 841 年。
司马迁无法做夏商周三代的年表是因为其年代不可
…53
…………………………………………………………Page 58……………………………………………………………
第 4 章 流于形式的沟通
考，这是因为自黄帝以来的许多文献材料部分虽有年数，
但比较模糊且不一致，所以他只能弃而不用。
现在国家在“夏商周断代工程”中再次推算和考证编
年史，这些相关资料也同样只做参考，实际采用的方法是
更有可信度的金文（记载） 、历史学、天文学、碳…14 测年
等。
资料的缺失、及其有效性的缺乏，给中国编年史撰写
带来了莫大的困难。
项目的中断和中止，与历史产生断层的内因是一致
的。——我发现很多的项目（尤其是产品计划）在负责人员
离开后，就自然而然地死掉了。我把这一切的原因归咎于
“没有history ”。
在先人写“谱牒”（简、册） 时想必是没有考虑过后人
要读的，或者更为远古的先人可能根本没想过要留下他们
的生活和部落记录，再加上有象秦始皇这样的人在前面放
火烧东西，所以司马迁拿不到夏商周三代的确切史料，也
是情理之中的事了。
——远古的先人不知道司马迁这一号角色的存在，司
马迁也没有办法跟古人约定一下要留点记录给他写《史
记》。
我 们 做 项 目 的 时 候 ， 如 �