时间: 2021-07-30 09:33:52 人气: 0 评论: 0
编辑导语：群思陷阱指的是群体中出现的这样一种现象：群体成员追求“和谐一致”的愿望导致了一个非理性的决策；本文作者分享了关于产品开发过程中遇到的“群思陷阱”的分析，我们一起来了解一下。
“群思陷阱”极易产生不惜一切代价达成一致的倾向，每个人以团体的立场为自己的立场，不同意见被隐藏起来，或者被置之不理，因而群体表现出高度一致。为了和谐一致，人们甚至忘了群体本来的目标。
在日常工作生活乃至新闻上，“群思陷阱”都以不同的展现形式出现过：大学里，很多人都是以寝室为单位，成群结队的活动，当室友都开始赖床、逃课、熬夜时，自己也极易被影响，一方面躺平生活总是充满着巨大的诱惑，另一方面高度追求和谐团队氛围、不孤僻也是大部分人所；因此宁愿浪费时间也不愿意提出进步的诉求，最终只**导致团队内的所有人虚度光阴。
而在回顾大量集体犯罪的案件中，当团队成员在犯案时，往往**因为某一“意见领袖”的临时起意而放弃自身的道德与底线，做出违背法律甚至残忍至极的事情；其本质不仅有领导人行事专断，满足一己私欲的因素在，很大程度也因为成员生怕案后受到团队的疏远，最终成为案件升级的助推器。
而在产品开发过程中，也经常因为各种原因导致整个团队都陷入了群思陷阱中难以自拔。有些团队里，领导人行事专断，自以为是，往往要求团队根据自己的喜好开发内容，导致产品上线后数据一塌糊涂；有些团队各成员之间沟通少，交流不畅，甚至存在个体孤立状态，做完才发现每个人的理解都不同，呈现的效果也南辕北辙；甚至有的团队里因不注重个体的自由表达，导致研发人员习惯性低头写代码，不考虑产品的实际效用，如此恶性循环……
作为产品人，不论是掌握统筹大权的产品总监乃至CEO，还是略显工具人的“产品助理”，在开发过程中，都需要学**并引导团队其他人一同逃离“群思陷阱”，避免偏离产品目标。
不可否认团队内和谐氛围的重要性，如果产品和开发同学经常相互争吵、指责、质疑，**给团队内部造成极大的沟通成本、无意义的资源与时间的浪费，最终的产出物质量也可见一斑。但我们在追求团队内友好氛围时，也需要积极的表达，甚至可以是激烈的讨论。产品可以对开发的实现方式、响应速度、架构扩展性发表自己的建议；开发也可以针对产品功能的目的性、价值性、交互方案表达自己的想法。
曾经在一个产品版本中，关于文件重名时的判断与交互方式，我在产品设计中制定了若重名则展示提醒确认的二次弹窗，交由用户选择更名保存、替换上传的操作；但在开发过程中，客户端研发提出是否可以通过系统自动添加数字后缀的方式上传文件，一来可以同时满足分页/不分页的效果，二来也可以相应减少运行压力。
虽然在用户体验方面，我仍然认为产品不应该直接给用户做决定，尤其是在遇到问题时，更应该告知用户并提供相应的解决方案；但经过双方的沟通以及征求产品总监的意见想法后，最终决定在第一期通过简单的添加数字后缀解决重名问题，并在上线后根据实际用户使用的文件数量与可承载的数量对比确定是否合适增加重名判断提醒功能。
最终双方都获得了各自满意的答案与解决方案，各自表达了不同视角的合理观点，团队氛围也并没有往恶性发展。
我一直认为，CEO、产品、研发乃至运营在本质上思维都是可以互通的，并不**因为职位的高低和职位的不同产生极其巨大的差异。只要是人类就**犯错，只要是人类，他的思想认知就**有偏差有局限，因此，当作为产品，接受到拍脑袋的奇怪决定时，需要学**用于拒绝，用自己的三寸不烂之舌与数据事实防止生产出奇怪的产品功能。
我刚进入企业协同领域时，对于纯B端产品的认知度还很低，加之公司产品实际仍为初创，很多理念、想法都还仅限于一些简单的个人认知基础和竞品的处理方案，因此对于自己的一些产品逻辑其实并没有太大的自信。曾经因为没有把握自己的判断一定是正确的，也不愿在大家面前暴露自己的“无知”和“固执”，未能表达自己的真实想法，压制自己的良心和理智，酿成大错。
在一次内部沟通**中，运营提出有不少个人用户也想通过协同产品来完成与外部联系人的沟通的现状，希望产品可以增加个人版已获得用户增长。因此我在版本设计中新增了注册时的用户类型选项区分个人版与企业版（类似于WPS的个人版与企业版的区分）。
但在产品内部评审**时，老板提出更改选择为默认创建个人版，若需要注册企业版可通过个人版升级实现，理由是产品还在初期，即便是企业想要使用也**先通过试用的方式体验，个人版即可满足相应需求。作为新人的我在表达了个人观点后并未能改变想法，最终硬着头皮改了方案。
结果，版本上线后，运营开始接收到各种用户对于登录注册流程的吐槽，想要体验的企业负责人也因为默认注册的个人版没有企业人员管理相关功能而不再深入了解产品，导致了大量的新用户流失。从这个版本后，我才真正明白了所有功能点都需要经过仔细推敲与数据支撑，纯粹拍脑袋的独立专行的决定都是作为产品经理所应该避免而杜绝的。
在产研团队，不同的岗位承担着不同的责任也面对着不同的“世界”，作为接触用户、市场第一线的产品，所掌握到的信息往往要明显多于开发组的同事们，也就造成了有时候产品为了实现用户需求而引发了开发们的一致炮轰与质疑，其深层原因还是开发对于产品功能的价值点的不清晰与未来方向规划的迷茫性，此时的产品经理需要在版本开发过程中持续的进行价值的灌输，不仅能让研发人员放心，也能激发人的积极性。
我负责的一款**议室管理系统是公司协同产品中的一条重要的独立分支，主要服务于企业内部的**议室管控与改善的解决方案。
在项目成立初期，我便在评审**上首先做了产品线前景说明，大概介绍了目标客户、已有客户、潜在客户的相应内容，并大致介绍了产品的商业目标，获得了极好的反馈；在后续产品开发过程中，团队内的不少成员根据自身已有的经验与理解提供了大量的优秀建议并成功落地；而在开发过程中，每当获得一份新的合作合同乃至意向时，我也**在产品线的项目群内发布公告，每次公告发布我都能看到群内成员的活跃度与积极性有了明显的提高，最终的产品落地效果也比其他项目高出一大截。
防止出现成员之间的信息交流不畅，避免个体处于孤立状态是作为产品负责人需要实现的，不论是小公司的倾其所有进入开发还是大厂的球爹求妈式地申请资源，只有大家获得有效的信息以及一致的目标时，产品开发才更有利于步入正轨，**额完成。
除了前文说的不想成为另类、害怕表现出无知外，没有人愿意承担责任，不想为此负责也是团队陷入群思陷阱的原因之一。我们常说产品需要有主人翁精神，除了对产品有个人认同感、积极主动性，也要勇于承担责任。责任不仅包括自身的调研问题、产品设计缺陷，也包括开发方案、开发进度、对外宣传效用等。
“甩锅”一词其实经常可以在产品与研发中体现，双方经常因为一些原因各自甩锅，产品说是开发没有理解需求、技术能力弱；研发反驳是产品设计缺陷、逻辑混乱。
我个人认为不论是什么原因，产品首先得承担起责任，不造锅也不甩锅，必要时接起别人的锅，只有这样团队内部才能有更正向的发展，产品经理自身也可以获得更好的成长。
相信甩锅的案例大家都有过很深的亲身体**，在此就不再举例。
最近在自己的产品开发过程中陆陆续续遇到了不少问题，因此特别想写一些跟思维、团队、项目相关的内容，分享的同时也希望自己和大家都能够引以为戒，做到更好！
本文由@碌碌无为的阿栓 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
