因為一個版本bug的問題，假期跟同事開會交流，新版本的上線導致原來更多問題的出現，因此開會的過程就必然會涉及到問題追責。

這如果是在以前工作的時候，我對于此類問題的解決路徑更多的會選擇本能的憤怒，指責。但經歷創業后，我發現這“憤怒”也許并不能避免問題的發生。

面對問題，當在指責別人的時候，這其實并不能有效的解決問題。

因此，我選擇的方式是：從共識開始聊起。

什么是共識，共識就是共同的認識。

之所以這樣展開交流，是做了一個假設：

這問題的出現一定不是大家故意設定的，甚至他們有可能都不認為這是問題。即：對問題本身理解有問題。

因此，從共識談起就顯得非常有必要，共識的目的就是大家統一目標，即：

我們這個版本的規格，達成的目標認識先要統一。

果然，在共識階段每個人對于問題的目標認識是有偏差的，不同的人對于規格的理解認識是不同的。

因此也就不難理解同樣一個結果，我認為不對，有的人就會認為對的原因了。

對和不對的爭論，指責這已經不重要。重要的是我們理解的問題并沒有形成共識。

如此，會議要解決的問題其實并不是這個版本bug的問題，更是我們對于產品開發形成共識的機制出了問題。

問題找對了，答案也就更容易產生。基于達成共識的源頭問題，我們一起討論形成了新的產品開發機制，而版本出現的bug也將在新機制基礎上自然會得到有效解決。更或者說：

這其實并不是bug的錯，bug不過是問題的表象，沒有形成對產品開發的共識機制才是問題的源頭。

我們常說一次把事情做好，更多的是說把表像問題做的更好，避免同樣的表象再發生。但真正在解決問題的時候，就很容易被表象迷惑，投入更大的注意力去改變表象，但這樣的解決模式必然無法避免同類問題的再發生。

任何現象背后被有規律，找到問題的底層規律，對規律加以改變，才可能讓表象變得趨于美好起來。

我曾經看過一句話：好的貴人不是幫助別人解決問題，而是幫助別人選擇問題。

這在我們日常工作中，也非常適用于業務賦能。

無論是跟客戶業務交流還是內部問題溝通，選擇比勤奮重要，學會洞見客戶預算背后的真正問題，學會發展團隊效率的底層問題，然后才是解決問題的過程。

這非常重要，面對問題的發生，不能總是慣性的想要改變表象，發泄不滿。核心還是要學會洞見表象之下那個造成不滿的源頭所在，選擇比勤奮重要的原因也在于此，共勉。

今日思考，不求絕對，但求養成獨立思考的習慣。