在互联网团队中，任何一个产品经理协同的核心在于，如何做到“双赢”，即在实现好的产品下共同友好合作。产品经理岗位的要求里都会提到“沟通能力”、“项目协作”、“跟进迭代”，等产品经理团队协同分内的相关软技能。团队协同的基础是解决一个问题，高阶协同是让大家都可以接受的范围内解决一个问题，而不是从其他角度上证明到底谁对谁错。

下面看一个经典小故事，说道一位著名企业家在做报告。当台下听众咨询他最成功的做法时，他拿起粉笔在黑板上画了一个圈，只是并没有画圆满，留下一个缺口。他反问道：“这是什么？”

“零”、“圈”、“未完成的事业”、“成功”，台下的听众七嘴八舌地答道。

他对这些回答未置可否：“其实，这只是一个未画完整的句号。你们问我为什么会取得辉煌的业绩，道理很简单：我不会把事情做得很圆满，就像画个句号，一定要留个缺口，让我的下属去填满它。”

这个有缺口的圆圈故事的核心思想是让每一个人都有自主参与做相关动作或决策，才称得上拥有权利。

上述故事也反应“戴伊定理”的核心思想，换句话说，“一人说了算，大家不去干”

团队协同双赢的关键词：参与感&责任感

下面以产品经理视角从“需求评审”角度，结合《责任病毒》书中的“责任阶梯”来理解并解决，有效提高团队责任感与参与感，达到团队高效协同。

需求评审最终的目的是通过这个评审会，让团队成员对自己岗位的“新任务”有更清晰的认知、责任感和参与感。如果评审时出奇的一致无其它声音，产品后期总会源源不断的出现问题。这种状态还会造成团队成员惰性，把所有因果都推给产品经理。产品经理更多是需要“掌控大局”，而不是掌控全部。

“责任阶梯“分等级1-等级6共有6个等级，表示我们在团队协同的过程中可能扮演的角色等级。

责任阶梯等级六：把问题堆在对方的桌子上，摆出一副无助的样子

该等级角色表示自己不承担任何责任，把责任推给对方，让对方来帮你解决问题，这个责任等级不管在任何一个场景下都是一个不合适的责任等级角色。破坏团队协同氛围，仿佛在警告对方赶紧想解决办法，该等级角色只会让问题变得越来越糟，而不会变好，更不合适产品经理在需求评审中扮演。

责任阶梯等级五：请对方来解决问题，但是你一定要在旁边观看和学习，以保证你下一次可以自己解决

该等级角色有一定的求知态度，并表明有意愿和兴趣来提高自己的能力，以便下次遇到类似问题自己可以独立解决，同时也没有完全抛开责任。但在互联网团队不是非常适用，因为互联网团队各岗位互相独立，工作职责耦合度低。比较适用于部门下级遇到问题来请求上级支持。就一个小小的信号都能帮助自己树立形象和立场，也比角色等级6也更尊重对方。

责任阶梯等级四：向团队描述问题，并请他们将问题结构化

这个场景每个产品助理/经理都会遇到，在规划新需求遇到一些技术实现及相关逻辑不清晰，产品经理个人难以理解评估的时候，需要他人支持并进行结构化拆解，比起“等级六”将问题直接扔给对方求解决，该等级表现出一种“希望合作”的意愿，希望对方也能参与进来共同担责，而不是把问题抛出去后撒手不管。

从评审内容中按实现难易度的维度划分，对于复杂偏技术实现的需求，产品经理可扮演该角色等级，评审中向技术部门灌输清晰的需求背景，让他们也基于当前的问题进行思考，是否有更多可行的解决方案，方案未必非常周全，但思路一般是可行性比较高的。如果是简单容实现的问题就别扮演该角色等级，他人容易认为产品经理专业能力不行。

责任阶梯等级三：向团队提出几个想法，并请他们帮你做出选择

承担该等级角色意味着自己独自进行问题结构化并且产出对应的解决方案，但觉得自己不能从解决方案中挑出一个最好的，对自己的决策能力不够自信。

“在产品推荐列表上我注意到一个问题，我想过了，我认为处理方法有4种，你们认为怎样？“，这比“我在产品推荐列表上注意到一个问题，你们打算怎么办要好很多。”

该等级在需求评审中，能有效凝聚团队及认知责任的一种，产品经理不是全能的，他人的视角能看到产品经理看不到的东西，给团队相关人员留下空间，运用集体的智慧，在评审上适当让团队成员参与产品部分的决策事务，是对他们的肯定，也是满足队员们自我价值实现的精神需要。赋予团队成员更多的责任和权力。同样在评审内容中在实现难易度的维度划分，对于复杂偏技术实现的需求，产品经理也可以扮演该角色等级。

责任阶梯等级二：向团队提出几个想法，以及自己建议采用哪个方案

该等级角色已经能够分析各种想法，并且能够给对方建议哪一个比较合适，扮演该角色等级意味着自己承担了大部分决策责任，虽然有可能拍板者是对方（老板、技术leader），但自身能独立自主的解决问题和发现相关风险。同样在评审内容中在实现难易度的维度划分，对于非复杂技术型的需求，产品经理就应该扮演该角色等级，提议的原因有可能是因为其它技术因素的限制，与限制方协调沟通，共同商议决策。而不是强制要求，就这么干。

在新的关系列表中，我有2个方案：第一个是直接把用户关系直接读出来，但列表过多和网络不佳时可能请求时间很长；第二个是不带出用户详细关系，仅在界面做出“有关系”的视觉效果。

我个人推荐第二个方案，因为用户体验比功能重要，“如果技术伙伴能有效解决用户关系请求速度，也可以用第一种。比起“我们直接把用户列表的关系显示出来，技术伙伴必须解决关系列表请求问题”这样的协调要好很多。

责任阶梯等级一：考虑各个选项并做出决定，然后通知对方

该等级角色是目前多数产品经理进行需求评审及日常沟通时常见现状，把本次需求考虑得周全，让团队听懂，无其它异议就会议结束，然后一顿开干。这就是典型的“英雄主义”，仿佛在高呼“我说了算”，其实言外之意就是“你们最好走开”。

久而久之团队成员的责任心也大大降低，出了问题就甩锅，“产品说这么做的”。如果团队关系比较恶劣，会导致研发人员产生逆反心理，即便需求上出现明显的逻辑漏洞及错误也不情愿向上级领导或相关产品人员提出，而是坐等看戏。

最后

互联网团队讲究高效协同，而不是单兵作战。不管是技术、产品还是设计等团队成员能定期的公开使用责任阶梯，那么会发现这是一个及其见效的“工具”，也是无形中团结大家向同一目标努力的一股力量。

通过角色等级代入对比，承担等级2~等级5的责任等级使双方都能同心协力，从而建立良好协同关系，培养积极框架。如果能有预见性地对其加以运用，“责任阶梯”框架有利于更友好的开展工作，灵活的变换各种等级角色，使团队协同更高效。

#专栏作家#

动物园园长，微信公众号：首席吹牛官，人人都是产品经理专栏作家。互联网圈十八线作词人，国家一级退堂鼓表演艺术家。颜良而文丑，欢迎交流。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议