因为一个版本bug的问题，假期跟同事开会交流，新版本的上线导致原来更多问题的出现，因此开会的过程就必然会涉及到问题追责。
这如果是在以前工作的时候，我对于此类问题的解决路径更多的会选择本能的愤怒，指责。但经历创业后，我发现这“愤怒”也许并不能避免问题的发生。
面对问题，当在指责别人的时候，这其实并不能有效的解决问题。
因此，我选择的方式是：从共识开始聊起。
什么是共识，共识就是共同的认识。
之所以这样展开交流，是做了一个假设：
这问题的出现一定不是大家故意设定的，甚至他们有可能都不认为这是问题。即：对问题本身理解有问题。
因此，从共识谈起就显得非常有必要，共识的目的就是大家统一目标，即：
我们这个版本的规格，达成的目标认识先要统一。
果然，在共识阶段每个人对于问题的目标认识是有偏差的，不同的人对于规格的理解认识是不同的。
因此也就不难理解同样一个结果，我认为不对，有的人就会认为对的原因了。
对和不对的争论，指责这已经不重要。重要的是我们理解的问题并没有形成共识。
如此，会议要解决的问题其实并不是这个版本bug的问题，更是我们对于产品开发形成共识的机制出了问题。
问题找对了，答案也就更容易产生。基于达成共识的源头问题，我们一起讨论形成了新的产品开发机制，而版本出现的bug也将在新机制基础上自然会得到有效解决。更或者说：
这其实并不是bug的错，bug不过是问题的表象，没有形成对产品开发的共识机制才是问题的源头。
我们常说一次把事情做好，更多的是说把表像问题做的更好，避免同样的表象再发生。但真正在解决问题的时候，就很容易被表象迷惑，投入更大的注意力去改变表象，但这样的解决模式必然无法避免同类问题的再发生。
任何现象背后被有规律，找到问题的底层规律，对规律加以改变，才可能让表象变得趋于美好起来。
我曾经看过一句话：好的贵人不是帮助别人解决问题，而是帮助别人选择问题。
这在我们日常工作中，也非常适用于业务赋能。
无论是跟客户业务交流还是内部问题沟通，选择比勤奋重要，学会洞见客户预算背后的真正问题，学会发展团队效率的底层问题，然后才是解决问题的过程。
这非常重要，面对问题的发生，不能总是惯性的想要改变表象，发泄不满。核心还是要学会洞见表象之下那个造成不满的源头所在，选择比勤奋重要的原因也在于此，共勉。
今日思考，不求绝对，但求养成独立思考的习惯。
