第四章 流于形式的沟通
第一节 客户不会用C，难道就会用UML吗
我们总是要先接触客户的。......
......
因此在前面提到的R模型中，开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流。
或者你更愿意开发人员尽早地进入状态，那么，你可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研”，如果他不能适应这种转变，那就别让他去--那会是灾难的开始。
......
到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：如何与客户交流？
他们的解决之道是建模语言。
有什么差别吗？
程序员不能要求客户会C，难道需求分析师们就能要求客户会UML吗？！
第二节 项目文档真的可以用甲骨文来写
......
UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及......更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及你用UML是否正确。客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML图画的是否精确。
现在来思考：为什么非要让客户看UML图呢？如果有能够满足“极限编程”所要求的“现场客户”，那当然可以不用画用例图；相反，如果客户雇佣了一些专家组来评审需求，那么你就老老实实地画用例图好了。
第三节 沟通的三层障碍
......
所以沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是“不知所云”。这种情况下，你需要“组织语言、学会说话”。
......
仔细理解这两句话，前者在说的是“我们没有”，因而责任在我；后者在说的是“您想要的”，因而责任在您。看起来这两句话是在表述同一件事，但因为语言组织得不同，前一句的语气是在“致歉”，后一句则是在“推诿”。
......
由此看来，从叙述中揣度结果，那么他们都一定会像分析这两句话的差异一样，无比细致地去分析对方的描述。因此，（注意！）他们事实上都会关注对方的措词、语气、句法，或者分析表达的前后逻辑与关联。而这样做，通常有两个目的：
找到对方表达的潜在含义与目的；
找到对方叙述中的逻辑错误。
第一个是支持者的心态，第二个则是反对者的心态。然而你应该知道，这两种心态就是一个会议的全部内容。
所以你会发现，重要的人很少说话，而重要会议所需要的发言也很少。这样的角色，或者这样的场合下的言论都是经过充分组织的。--只有这样表达，才会更加有效。
我的老朋友Soul有一句名言：“对于两个聪明的人来说，正确的结论通常只有一个。因此如果出现了争执，那么讨论的一定不是同一问题。”
......
所以沟通的第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下，你应当预设前提，并尽早阐述结论。
......
用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键。正是因为有了人和时间这些成本因素的约束，所以“我们讨论清楚”再做这个设定可能就会很荒谬。所以第三层障碍的主要表现是：不知缓急。解决之道，则是不要把沟通目标设定为“让对方认同”。
在我们的确没有办法把一件讨论“讨论清楚”的时候，就是“旁观的人最重要”了。--作为管理者，应当去观察、理解和发现问题（或者由专人向你汇报）。你要尽量去听、去思考。因为作为这个角色，你总是有机会纠正问题的。
但是，不要急于去纠正--在一个会议上即使某种想法有问题，也决不是在你发言的三分钟里就能纠正的，而是在最后你做出的决策里去纠正的。这种决策通常有两种：
给出明确答案；
存而不论。
看起来，让你“给出明确的答案”是职责所在。反过来说，“存而不论”就似乎是在推卸责任了。但是可能在某些情况下，“存而不论”才是最好的决策。
项目经理不是理论家，所以并不是“一定”要把一件事情理论清楚才能实作。“论理”是要以沟通成本（人力和时间为代价的），也可能以牺牲“事件”本体来做代价。因此作为管理者，你应该“适时终止讨论”。
沟通不过是手段、是工具之一种，管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人“而不是整个团队”继续去讨论。于你而言、于项目而言、于整体而言，“有的‘异’无关宏旨，无碍大局，可以存而不论”。
第四节 最简沟通
......
在大多数项目中，这样的问题都是存在的。真正能满足极限编程所提出的“现场客户”的情形并不经常出现。即使能将程序员送到客户现场中去，沟通问题仍然是不可避免的。
因此在D项目中我提出了“最简沟通”。
我们开始在网络上查看相关的软件系统的特征，以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式以及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手再做什么和在关心什么......
其实我们了解sipp，abcus就是走的这一步。
......
我们开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能多的具有发散性以便形成更多的推论和假设。
......接下里就是设计需求条目。
我们从数百条的需求条目中，整理出系统结构和模块，需求条目被映射到各个模块。我们很快就画出了模块间的相互关系图，......
我们对用户角色、原始数据和系统结构进行梳理之后，我们花了很短的时间实现了第一个系统模型。......
这一次的沟通我们使用了面对面的模式。而正好我们有一个模型......
接下来的分析设计是顺理成章的事。......
应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
第五节 为不存在的角色留下沟通的渠道
......
项目的中断和中止，与历史产生断层的内因是一致的。--我发现很多的项目（尤其是产品计划）在负责人员离开后，就自然而然地死掉了。我把这一切的原因归咎于“没有History”。
我们做项目的时候，如果也不留下历史记录（History），那么以后别人来看这个项目，也会是两眼一抹黑,.....
维护项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己再做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟通、对话的渠道呢？
......而History是为整个项目而记录的。一些参考的记录内容有：
需求阶段：与谁联系、联系方式、过程、结果以及由此引发的需求或变更；
设计阶段：如何进行设计、最初的设计、最初的架构、各个阶段的框架变化、因需求变更导致项目结构上的变化（有助于了解构架的可扩充性）；
开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序的单元测试框架；每一个设计和架构变更所导致的影响；
测试阶段：还记得测试用例和测试报告吗？那是最好的History之一。
其实我也比较有同感，但是这样是不是和敏捷开发有冲突？
第六节 流于形式的沟通
在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或这打回访电话。
......
流于形式的沟通，可能是使你的项目不断推翻和延迟的最直接原因。
沟通问题不仅仅存在于你跟客户交流中，还存在于项目的各个角色中间。.....
UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的--要让UML在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻理解UML的思想。
......
使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
个人感受：
1、过去怎么做;
过去做任务都是站在自己的立场上，自己想怎么做就怎么做，完全没有站在用户或客户的立场上，用户是主观的，做软件是为了让用户使用，要满足客户的需求。还有就是沟通，不仅是与客户之间的沟通，还有与队员之间的沟通，他需要有技巧的沟通，要学会说话。
2、这样的坏处：
做项目不站在客户的立场上，会导致客户的体验差，而且给自己留下不好的印象。与客户之间的交流不能只是形式见的交流，客户不一定会看uml图，或许做出的结果与它想要的软件不是一种软件，导致不可挽回的纠纷。与队员之间的交流也是有技巧的，不能更好的沟通只会导致队伍的破裂，这样怎么能完成一个项目呢？
3、解决办法：
学会交流，学会说话，做软件要站在客户立场上，做需求调研，减少纠纷，在队伍内达成一致的目标。