团队沟通出现冲突摩擦是因决策权不清晰

曾经西湖

在项目开发团队中，团队成员之间的沟通过程中经常会出现各种各样的冲突和摩擦，仔细分析这些冲突的根源，你就会发现。大部分冲突的产生都有一个共同的特点即：引发冲突的事务的决策权不清晰，或受到了某种程度的干扰。

以下是几个引发冲突的案例：

【案例1】运营看到视觉设计师的方案，运营：“我觉得这个秒表的图形应该用圆形而不是方形”

运营的说法侵犯了视觉设计师的决策权，是对视觉设计师职业分工的一种否定和不信任。

【案例2】交互设计师发现一个需求时向产品经理建议加上某功能，产品经理：“这个功能我知道有用之前也考虑过，但担心交互上太复杂用户理解不了就没加。”

产品经理基于自己对交互复杂程度的猜测而放弃了某个产品功能，忽略了交互设计师的角色定位。

【案例3】交互设计师要用新窗口的方式代替弹出层方式，已经和产品经理达成一致了。 开发工程师：“我不接受！…”

只有项目管理者才有拒绝设计方案的权利，开发工程师利用自己在项目进度中的制约作用行使不属于他的决策权。

引发冲突的根源
这些对话引发冲突的一个共同的根源在于：项目开发团队各个角色间的决策权是混乱的，一个角色可以跨越自身的职责范畴干扰其他角色的决策权，开发可以做出产品经理的决策否定设计方案，运营的意见左右视觉表现。这种决策关系的混乱最终反映到产品上就必然导致产品的混乱。

决策权受到侵犯存在以下两种情况:

显性侵犯

案例1中视觉设计师的决策权受到非视觉专业领域人士的直接干预，属于显性侵犯。这种侵犯肯定会遭到抵抗。面临这种情况时被侵犯者需要具备一定的职业技能和较强的沟通技巧，才能完全不受这些非专业意见的影响。 虽然只要具备了上述能力设计师就能保护自己不受侵犯，但做出专业决策要依赖于非专业技能这件事本身就是一个严重的问题，首先非专业技能的学习需要付出高昂的学习成本，另外即使具备了这种技能也会有很多时间浪费在无效沟通上，尤其是对新设计师而言他们很难保护自己的决策权不受侵犯。最终导致非专业意见跨越职责分工影响产品最终形态。

隐性侵犯

还有一种侵犯属于隐性的，比如案例2中：产品经理在产品功能规划阶段砍掉了一个用户需求量很大的功能，原因是他推断此功能交互方式太复杂用户难以理 解，这个过程是发生在产品经理头脑中的思维过程，是完全不可见的，产品经理根据自己对产品交互方式的理解作出“太复杂”的判断显然是不恰当的，对交互方式 复杂程度的判断应该属于交互设计师的决策范畴，但由于砍掉产品需求这个过程是隐性的很难被发现的。所以交互设计师甚至没机会察觉自己的决策权被侵犯，就已经失去了决策机会。

以往的工具及其局限性
针对这种决策权混乱的情况，我们已经有一些基本的管理工具，比如流程管理就在一定程度上避免了混乱，他通过划分每个角色的职责范畴来规定各个角色在项目开发事务中分别拥有的决策权，但这种划分只能解决项目主干任务上的决策权界限问题。对与项目分支任务中的细微决策点和决策权的隐性侵犯问题却不能有效解决。

在分支任务中的决策权混乱和决策权的隐形侵犯问题有没有更好的解决方式呢？

制定更加详细的流程，规范项目开发的每个细节？繁复臃肿的流程会大大降低系统的执行效率这样做显然不可行。因此，就需要建立另外一种规则，它不具有流程的强制执行的特点，因此更加灵活变通不会影响效率，但同时它又需要具有一定的约束力。这就是为什么我们要引入伦理的概念。

伦理工具的特点
伦理具有以下特点使它能够成为制止混乱的有效工具：

伦理在一定程度上起到了调节社会成员之间相互关系的规则的作用，类似于约定俗成的交通秩序，引申为人在社会上为人处世的规则。它试图从理论层面建构一种指导行为的法则体系，即“我们应该怎样处理此类处境”，“我们为什么/依据什么这样处理”。并且对其进行严格的评判。

伦理这种“约定俗成”和“指导法则”的感性特征使他可以影响我们处理事情的方式，但又不具有强制色彩。而且它通过公众评判产生约束力（例如古代贞节 牌坊的象征意义，就是对受封者守寡行为的约束），在项目团队中这种约束力来自项目成员对规则的普遍认同，对不遵守规则的成员进行评判。

项目开发伦理的基础内容
为了解决决策权混乱的问题，我们需要项目成员彼此尊重对方的角色定位和职业分工。这也就形成了项目开发伦理的基础内容：尊重角色定位和职业分工，不同的角色对自己职责范畴内的事务拥有最终决策权，其它角色可以提出意见和建议但是角色本身掌握最终决策权。

尊重伦理的作用机制及其有效性
这种伦理将会给我们带来什么样的好处呢？我将通过以下案例说明：

在某项目中，设计师对产品经理的产品方向提出质疑认为功能设计不合理，并通过用户调研手段发掘出了真正的用户需求。但产品最终并没有体现这些需求， 设计师是应该利用自己对项目进度的影响为了用户的利益 “坚持到底”，还是将产品的风险告知产品经理并且尊重产品经理的最终决策权“点到即止”。

坚持到底

好处：产品在我们的坚持下，虽然付出了一定的变更成本，但最终做出了有利于用户的改动。 我们得到了一个好产品。

坏处：一旦我们为了满足某些用户需求质疑产品经理在产品方向上的决策权，就会破坏尊重职业分工的伦理，在这种伦理被破坏的情况下每个项目成员的决策 就都有可能受到其他项目组成员的反复质疑。系统的整体执行效率必然大打折扣。产品经理在本项目中的失误没有暴露出来，因此系统无法识别自身的薄弱环节，因 此为下一个产品埋下了隐患。

点到即止

坏处：这个产品不能满足一部分用户需求。

好处：我们尊重产品经理的最终决策权（虽然不一定信服），在相互尊重的伦理中，系统高效运转项目顺利完成，尊重伦理保证了系统的执行效率。 由于产品对市场的把握不准确，产品经理团队内部做出了调整。我们形成了一个更有战斗力的项目开发团队。

从上面的例子可以看到，尊重伦理保证了项目开发团队本身的良性发展和进化。因此，单个产品的成败，和系统的整体强健高效相比显得微不足道。

尊重伦理的基础
相互尊重建立在职责分工明确的基础上，只有在职责分明的情况下才能识别哪个角色拥有优先决策权，流程工具保证了主干任务的明确分工。在分支任务中如果存在角色职责模糊的地带，就需要遵循能力尊重原则，设计师深入理解用户行为的能力使他对产品细节有相对优先决策权。产品经理对市场的把握能力，使他在产品方向上有相对优先决策权。

如果不能明确职责分工，设计师干扰产品策略，开发干预产品设计。不但会影响适当的人作出正确的决策，当产品出问题时，系统也无法识别出错环节，不利于系统的进化。

尊重伦理在团队中如何形成？
一方面：要求角色有能力证明自身决策的权威性和正确性

其实很多质疑者的质疑习惯源于以往的质疑成果的激励。质疑者大多在之前有过成功质疑的经验，并且认为自己的质疑使产品更加完善。这种成功质疑的对象 必然是那些没有能力证明自己决策的正确性和必然性的不成熟的角色。如果质疑者的每次质疑都被成功说服。那她的质疑习惯就会被尊重习惯和信任习惯所取代。

对与设计师来说，就是自己的每一个设计决策都要禁得起质疑。能在每一次受到质疑的时候给出充足的理由。在经过多次合作后，其他成员自然会建立起对你 的信任和尊重。质疑声会逐渐消失。最理想的情况是设计团队的大多数成员都具有这种能力，那整个部门都将收到足够的尊重，即使是部门中少数不成熟的成员（这里的不成熟是职业技能而非专业技能）也可以享受这种尊重成果并尽快成熟起来。

另一方面：依靠所有成员对尊重伦理的认同。

所有伦理的产生都源于，利他利己原则，利他是为了利己。就像红灯的时候让别人先走。是为了自己在绿灯的时候不会受阻一样。尊重伦理也是同样的原理， 通过案例教育使成员认识到尊重原则的重要性，尊重别人是为了让自己的决策更受尊重，当大家都对这个伦理产生一至认同的时候伦理建设就基本完成了。

什么时候可以突破尊重伦理（推倒贞洁牌坊）？
虽然贞节牌坊制造了“和谐”的社会风气，但也束缚了广大妇女同志追求性福的脚步。严重的甚至有可能对“偷情”的小寡妇造成人身伤害，因此有必要的时候我们必须要推翻它，

伦理在保护角色决策权的同时，有可能会屏蔽一些合理意见。当产品的大方向不会受到影响的情况下，这种负面的影响在可接受的范围内。但是如果产品目标出现严重偏差，而且有可能会威胁到用户的核心体验时。是有必要突破伦理的。

何时突破伦理有一个模糊的界限：产品形态跟产品目标出现严重偏差时有必要突破尊重伦理。

至于什么程度算是严重并没有明确的标准，只能根据具体项目具体评估。