【原】为什么产品和开发相爱相杀？｜「推论阶梯」可以解释

网络上有很多产品经理和开发人员相爱相杀的故事，因为需求的理解不同，甚至有双方大打出手的案例。作为前产品经理、现开发经理，我深有体会。在公司里，跨部门的职责和沟通，特别容易出现“各说各话”的情况。产品经理能吐槽十几项开发的问题，而开发人员也能罗列若干产品经理的“罪状”。

有时候我总在想，是什么导致这种情况的发生呢？最近看到一个理论叫「推论阶梯」，觉得很好地解释了这种现象。

这个理论是由哈佛商学院名誉教授克里斯·阿吉里斯（Chris Argyris）（其个人介绍可查看维基百科：https://en./wiki/Chris_Argyris）所提出。该模型基于人们经常会在无意识的推理过程中根据可观察到的“数据” 推论人们如何采取行动。

它将我们人的思考过程分为七个阶梯，分别为：「观察」、「选择数据」、「赋予意义」、「假设」、「作出结论」、「调整看法」、「作出行动」。

第一层，我们透过经验和观察得来原始数据；

第二层，我们从我们的经验中筛选特定数据和细节，在不知情的情况下根据我们的偏好、倾向，还有其它我们相信重要的事来筛选它们；

第三层，我们为那些已通过筛选的数据赋予意义并诠释那些数据的内容；

第四层，我们开始基于前一阶段所创造的意义“做出假设”，同时，我们开始混淆事实和故事之间的分际；

第五层，我们基于我们的假设“得出结论”，这一阶段也是我们创造情绪反应的地方；

第六层，我们“调整”了我们对周遭世界的想法，同时第六层建立的信念会影响下一次我们选择的数据；

第七层，我们基于我们调整后的想法“采取行动”。

用这个「推论阶梯」来分析人与人、部门与部门之间的冲突，基本上是这样一个过程。我们会下意识地通过观察到的信息去筛选符合自己利益的方面并赋予其意义，再根据我们自认为正确的结论和情绪去采取行动。当两者的推论阶梯相反时，冲突就产生了。比如产品经理会想，开发为什么连这么简单的事情也做不好，他选择性地忽略了在一开始就没有给出明确的输出；而开发会说，现场的技术支持咋这么差，这点小问题都解决不了，这个时候开发只看到了别人的问题而忽略了自己设计的缺陷。

其实这个「推论阶梯」也适用于我们对自身的认知，比如只了解了一件事的部分信息就开始筛选自己能看懂或感兴趣的部分，在此基础上进一步强化，从而得出错误的假设、想法、结论以及行动。前两周在读西奥迪尼的《影响力》（无意识的行为是如何产生的？-读《影响力》）时，作者举了很多类似的例子。为什么赌马的人一下注就对自己所挑之马获胜的信心立时大增？为什么分手后的情侣在复合后能更容忍对方？为什么明知道独特的冥想术是个骗术，不少人仍然趋之若鹜？等等。

还有一种情况也适用「推论阶梯」，在产品设计和开发的前期，尤其要警惕。我想起去年我负责的一款产品，当时做的时候觉得真了不起，以为我们想出了业界最牛逼的方案，殊不知是因为我们对自己选择的方案人为地赋予了意义和价值，即使在做的过程中已经发现了一些问题，但大家还是选择性地忽略了。等到产品上市后一投放就傻眼了，客户反馈惨不忍睹。

当我们遭遇这些问题的时候，该怎么办呢？克里斯·阿吉里斯（Chris Argyris）在他的学术论文中，给出了几个建议。

1、大多数人将学习狭义地定义为仅解决问题，因此，他们专注于识别和纠正外部环境中的错误。解决问题固然重要，但要想持续学习，管理人员和员工也必须向内看。他们需要批判性地反思自己的行为。

2、大部分人习惯“单循环”，就是准备对他人施加改变，但拒绝任何改变自己的思想和工作习惯的尝试。但实际上，我们应该执行“双循环”，根据信息辨清问题，对变化做出反应，并准备做出改变和行动。向他人学习，通过学习和理解形成良性循环。

3、不要太脆弱，不要想单方面实施控制，不要总抱着“最大化受益、最小化损失”心理。

「推论阶梯」其实就是一个循环，当我们的经验足够多或观察足够全面的时候，我们看事物会更全面，如果能做到从错误中积极提炼更好的“想法”，这样就会形成一个正反馈。

同样道理，在我们说别人或其他部门的问题时，一定要听听自己内心的声音，是为了面子还是为了解决问题，是真的想解决问题还是为了逃避责任，这些在我们内心深处是无法自欺欺人的；在采纳群体证据时，我们也有必要周期性地四处看看，因为群体都有从众心理；在产品设计方面，可以多想一想，我们的思考是否足够完整、周全，不要急着给解决方案，而是多想想问题。

备注及参考资料：

克里斯·阿吉里斯（Chris Argyris）是组织发展的共同创始人，并且以学习型组织的开创性工作而闻名。

在全球50大思想家名人堂这份杂志上，克里斯·阿吉里斯（Chris Argyris）是比较早期入选的人物之一。

https:///blog/chris-argyris-1923-2013-appreciation/