產(chǎn)品后端開發(fā) 后端產(chǎn)品經(jīng)理職責范圍(六篇)

本文格式為Word版，下載可任意編輯——產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍(六篇)范文為教學中作為模范的文章，也往往用來指寫作的模板。往往用于文秘寫作的參考，也可以作為演講材料編寫前的參考。大家想知道怎么樣才能寫一篇比較優(yōu)質(zhì)的范文嗎？下面我給大家整理了一些優(yōu)秀范文，希望能夠幫助到大家，我們一起來看一看吧。

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇一

4,熟悉阿里巴巴國際站后臺的操作使用,根據(jù)公司需求制定阿里巴巴國際站運營方案;

6.查看分析阿里的后臺數(shù)據(jù)并優(yōu)化;

7.對數(shù)據(jù)十分敏感,愿意研究數(shù)據(jù)和提升結(jié)果

8.其它相關(guān)職責和辦公室事情的協(xié)助!

任職要求:

1.大專以上學歷,電子商務(wù)專業(yè)優(yōu)先;

2.至少1年阿里巴巴運營經(jīng)驗,了解阿里巴巴國際站后臺運營;

3.擅長分析,尋覓發(fā)現(xiàn)規(guī)律,具備良好的溝通、學習能力和客戶意識。

福利:上午:9:00-12:00下午:13:30-18:30(周一到周五,周六上半天也就是(9:00-12:00)

年假;節(jié)假日禮品;一年至少2次團體旅游;公司為員工慶生;年會,年終獎金;多維度獎勵(年度目標獎勵,博楚教案獎勵制度,公司活動旅游獎勵,年度人物評比,年終抽獎等,多重獎勵),所有國家假期

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇二

在進行詳細的需求設(shè)計時，遵循三個原則：

前面兩點簡單地說，就如下圖展示的狀況，模塊高度集成且相互關(guān)聯(lián)；

然后在制定詳細的需求書時需要先制定基礎(chǔ)功能，類似于角色數(shù)量、權(quán)限管理及審批、賬號登錄\登出等，如下圖：

還是以ota作為例子，在這個例子中，由于首先是面向的對象是車企研發(fā)和測試的人員，使用對象不會外授權(quán)給外部開發(fā)者和市場人員。

終究假使更新包或者策略出問題了，這個確定是會造成車企經(jīng)濟損失和名譽損傷。

這時候其實角色數(shù)量和審批的流程就可以簡化處理，角色定義管理員和普通角色、審批流采取二級審批或者驗證碼二次確認即可，假使為了保險，其實也可以增加一個密鑰驗證；

確定好角色和審批，就需要確認賬號體系，但一般tob大型項目都會有一套通用的賬號體系，所以直接沿用即可；

當我們制定了完整閉環(huán)的業(yè)務(wù)流程后，我們就可以參考之前的需求分析抽取的功能點和業(yè)務(wù)流程制定幾個大的功能模塊；

由于ota的領(lǐng)域要求，一般都是會對數(shù)據(jù)及升級狀況有比較明確且具體的要求，下面就以和展開；

在我負責項目中，接收的數(shù)據(jù)要求有：

在初始化項目時，一般我們都是需要有初步的數(shù)據(jù)源導入到平臺中，由于從0-1的項目中，設(shè)備未激活，無法上報對應的數(shù)據(jù)，我們就無法發(fā)布任務(wù)推送到端上，所以是需要默認的數(shù)據(jù)源作為平臺的基礎(chǔ)數(shù)據(jù)；

而一般這類基礎(chǔ)數(shù)據(jù)都會由車企或者tier1來提供，我們需要導入到平臺中進行初始化；

有了基礎(chǔ)數(shù)據(jù)，我們還需要定義好具體的數(shù)據(jù)指標，便利項目交付后的驗收，浮現(xiàn)的數(shù)量雖然能滿足車企的訴求，但不夠直觀，所以一般我們還是需要定義具體指標；

如推送成功率=下載成功量/成功推送量等；

這類數(shù)據(jù)需要基于客戶端下載的狀況進行上報，如設(shè)備在接收到軟件包升級時，需要在升級成功時同時上報升級結(jié)果、當前版本，假使涉及到地區(qū)分布需求，還需要上報經(jīng)緯度，然后后臺進行推演依照地區(qū)或者省份進行展示；

任務(wù)對于每次的ota都是至關(guān)重要的部分，需要確鑿記錄每一個vin碼的升級狀況（vin碼、升級成功與否、推送成功與否等），任務(wù)的推送狀況及錯誤日志上報；

另外任務(wù)的詳細信息可能確鑿在后臺上做浮現(xiàn)，便利后續(xù)的維護和迭代運營；

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇三

最終我就以個人的經(jīng)驗共享“坑〞，便利大家避避雷；

一般權(quán)限分幾種：操作權(quán)限、菜單權(quán)限、數(shù)據(jù)權(quán)限和用戶權(quán)限；

我遇到過之前有個平臺只有菜單權(quán)限，整個平臺中只要具備菜單的權(quán)限就可以進行操作，細分顆粒度不夠，導致管控的力度比較粗；

這樣導致的后果，就是無法有效的管理用戶的操作和數(shù)據(jù)泄密的問題，而且假使還沒有操作記錄功能的話，那完全無法知道是誰做了哪些操作，追溯起來十分麻煩；

一般而言，平臺化的交互模式都是自上而下，模塊放置左側(cè)，右側(cè)放置模塊內(nèi)容信息，并且以列表的形式浮現(xiàn)；

這樣的結(jié)構(gòu)符合用戶的習性和查看習慣，假使刻意追求標新立異的模式，如從左到右的模式，就有種畫蛇添足的感覺；

如之前接觸過一個平臺頂部放置功能欄，左側(cè)放置數(shù)據(jù)報表和數(shù)據(jù)，右側(cè)放置模塊內(nèi)容信息，整個交互即讓人眼花繚亂，交互起來又經(jīng)常出問題；

另外平臺需要注意盡量不要出現(xiàn)以下幾點：

以上就是本文的全部內(nèi)容，希望能在業(yè)務(wù)管理后臺的設(shè)計上提供一些建議和幫助！

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇四

單從ota，我們就可以找出三類玩家：

而傳統(tǒng)車企一般都是和傳統(tǒng)ota廠商合作，當隨著科技能力的滲透和智能化、新能源化越來越高，車企也逐步和科技公司一起合作，在這里我就舉百度的ota能力(給baidu打個廣告)；

從百度提供的ota后臺可以看出類似開放平臺的產(chǎn)品定位，以通用能力提供技術(shù)能力，輸出較為豐富的行業(yè)理解能力和技術(shù)底層能力，使接入方能快速接入上線服務(wù)；

但假使我們從項目的角度出發(fā)，我們需要從平臺中抽象出ota的特征通用需求出來作為參考，如下：

在抽取了ota的特征需求后我們需要針對真實的項目狀況去落地設(shè)計；

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇五

不同的行業(yè)對管理后臺的要求有微弱的區(qū)別，以行業(yè)的角度來看：

大致可以分為以上幾類，商城類的重視訂單管理和產(chǎn)品發(fā)布，開放平臺重視開發(fā)者和技術(shù)應用，客戶管理（crm）重視客戶信息和訂單管理，財務(wù)關(guān)注資產(chǎn)管理和工資管理，oa重視業(yè)務(wù)流和審批層級，特別類如ota和金融監(jiān)管也有各自的業(yè)務(wù)訴求，如ota重視軟件管理和任務(wù)管理，雙錄重視監(jiān)管和訂單；

雖然管理后臺面向各行各業(yè)都有不一樣的特性，但一般都是有賬號體系、角色體系、審批流程和操作日志等基礎(chǔ)功能，下面基于其中一類以及筆者經(jīng)歷較深的領(lǐng)域-ota和開放平臺；

單從ota來看，市面有分三種，fota、sota和集成os三類；

fota-固件遠程升級，一般是涉及到汽車底層電子元件的軟件升級，剎車、座艙底層和儀表盤等軟件的升級，大部分的傳統(tǒng)車企都有這部分的能力，并且對安全性和穩(wěn)定性要求都十分高，終究涉及到擋位這類行駛的控制，假使沒有必要的缺陷，基本都不會隨意升級；

但在汽車行業(yè)的資本滲透和新興玩家入場，如特斯拉\小鵬等，現(xiàn)在逐步的開放fota的遠端升級，但一般都是集成類升級，不會單獨分開升級fota；

sota-又稱軟件系統(tǒng)升級，一般都是中控臺的os層及應用升級，類似手機系統(tǒng)升級，但在汽車行業(yè)，這塊還是跟手機端有所不同，區(qū)別在于以下幾點：

舉個簡單的例子，假使車企需要升級某個應用層的bug或者有新的應用可以發(fā)布，一般都是通過sota的形式推送給到各端，包括已銷售出去的汽車；

本人接觸的有語音語義和小程序開放平臺，這類管理后臺一般是面向三方開發(fā)者提供技術(shù)底層能力和應用框架；

類似于小程序管理后臺，這類平臺會提供開發(fā)者接入手冊和底層小程序的技術(shù)框架，開發(fā)者基于這個框架定制化開發(fā)多個小程序，這類平臺重視生態(tài)的擴展和開發(fā)者入駐的數(shù)量，所以一般都是技術(shù)能力或者市場實力較為雄厚的科技平臺公司在布局，這類平臺既具備toc能力也有tob的能力，區(qū)別在于兩者的資質(zhì)認證；

可以看出，各行各業(yè)的管理后臺，五花八門，那么我們現(xiàn)在就基于單個應用領(lǐng)域去切入，進行詳細的產(chǎn)品設(shè)計工作；

產(chǎn)品后端開發(fā)后端產(chǎn)品經(jīng)理職責范圍篇六

一般而言業(yè)務(wù)管理后臺都是面向tob產(chǎn)品，而tob的產(chǎn)品最大的特點就是定制化程度高，私有化部署；

而這對產(chǎn)品設(shè)計帶來的挑戰(zhàn)就是業(yè)務(wù)訴求頻繁變化和場景繁雜，假使考慮不全面，后續(xù)平臺返工的成本、概率就會隨著功能的堆疊變得越來越高；

所以第一步我們需要對業(yè)務(wù)需求和使用場景進行梳理，并且需要基于項目背景及終端設(shè)備出發(fā)，制定核心可落地的功能