產品經理可謂是一個需要各方面能力的崗位：罩得住程序猿、哄的住設計獅、要懟得過客戶，還得應付得了老板。要不要學技術，更是一個老生常談的話題。筆者根據平時積累的經驗做一些分享，希望和大家多多交流。

首先簡單介紹自己：九零后學生物非技術出身目前搞云計算的產品經理。所以，在學習相關專業技術的方面有一些心得體會，和大家分享一下。希望給一些非技術出身的產品新人一些經驗，如有不足之處也歡迎各位產品大牛給予指正。

問題

• 作為產品當你給研發小伙伴提需求后，肯定聽過這幾字：實現不了！如果你臉皮夠厚的話肯定會反問一句，不就是根據手機殼換個APP主題顏色么，有啥實現不了的……
• 即便研發同學說可以做！但是研發成本比較高，需要xxx個人天的工作量才能開發完，現在其他需求排滿了沒有時間做，你內心又想改個顏色需要這么長時間么。

其實也都是開玩笑的例子，但是在現實工作中，一個需求提出來，可能是老板提的、客戶提的或者是產品自身提的，作為產品首先需要評估這個需求的優先級以及可行性。而在評估的時候不需要明白需求具體的代碼實現方式，但是大方向的實現邏輯一定要懂，只有這樣才不會和研發提出一些不合邏輯的需求：

• 比如設計列表的篩選條件的時候，要知道列表的查詢都是通過SQL語句實現的，你得明白SQL是什么，通過SQL語句大致都能對數據進行哪些操作。
• 對接第三方系統的時候，第三方提供哪些API，可以實現什么功能最好要做到心中有數。
• 從另一個方面來說，你想實現什么功能，需要什么API來實現需要和研發溝通后，讓第三方進行提供（首先是第三方能提供定制化的API作為的前提）。當然這種情況一般產品只需要把需求講清楚，需要哪些API是研發來輸出即可。但是，如果產品懂一些的話會很大程度上提高溝通的效率。

類似于這樣的例子不勝枚舉，總之產品這個崗位，個人認為還是需要懂一些技術的，下面就大概講一下如何學習技術方面的相關知識。

如何學習？

筆者本身是非科班出身（大學中計算機公共課只學習了一些計算機的基礎知識，語言學的還是VB……）。學習技術知識首先要有高效學習的方法。其次需要根據自身情況確定一個學習的范圍。

學習方法

• 最高效的方法還是參考前輩們的經驗，筆者在剛轉行的時候買過一些書籍，其中也介紹了一些產品為什么要懂技術，大概都要學什么東西，對于當時還是產品&技術小白的我受益匪淺，叫什么名字就不提了以免打廣告。
• 其次，如果你需要了解需求的底層技術，去一些技術論壇搜一下如何實現相應的功能，一般都會有一些文章，多看看幾篇了解基本的原理即可。
• 在平時工作中你的研發小伙伴也是你的良師益友，遇到問題虛心請教，一般情況下大家也都會知無不言的。

總之，學習方法千千萬，我說也并不一定適用你，一定要找到適合自己的一套學習方法，才能更高效提升自己。

學習范圍

需要學習什么內容是需要根據公司產品情況、負責的項目、負責的功能模塊有針對性的學習。

• 比如：負責的產品是APP，一定要了解IOS/安卓的客戶端知識，二者的區別，交互規則都是怎樣的。
• BS架構的產品，客戶端則是web瀏覽器，用戶操作界面當然也是依托瀏覽器進行，相應可以了解前端的相關知識，比如：html、CSS、JavaScript等相關知識。
• 客戶端只是做頁面可視化的展示和少量的事務處理，而應用主要的事務邏輯在服務端實現，這又引入了服務端的內容，服務器是什么？前后端是如何發生交互的？接口是什么東西？
• 有的時候服務端將前端提交的數據處理后需要保存到數據庫中，數據庫顧名思義當然是保存數據的東西，其中比較常用的是關系型數據庫，例如MySQL。
• 現在很多云服務商也提供很多對象存儲的產品，用于存儲非結構化的數據（圖片、視頻、音頻等）如有需要也可以了解一下。
• 筆者所在公司的業務是做云計算的，與公司業務息息相關的知識更需要學習，例如：云服務器、云數據庫、彈性公網IP、對象存儲、負載均衡等等。

對于小白同學來說，如果有明確的方向，那就針對性的規劃學習范圍；如果沒有明確的方向，建議每個方面的知識都要了解一些。

說到這里想起來有一點是基本上都必須要了解的，就是一些計算機的基礎知識，當下比較流行的編程語言都有什么；數據都有哪些類型，它們具體表示什么；程序是怎么進行一些邏輯判斷的等等。

筆者最早也曾嘗試過轉型做程序猿，自學了一段時間的計算機基礎知識和java編程。后來轉做產品后以為當時學的一些東西沒什么用，畢竟不用寫代碼。但是，在實際工作中逐漸發現之前積累的技術知識，對于產品設計還是很有幫助的。

踩過的坑

雖然有些技術是產品必須要學習的，但是千萬不要被技術擾亂我們的產品思維。

曾經有一段時間，當我接到新的需求后，首先想到的不是用戶使用場景，不是用戶背后的真實需求，而是從技術的角度考慮如何去進行產品設計，想的是背后的數據庫、表如何設計?？上攵?，當這個需求實現后也僅僅是能用，用戶體驗極差，甚至做出來的東西都不是用戶真實想要的。

一度為了迎合技術實現，從而忽略的產品設計的本質。為了實現某個需求，過度的關注在技術層面的東西，從而忽略了產品經理存在的意義。產品經理的存在就是保證做出來的需求是用戶的真實需求，而研發的意義才是將需求變為現實。

假如說根據手機殼顏色使得APP主題顏色切換，看似是個荒謬的需求。但是，如果把他實現了公司會得到無法想象的巨大收益，那么我相信他一定能實現。至于具體怎么實現，就不是產品經理需要考慮的范圍了。

舉個學習例子

系統：XXX后臺管理系統

功能模塊：工單管理

用戶：后臺管理員，確切的來說是處理工單人員

需求描述：當控制臺客戶端提交一條新的工單后，在后臺管系統中，需要有這條的工單消息提醒，以達到提醒工單處理人員對有新的工單需要處理。

當將這個需求和技術人員進行簡單溝通后，我們公司的技術小牛說到：“可以用websocket來實現工單消息的實時提醒功能”。

聽的我一臉懵~趕緊百度百科了一下：

WebSocket protocol 是HTML5一種新的協議，它實現了瀏覽器與服務器全雙工通信(full-duplex)，一開始的握手需要借助HTTP請求完成。

原理

WebSocket同HTTP一樣也是應用層的協議，但是它是一種雙向通信協議，是建立在TCP之上的。

連接過程——握手過程

1. 瀏覽器、服務器建立TCP連接，三次握手。這是通信的基礎，傳輸控制層，若失敗后續都不執行。
2. TCP連接成功后，瀏覽器通過HTTP協議向服務器傳送WebSocket支持的版本號等信息。（開始前的HTTP握手）
3. 服務器收到客戶端的握手請求后，同樣采用HTTP協議回饋數據。
4. 當收到了連接成功的消息后，通過TCP通道進行傳輸通信。

目的：即時通訊，替代輪詢

網站上的即時通訊是很常見的，比如：網頁的QQ，聊天系統等。按照以往的技術能力通常是采用輪詢、Comet技術解決。

三種技術對比分析

1）http請求

開始單純采用傳統http請求響應客戶端服務器，http協議是非持久化的，單向的網絡協議，在建立連接后只允許瀏覽器向服務器發出請求后，服務器才能返回相應的數據。

當控制臺客戶端提交一條新的工單后，后臺管理系統中不會主動收到提醒消息，需要手動刷新網頁（后臺管理系統主動請求服務器）后才會彈出新的工單提醒。

造成如下后果：

1. 不能保證消息的時效性，新的工單信息不能被后臺人員即使看到并進行處理；
2. 如果用戶有緊急問題需要咨詢處理，耽誤時間，影響用戶的業務發展，甚至可能會丟失用戶；
3. 增加了后臺工單系統的運維成本，工單處理人員需要隨時刷新網頁查看是否有新的工單。

2）輪詢

通過輪詢在特定的時間間隔（如1秒），由瀏覽器向服務器發送Request請求，然后將最新的數據返回給瀏覽器。解決了消息時效性的問題，但是需要每一個客戶端每秒都需要向服務發送請求。

通常HTTP request的Header是非常長的，為了傳輸一個很小的數據 需要付出巨大的代價，是很不合算的，占用了很多的寬帶。

3）websocket

采用websocket后，只需要服務器和瀏覽器通過HTTP協議進行一個握手的動作，然后單獨建立一條TCP的通信通道進行數據的傳送。當控制臺客戶端提交一條新的工單后，后臺管理系統中直接會彈出新的工單提醒。

如下優勢：

1. 保證消息的時效性，新的工單信息及時被后臺人員即使看到并進行處理；
2. 優化了資源利用率；
3. 減輕后臺工單系統的運維成本。

小結

其實websocket應用之處還有很多，因為建立一條TCP的通信通道，利用這個持久性的特點，可以看到系統當前在線人數有多少。

而他的實時性特點，也是一些辦公協同工具（在線多人同時編輯文檔）所必須要用到的，等等可以實現的功能不再贅述。

看似很專業的技術知識，其實筆者也只是了解它是什么東西，有什么特點，利用他的特點能實現什么功能而已，而作為產品我認為能了解到這種程度已經完全夠用了。

總結

筆者作為To B的后臺產品經理，起碼在這個領域的產品崗位還是需要懂一些技術知識的。

首先，To B的產品經理，需求來源方首先就是甲方爸爸，與客戶溝通，對接第三方相關需求，也會涉及到一些技術相關知識。如果不懂的一點的話，溝通效率低，成本比較高。筆者之前接觸過類似的與技術相關的需求，比如：集成第三方SSO單點登錄服務、接入第三方用戶體系、實名認證體系、接入第三方支付功能等等。

其次，前端產品經理可能更注重一些界面設計、用戶體驗更加的交互方式等等（個人見解，前端產品看官勿噴）。而后臺產品的話更多的根據復雜的業務邏輯去呈現不同的表格、數據，對應的需要根據不同的條件去搜索數據，對接哪些API來實現需求。后臺的產品設計，一些功能設計更多的是由技術進行主導。了解一些技術實現方式，對產品的理解也會更深一些。

比如：在實現系統初始化相關功能的時候，能夠初始化哪些內容需要和技術同學配合進行。

技術同學提出可以配置系統中使用的短信服務的相關配置項：短信簽名、模板信息，還比如可配置系統使用的郵件服務相關配置項，郵件服務地址、用戶名、密碼等。

但是，在后續測試過程中技術發現存在問題，系統使用的spring cloud框架已經集成了郵件配置的相關功能，在服務啟動的時候必須有郵件的相關數據，否則系統啟動不起來——換句話說郵件的相關配置信息需要提前配置好，不能在系統初始化中進行配置（其實和技術溝通后，也可以通過修改框架源碼的方式或者通過API的方式去實現郵件的相關功能，但是綜合考慮起來目前沒有必要為了初始化的需求去進行其他的改動，故先將郵件的配置項從初始化步驟中刪除）。

簡而言之，請對技術懷有一顆敬畏之心，了解技術實現邊界，做一個懂技術的PM。會讓你設計的產品更合理，讓溝通交流更加順暢，讓技術同學更加信任你，讓你在成為PM大牛的路上事半功倍！

在產品的路上一直都是在借鑒前人的經驗，是時候回饋一下社會了！以后努力把一些工作中的心得、體會分享一下，希望幫助到需要的人。

作者：天氣不錯，公眾號：天氣的朋友（friends_of_tianqi）

本文由@天氣不錯 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。