avoid wishful thinking design

背景

最近工作中经历了一次方案设计的讨论，作为方案 reviewer 我跟同事有多次探讨甚至争论，所幸的是最终我们在方案设计上形成了一致。后来我在反思这次方案设计时心中隐隐约约感觉还是有问题：这次方案设计是在围绕技术提出问题解决之，不是围绕问题寻找技术解决之。细细想来，这次的技术方案有过重的平台化思维、拿着锤子找钉子，甚至有一点"炫技"的味道。这让我想起了道哥一段话：

"细节根本不会决定产品的成败，甚至很多成功产品在早期的时候产品体验和各种细节都是一塌糊涂。准确来讲，是深度决定了产品的成败。包括了技术的深度、对行业对客户理解的深度等等。"

代码方案的设计不是一厢情愿的拿着锤子找钉子，起码严肃的产品交付不应该这样子，到了代码方案设计阶段的时候意味着对于产品分析已经基本完成，代码方案的设计应该是围绕“产品价值”来展开，这对应于道哥说的对“对行业、对客户的理解”。代码方案的设计不应该陷入 wishful thinking，应用技术≠理解技术，对技术的理解应该是化繁为简的（less is more）。

另外，值得说明的是这里说的 wishful thinking 是指设计方案时的一厢情愿，而不是《Structure and Interpertation of Computer Programs》中介绍的数据抽象策略即 programming by wishful thinking。

什么是 wishful thinking

Wishful thinking is the formation of beliefs based on what might be pleasing to imagine, rather than on evidence, rationality, or reality. It is a product of resolving conflicts between belief and desire.

所谓一厢情愿（wishful thinking）就是基于美好的想象而不是基于理性思考和客观证据而形成的想法和信念。举个很简单的例子：

我的儿子怎么可能酒驾撞死人？他做事情一向都很谨慎小心的。
他做xxx小心，blah, blah, blah
他很谨慎，blash, blah, blah
...

上面这个简单的例子，清醒的我们都会嗤之以鼻——两个根本不存在因果关系。但是在设计令人心血澎湃的 nubility awesome idea，我们就会陷入 Christopher Booker 形容的“fantasy circle”，根本不会理性思考，只会为自己寻找证明的成立的证据是不是面对可能不成立的现实。

而这一点恰恰是在我们做代码方案设计的时候被主动忽视和隐藏的一个陷阱，我代码方案设计的时候是这样的：客户用上我们的方案就可以怎么样，这个方案技术是业界规范，这个抽象的鲁棒性是无可挑剔，我们是怎么样怎么样……

如果这个时候我们停下来思考一下：如果客户不使用我们的方案设计他们有其他可选项吗？如果客户不使用我们的方案我们的这些证明和优势还有存在的必要和意义吗？

可是陷入 wishful thinking circle 的时候，很难意识到需要这样问自己问题，更难的是我们需要放下“技术自信”面对现实。

如何避免 wishful thinking design

产品设计中最容易的事情是一厢情愿的想法。这是你认为你的产品想法很好的部分，你开始寻找任何证据来支持你的一厢情愿。这是你失去现实的部分。你开始回避所有不支持你想法的反馈。你寻找对你的想法的确认。你不再问人们为什么不关心你的产品，而是问 "你会使用我的伟大产品吗？并开始寻找 "是的，我们会使用它 "的答案。你开始想象你的产品被数以百万计的人使用，而你所要做的就是建立一个产品并为其添加大量功能。然后等到他们都放弃他们以前所做的和使用的一切，突然开始使用你的出色的解决方案。