注：这是一篇把之前的一系列推文重新整合修正后的稿件，加入一些新思考，删除冗余描述，对排版做优化，以方便读者朋友们阅读。

一个亲身经历的地狱笑话

最近在公司经历了一个项目，堪称地狱笑话。

为了信息脱敏，叙述中会掺杂真假信息，但绝对不会影响你理解故事的核心。

我负责一个数据产品，其中有个关键的筛选字段，因诞生太早，与公司后来的统一标准不符。这导致客户体验割裂，投诉不断。

2022年，前任评估过修复方案，结论是成本太高，ROI太低，项目被搁置。

今年，问题临近爆雷，我接手了这个项目。设计了一个成本可控的方案，准备推动。但戏剧性的变化开始了：

首先，支持这个项目的部门负责人离职。大老板对这事的态度变得暧昧，他看得到收益，但始终对成本存疑，不反对，也不力推。没有自上而下的强推，底层治理项目基本就是原地踏步。

一个月后，大老板也走了。新老板到岗，对着这个问题一顿输出，批评团队没有防患于未然，导致现在积重难返。

又一周后，我转岗了。我的新任务，是参与重构公司级的标准——一个向前完全不兼容的重构。

这意味着原来那个部门我留下来的半成品项目需要推倒重做，当然思路还是可以借鉴的。

我亲手点的火，换了个部门，再亲手来灭。

事情到了这个地步让我感觉这简直是一个巨型的地狱笑话。

草台班子

这个故事很容易让人联想到一个网络段子：这个世界是由草台班子组成的。

在我有限的认知里面这句话最早应该出自于论坛 Stage1st。

原文是：「我工作以后才发现，大家都是草台班子。政府草台，企业草台，我也草台，大家都草台，凑合赚钱过日子。一个企业，看着像台奔驰在高速公路上的豪华轿车，里面其实是几个人蹬着自行车顶个壳。路上的车都是这样，大家谁都不戳破。」

后来被不知道哪个网红发扬光大了。

但其实草台这件事情基本上可以说是市场经济或者自然选择之下的必然产物。

如果了解人类眼球的结构，就会忍不住感叹，上帝真的是一个草台程序员。

把人类的视网膜装反了不说，为了传输数据还搞了个飞线，导致盲点的存在，最后还得靠人类无敌的大脑疯狂二次后期处理，人肉 HDR 才得以实现良好的视觉体验。

但是这不妨碍人类成为这个星球上事实上的统治级物种，站在食物链的顶端。

无论是对一个物种，还是一家公司，任何对「生存」这一核心目标无益的过度优化，本质上都是一种自我满足。

面对一个难题，最简单的做法是责怪前人没有防患于未然。

但在此之前，不妨反问自己：设想中的「完美」优化，能带来多少收益？需要付出多大代价？这次优化如果视为一次固定资产投资，需要多久才能收回成本？

很多时候，拒绝一个看似「正确」的提议，反而是更明智的选择。

许多人在调整软件时，忽略了一个核心问题：软件是一种固定资产。

重构是不需要勇气的，拒绝重构才需要勇气，动辄重构是用行动的勤奋掩盖思考的懒惰。

37signals 的主页上有句话：「No」 is no to one thing. 「Yes」 is no to a lot of things.

这句话的意思是，每当你对一件事说「是」，你就同时对其他所有可能性说了「不」。

理解这一点，需要从投资、工程、产品可行性和需求时效性四个角度来看。

第一，做需求是一种投资。 如果一个需求不符合产品原则，不服务于年度规划，在单个项目的ROI上也没有明显收益，那为什么要投入资源？更直接地说，即便ROI再高，如果与团队的核心目标（KPI）无关，接手的动机又是什么？

第二，每个新需求都可能增加软件的债务。 软件的复杂度会随着功能叠加而必然上升，无论工程师多么谨慎。而软件是公司的核心资产，急剧增加系统的复杂度，无异于「破坏固定资产」。在传统行业，破坏固定资产是大事；但在互联网公司，制造技术债务却司空见惯。

第三，不是所有问题都能被完美解决。 解决一个问题，很可能引发新的、更棘手的问题。 很多人都想教张小龙做产品。比如，有人抱怨微信PC端不支持密码登录。但如果真的加上，马上会有人质疑安全性，毕竟微信里有钱包。又比如，有人抱怨微信的文件传输大小限制。如果放开限制，用户又会开始抱怨微信占用存储空间。这些看似简单的改动，背后都是复杂的权衡。

第四，不是每个问题都需要立即被解决。 许多问题会随着时间推移而自行消失或变得不再重要。 比如性能问题。如果一个运算的复杂度不会随着业务规模扩大而上升，就可以考虑不优化。因为根据摩尔定律，18个月后硬件性能会翻倍，问题自然缓解。 再比如内部效率工具。除非能证明某个流程的人力消耗是长期、大量且持续增长的，否则投入自动化工具的意义不大。很多时候，效能工具刚上线，对应的业务就已经萎缩甚至消亡了。

因此，接到大部分需求后，首要考虑的不是如何解决，而是是否需要解决。有时候，问题会自己解决，或者承载问题的业务本身被「解决」了。

把软件系统当作一种会折旧的固定资产来管理，才能真正理解「拒绝」的价值。

拒绝去解决一个不值得解决的问题，本质上就是在维护公司资产。

我们看到的那些混乱不堪的「草台」产物，很多并非源于最初的疏忽，而是在没有想清楚上述问题前，就仓促进行重构或优化的结果——在既有的「屎山」上继续堆砌，最终越陷越深。

所谓的「防患于未然」，如果缺乏深思熟虑，措施本身不仅无法防患，反而会增加新的隐患。

从这个角度看，等到问题快要爆雷时再集中处理，未必不是一种有效的策略。事实上，这也是大多数组织在实践中的选择。

尽管看上去这是一种很「草台」的选择。

ROI 会失灵吗？

做产品最忌讳过度优化，任何对生存无益的改进，本质上都是自我满足，只会加速固定资产的折旧。

但如何判断一件事是必要的「防患于未然」，还是「锦上添花」式的过度优化？

许多公司的答案是：数据驱动，用ROI（投入产出比）来决策。

这听起来无懈可击，在大多数场景下也确实有效。数据作为一种共识机制，可以极大地降低沟通成本。

但数据度量并非万能，比如：

• 大型创新项目，其结果无法用现有数据预演。
• 体验优化项目，如统一设计系统，其长期收益难以被短期数据量化。
• 数据度量手段本身可能不准确，甚至会误导。我曾经历过核心性能指标上升，但用户满意度反而下降的情况。
• 对于一些小改动，度量的成本甚至可能接近项目本身的成本。

就好比我故事里的项目，它属于「道理上都懂，但数据上难证」的类型。

当一个组织过度依赖可量化的ROI时，会自然形成一种惯性：倾向于做易于度量的渐进式改进，回避需要承担风险的激进式创新。

因为前者更容易在绩效考核中获得认可。这或许是许多大公司陷入「慢性死亡」的根源之一。

这也是为什么很多技术债务、体验问题总会拖到快爆雷时才被解决。

因为临近爆雷时，不做事的损失变得清晰可见，ROI的计算也就变得简单直接。

即便如此，我仍然认为花精力去做一些在数据层面上没有价值的事情是值得的。

因为很多时候我们断定一件事没有价值，并非因为它真的没有价值，而是我们现有的工具和认知，尚无法度量它的价值。

这些很难度量的价值，是我在最初的小故事里面愿意去接一个看上去很坑的项目的原因。

如果不持续投入维护成本，一个90分的产品会因系统的日常迭代造成的「固定资产折旧」，逐渐滑落到60分，最终被市场淘汰。

仅仅因为价值难以度量就放弃那些正确的事，或许一两年内相安无事，长此积累必然会造成成无法挽回的恶果。

因此，产品经理不仅要关注宏观的数据，更要去审视微观的用户反馈，倾听真实的声音，去一条一条地看用户原声，听用户访谈，通过微观观察来佐证自己的判断，避免因为数据度量的缺陷忽视真正重要的问题。

我认为打造一个好产品的欲望，是每一个加入到这个行业的人最原始的动力之一，而用户的真实反馈可以最大程度激发一个人打造好产品的原始欲望，

当所有方法论和流程都陷入僵局时，这种源于直觉的判断力，看似古老的访谈方法，往往是最终的指南。

信仰投入

要解决ROI失灵的困境，团队必须保有打造卓越产品的原始欲望，而公司的职责，则是设计一种机制来保护这种欲望，使其能够落地，并确保践行者不受伤害。

许多公司采用的策略是制定「产品原则」。

产品原则是在产品设计、运营、迭代过程中需要共同遵守的核心规范。

产品原则的核心逻辑是用「共同信仰」代替「复杂的数据度量」，从而降低组织运行时的摩擦成本。

这并非不科学，恰恰相反，产品原则本身就来自于大量实践的总结，是将已被验证的业务认知固化为决策依据。

例如各大 OTA 的机票搜索相比火车票搜索要慢 3 倍，“找到最低价”的优先级高于“搜索速度”。

用户愿意忍受更长的加载时间以换取更便宜的机票。这条原则一旦确立，团队就不必在每次迭代时都重新论证和测试是否要这么去做。

市面上公开自己产品原则的公司不多，有赞就是一个，有赞的产品原则中有一条内容是：「不可减少，每个用户都重要。新产品不能比老产品的功能少，不应该轻易下线产品功能，不降低服务。不让少数服从多数，每个用户的需求和习惯都是重要的。」

这既是保护客户，避免产研团队犯下低级错误，防止产品体验在追求短期指标的过程中滑向深渊，也是在警示产研团队，上线任何功能都需深思熟虑。

同时产品原则还会有一个潜在的好处，就是减少「债务」的产生。当我们需要重构时，究其根本原因大概率是以前为了快速迭代业务做了很多糙猛快的决策，但是大部分产品原则在设定的时候天然就会更倾向于长期而非短期价值，所以一些原则的设定可以避免债务快速堆积，进而避免我们总是陷入不重构就迭代不下去，不得不面临削减业务投入来重构的窘境。

想清楚这一点之后就会发现，这个世界上绝大部分基础设施建设都是信仰投入。

比如中国的扶贫，为什么要跑到穷山恶水的地方去扶贫，这个 ROI 用经济账算怎么都不可能是正的，但是为什么要扶贫，从一个角度来说这是信仰，是一个政党对自己民众的承诺。

另一个角度来说也是信仰，历史上那些不扶贫的朝代都已经不复存在了。

康威定律

然而，有时一个逻辑上明确有价值、却无法计算ROI的工作推不动，问题可能不在于度量本身，而在于组织结构。

这就引出了康威定律：「设计系统的组织，其产生的设计等同于组织之内、组织之间沟通结构的副本。」

通俗地讲，组织是什么结构，你就会做出什么结构的产品。

现在，用康威定律来复盘我的「地狱笑话」：

• 为什么项目最初推不动？ 因为我所在的部门和老板，其核心目标（KPI）里没有「统一公司级标准」这一项。他们的沟通结构是局部的，自然会排斥这种需要跨部门协调、短期收益不明确的「份外事」。
• 为什么新老板能强推？ 因为他作为新的权力节点，暂时改变了局部的沟通结构和目标函数，他的意志覆盖了ROI的计算。
• 为什么项目最终又停了？ 因为我被调到了一个更高层级的、负责制定「公司级标准」的组织。这个新组织的出现，从根本上改变了整个公司关于「数据标准」的沟通结构。

项目的生死起伏，看似充满偶然，实则是组织结构变迁的必然结果。

理解康威定律，对产品经理的意义重大。

首先，它提供了一个客观视角来审视组织结构。 这不是鼓励办公室政治，而是要求我们从产品的理想架构出发，反思当前的组织结构是否与之匹配。当一个项目无法推进时，与其归咎于个人，不如先分析是否存在结构性的阻力。

了解这一点，能帮助我们在公司的宏大目标下，找到最适合自己的位置与发力点，减少不必要的内耗。

其次，它让我们理解团队间的冲突是系统性的。 在大公司里，不同团队的目标函数天然存在冲突。负责用户体验的团队和负责商业化的团队，背负的指标不同，日常争执在所难免。这并非个人恩怨，而是组织结构决定的必然现象。

将这些冲突视为系统中的正常博弈，心态会更平和。如果你的需求依赖对方，但与对方的核心KPI相悖，那么问题出在组织设计，而非个人刁难。

用科学的工程理论去理解组织现象，可以帮助我们避免陷入犬儒主义的陷阱，既能脚踏实地，又不至随波逐流。

很多事情背后有其客观规律，我们要做的是学习并适应它，而不是抱怨或扭曲它。

为什么每个从业者需要有自己的产品

说了这么多就会发现，一大堆所谓的长期问题和短期问题的平衡，解决之道无外乎良好的企业文化、团队共识和组织结构。

现实情况远比我上面说的理论更加复杂。

康威定律可以正着用，也可以反着用。可以为了设计合理的产品而设计合理的组织架构，也可以为了自己的利益，利用自身在组织的位置在软件上卡位，这种卡位显然并不是为了产品本身对客户更有价值，而是为了自身在这个组织上的位置而做的。

很多离谱的操作，有时候只是为了生存罢了，只是每个人求生的底线不同。倒也不用苛责，大路朝天，各走一边。

在复杂的公司环境中，要区分一个人的行为究竟是为了个人利益、组织利益，还是真心为了产品，是极其困难的。个人利益、部门墙、KPI导向，这些因素交织在一起，使得纯粹的产品思考变得奢侈。

这就是为什么每个从业者都需要有自己的产品。

无论是做一个开源项目、一个独立应用，还是写一个博客，拥有一个完全由自己掌控的产品，能让我们以最纯粹、最理性的视角去亲身体验前文讨论的一切。

当你面对完全属于自己的产品时，所有决策的出发点都是唯一的：如何让它变得更好。这时，你不用再纠结于ROI的短期计算，也不必受困于组织结构的制约。你是唯一的负责人，所有的投入和产出、短期利益和长期价值，都由你一人权衡。

在这个过程中，你是绝对的理性人。或者说，你的所有“私心”，就是产品的成功本身。

这种毫无保留的实践，是理解产品、商业和组织运作最深刻、最直接的方式。

进一步说，自己想做什么，如何做，和什么人一起做，打造一个什么样的自己，其实才是每个人需要思考的终极话题。