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

不過現在的互聯網產品經理從業者大部分是非技術出身，有心理學專業、新聞專業、廣告專業等等的人員加入，在他們與研發工程師進行交流時，往往就會出現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分支，打包。運維在服務器（可以是自己買的，也可以是在阿里云騰訊云華為云等租用的）上部署包運行起來需要的環境，包含操作系統、數據庫等等軟件，部署好了之后，用戶再次訪問產品頁面時就是最新開發的內容了。此后如果用戶在使用產品時打不開頁面了、使用緩慢了，直接反饋給到運維人員，運維人員排查如果是機器資源問題，就申請新的機器，再部署一套服務，滿足更多的用戶可以訪問；如果是業務問題，就反饋給到測試人員和研發人員進行解決。

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