第二部分如约而至，继上篇中提到的协同的问题，虽然构架稍微清晰，流程也有针对性的调整，但是在做事的过程中，人和人之间如何打交道还是成败的决定要素。好的事情由于坏的沟通会变得很坏，导致方向的偏差，而坏的事情由于坏的沟通也许会变得很“好”，隐藏了真相与风险，导致问题最终不可收拾。

外面大部分卖的专业书籍中，对于人和人沟通的技巧讲了不少，次要偏重于市井生活的欲拒还迎、官场上的溜须拍马、或者商场上的尔虞我诈，厚黑的概念从一而终不曾改变。但是在我们的设计行业中，沟通的方式多少有点技术化，甚至我可以讲大部分设计师是讨厌勾心斗角，并且嫉恶如仇的，如果沟通不断处于一种灰色的地带，那么潜规则将越演越烈，最终构成对行业和团体的伤害。

那么，严肃而合理的沟通究竟有没有呢？从我本人的经验来看是有的：

1. 沟通的情境

我们经常说的一个词，叫察言观色，这个技术在用户测试与可用性研讨中是非常重要的手段，强调研讨过程中的观察与分析的要素，而既然我们都是用户体验的从业人员，为何在情境转变当前，又不善于利用这种技术呢？其实在项目管理的过程中，设计师与程序开发工程师、产品经理、市场人员、老板的沟通上都需求“不同的情境不同的沟通方式”。

向上沟通，提供价值 — 和上级领导沟通的时候，如果你希望提出一些需求的话，最好先预备好证明本人价值的材料或任务成绩，作为管理层最不情愿参与的事情莫过于员工的自我管理，如果一个沟通过程（绝大多数情况是某些会议）显得缺乏预备，没有预期效果，那么我建议你最好不要先通知领导参加，否则他只能看到你处理事情上的不成熟。

优秀的技术型领导多半关注真实的数据和行业发展趋势， 沟通的基础是你处理了某些问题，发现了某些更好的方案，而这些价值要得以体现必须得到领导的支持，那么他会非常有兴味。最没无效果的沟通方式是，两个技术人员在领导面前吵架，如果你经历过，你可以回想这样的场面能否给你带来了正面的评价。

平行沟通，注重成效  — 项目UI设计师和软件工程师、WEB设计师与前端开发人员、各部门内部成员之间，这种叫做职能平行关系，这种沟通之间，最重要的就是沟通的成效。缺乏成效的结果是形成信息的衰减，最后影响到不同人员之间的任务量。比如：一个需求的变更，如果没有在第一时间让项目组成员完全了解，就会导致最后一个任务部分的成员积压大量未知的修正和不确定任务内容。

在平行沟通中，为了节约时间和提高效率，大部分人不喜欢使用文档，而这正是沟通失败的次要缘由，越是联系紧密，任务成果传递迅速的平行关系成员，越应该建立无效快速的文档迭代体系。这样才能保证在任何一次小的需求变更上都有明确的记录，这个好处一是不能赖账，二是有脉络可循，三是任务量评定很直观。

向下沟通，履行职权  — 任务向下传递的过程中，遇到的阻力往往来自于时间压力还有项目人手的压力，我之前说过的部门墙会在这个时候发挥巨大威力，如果碰上不太踏实的团队和流程，你大可以看到同仇敌忾的场面。这个问题的最简单处理办法就是在项目开展初期，即明确各个部门的职权与关键点的评审责任，比如：页面实现一定要恪守页面设计效果图，代码效率一定不能低于某款产品的标准，软件开发一定要满足交互设计的预研效果…… 确定一个配合的主次关系，再辅以资源支持的范围，利用好话语权决定沟通以外的事情。

2. 沟通的阀值

沟通的阀值是指沟通的心思底线，每个沟通的过程总是会有目的，达到这个目的会影响每个参与沟通的人的心思价位，普通来说，如果你要确定沟通中的有价值的部分，你需求回答四个问题：你的意见或者批评 — “有用的是什么”、“没用的是什么”、“如果这么做，得到什么”、“如果不这么做，得到什么”

如果沟通过程中，你说的话没有处理以上4个问题中的任何一个，那么你说的话基本是废话，没有沟通的必要。

沟通中有句真理：角度决定程度。我们不断提倡换位思考，但有时候换位是没有必要的，也不是非常客观的，换位的本质是希望找到共同的战略目标和利益链，如果你们之间的战略目标有较大的不同，那么换位显得有点假惺惺的多余，这时评价的独一标准不是妥协，而是找到正确的沟通切入点，以及在做事上的程度。比如：关于设计时间和设计质量之间的取舍，过分追求时间和过分追求质量都是有问题的，切入角度在于质量惹起危机，还是时间惹起危机，如果客户说1个月不交付就不签单了，那么你还能追求质量最大化么？如果客户领取的成本足够你利用2个月来完成设计，那么就应该投入足够的精力去面对它。

3. 沟通的门槛

减少沟通次数  — 这里说的是减少无意义沟通的次数，有部分产品经理喜欢这么干，确定责任前开会，安排项目前开会，交付周期前开会，质量评审前开会，反正一切都是大家说了算的，出了问题也不能怪到我产品经理的头上 — 这种二百五的作风说好听点是群策群力，说难听点就是为本人的无能找一堆垫背的。请问所有的事情都是大家做的，那么你团体的价值在哪里？

所以，不处在关键节点的会议是不必开的，超过关键节点关注以外的话题是不用讨论的，关于质量和评审的标准是客观的，不需求沟通的。

降低问题难度  — 沟通的基础是沟通的双方（或者多方）都能精确理解对方的意图，因此沟通的过程就是一个稀释问题，处理问题的过程，最好的方式是降低难度，一个关于开发周期确定的问题，可以降低到开发人员配置与项目周期的问题，而开发人员配置可以降低到人员数量和任务时间计算的问题，人员数量的问题可以降低到是不是有资源提供加班补助的问题。

大部分项目推进困难，次要问题就是出在 钱 的问题还有 成就感 的问题，但是很多佯装高贵的设计师，开发人员，产品经理，就是不愿谈这个直接的话题，反复谈什么企业文化，奉献精神，流程完善、人员经验等。

我不得不通知你，如果你的成员说这个东西没时间做，潜台词就是“你没有给加班工资”，如果你的成员说这个东西有风险，潜台词就是“你给的钱和职位不足以让我承担这个风险”，如果你的成员说这个东西很简单，可以稍后考虑，潜台词就是“这玩意做得没意思，杀鸡不能用牛刀”，如果你的成员说我们慢慢来，心急吃不了热豆腐，GOOD，他可能预备跳槽了。

提出问题而不是景象  — 大部分沟通峰会，如果你留意观察的话，多数人都乐于提出景象，而不是问题本身，比如: 你们市场部不能老这样提出修正，产品都没做完，为什么要改呢？ — 这个话基本没有说出问题的关键，问题出在为什么市场部可以提频繁的修正需求？谁给的权利？客户的要求由谁过滤的？修正的成本谁来承担？修正不好谁又来担任？是输入问题还是输出问题？

沟通要保证效率，就得在沟通之前预备好真正的问题，围绕问题，提供处理方法，否则沟通就像领导发言一样“李总，你带人把这些问题研讨一下，尽快给我结果”，官僚思维带来沟通效率降低。