翻到一个神贴 How to make Product give a shit about your architecture proposal ，标题直译就是《如何让沙雕产品经理接受技术改造》

具体故事，原文非常值得一看。搞了这么多研发，产品经理各种水平的都遇到过一堆，最大的烦恼就是“我有个想法”，“今天就要”而全然不顾你当前技术架构的问题。到底是技术优先，还是业务优先？开发人员和销售非常普遍的冲突怎么处理？

产品经理，老板，甲方，销售，实际上是研发的衣食父母。他们所有的诉求：

1. 产品不管你的技术问题，他们也不懂。他们只关心 产品 本身
2. 产品需要的是一个 结果，而不是一个白板上巨复杂的分布式系统架构图
3. 产品是人，产品为人服务。他们也能理解有工程方面的顾虑，这也是他们找开发的原因。他们是来“讨价还价”的！

开发是“乙方”，正如那个文章里的 水管工 故事一样，实际上是 “赢得信任” 的实施方。所以接下来的套路是：

1. 你先不要 what about，先别反驳说 but 。先按照理想的条件，全部答应下来，
2. 做一个理想化，全套，SSVIP，贵宾级别的报价，所谓 platinum package。内部需求就把人力、服务器、时间、排期等成本按最坏的估计全部算出来。
3. 拿这套方案，给到需求方，一定要让他们很诧异的问出：“why” ，怎么这么麻烦啊！？
4. 这就是让产品对你的技术问题关心的机会！接下来，开发需要有礼貌，不卑不亢的，有理有据的把你的处境讲出来，要展示你的专业能力和素养。
5. 接下来需要让对方陷入自我怀疑，内心：“Do I really need all this? 是不是这要求有点过份！？”
6. 最终结论，还是要做，换更经济的方式去做，要么不做。如果这件事是能挣钱的，那么的确投入人力物力时间去征服麻烦啊。

文章也讨论了，话也说回来，一个粗糙的结果，和没有结果，哪个更讨人厌？实际上是粗糙的结果。就好比故事里的水管工，你下水道漏了，又舍不得大修，就缝缝补补。结果过一段时间又漏了。这还不如不修。烦呐！

所以一般的经验是，要么不做，要么就把一个事彻底解决最好。不要交付半吊子工程！

当然，这个时候要思路灵活。水管坏了不一定要在原地修补啊，说不定换一个管线完全绕过以前的大坑呢？

所以就回到了这篇blog的主题：tradeoff

以前我不知道如何准确翻译这个词，一直把叫“妥协”。但是这似乎有点贬义。或许叫 折衷，取舍 更好？。

我觉得装逼的翻译是 —— 中庸。

成年人的世界哪有那么多“既要……又要”，乃至“……还要”。

以前上学的时候，就喜欢“中庸”，60分及格万岁，一个知识点了解个大概就行，平庸，和稀泥，不表态，无原则，优柔寡断。结果贻害无穷。一只吃亏到而立之年，发现中了孔老二的圈套。

对中庸最大的误会是它丫的压根就不应该是一个“方法论”，而是一个“对结果的欣然承认”态度；

作为方法论，我的心得是，才接触一个事，就要走极端。抓东西就从一个“抓手”入手，如果恰好能抓住“主要”矛盾那就最好不过，而且最好只抓一个。抓住，抓稳了之后，再去了解事物的全貌和corner case，这个时候事半功倍势如破竹。

就好比，以前打 CS 1.5，突然转角处出现两个敌人，你慌乱之中，既不向A也不朝B开枪，而是瞄准他俩的中间空隙biu～biu～biu～。然后就躺了。这种遭遇战就应该训练自己的下意思，必须集中火力，断其一指。

做事也一样，认准一个方向，全力推到超出它极限为止；然后再停下来，考虑有没有更好的方案，做到周全；其次考虑对方接受程度，该省省能砍砍；最后一看，嘿，也就一般般。

好吧。其实我也不懂中庸，也不想懂，更不想revision中庸，就是纯粹想附会，如果是个误会也无所谓。就这样吧。