第4章 流于形式的沟通
“足下求速化之术，不于其人，乃以访愈，是所谓借听于聋，求道于盲。”
——唐·韩愈《答陈生书》
1. 客户不会用 C，难道就会用 UML 吗？
我们总是要先接触客户的，是的，如果不这样，我们将无法确知要做什么。
作为开发人员，可能更希望客户能学习或者精通 C语言，这样客户就知道开发人员正在做什么，以及有多么地勤劳。或者，这样的客户还能以 C 语言的方式告诉开发人员他们究竟想要什么。
然而要求客户学习 C 语言明显是自杀式的行为。在客户(的代表)学会用 C语言来向开发人员描述他们的需求之前，可能他就已经被老板开掉了。因此没有客户会笨愿意用 C 语言来描述他们的需求。
C 语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。
因此在前面所提到的 R 模型中，开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解 C 语言，也可以用一种非 C 的语言来与客户交流(比如说汉语)。
——或者你更愿意开发人员尽早地进入状态，那么你可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研”，如果他不能适应这种转变，那就别让他去。——那会是灾难的开始。
要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉的业务。但这往往我们所做不到的，因为我们是软件公司，而不是做这些(客户的)业务的公司。这时惯常的做法是聘请行业咨询公司(或者个人)来介入需求阶段，协助了解和分析需求。
他们总是很喜欢把事情搞得很复杂，所以他们会说这一切的过程有个专用名词，“En...这叫需求建模”他们很专业地说。
现在你应该发现了差距。比如我们的项目经理，以及那个被调来充当调研角色的程序员，他们就不会什么“需求建模”.
接下来咨询公司会与我们的客户一起做业务建模，然后再做业务到需求的映射，再抽取需求并完成需求建模。他们做业务建模的时候，可能使用一些客户业务范畴内的符号和标识；而在做需求建模时，则需要使用一些软件行业中(的设计和分析人员)习惯的符号和标识。
这些符号和标识也有个专用名称，“En...这个叫模型语言(ML)。”他们无时无刻不在向你展现他们的专业(这已经是他们还存在的唯一原因了)。
如果他们更加专业，他们会告诉你他们用的是 UML。向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将大放异彩。
UML是模型世界里的世界语 。
到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：与客户如何交流？
他们的解决之道是模型语言。
有什么差别吗？
程序员不能要求客户会 C Language，难道需求分析师们就能要求客户会 Modeling Language 吗？！
2. 项目文档真的可以用甲骨文来写
独孤木 (http://www.javaworld.com.tw/) 曾经在一篇《UML, OOAD and RUP》中讨论到 UML 实际应用中的问题。其中的两个问题是：
A: “大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件(User Case)的正确性与完整性。”
B:“除了客户不了解 UML，OOAD 跟 RUP 以外，另外一个更糟糕的现象就是 project team 里面的人也不懂。”
这实在是很有趣的事。
看来在一些情况下，在项目中使用 UML 只是完全不懂的老板，以及什么都懂的博士的主意，而真实的场景中去做事的那些客户与项目成员，其实是未见得就能用好UML 的。
仅以 UML 的 User Case 来说，由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如果去实作。图则很简单，就是几个图形符号来描述系统边界和角色关系。
显然甲骨文也能描述范围与关系。例如甲骨文中的“家”这个字，就是上有房子下有猪 ，这个边界就定义得很好；在古文中，“三”通常是泛指，跟UML图中的线条上标注的那个“*”是同义的，而甲骨文中“众”这个字，就是日字下立有三个人，也就是在同一个日头下做事的很多人即为“众”，这个关系也描述得很确切。
所以只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。同样的，只要约定一套“语法”，你同样可以用甲骨文来做活动图、类图、构件图??以及这些图相关的规约。相比来说，古巴比伦人使用的楔形文字“象形性”差一些，因此我不建议用它来画用例图。
既然甲骨文可以用来做为一种模型语言(同时它也是一种文字和口头的语言)，那么，如果你的项目中面对的对象是商周文化的考古学家，以及你的项目组都由精通这种语言的成员构成，这时你就可以用甲骨文来做项目文档，以及画各种模型图例。
你要明白，要让考古学家看懂用例图，难度远大于看懂甲骨文。与其要求他们学一种语言，不如使用他们那个世界的通用语(当然，前提你的项目组也懂得这种语言)。
在韩愈的《答陈生书》中，他因自己不会“速化之术”，所以说陈生是“求道于盲”。然而他用了一个不恰当的比喻：要知道盲人并非不知道路如何走，只是他不能象常人一样描述他所知道的路。因此“问道于盲”是没有错误的，真正错误的是你睁着眼睛问。
我们需要在正常人与盲人之间建立一种沟通的方式，既然盲人不能睁开眼睛，那么你就闭上眼睛好了。
UML 图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及??更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种方式是不是 UML，以及用 UML 表达得是否正确。——客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的 UML 画得是否精准。
现在来思考：为什么非要让客户看UML图呢？如果有能够满足“极限编程(XP)”所要求的“现场客户 ”，那当然可以不画用例图；相反，如果客户雇了一个专家组来
评审需求，那么你就老老实实地画用例图好了。 需要留意的是，专家组还要一种方式与客户沟通，这有可能不是 UML。——当然，客户愿意增加沟通成本，那是他们的事。
一旦源头确定，你就可以接下来约定在项目组中要使用的沟通方式。愚公——这个伟大的项目经理——所使用的“聚室而谋曰”，就是很好的沟通方式。当然，如果客户精通 UML，那么我想愚公采用的项目沟通方式将会是“聚室而论 UML”。我想一定会这样，因为愚公是很懂得沟通的、伟大的项目经理。
3. 最简沟通
在 D 项目中，我向我的项目组员提出在需求阶段与客户的沟通计划。这个计划只有三条：
A: 在一个月中，只能跟客户作三次联系；
B: 三次联系中，最多只能有一次面谈的机会；
C: 一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划。
D 项目并不大，所以从主观上来讲，客户(代表)并不会为这个项目投入太多的精力。重要的是，我们在前期交涉中已经发现：这个客户代表为大量其它的项目和工作所困扰，他不会有时间来处理我们的问题。因此，减少沟通和保障沟通质量的问题就显得非常突出。
在大多数的项目中，这样的问题都是存在的。真正能满足极限编程(XP)所提出的“现场客户”的情形并不经常出现。即使能将程序员送到客户现场中去，沟通问题仍然是不可避免的。
因此在 D 项目中我提出了“最简沟通”。
我们开始在网络上查看相关的软件系统的特征以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式以及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手在做什么和在关心什么
最后，我们开始综合以下两个方面的因素：
A:客户在公司层面的外在表现、内部机制和运营管理手段。
B: 客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求。
这样我们就了解了客户项目中所有会产生需求的信息点。
我们开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设。
我们把这些做成项目概要用 mail 提交给客户，并在第二天电话回访他。他以口头的形式回复了这封 mail，这让我们尽可能地得到了项目在方向上修正。
我们确定了项目的实际目标，以及远期的方向。接下来就是设计需求条目。
客户已经先期提供了一些关于项目的文档、报表和工作数据。因此基于这些数据的需求分析，将是下一个沟通前所进行的最坚苦的工作。项目组员被要求：
A:分析用户的每一个表格，以构建基础数据库；
B:分析每一条数据的含义以确定它的上下限，以及数据间的相关性；
C:从工作文档中去了解客户的组织机构及其相互关系，同时确定了每一类使用该系统的角色；
D:从报表中去了解客户关注的数据信息，以及被他们所忽略掉的数据信息。
我们从数百条的需求条目中，整理出系统结构和模块，需求条目被映射到各个模块。我们很快画出了模块间的相互关系图，并通过这个图分析了数据交叉关系，设计了相应的数据索引并增加了一些新的关系性数据。
我们对用户角色、原始数据和系统结构进行了梳理之后，我们花了很短的时间实现了第一个系统模型。当然，很多的功能项目，我们都只是简单 show a dialog。但我们优化了每一个操作流程，以保证不同的用户(角色)在使用时都尽可能流畅。
这一次的沟通我们使用了面对面的模式。我们很庆幸的得到了与这个系统的每一类用户(角色)接触的机会，而正好我们有一个模型，我们便让他们来操作并提出意见。这一次我们终于有了一份详尽的的调研报告。
接下来的分析设计是顺理成章的事。我们在一个月后完成了这个项目的需求分析报告，以及在这个分析上的一些框架型的设计。还有，一个被用户所接受的原始模型。 ——尽管，第三次的沟通中还发现了一些问题。但我们终于有了一个好的开端。
应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
吃饭并不是有效的沟通。大多数时候，那将以酒醉收场。
4. 为不存在的角色留下沟通的渠道
大多数人不会知道，我们中国的“五千年文明史”实际上仅有三千年“有史可查”。
司马迁在史记中写道：“维三代尚矣，年纪不可考，于是略推，作三代世表”。也就是说，他在写史记时“(夏商周)三代”的年代已经不可考了，因此只能做“世表”；而其后十二诸候国的年代才可考证，因而有“(十二诸侯)年表”。
世表和年表的准确性和可靠性有明显的差异，因此我国古代编年史能追溯到的上限，就成了《史记·十二诸侯年表》中记载的西周共和元年，亦即公元前 841 年。
司马迁无法做夏商周三代的年表是因为其年代不可考，这是因为自黄帝以来的许多文献材料部分虽有年数，但比较模糊且不一致，所以他只能弃而不用。
现在国家在“夏商周断代工程”中再次推算和考证编年史，这些相关资料也同样只做参考，实际采用的方法是更有可信度的金文(记载)、历史学、天文学、碳-14 测年等。
资料的缺失、及其有效性的缺乏，给中国编年史撰写带来了莫大的困难。
项目的中断和中止，与历史产生断层的内因是一致的。——我发现很多的项目(尤其是产品计划)在负责人员离开后，就自然而然地死掉了。我把这一切的原因归咎于“没有 history”。
在先人写“谱牒”(简、册)时想必是没有考虑过后人要读的，或者更为远古的先人可能根本没想过要留下他们的生活和部落记录，再加上有象秦始皇这样的人在前面放火烧东西，所以司马迁拿不到夏商周三代的确切史料，也是情理之中的事了。
——远古的先人不知道司马迁这一号角色的存在，司马迁也没有办法跟古人约定一下要留点记录给他写《史记》。
我们做项目的时候，如果也不留下历史记录(History)，那么以后别人来看这个项目，也会是两眼一抹黑，要么就象司马迁一样“存而不论”，项目便就此中止；要么就象“夏商周断代工程”一样，花大量的人力物力来攻关。
维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道呢？
我把项目的 History 作为跟这种“不存在的角色”沟通的一种方式。History 的丰富和准确为项目的后继开发、维护提供了可能。
历史记录(History)与注释(Comment)不是一回事。代码中的注释是为阅读代码而留备的，而 History 是为整个项目而记录的。一些参考的记录内容有：
A:需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；
B:设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性)；
C:开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；
D:测试阶段：还记得测试用例和测试报告吗？那是最好的 history 之一。
当然，另一件最重要的事，是记得在每一笔记录后写下时间和你的名字。你的每一笔记录都是打算留给一些根本不了解这个项目的人看的，之所以要记下你的名字，是便于那些人能够再找到你并溯源到问题的源头。——当然，这得赶在你和古人一样“与天地共存”之前。
我们知道，大多数的工具都有历史记录的功能。在开发工具和测试工具中尤为突出。此外，版本管理工具也留下了每个阶段的印迹。然而，我不建议过于信任它们 ，如果不明确要求项目组员写下详细的History，那么他们可能在每一次版本签入时都只写下两个字的备注：“完成”。
5. 流于形式的沟通
在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或者打回访电话。
其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目最末了，才是交流感情。
然而大多数的情况下，它仅仅被看着交流感情。这便成了形式。且往往是客户所讨厌的一种形式。
沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不通。等等都是沟通问题。
UML 的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。——要让 UML 在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻的理解 UML 的思想。
也不要指望在每个项目中都能用它，如果你的客户能理解并支持使用 UML，那以这个项目就会有一个良好的UML 使用环境。否则，开发环节中资料的不一致性，将会使得项目难以收场。
使用与不使用 UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
每一次回顾项目时都应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
评论