大道至简第四章

    第四章 流于形式的沟通

    第一节：客户不会用C，难道就会用UML吗？

不要强求客户用专业的语言如C语言去和你沟通，并且就像R模型中，开发人员最好不要直接面对客户，而是让可以不用C语言而是用一种非C语言与客户沟通的项目经理去面对客户；或者你想让开发人员尽早的进入状态，那么可以让开发人员以需求调研的身份出现在客户面前。

   第二节：项目文档真的可以用甲骨文来写

独孤木曾经在一篇《UML, OOAD and RUP》中讨论到UML实际应用中的问题。其中的两个问题是：

（1）大部分的使用者，以及客户的信息人员，其实没有足够的能力，来确认这些文件（User Case）的正确性与完整性 。

（2）除了客户不了解UML,OOAD跟RUP以外，另外一个更糟糕的现象就是project team里面的人也不懂。

    仅以UML的User Case来说，由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如果去实作。图则很简单，就是几个图形符号来描述系统边界和角色关系。显然甲骨文也能描述范围与关系。所以只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。同样的，只要约定一套“语法”，你同样可以用甲骨文来做活动图、类图、构件图⋯.以及这些图相关的规约。

第三节：最简沟通

    我们可以综合以下两个方面的因素来抽取客户所关心的的因素：

（1）客户在公司层面的外在表现、内部机制和运营管理手段。

（2）客户在项目中即已明确的需求和可能发生的需求，以及客户围绕其公司行为（和方向）所提出的需求。

  我们开始设计提问，然后确定了项目的实际目标，以及远期的方向。接下来就是设计需求条目。然后就是分析设计，然后完成了整个项目的需求分析报告

     保障每一次沟通的有效性都是最重要的事。每一次沟通都是向客户了解更深层次的需求的机会，所以最好在见客户之前，设计好所有的问题和提问方式。

第四节：为不存在的角色留下沟通的渠道

 

历史记录(History)与注释(Comment)不是一回事。代码中的注释是为阅读代码而留备的，而History是为整个项目而记录的。一些参考的记录内容有：

 需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；

  设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性)；

 开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；

  测试阶段：还记得测试用例和测试报告吗？那是最好的history之一。

还有一件最重要的事是，记得在每一笔记录后写下时间和你的名字，方便之后不了解该项目的人看。

   第五节：源于形式的沟通

沟通具有目的性，这种目的，可以是了解项目的讯息、挖掘潜在的项目……最后才是交流感情。

沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不通等等都是沟通问题。

UML是解决沟通问题的最佳手段之一。但并不一定非要在你的项目中使用，只有行之有效、能在各个项目角色间通用的才是好的沟通方式。

个人感想：一个项目的完成需要项目组内部人员的交流还要有项目人员和客户的沟通，并且不要用专业术语去和客户交流，要选择一种行之有效的、客户可以接受的方式去沟通；还有就是做项目的时候要对你做的东西加注释，方便其他不了解的人。