产品后端开发 后端产品经理职责范围(六篇)

本文格式为Word版，下载可任意编辑——产品后端开发后端产品经理职责范围(六篇)范文为教学中作为模范的文章，也往往用来指写作的模板。往往用于文秘写作的参考，也可以作为演讲材料编写前的参考。大家想知道怎么样才能写一篇比较优质的范文吗？下面我给大家整理了一些优秀范文，希望能够帮助到大家，我们一起来看一看吧。

产品后端开发后端产品经理职责范围篇一

4,熟悉阿里巴巴国际站后台的操作使用,根据公司需求制定阿里巴巴国际站运营方案;

6.查看分析阿里的后台数据并优化;

7.对数据十分敏感,愿意研究数据和提升结果

8.其它相关职责和办公室事情的协助!

任职要求:

1.大专以上学历,电子商务专业优先;

2.至少1年阿里巴巴运营经验,了解阿里巴巴国际站后台运营;

3.擅长分析,寻觅发现规律,具备良好的沟通、学习能力和客户意识。

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

年假;节假日礼品;一年至少2次团体旅游;公司为员工庆生;年会,年终奖金;多维度奖励(年度目标奖励,博楚教案奖励制度,公司活动旅游奖励,年度人物评比,年终抽奖等,多重奖励),所有国家假期

产品后端开发后端产品经理职责范围篇二

在进行详细的需求设计时，遵循三个原则：

前面两点简单地说，就如下图展示的状况，模块高度集成且相互关联；

然后在制定详细的需求书时需要先制定基础功能，类似于角色数量、权限管理及审批、账号登录\登出等，如下图：

还是以ota作为例子，在这个例子中，由于首先是面向的对象是车企研发和测试的人员，使用对象不会外授权给外部开发者和市场人员。

终究假使更新包或者策略出问题了，这个确定是会造成车企经济损失和名誉损伤。

这时候其实角色数量和审批的流程就可以简化处理，角色定义管理员和普通角色、审批流采取二级审批或者验证码二次确认即可，假使为了保险，其实也可以增加一个密钥验证；

确定好角色和审批，就需要确认账号体系，但一般tob大型项目都会有一套通用的账号体系，所以直接沿用即可；

当我们制定了完整闭环的业务流程后，我们就可以参考之前的需求分析抽取的功能点和业务流程制定几个大的功能模块；

由于ota的领域要求，一般都是会对数据及升级状况有比较明确且具体的要求，下面就以和展开；

在我负责项目中，接收的数据要求有：

在初始化项目时，一般我们都是需要有初步的数据源导入到平台中，由于从0-1的项目中，设备未激活，无法上报对应的数据，我们就无法发布任务推送到端上，所以是需要默认的数据源作为平台的基础数据；

而一般这类基础数据都会由车企或者tier1来提供，我们需要导入到平台中进行初始化；

有了基础数据，我们还需要定义好具体的数据指标，便利项目交付后的验收，浮现的数量虽然能满足车企的诉求，但不够直观，所以一般我们还是需要定义具体指标；

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

这类数据需要基于客户端下载的状况进行上报，如设备在接收到软件包升级时，需要在升级成功时同时上报升级结果、当前版本，假使涉及到地区分布需求，还需要上报经纬度，然后后台进行推演依照地区或者省份进行展示；

任务对于每次的ota都是至关重要的部分，需要确凿记录每一个vin码的升级状况（vin码、升级成功与否、推送成功与否等），任务的推送状况及错误日志上报；

另外任务的详细信息可能确凿在后台上做浮现，便利后续的维护和迭代运营；

产品后端开发后端产品经理职责范围篇三

最终我就以个人的经验共享“坑〞，便利大家避避雷；

一般权限分几种：操作权限、菜单权限、数据权限和用户权限；

我遇到过之前有个平台只有菜单权限，整个平台中只要具备菜单的权限就可以进行操作，细分颗粒度不够，导致管控的力度比较粗；

这样导致的后果，就是无法有效的管理用户的操作和数据泄密的问题，而且假使还没有操作记录功能的话，那完全无法知道是谁做了哪些操作，追溯起来十分麻烦；

一般而言，平台化的交互模式都是自上而下，模块放置左侧，右侧放置模块内容信息，并且以列表的形式浮现；

这样的结构符合用户的习性和查看习惯，假使刻意追求标新立异的模式，如从左到右的模式，就有种画蛇添足的感觉；

如之前接触过一个平台顶部放置功能栏，左侧放置数据报表和数据，右侧放置模块内容信息，整个交互即让人眼花缭乱，交互起来又经常出问题；

另外平台需要注意尽量不要出现以下几点：

以上就是本文的全部内容，希望能在业务管理后台的设计上提供一些建议和帮助！

产品后端开发后端产品经理职责范围篇四

单从ota，我们就可以找出三类玩家：

而传统车企一般都是和传统ota厂商合作，当随着科技能力的渗透和智能化、新能源化越来越高，车企也逐步和科技公司一起合作，在这里我就举百度的ota能力(给baidu打个广告)；

从百度提供的ota后台可以看出类似开放平台的产品定位，以通用能力提供技术能力，输出较为丰富的行业理解能力和技术底层能力，使接入方能快速接入上线服务；

但假使我们从项目的角度出发，我们需要从平台中抽象出ota的特征通用需求出来作为参考，如下：

在抽取了ota的特征需求后我们需要针对真实的项目状况去落地设计；

产品后端开发后端产品经理职责范围篇五

不同的行业对管理后台的要求有微弱的区别，以行业的角度来看：

大致可以分为以上几类，商城类的重视订单管理和产品发布，开放平台重视开发者和技术应用，客户管理（crm）重视客户信息和订单管理，财务关注资产管理和工资管理，oa重视业务流和审批层级，特别类如ota和金融监管也有各自的业务诉求，如ota重视软件管理和任务管理，双录重视监管和订单；

虽然管理后台面向各行各业都有不一样的特性，但一般都是有账号体系、角色体系、审批流程和操作日志等基础功能，下面基于其中一类以及笔者经历较深的领域-ota和开放平台；

单从ota来看，市面有分三种，fota、sota和集成os三类；

fota-固件远程升级，一般是涉及到汽车底层电子元件的软件升级，刹车、座舱底层和仪表盘等软件的升级，大部分的传统车企都有这部分的能力，并且对安全性和稳定性要求都十分高，终究涉及到挡位这类行驶的控制，假使没有必要的缺陷，基本都不会随意升级；

但在汽车行业的资本渗透和新兴玩家入场，如特斯拉\小鹏等，现在逐步的开放fota的远端升级，但一般都是集成类升级，不会单独分开升级fota；

sota-又称软件系统升级，一般都是中控台的os层及应用升级，类似手机系统升级，但在汽车行业，这块还是跟手机端有所不同，区别在于以下几点：

举个简单的例子，假使车企需要升级某个应用层的bug或者有新的应用可以发布，一般都是通过sota的形式推送给到各端，包括已销售出去的汽车；

本人接触的有语音语义和小程序开放平台，这类管理后台一般是面向三方开发者提供技术底层能力和应用框架；

类似于小程序管理后台，这类平台会提供开发者接入手册和底层小程序的技术框架，开发者基于这个框架定制化开发多个小程序，这类平台重视生态的扩展和开发者入驻的数量，所以一般都是技术能力或者市场实力较为雄厚的科技平台公司在布局，这类平台既具备toc能力也有tob的能力，区别在于两者的资质认证；

可以看出，各行各业的管理后台，五花八门，那么我们现在就基于单个应用领域去切入，进行详细的产品设计工作；

产品后端开发后端产品经理职责范围篇六

一般而言业务管理后台都是面向tob产品，而tob的产品最大的特点就是定制化程度高，私有化部署；

而这对产品设计带来的挑战就是业务诉求频繁变化和场景繁杂，假使考虑不全面，后续平台返工的成本、概率就会随着功能的堆叠变得越来越高；

所以第一步我们需要对业务需求和使用场景进行梳理，并且需要基于项目背景及终端设备出发，制定核心可落地的功能