标签：
第四章 流于形式的沟通
C语言是程序员与计算机交流的语言，而不是他与客户交流的语言，程序员面对的是计算机，但计算机不是客户。因此，开发人员最好不要直接面对客户。项目经理由这样一种优势： 他可以不用了解C语言，也可以用一种非C的语言来与客户交流。
要深入项目需求阶段的项目经理或者调研人员，被要求深谙项目所涉及的业务。但这往往是做不到的，因此惯常的做法是聘请行业咨询公司（或个人）来介入需求阶段，以协助了解和分析需求。
沟通时需要确认沟通方式的有效性，而不是追求这种方式是不是UML，以及用UML表达得是否正确。客户是因为他认为你理解了他的需求而在“需求确认书”上签字，而不是因为你的UML图画得是否精确。
沟通的三层障碍
1. 沟通并不在于你要表达的内容，而在于你如何表达。此时，你需要组织语言，学会说话。“对不起，先生，我们这里没有你想要的东西……”和“对不起，先生，你想要的东西我们这里没有”的区别：前一句的语气是在“致歉”，后一句则是在“推诿”。
从叙述中揣度结果，是人们子啊交流沟通过程中潜在的意识和行为。如果两个人在努力地交流，那么他们一定会无比细致地去分析对方的描述，因此，他们事实上都回关注对方的措辞、语气、句法，或者分析表达的前后逻辑与关联，这么做的目的是：
a. 找到对方表达的潜在含义与目的
b. 找到对方叙述中的逻辑错误
第一个是支持者的心态，第二个是反对者的心态，这两种心态就是一个会议的全部内容。
2. 第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。此时，应当预设前提，并尽早阐述结论。
对于两个聪明人而言，正确的结论通常只有一个，因此，如果出现了争执，那么讨论的一定不是同一个问题。
一个结论是需要在大多数人之间做出，还是只需要在一两个人之间做出，是在一开始就要被确定下来的。
3. 沟通不知缓急。此时，不要把沟通目标设定为“让对方认同”。
用尽可能少的人、在尽可能短的时间内做出决策，是降低沟通成本的关键。
作为管理者，应当去观察、理解和发现问题（或由专人汇报），你要尽量去听，去思考，因为作为这个角色，你总是有机会纠正问题的。但是，不要急于去纠正。在一个会议上即使某种想法有问题，也绝不是在你发言的三分钟里就能纠正的，而是在最后你做出的决策里去纠正。这种决策通常有两种：给出明确答案和存而不论。
沟通不过是手段，是工具之一，而管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人继续去讨论。
保障每一次沟通的有效性都是最重要的事。你得到的每一次沟通机会，都是向客户了解更深层次需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
历史记录与注释不是一回事。代码中的注释是为阅读代码而留备的，而历史是为整个项目而记录的。一些参考的记录内容有：
a. 需求阶段：与谁联系、联系方式、过程、结果以及由此引发的需求或变更
b. 设计阶段：如何进行设计，最初的构架，各个阶段的框架变化，因需求变更导致的项目结构上的变化（有助于了解构架的可扩充性）
c. 开发阶段：每一种技术选型的过程，每一种开发技巧的细节和相关文档，摘引的每一段代码、算法、开发包、组件库的出处和评测，程序单元的测试框架，每一个设计和构架变更所导致的影响。
d. 测试阶段：测试用例和测试报告
其实，沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息，挖掘潜在的项目……最末了，才是交流感情。
沟通问题不仅仅存在于你跟客户的交流之中，还存在于项目的各个角色之间。
使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
流于形式的沟通，极有可能是你的项目被不断推翻和不断延迟的最直接原因。
第五章 失败的过程也是过程
瀑布模型将软件开发过程分成需求、分析、设计、开发和测试五个阶段。
从最开始，从我们编程开始，我们的目的就是实现一个东西，而工程，只是一种实现的途径。
越是简单的东西，往往越是接近于本质。
标签：
原文地址：http://www.cnblogs.com/Ribbon/p/4500456.html
