后端產品經理要懂的知識點
本文從我自身的角度,介紹了關于前后端產品經理的區(qū)別和一些關于系統(tǒng)的認知,歡迎交流,不喜輕噴。
1. 前端產品經理和后端產品經理
大學畢業(yè)前,有一段在直播行業(yè)做產品實習生的經歷。
后來轉入互金行業(yè),還記得我上級面試時問我:
你知道什么是后端產品經理嗎?
當時的我一臉懵逼,不過還是幸運地被錄取了,職位是前后端結合的產品經理。
工作一段時間后,我上級又問我:
你覺得做互金產品和直播產品有什么區(qū)別?
以下就是我對前端產品經理和后端產品經理的思考:
前端產品經理,更注重用戶體驗和交互方式,對設計模式、用戶心理有一定要求。
市面上流傳的很多“產品經理必讀書目”都在介紹用戶思維、交互體驗。
后端產品經理,更注重業(yè)務邏輯和實現(xiàn)方式,對技術基礎、邏輯思維有一定要求。
常見于電商、金融等行業(yè)。
就我知道的而言,后端產品經理比前端產品經理核心競爭力更強一些。
用戶思維、交互體驗、數據敏感度逐漸成為產品經理的基礎能力,而不是核心競爭力。
“T型人才”將成為未來的發(fā)展趨勢?!啊贝韽V播的知識面,“|”代表知識的深度。這對于產品經理的職業(yè)發(fā)展意義是:
在培養(yǎng)基礎能力的同時,也要在某一行業(yè)深耕,構建自己的核心競爭力。
簡單來講,前端產品經理更偏重產品的“門面”,后端產品經理更偏重產品的“骨架”。一個好的產品,不光要有優(yōu)秀的前端用戶體驗,也要有健康穩(wěn)定的后端系統(tǒng)支撐。
不管是前端產品經理還是后端產品經理,都要有一顆踏實做事的心,實實在在為用戶創(chuàng)造價值。
2. 后端產品經理如何分析需求
2.1 功能需求
功能方面的需求指定系統(tǒng)必須提供的服務。
通過需求分析應該劃分出系統(tǒng)必須完成的所有功能,以及功能如何在系統(tǒng)之間實現(xiàn)。
感受一下后端產品經理的日常流程圖:
在前端,用戶完成簡單的商品瀏覽、商品選定、下單支付過程,就涉及到后端六個系統(tǒng)之間的交互。對于體量更大的公司,系統(tǒng)模塊只會更多。
這就要求產品經理不再局限于前端的頁面層次,而是基于業(yè)務對整體后端系統(tǒng)有一個宏觀的認知,能區(qū)分各個系統(tǒng)的主功能,搭建一個好的產品架構。
2.2 性能需求
性能需求指定系統(tǒng)必須滿足的定時約束或容量約束,常包括速度(響應時間)、信息量速率、安全性等方面的需求。
比如,“支付系統(tǒng)必須在半分鐘內返回用戶支付狀態(tài)”就是一項性能需求。
2.3 可靠性需求
可靠性需求定量地指定系統(tǒng)的可靠性。
比如,“商品系統(tǒng)在一個月內不能出現(xiàn)2次以上故障”。
2.4 出錯處理需求
出錯處理需求說明系統(tǒng)對錯誤應該怎樣響應。
比如,“訂單取消后,用戶支付已取消訂單成功會怎樣”。
2.5 逆向需求
逆向需求說明系統(tǒng)不應該做什么。
產品經理應該選取能澄清真實需求且可消除可能發(fā)生誤解的那些逆向需求。
2.6 將來可能提出的需求
應明確那些雖然不屬于當前系統(tǒng)開發(fā)范疇,但是據分析將來可能會提出的需求。
比如需求迭代、增加新功能等。
其目的是,對系統(tǒng)將來可能的擴充和修改做準備,以便日后確定需求時能比較容易地實現(xiàn)。
3. 好的系統(tǒng)是什么樣子
之前在文章《產品經理的技術思維手冊》提到過“模塊化思維”?!澳K化思維”不僅適用于前端設計,也適用于后端開發(fā)。
模塊化:把程序劃分成獨立命名且可獨立訪問的模塊,每個模塊完成一些類別相似的子功能。把這些模塊集成起來構成一個整體,可以完成指定的功能滿足用戶需求。
在章節(jié)2.1的流程圖里,訂單系統(tǒng)、商品系統(tǒng)、運營系統(tǒng)等,都是相互獨立的模塊。
3.1 為什么要系統(tǒng)模塊化?
首先來思考一個感性的認知,如果淘寶這么大體量的電商系統(tǒng),只有一個模塊,那么一點小變動就會導致開發(fā)人員在海量代碼里找尋相關的代碼,遺漏、錯誤的可能性很高,系統(tǒng)安全備受質疑。其次,如果團隊加入新的開發(fā)人員,他對系統(tǒng)代碼的熟悉成本也是巨大的。
再來一個理性的認識:
設函數 c(x)表示問題 x 的復雜度,函數 t(x)表示解決問題 x 需要的工作量(時間)
對于問題 x1 和 x2 ,
如果? ?c(x1)> c(x2),
則? ? t (x1)> t(x2)
根據人類解決一般問題的經驗,還有一個有趣的規(guī)律:
c(x1 + x2)> c(x1)+ c(x2)
則 t(x1 + x2)> t(x1)+ t(x2)
即是:由多個問題組成的問題的復雜度,大于分別考慮每個問題的復雜度之和。
則:解決集合問題的工作量比分別解決每個問題工作量之和更大。
這帶給我們的啟示是:
利用模塊化,可以將總功能拆解為一個個子集,提高系統(tǒng)的分工效率。
3.2 如何界定模塊的獨立程度?
首先,模塊的獨立性很重要:
- 基于有效的模塊化(即具有獨立性的模塊)的系統(tǒng)比較容易開發(fā);
- 獨立的模塊比較容易測試和維護。
相對于不進行模塊化的系統(tǒng),有效模塊化修改系統(tǒng)需要的工作量更小、錯誤傳播范圍更小,需要擴充時也能更容易地加入新模塊。
其次,界定模塊的獨立程度有兩個標準:
- 耦合
- 內聚
耦合:度量一個產品結構內不同模塊之間的互連程度。
耦合強弱取決于模塊間接口的復雜程度,進入或訪問一個模塊的點,以及通過接口的數據。
內聚:度量一個模塊內各個元素彼此結合的緊密程度。
比較理想的模塊化是:低耦合,高內聚。各個子系統(tǒng)便于開發(fā)和維護,提高整體分工效率。
4. 總結
后端產品經理一職,要求產品經理非常懂業(yè)務。對于系統(tǒng)架構、業(yè)務認知以及行業(yè)發(fā)展的前瞻性都要形成自己獨特的思考體系。
想要成為后端產品經理?
我認為主要是兩點:
(1)找準想要深耕的行業(yè)
電商、金融、B端產品等等,多體驗多思考,比如想從事電商行業(yè)可以去淘寶開一下店,體驗一下面向商家的系統(tǒng);想從事金融行業(yè),那么基礎的金融知識肯定是必須的;實在不行,公司的CRM系統(tǒng)、OA系統(tǒng)也可以觀摩學習。
(2)積累一點技術基礎,提升邏輯思維
建議閱讀《計算機網絡》,對OSI模型有一個大體的認識,知道底層數據如何傳輸、計算機如何互連。像API、RPC這些名詞也要知道其作用是什么??梢钥纯醇夹g同事的開發(fā)文檔,基于單個功能的系統(tǒng)交互圖,不懂多問。
產品經理每天都很忙,沉迷工作是一個好事,但一定要騰出時間思考、學習和總結,長期的輸入才能帶來思維的提升。
最后,祝愿我們都能成為優(yōu)秀的產品經理,不忘初心、砥礪前行。
作者:苒苒上升,公眾號:苒苒上升,互聯(lián)網金融產品經理,負責3億用戶平臺
本文由 @苒苒上升 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pexels,基于 CC0 協(xié)議
請問金融基礎知識主要是指哪些?感覺金融方面知識蠻難理解的,又相關推薦嗎
0基礎的話可以買個金融課,推薦一下得到的《香帥的北大金融學課》,這種網課雖然深度不夠,但是會形成一個宏觀的認知。然后你可以再選擇細分和研究的領域~
同后端產品,可以交流一下。
模塊拆分是由產品主導發(fā)起還是開發(fā)主導發(fā)起?
開發(fā)主導,系統(tǒng)設計一般都由專門的架構師負責。我們只需明確功能涉及的系統(tǒng),如何在系統(tǒng)之間交互即可。核心還是業(yè)務能力。
寫的非常不錯
前端產品如何轉后端呢
建議作者有空在詳談一下后臺的規(guī)劃方法,這篇比較淺
不錯,學習了
感覺還是沒有講清楚系統(tǒng)模塊化的設計思路~~ 期待更新
請問這個計算機網絡 的具體書名和作者是誰啊
同問
計算機網絡 是一門課程 大學計算機專業(yè)有這個課
不用糾結作者是誰,要學的知識點其實都是那幾點
看完文章忽然發(fā)現(xiàn)大學學到的課程竟然在工作能用得上
所謂的模塊也就是把功能單元拆分整合,類似開發(fā)的“微服務化”進行設計,一是文章所述后續(xù)便于維護代碼,二是對于原型也方便查閱。對于以后迭代設計,更加方便整理思路
寫的很棒