[[223497]]

畢業 6 年，做過千萬級后臺的主程，也主持過億級 DAU 推薦系統的架構設計，招過人帶過人開過人，也曾以產品經理的角色參與過多個運營系統項目。深知程序員與產品經理的溝通始終是 IT 行業繞不過去的坎，不長的職業生涯里，見過程序員與產品經理溝通順暢相得益彰雙雙升遷的正面案例，也見過更多的撕逼堵心相互拆臺兩敗俱傷的反面案例。

這兩種職業本來不應該有如此水深火熱的對立，甚至從技術轉產品也好從產品轉技術也好都可以找出成功的樣板，那么癥結在哪里？作為實現過角色轉換的人，我覺得根本是二元思維的對立：程序員的游俠精神，產品經理的老板想象。那么兩個如此迥異的物種如何溝通無間合作自如相親相愛呢？以下就是我從各自角度出發的一點細微建議。

　　首先是給程序員的三個溝通錦囊：

　　學習技術不應成為最重要的目標

　　也許沒有如同程序員一般自由的職業了，雖然經常被類比農民（碼農），可真正下地干活時我們可以做到心無旁騖，帶上降噪耳機循環一首不合時宜的搖滾，機械鍵盤奏鳴著敲下的，是你的奇思妙想，與天時與地利無關（甚至我還碰到過因為想寫自己喜歡代碼甘愿從 leader 自降為普通員工的程序員）。然而，有很多初出茅廬的程序員就會滑向另一個極端：認為追求技術的持續深入是工作中最為重要的目標，如此一來導致的壞結果就是，要是產品經理丟過來的需求沒有技術含量，就不樂意接，就打心底抵制；要是產品經理插入的需求恰好要破壞這一畝三分地（代碼架構）的美感，就像被要了老命似的。

　　公司不是學校。公司支付你的薪水，不是讓你深造技術，而是希望你替老板解決問題。你的聰明才智，除了用來造一個酷炫的預測模型擬合出用戶增長的趨勢，除了用來搭一個華麗的網絡框架支撐千百萬并發的訪問，自然還得用來跑一個尋常不過的活躍數據，寫一個簡陋不已的監控網頁。因為，這些都是業務發展不可或缺的一環。而你還想學習最拉風的技術？那么請窮盡所有的業余時間，去閱讀最頂尖的論文，去操練最前沿的工具，去模仿最鬼斧神工的代碼。一旦回到工作場合，你的大腦應當無時不刻在思考，如何高效、準確、敏捷完成產品提出的需求，以擠出更多的時間去關注業務的全局變化、去思考新技術與既有業務的結合點、去提高其他成員的技術能力。如果能做到這一點，我相信你會迅速成為團隊所倚重的技術骨干。

　　刻意培養對外表達能力

　　程序員一直是羞于言語表達的，祖師爺 Linus 的格言早已銘記于心：Talk is cheap, show me the code。但是公司卻是各種角色的集合，像老板、設計師、HR、外包測試乃至前臺，彼此間的交流仍然要通過自然語言而不是機器語言實現。所以能夠適時把肚子里的聰明才智秀出來、能夠恰當把眼皮底的功勞業績拿住了、能夠隨時把身邊的工作伙伴愉悅了，自然而然會成為受歡迎的人。

隨著平臺的擴大，表達也不局限于一對一的單挑溝通，向上匯報、規劃腦圖、總結郵件、技術指南、膠片與演講，都是現代職業人不得不學的技藝。學會了它，你的影響力將成十倍成百倍的擴散。可惜的是，我曾經看到過不下十個編程功夫已入化境的程序員倒在了這一陣，由于天性內斂敏感，加上長時間對著機器，養成了拙于表達、怯于表達的人設，導致回報與產出完全不成比例。從畢業至今，我一直堅持著一個從前任 CTO 那里偷師來的習慣：工作一兩個小時起來走一圈，隨意挑一位不忙的同事，和他聊上兩三分鐘，了解他近期手頭的項目，順道也介紹自己的項目，許多意料之外的成果就產生在這種貌似不刻意的小連接之上。

　　勇于挑戰產品經理的邊界

　　若干年前我曾寫過一篇倍受歡迎的理想的程序員，講到理想程序員比普通程序員突出的六個一點點，就有一點是 Never Say No，這引發了很熱烈的爭辯，也有讀者誤解為全盤接受產品提出的需求，當然不是！我只是鼓勵程序員尤其是新手程序員以開放的心態去面對需求，并不意味著合理的不合理的需求都要一昧接下。在我看來，除了表達能力之外，程序員最該培養的第二項技能就是產品思維。

技術工作的本質，無非就是通過技術實現用戶或客戶的需求，產品經理恰好是承擔了連接技術與商業的職責，如果連接器沒發揮好，即便技術完美達成了，也是無用功。除了產品經理之外，整條互聯網流水線上的所有角色尤其是負責實現需求的程序員，都應該是需求的把關者，都應該具備敏銳的產品意識。當然你一開始或許不具備 Say No 的能力，但是接到需求時不妨多想一想需求從何而來，它真實存在嗎，你是用戶怎么感受，你媽是用戶又怎么感受。長此以往的死磕之后你的產品意識會越來越好，程序員懂產品，好比流氓會武術，并不是你一定要和 AllenZhang 一樣轉行去做產品經理，但至少你在產品經理心目中的話語權和專業度會漲好幾個段位，需求也會越接越少，越接越精，騰出更多時間去建設你的技術影響力。

　　然后是給產品經理的三個溝通錦囊：

　　產品經理不是經理

　　記得畢業前問一位同學為什么選擇產品經理這個職業，他打趣道因為這大概是惟一能給應屆生提供的經理職位，許多人也許有類似的誤解，覺得產品經理比程序員地位更高。一個產品經理尤其是新手產品經理，如果帶著這么一種心態去與程序員溝通結果無疑是悲慘的。產品經理與程序員一樣要從螺絲釘做起，無非一個的職責是寫代碼，另一個則是寫需求。雖然產品經理有更多與老板對接的機會，但切記一定不能把自己代入為老板。請看某產品菜鳥A與程序員菜鳥B的失敗溝通案例：

A：現在有一個超級緊急的需求，X總說今晚就想上線，加個班兄弟？

B：@!#$%^&*

　　再來看產品大牛C與程序員菜鳥B的溝通就順暢多了：

C：我們最近看了數據，發現在左側加個導航欄能增加 10% 的聊天功能活躍，和X總溝通過之后他覺得這個功能也挺重要的，上線這個功能之后今年的 KPI 也就有譜了，這個模塊你最熟，能不能評估需要多久改完？雖然X總很著急，但是我們肯定要先保證質量，人力方面有困難的話我幫你去協調。

B：有理有據，無法拒絕。

　　C 與B的對話，雖然目的同樣在于傳遞一種要求，但有更多的平等交流的味道，能讓對方了解到更多的背景信息，讓對方感覺是在為共同的目標工作，而不是把對方當成下達指令就能開動的機器。

　　主動為程序員尋找資源

　　羅振宇曾經把產品經理比喻為一個連接器，這個連接器除了連接上文提到的技術與商業，還需要連接團隊中的不同角色。通常產品經理所掌握的信息是最多的，但是許多產品經理并不知道信息必須要充分流動起來才能成為資源，比如哪里有現成的組件、誰做過類似的工作、哪個組可能有空缺的人力，這些信息都是有潛在價值的，一旦供應方的信息和需求方的信息匹配上，就會形成資源的優化配置。

一個合格的產品經理，應該為程序員留心和協調資源的引入，幫助他們減輕工作負擔、提高產出效率。而一個優秀的產品經理，還應該為程序員的職業發展路徑考慮，幫助不善言辭的程序員向上請功，幫助醉心技術的程序員爭取更多與大牛交流的機會，幫助堆砌業務的程序員挖掘更多的技術亮點。畢竟你幫助別人更多，別人自然也就更愿意回報你。產品經理與程序員，從來就是相依為命，「狼狽為奸」。

　　做團隊的最強大腦

　　產品經理這個職業相比程序員，最有趣的一點就是除了決定怎么做，還能決定做什么（當然程序員這個職業太多更有趣的地方，容我賣個關子，以后專文寫）。所以，一個差勁的產品經理將成倍放大團隊的人力耗費，降低團隊的運作效率。有許多經驗帖都談到產品經理與程序員的矛盾癥結在于改需求，其實改需求只是表象，互聯網本來就是一個快速變化的行業，改需求不可避免，根源在于產品經理是否有獨立思考的能力和意識，改需求是人云亦云，是老板 Push，還是實踐過后從觀察數據洞悉人性得來的深刻啟發，這里大不相同。

因此產品經理除了要當團隊的連接器之外，還得鍛煉自己成為團隊的大腦，不僅是大腦，而且還得是最強大腦。只有你把需求想踏實了，想細致了，想全面了，才有足夠的底氣去應對各方各面的挑戰，讓程序員們信服你，追隨你，死心塌地為你改需求。

　　下次去找產品經理（程序員）對需求之前，不妨帶上我的這三個溝通錦囊，真心期待你們能碰出新的火花，攜手走向下一個職業巔峰。