產品經理必須懂的技術知識

在網際網路行業中，最重要的人員莫過於研發工程師，有了程式設計師的代碼，才能跑起來應用，提供產品和服務給到用戶。而我們程式設計師哥哥們又愛又恨的便是產品經理了，產品經理就是給程式設計師提需求的人，通過原型圖繪製出整個功能的雛形、用戶使用路徑，然後交由程式設計師去實現。

不過現在的網際網路產品經理從業者大部分是非技術出身，有心理學專業、新聞專業、廣告專業等等的人員加入，在他們與研發工程師進行交流時，往往就會出現GAP了。產品經理覺得這個需求很簡單啊，我只是想要手機屏保隨著天氣變化，我只是想增加個搜索功能，我只是想做個條件過濾，幾行代碼就可以搞定了，而到了程式設計師這邊，這個需要改動底層架構，那個需要兼容歷史版本，最後這個需要改變數據結構，起碼得一周以上才能搞完了，哪裡這麼簡單呢？於是乎程式設計師和產品經理開始廝殺起來，整個需求從開發到上線的過程不是你死就是我活，場面一度很慘烈，像這樣的例子數不勝數。

今天我們就給大家介紹一下作為網際網路產品經理必須要懂的一些技術知識，它能幫助你在自己設計需求時初步就能評估需求實現的難度，結合技術想出更多的可行解；它也能幫助你在需求評審、項目排期時，更好的與開發溝通，了解到這個需求是不是真的做不了，實現成本很高（免得被開發一句「做不了」就懟回去了）；它還能幫助你在用戶驗收測試時比較準確的描述出問題。

網際網路產品經理必備的知識我們可以從需求的產生到上線這條線來介紹，在需求設計及評審完之後，第一階段是開發；第二階段是聯調；第三階段是測試；第四階段是上線。

在開發階段，我們要懂的第一個知識便是代碼倉庫與分支。無論前端、後端、測試這三個角色都會涉及到，前後端基於代碼分支進行開發，測試基於代碼分支進行測試。那麼分支是什麼呢？分支就是我們的代碼版本記錄，它存在代碼倉庫裡，有新項目開發時就新建一個代碼倉庫，開發新需求時就在倉庫裡建立一個分支，每次在本地寫了代碼後，就通過分支提交。程式設計師們約定俗成的使用master分支來存放生產環境的代碼，比如我的APP現在有瀏覽、下單、支付功能，我想新開發用戶註冊功能，那我就需要在master分支上切出來一個feature分支，這時候feature分支包含了master分支的代碼，也就包含了瀏覽、下單、支付功能，我再在feature上寫了用戶註冊的代碼，這時候feature分支就包含了註冊、瀏覽、下單、支付功能了。測試人員使用feature分支進行測試，測試通過之後，再把feature分支的代碼改動部分合併到master分支，進行新版本的發布，這時候master分支就包含了註冊、瀏覽、下單、支付功能了。所有的新功能開發從master切出分支，開發完成後合併到master發布，這樣就保證用戶看到的功能是一致的了。目前業內常用的代碼開發管理工具是GitHub、GitLab。作為產品經理，當程式設計師和我們討論在哪個分支做開發時，你只需要告訴他我希望用戶能使用的功能有哪些就可以了，開發人員會根據產品經理希望上線的需求選擇在什麼版本上去做開發，產品經理也可以根據本片段講解的分支知識來佐證想法。

在開發階段，我們要懂的第二個知識便是前端開發。作為產品經理，我們能感受到的就是前端頁面，通過整個的布局、交互來感受這個功能如何傳遞給到用戶。而在和前端工程師打交道時最常聽到的名詞莫過於組件了。在了解組件之前，我們先了解下前端頁面是如何生成的（本篇介紹web前端開發）。我們的用戶都是基於瀏覽器來瀏覽網頁，所以前端開發也是基於瀏覽器引擎去做的。假設我們現在要開發淘寶的首頁，這時候前端工程師會給它做一個布局，將整個屏幕規劃一下，哪些是橫著、哪些是豎著；在布局規劃好之後，給頁面寫內容，在哪個地方查看什麼品類的衣服，哪些地方放男裝，女裝，顏色、字體、大小怎麼樣；最後再處理用戶點擊後是去進行支付環節，如何成功完成支付，全完事後通過瀏覽器訪問，底層瀏覽器引擎去DOM渲染，就加載出來頁面了。在搭架子階段使用HTML和CSS語言就可以搭建起來模型，而用戶可以去點擊做什麼操作使用JavaScript技術可以實現，用戶操作後可以得到什麼結果就通過後端接口可以返回。

劃重點，在前端開發中的兩個欄位便是組件和接口。可能有的產品經理同學在和前端打交道時，總聽他們提起這個組件不支持啊，後端接口沒有到位啊之類的，但對於組件和接口還很陌生。我們先來看看組件是什麼？當前端在去開發一個產品時，需要寫很多的頁面，每個頁面的元素總有一些是共通的，比如都需要按鈕、下拉列表、搜索、幫助提示、輸入框等等，如果每個頁面的這些內容都去重新寫一遍，代碼很冗餘，前端也很累。於是聰明的前端同學便把這些可以復用的部分抽象出來，專門寫了支持這個功能的html、css、js代碼，以後在其他模塊要使用時，直接引用這個組件庫就好了。介紹完了組件，我們再來看看接口是什麼？我們知道一個產品只有前端，那是無法完成用戶流程的，只能看看點點，不能更進一步了，因此需要後端來去實現業務的邏輯，並通過接口把信息發回給前端做反饋。比如在電商購買場景中，用戶瀏覽看到nike的鞋子不錯，選中了藍色、37碼的AJ，這時候需要前端把這些商品信息通過接口傳遞給到後端，後端接收到這些參數後，通過把參數套進自己寫的函數裡，一步步的實現了資料庫的增刪改查，也就是支付、下訂單、減庫存，最後返回前端交易的結果，前端再處理返回給用戶。

開發結束了，就進入到了聯調階段。在聯調階段，主要做的事情就是前後端聯同起來看看，雙方寫的前後端代碼能否交流，數據格式是否符合預期？數據能否傳遞給到後端？是不是正確實現了功能。聯調介紹後，研發把他們的代碼開發分支提交，告訴測試人員可以測試了，測試人員就去找到對應的測試分支進行測試。

在測試的時候，最重要的兩個便是打包和環境了。所謂打包就是把程式設計師寫的代碼通過打包工具編譯成為運行環境可以識別的產物，在前端開發中會把代碼寫在很多文件裡，把文件轉化成html代碼時，需要引入js代碼，這樣會使得每次請求都需要加載頁面，從而導致性能損耗增加，通過把各種前端資源打包成一個整體，頁面請求只需要一次就可以完成，提高了性能。前端代碼的事情說完了，就該聊後端的事情了，後端的代碼要運行起來需要一個環境，環境包含機器、作業系統、運行要用的資料庫、其他軟體、業務代碼運行的工具（如tomcat容器、Docker容器），後端代碼開發完成之後，會把代碼通過構建工具編譯成一個jar包或鏡像文件，放在對應的環境裡去運行。測試人員在環境裡把前後端的包部署上去，再通過瀏覽器就可以訪問新開發的功能進行測試驗收了。

測試通過後，就進入到了上線階段。上線階段主要參與人員就是研發和運維了。研發把代碼分支內容合併到master分支，打包。運維在伺服器（可以是自己買的，也可以是在阿里雲騰訊雲華為雲等租用的）上部署包運行起來需要的環境，包含作業系統、資料庫等等軟體，部署好了之後，用戶再次訪問產品頁面時就是最新開發的內容了。此後如果用戶在使用產品時打不開頁面了、使用緩慢了，直接反饋給到運維人員，運維人員排查如果是機器資源問題，就申請新的機器，再部署一套服務，滿足更多的用戶可以訪問；如果是業務問題，就反饋給到測試人員和研發人員進行解決。

本文介紹了產品經理在工作全流程中需要和技術打交道的內容，看完之後是不是收穫滿滿啊？其實在產品經理的世界主要是概念層（關注目標）、範圍層（關注功能）、結構層（關注互動設計&信息架構）、框架層（關注界面設計&導航設計&信息設計）、表現層（關注視覺設計），而技術人員的世界主要是邏輯層（關注業務流程&功能模塊）、實現層（關注具體實現函數）、接口層（關注功能&頁面&模塊之間交互的通道）、數據層（關注資料庫執行結果）、架構層（關注技術架構&調用關係&技術規範）。處於不同世界的人在網際網路產品這有了交集，如何才能協作的更好呢？那便是多了解彼此一些，技術人員在交流的時候淺顯易懂，產品經理也多了解技術知識，明白技術人員在表達什麼？他們的工作邏輯是怎麼樣？這會幫助雙方都工作愉快噢～