客户沟通:
要先接触客户的，要确知要做什么
开发人员最好不要直接面对客户
项目经理直接面对客户的优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流（比如说汉语）。
愿意开发人员尽早进入状态，那么，可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研者”，如果他不能适应这种转变，那就别让他去——那会是灾难的开始。
行业咨询公司（或者个人）来介入需求阶段:
这些咨询专家总是很喜欢把事情搞得很复杂
他们无时无刻不在向你展现他们的专业（这已经是他们还存在的唯一原因了）。
咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：如何与客户交流？
UML:
在项目中使用UML只是完全不懂的老板，以及什么都懂的博士的主意，而真实的场景中去做事的那些客户与项目成员，其实是未见得就能用好UML的。
只要你运用得法，甲骨文一样可以用来画用例图和写用例规约
UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及……更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML
客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML图画得是否精准。
如果客户雇了一个专家组来评审需求，那么你就老老实实地画用例图好了。
沟通的三层障碍:
第一层障碍“不知所云”
沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是“不知所云”。这种情况下，你需要组织语言、学会说话。
- 找到对方表达的潜在含义与目的；
- 找到对方叙述中的逻辑错误。
“对于两个聪明人来说，正确的结论通常只有一个。因此如果出现了争执，那么讨论的一定不是同一问题。”
通常，如果一件事正确，那它就是正确的。无论你分析的过程如何，结论也“不过如此”。所以你应该把结论放在文档的前面，把指导性的原则放在更前面，把事件的前因与目标以概要的形式放在最前面。一个聪明人只需要200字就可以说完的一件事，同样另一个聪明人也只需要这200字就能理解。
第二层障碍“不知所为”
第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下，你应当预设前提，并尽早阐述结论。
用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键。
第三层障碍不知缓急
第三层障碍的主要表现是：不知缓急。解决之道，则是不要把沟通目标设定为“让对方认同”。
在一个会议上即使某种想法有问题，也绝不是在你发言的三分钟里就能纠正的，而是在最后你做出的决策里去纠正的。这种决策通常有两种：
- 给出明确的答案；
- 存而不论。
项目经理不是理论家，所以并不是一定要把一件事理论清楚才能实作。论理是要以沟通成本（人力和时间）为代价的，也可能以牺牲事件本体来做代价。因此作为管理者，你应该“适时地终止讨论”。
沟通不过是手段，是工具之一种，而管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人（而不是整个团队）继续去讨论。于你而言、于项目而言、于整体而言，“有的‘异’无关宏旨，无碍大局，可以存而不论”。
最简沟通:
保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单。你得到的每一次沟通机会，都是向客户了解更深层次需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
History:
我们做项目的时候，如果也不留下历史记录（History），那么以后别人来看这个项目，也会是两眼一抹黑，要么就像司马迁一样“存而不论”，项目便就此中止；要么就像“夏商周断代工程”一样，花大量的人力物力来攻关。
流于形式的沟通:
其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目……最末了，才是交流感情。
使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
在每一次回顾项目时都应该注意：流于形式的沟通，极有可能是你的项目被不断推翻和不断延迟的最直接原因。
大道至简：软件工程实践者的思想 第四章 流于形式的沟通
标签：需求,障碍,沟通,项目,软件工程,客户,UML,团队 From： https://www.cnblogs.com/ooo0/p/18232668