我是純產(chǎn)品出身，沒有碼過代碼，像我一樣的產(chǎn)品經(jīng)理在工作時可能經(jīng)常聽到開發(fā)講這樣一句話：“你這個方案實(shí)現(xiàn)不了”。
如果我們對技術(shù)一無所知的話，就無法理解怎么個實(shí)現(xiàn)不了，可能只能聽從開發(fā)的意見；但是如果我們對技術(shù)有所了解，這個了解不是說我們必須知道怎么去碼代碼，而是要知道代碼世界的運(yùn)行規(guī)則，實(shí)現(xiàn)邏輯，知道這個之后，如果開發(fā)再說實(shí)現(xiàn)不了，那我們就可以理解他所講的方案，甚至可以幫助想出其他可以實(shí)現(xiàn)的方案，畢竟對產(chǎn)品還是產(chǎn)品經(jīng)理比較了解，產(chǎn)品經(jīng)理可以幫助決策怎么以最小的成本實(shí)現(xiàn)想要的目標(biāo)。
而且做B端產(chǎn)品經(jīng)理最好要懂些技術(shù)，B端產(chǎn)品的邏輯和流程比C端復(fù)雜得多，很多東西需要產(chǎn)品經(jīng)理抽象總結(jié)出來，如果不懂技術(shù)，出方案的時候就可能會犯浮于表象的錯誤。比如訂單發(fā)貨需要拆單，不懂技術(shù)的產(chǎn)品可能只知道這么出方案：“訂單中的商品任意組合拆單，如取消拆單需恢復(fù)原單狀態(tài)?！保桨缚赡艹龅脹]什么問題，但是他可能不知道恢復(fù)原單需要在訂單表里面記錄原訂單ID，一層層溯源才能恢復(fù)原單，如果不知道這點(diǎn)，開發(fā)看需求也看露了，很可能這個功能就沒有實(shí)現(xiàn)。
我工作過程中發(fā)現(xiàn)懂技術(shù)還有一個 好處，就是知道技術(shù)世界運(yùn)行的規(guī)則后，可以反過來幫助你思考產(chǎn)品，查漏補(bǔ)缺，保證該考慮的場景都能考慮到，也能幫助產(chǎn)品反思自己所出的方案有沒有問題，這樣就不會發(fā)生上線后部分場景漏考慮導(dǎo)致流程卡殼的情況。
以上只是想說明做B端產(chǎn)品經(jīng)理懂技術(shù)的好處，那么B端產(chǎn)品經(jīng)理必須要懂哪些技術(shù)呢？我根據(jù)已有的工作經(jīng)驗(yàn)總結(jié)了一部分，如有技術(shù)同學(xué)看到覺得不對的請及時指正哦。
API
API的全稱是Application Programming Interface，中文是應(yīng)用程序接口，API的作用是信息傳遞，比如，我們通過天貓API接口獲取某筆訂單的詳細(xì)信息：訂單號，收貨人，訂單商品信息，訂單金額等。
獲取信息的方式有兩種：主動調(diào)用和被動調(diào)用。主動調(diào)用是我們通過別人的接口，獲取自身想要的信息；被動調(diào)用需要我們提供API接口，讓別人通過接口獲取信息。
如何了解某個具體的API
通過API文檔。無論是公司內(nèi)部或公司之間通過API傳遞信息時，都會撰寫API文檔，API文檔說明了這個API可以傳輸哪些信息，通過看一個公司提供的API文檔其實(shí)也可以了解該公司的業(yè)務(wù)，大家感興趣的話，可以去網(wǎng)上看看比如淘寶開放平臺的API文檔或者微信公眾平臺的API文檔。
API文檔中我們需要讀懂以下兩個信息：請求參數(shù)和返回參數(shù)。
請求參數(shù)是獲取想要的信息需要告訴接口的條件，比如想要獲取某筆訂單的詳細(xì)信息，就需要告訴天貓對應(yīng)的訂單號，天貓根據(jù)訂單號告訴我們這個訂單對應(yīng)的詳細(xì)信息。
返回參數(shù)是接口能告訴我們的信息，如上面所說訂單的收貨人、訂單金額、訂單商品有哪些。
前后端分離
什么是前端
運(yùn)行在用戶端，你能直接看得到的，比如我們看到的知乎的網(wǎng)頁。
什么是后端
運(yùn)行在非用戶端（服務(wù)器端），你不能直接看到的，比如知乎里面一篇篇文章。
前端負(fù)責(zé)啥
網(wǎng)頁的樣式展示（比如知乎導(dǎo)航欄上頭像放哪，消息提示放哪）、網(wǎng)頁上的交互、網(wǎng)頁跟網(wǎng)頁之間的跳轉(zhuǎn)。
后端負(fù)責(zé)啥
只負(fù)責(zé)提供數(shù)據(jù)，如知乎熱搜有哪些，每篇文章的具體內(nèi)容是什么由后端提供給前端進(jìn)行展示。后端給前端傳遞信息的通道就是API，前端會根據(jù)跟后端約定好的API文檔將請求參數(shù)發(fā)給后端，后端返回前端想要的數(shù)據(jù)。
同步異步
同步
就是在發(fā)出一個調(diào)用時，在沒有得到結(jié)果之前， 該調(diào)用就不返回。如：你直接面對面問大神一個問題，等大神當(dāng)面告訴你答案才走，這是同步。再比如：ERP調(diào)用天貓的接口修改用戶地址，肯定要等天貓返回“成功/失敗”，然后再把這個結(jié)果反饋給修改用戶地址的客服。
異步
調(diào)用在發(fā)出之后，這個調(diào)用就直接返回了，所以沒有返回結(jié)果。如：你去知乎向大神提問，提問完就干別的去了， 大神會看到消息然后再回復(fù)你，這是異步。再比如：OMS系統(tǒng)訂單審核通過后，要生成WMS系統(tǒng)的出庫單，這個操作是通過異步實(shí)現(xiàn)的，因?yàn)閷徍送ㄟ^本身跟生成出庫單是沒有強(qiáng)邏輯關(guān)聯(lián)的，不是一定要等出庫單生成成功才能審核通過，所以O(shè)MS訂單審核通過后，便自動排隊(duì)等生成出庫單了。
我理解所有的異步操作都可以通過同步實(shí)現(xiàn)，只是部分場景通過同步實(shí)現(xiàn)太浪費(fèi)性能，也不是非得通過同步實(shí)現(xiàn)，那就可以改為異步實(shí)現(xiàn)。
數(shù)據(jù)庫相關(guān)的基本知識
數(shù)據(jù)庫
數(shù)據(jù)庫可以理解為數(shù)據(jù)存儲的倉庫。
數(shù)據(jù)庫管理系統(tǒng)
數(shù)據(jù)庫管理系統(tǒng)是一種操縱和管理數(shù)據(jù)庫的軟件，用于建立、使用和維護(hù)數(shù)據(jù)庫，它可以提供數(shù)據(jù)錄入、修改、查詢等功能。我們常聽到的SQL Server、MySQL就是數(shù)據(jù)庫管理系統(tǒng)。
數(shù)據(jù)庫表（僅限關(guān)系型數(shù)據(jù)庫）
數(shù)據(jù)庫中存儲具體數(shù)據(jù)對象的二維表。比如訂單的基本信息會存儲在訂單主表和訂單明細(xì)表中：訂單表中一個訂單一行數(shù)據(jù)，存儲了這個訂單的訂單ID、訂單編號、訂單金額、下單用戶、下單時間、支付時間、收貨人等信息；而訂單明細(xì)表中存儲了每個訂單的購買的詳細(xì)的商品，一個訂單一個SKU一行數(shù)據(jù)，如訂單明細(xì)ID、訂單編號、商品ID、商品名稱、商品規(guī)格、購買數(shù)量、實(shí)付金額等等。
可以先從現(xiàn)有的業(yè)務(wù)了解起，知道系統(tǒng)的每個業(yè)務(wù)的數(shù)據(jù)在數(shù)據(jù)庫的哪些表中存儲，每個表之間的關(guān)系如何， 知道這些后會對自己以后出產(chǎn)品方案有幫助。
SQL
SQL全稱是Structured Query Language，結(jié)構(gòu)化查詢語言，通過編寫SQL語句可以查詢、新增、刪除、更新數(shù)據(jù)庫中的數(shù)據(jù)。我們可能經(jīng)常會讓開發(fā)幫忙拉數(shù)據(jù)，比如想知道昨天同時購買了口紅+香水的訂單有哪些，這時候開發(fā)就是通過寫SQL幫忙查出來的。
產(chǎn)品運(yùn)用SQL一般是用來查找數(shù)據(jù)進(jìn)行統(tǒng)計分析，不會涉及新增、刪除、更新數(shù)據(jù)庫操作，所以我們只用學(xué)會基本的查詢語句即可。一般而言，用點(diǎn)心思的話，一周可以學(xué)會了，可以像我一樣買本《SQL即查即用》學(xué)下，夠用了。
ER圖
ER圖全稱是Entity Relationship Diagram，實(shí)體-聯(lián)系圖，用于描述實(shí)體對象之間的關(guān)聯(lián)關(guān)系。我們設(shè)計產(chǎn)品時經(jīng)常要討論一些對象的關(guān)系，是一對多，還是多對多，就會用到E-R模型。理出相關(guān)業(yè)務(wù)的ER圖，有助于產(chǎn)品理解對象之間的關(guān)聯(lián)關(guān)系，也有助于產(chǎn)品信息結(jié)構(gòu)的設(shè)計。
下面是簡單的訂單、發(fā)貨單之間的ER圖，一個訂單對應(yīng)多個訂單明細(xì)，一個發(fā)貨單對應(yīng)多個發(fā)貨單明細(xì)這個很好理解，那訂單明細(xì)跟發(fā)貨單之間為啥是多對多的關(guān)系？一個發(fā)貨單有可能發(fā)多個訂單明細(xì)（比如發(fā)牛奶+抽紙），一條訂單明細(xì)也有可能拆成多個發(fā)貨單進(jìn)行發(fā)貨，比如客戶買了5臺iphoneX黑色256G，但是由于缺貨，可能先給用戶發(fā)2臺，剩下的3臺等到貨再發(fā)，這樣這筆訂單是通過兩個包裹完成的，一條訂單明細(xì)就會存在兩個發(fā)貨單。
數(shù)據(jù)流圖
數(shù)據(jù)流圖，全稱是Data Flow Diagram，描繪了數(shù)據(jù)產(chǎn)生和流動的情況。有助于產(chǎn)品自身從技術(shù)的角度去理解業(yè)務(wù)涉及的各項(xiàng)數(shù)據(jù)是如何產(chǎn)生及如何流轉(zhuǎn)的，也有助于開發(fā)理解產(chǎn)品需求。
下圖是采購業(yè)務(wù)中的數(shù)據(jù)流程圖，可以清晰的看到從采購到財務(wù)給供應(yīng)商付款，數(shù)據(jù)層面是如何流動的，當(dāng)然這個只是簡單地畫了一下，希望能幫助大家能透過這個事例理解。
其他小常識
1、相同的功能開發(fā)只會寫一個方法，供不同的地方進(jìn)行調(diào)用，比如訂單支持單個訂單的換貨和多個訂單的批量換貨，那么換貨邏輯開發(fā)只會寫一套，不會分開寫兩套（當(dāng)然如果開發(fā)沒有這種意識的話另談），這樣一來如果換貨邏輯有變更，如修改換貨后的庫存占用邏輯，只需要修改一個地方即可，不用怕有地方漏改；
2、能不寫死的盡量不要讓開發(fā)寫死，比如公司新在天貓上開一個店，需要在ERP系統(tǒng)錄入店鋪結(jié)算的相關(guān)信息（如：跟天貓結(jié)算扣點(diǎn)，每筆訂單需要的處理費(fèi)，方便后面查看報表銷售數(shù)據(jù)），這種數(shù)據(jù)如果寫死在代碼里面，每加一個店鋪有可能報表的取值邏輯都要寫一遍，特別不方便擴(kuò)展，最好的是加一張表存儲店鋪結(jié)算信息，報表字段直接從這張表里面取，這個表就是上面說的數(shù)據(jù)庫表，以后每新增一個店鋪就往表里面插入一行數(shù)據(jù)，這么做也方便日后如果想通過頁面配置這些信息的話，只需要前端動動手指就行了，后端的工作基本是完成了。
3、產(chǎn)品的PRD文檔一定要寫清楚，這個寫清楚不是寫給自己看的，是寫給開發(fā)看的，一定讓開發(fā)讀了你的文字之后沒有疑問。比如你想統(tǒng)計每天財務(wù)的收款金額，不能直接寫成某某字段為財務(wù)當(dāng)天的收款金額，一定要具體點(diǎn)，如匯總收款時間為當(dāng)天的且狀態(tài)為“收款完成”的收款單的金額。
4、考慮需求對老數(shù)據(jù)的影響。如你的新需求需要開發(fā)在原有的表里面新增一個字段，那老的數(shù)據(jù)需不需要考慮，需不需要初始化，要考慮到，不然上線后老數(shù)據(jù)全都不正常了可能。再比如原有的業(yè)務(wù)單據(jù)有類型區(qū)分，你如果有個新的單據(jù)也要生成這個單據(jù)的數(shù)據(jù)，那你的這個數(shù)據(jù)需要跟原有的類型做對應(yīng)嗎，還是要新增一個類型，這些都要考慮。
5、測試用例的基于產(chǎn)品文檔撰寫的，所以產(chǎn)品文檔中一定要將需要測試的場景羅列全。
做B端產(chǎn)品經(jīng)理要達(dá)到這種程度，你每提一個需求，都能透過現(xiàn)象看到技術(shù)脈絡(luò)，知道哪些地方會被改動。所以你要懂些技術(shù)（不需要到會碼代碼的地步哦），還要懂原有的業(yè)務(wù)，這樣做需求才不至于被動。
以上不一定是對的。
作者：青檸，微信公眾號：【一只進(jìn)化中的產(chǎn)品汪】（pm_move_forward），歡迎關(guān)注交流。
