因為一個版本bug的問題,假期跟同事開會交流,新版本的上線導致原來更多問題的出現,因此開會的過程就必然會涉及到問題追責。
這如果是在以前工作的時候,我對于此類問題的解決路徑更多的會選擇本能的憤怒,指責。但經歷創業后,我發現這“憤怒”也許并不能避免問題的發生。
面對問題,當在指責別人的時候,這其實并不能有效的解決問題。
因此,我選擇的方式是:從共識開始聊起。
什么是共識,共識就是共同的認識。
之所以這樣展開交流,是做了一個假設:
這問題的出現一定不是大家故意設定的,甚至他們有可能都不認為這是問題。即:對問題本身理解有問題。
因此,從共識談起就顯得非常有必要,共識的目的就是大家統一目標,即:
我們這個版本的規格,達成的目標認識先要統一。
果然,在共識階段每個人對于問題的目標認識是有偏差的,不同的人對于規格的理解認識是不同的。
因此也就不難理解同樣一個結果,我認為不對,有的人就會認為對的原因了。
對和不對的爭論,指責這已經不重要。重要的是我們理解的問題并沒有形成共識。
如此,會議要解決的問題其實并不是這個版本bug的問題,更是我們對于產品開發形成共識的機制出了問題。
問題找對了,答案也就更容易產生。基于達成共識的源頭問題,我們一起討論形成了新的產品開發機制,而版本出現的bug也將在新機制基礎上自然會得到有效解決。更或者說:
這其實并不是bug的錯,bug不過是問題的表象,沒有形成對產品開發的共識機制才是問題的源頭。
我們常說一次把事情做好,更多的是說把表像問題做的更好,避免同樣的表象再發生。但真正在解決問題的時候,就很容易被表象迷惑,投入更大的注意力去改變表象,但這樣的解決模式必然無法避免同類問題的再發生。
任何現象背后被有規律,找到問題的底層規律,對規律加以改變,才可能讓表象變得趨于美好起來。
我曾經看過一句話:好的貴人不是幫助別人解決問題,而是幫助別人選擇問題。
這在我們日常工作中,也非常適用于業務賦能。
無論是跟客戶業務交流還是內部問題溝通,選擇比勤奮重要,學會洞見客戶預算背后的真正問題,學會發展團隊效率的底層問題,然后才是解決問題的過程。
這非常重要,面對問題的發生,不能總是慣性的想要改變表象,發泄不滿。核心還是要學會洞見表象之下那個造成不滿的源頭所在,選擇比勤奮重要的原因也在于此,共勉。
今日思考,不求絕對,但求養成獨立思考的習慣。