最近一段时间还蛮神奇的，仿佛有人再一步步地帮助拨开心中的谜团。
事情的起因是这样的：
前段自己做了个业务设计，在团队Review之前，我把设计文档命名为【Notification Design】，翻译成中文，就是【通知设计】。看到这个名字，大家基本应该都能轻车熟路，了解大体上它是干嘛的，ok。那我来讲讲为什么用这个名字呢？一开始和业务团队沟通需求时，我们的用语总是这样的，“我们服务有了新数据，我们就通知到你们，如果XXX，我们就以事件的方式给到你们”，之类的云云而。看，这不顺手拈来嘛。
可能有些人觉得听着，也没啥问题，对，我就是那些人，不假思索地被业务“套路”了。俗话讲：入坑了。
后来Review之后，设计被冠以<过度设计>之名，让再修改。哈哈，犯了很多人都会犯的错误，因为年轻。
被打回之后，我就反复思索领导讲的话，嗯，顿悟，真的是顿悟，我重新把文档命名为【产品间数据交互方案】。这个名字，有木有一种更清晰的意味，直接反映了业务功能，且是不带具体方案的功能描述，需要细细体会。
事情的经过基本就是这样，文档的命名由【Notification Design】修改成了【产品间数据交互方案】。
方案做完了，功能也开发完了，但是这个心结其实自己一直都没有过去。
心心念念,必有回响。很巧的是，我遇到了个很有意思的概念，叫X-Y > problem。
原文如下
......
产品要做的任何事情，都应该围绕着某一个或某几个利益相关者的具体问题展开。很多产品经理在这里投入的时间和精力是不够的，大家更喜欢花时间在解决方案上，也就是后面会提到的[用什么方法]上面。这是不对的，应该在理解谁的问题，什么问题之后，才去想解决方案。
这个错误也被称作X-Y problem，也就是，我们可能希望X问题，然后想到了Y方案，随后把所有的精力放在Y这个解决方案上，而忽略了对要解决问题的本身的理解......
有种说到心里的感觉，这个X-Y Problem不就是我上面收集设计需求的经历嘛，把问题想成了方案的本身。在这之前，我常听到的另一些原则，比如第一性原理，做产品地不忘初心等等，这些原则，大白话，其实大体就是上面这位产品经理亲身体会去理解的东西。这时候脑海浮现，为什么懂了这么道理，我们依然过不好这一生~~，可能就是因为没有体验过吧，没有经历过吧，果然还是那句话，读万卷书，不如行万里路。
再来一遍，你说你巧不巧， 心心念念,必有回响。
就在昨天，4.23日，听了一场直播，是张建飞大佬讲的关于抽象的心得，期间讲了一本书《系统架构 -复杂系统的产品设计与开发》，结束后，书正巧几年前买了，去书中翻到直播中讲的一个案例，我去，看到一个标题叫【与特定解决方案无关的功能和概念】，我的天呐，顿时心里那个激动，原来早有大佬总结这个误区了。
这里，我还介绍下书中的那个例子
图中讲的是个开瓶器的例子，现在需求是如何把通过塞子把酒瓶打开？
通常情况下，我们可以这样描述这个系统功能，
- 使用螺旋把瓶塞拉拽出来；
- 注入空气把塞子推进去；
- 用叉子把塞子撬出来；
而采用与特定解决方案无关的方式来命名这个系统功能，
- 移动塞子；
看，采用与特定解决方案无关的方式来命名系统功能，似乎想象空间一下子都打开了，我们不会陷入里面，因为推、撬、拉拽等等，都是不同的实现方式，我们只要在合适的场景下，选取正确的方式就好了。
然后我们再回过头来看，前段时间review的设计，一下子就明白了，【Notification Design】明显就是个带有技术特征的设计，根据这个名字就很容易想到是否需要引入MQ或者要实现一套Pub/Sub机制等来满足需求。那么可能带来的后果就是 准备996了吧！！！
在Review之后，在新的设计方案里，我们仅仅是提供了几个API，让各个产品自己来获取数据。就这么简单，前一种，可能就是我们常常说的过度设计，可以体会下。
就是这样，一次简单的成长经历，每个架构人学习架构中必经的路。想起了去年和部门leader一次交流，他提到，架构师大概会经历三个阶段：“1. 缺少架构设计；2. 过度架构设计；3. 架构设计既不能多也不能少；”，大概是这样，记得不太清了。这三者其实是非常难权衡的，需要我们在日常的架构中不断地磨炼，找感觉。
讲几点方案设计的感受
- 方案要做400%的设计，意思是设计要足够多；
- 多走去调研，直到你心里不再有疑惑；
- 要用务实的语言写出方案的Scope，务实是指用准确的语言描述业务需求；
- 想明白Out Of Scope，我觉得这个最重要，这类似学习个组件，我们要知道它的使用场景，更要知道在什么场景下不合适；
- 开放的心态，多听听别人的意见；
好了，干饭人，继续努力吧！