答案永遠在現場

答案永遠在現場

   中國歷史上，中華民族和外族開戰敗多勝少，僅僅從軍事的角度開來，這也是正常的。不管是契丹突厥，仍是滿金匈奴，他們的指揮官都是在一線，反應迅速，戰略戰術調整及時；中原的指揮官都是在廟堂之上，妙算天下，某些王朝末年，還出現要等皇帝老子賜下戰陣圖擺陣的無厘頭時間。二者一對比，一頭狼咬一個行動遲緩的胖子，基本這就輸定了。

   一樣，一羣歷來沒有到客戶現場，看過客戶是怎麼使用咱們產品的研發經理，舒服的坐在辦公室裏，深思熟慮後，突然一拍腦殼，咱們應該加個XX功能/器件，這樣就能方便客戶怎麼，怎麼使用咱們的產品，多麼讓人激動的產品設計啊——這樣的產品，估計也好用不到哪裏去。

   躲在後方，屏蔽掉一線真實的聲音，經過冷冰冰的系統，就會把一線的一個個呼喚和需求，變成一個量化的數字遊戲。因此一線明明在呼喚，咱們須要XX，須要XXX。可是對於後端，看到的是一張張project表格，這個功能須要三我的月，這個功能須要六我的月，這個功能分分鐘的事兒。若是要我四個月出版本，我只能作到XX、XX功能。一樣，bug也是。可能一個bug對客戶來講，是緊急的致命的。可是流轉到後端，就是高中低，難易間的無數bug中的一個而已。

   2009年開年，任正非向華爲全體員工發出了振聾發聵的吶喊：讓聽到炮聲的人呼喚炮火！讓一線直接決策！沒有對企業經營管理本真的全神貫注，沒有對答案永遠在現場的心照不宣，沒有對每個滋生官僚癌細胞的深惡痛絕，沒有頭拱地不找藉口解決問題的地頭力，就發不出這麼強勢的吶喊。借用尼采的話說，這僅僅是力的事業：具備本世紀的一切病態特徵，但要以充盈的、彈性的、再造的力來調整。

   從心理的角度：

   網上有一個流傳已久的程序員的段子：若是你給程序員說：你的程序有bug！程序員會說：是你丫腦殘不會用吧？可是若是你給程序員說：你看來來，我是否是不會用，這個地方總是搞不定？程序員心理就會想：我擦，不會又有bug吧？

   一樣，你給一個研發經理說：你設計的產品有問題！研發經理會說：怎麼可能，是你不會用吧，咱們但是專業的人精心設計的，你知不知道目前主流的交互習慣和工程學？可是若是你讓研發經理本身到客戶現場，看客戶使用產品的場景——研發經理心理就會想：我艹，又傻X了，這個地方回去要改。

   從溝通的角度：

   層層反饋註定會是失真的，各類資訊機構用爛的一張圖，再次秀給你們。因此到一線去，聽聽客戶真實的需求是什麼，看準目標比盲目努力，更事半功倍。

   此外，專一於研發的研發經理，常常會困擾於市場方向產品經理的一個個需求：我要這麼這麼作，這個地方加個按鈕，一按就有什麼什麼效果，或者加個功能，實現什麼什麼功能。這種描述，是產品經理我的的明確要求，我要什麼，我告訴你怎麼作，你就去研發吧。實際上，客戶自己的需求，可能有不少的實現方式。而產品經理，每每由於種種緣由，選不到最好的方式，甚至選擇的實現方式，在框架上會和不少業務邏輯衝突。要相信，研發人員在本身的領域裏面都是聰明人，研發經理會找到更好的解決方案，因此，只須要把研發經理和客戶，放在一塊兒，而後產品經理充當翻譯器和買單者就ok了。

   從管理的角度：

   打破山頭主義和小圈子，調崗是必須存在的事兒。
   前段時間，業內一個朋友諮詢我一個問題，一個業務領域的先後兩個團隊，你們互相抱怨彼此的交付質量差，要不要創建詳細的操做手冊，檢查表，去規範兩個團隊的交付件。我回答他說：沒有必要——看起來嚴格的檢查和流程，會讓你們就事論事，區分責任歸屬，但實際上會讓兩個團隊的對立情緒愈來愈重，最後致使厚重的牆。我建議兩個作法：針對基層員工，開會宣導合做和互幫互助，而且本身帶頭不說抱怨的話，只作積極的事兒。若是發現有基層員工有抱怨和推諉，第一次私下談話，第二次點名批評，依次升級。若是中層管理者有抱怨，則馬上兩我的輪崗，既然你說別人作很差，那麼你本身過來作一下看看，是否是有不得已的苦衷？

   華爲的輪值制度很大程度上打破了部門牆，因此與其讓研發經理一次次的抱怨一線的朝夕變化，還不如讓研發經理走到一線去，看看爲何會有這種現象？說不定一個技術宅，就能更好的解決了這個問題呢？

   溫室裏面，培養的不只僅是嬌嫩的花朵，也培養了嬌嫩的產品，經受不起市場的風吹雨打。

   因此，尋找解決問題的真正答案吧，而答案，永遠在現場。

敬請關注個人新浪微博@叄石而厲