京东后端产品经理讲述做后端产品的五大思路

1. 前端产品经理和后端产品经理

大学毕业前,有一段在直播行业做产品实习生的经历。

后来转入互金行业,还记得我上级面试时问我:

你知道什么是后端产品经理吗?

当时的我一脸懵逼,不过还是幸运地被录取了,职位是前后端结合的产品经理。

工作一段时间后,我上级又问我:

你觉得做互金产品和直播产品有什么区别?

以下就是我对前端产品经理和后端产品经理的思考:

前端产品经理,更注重用户体验和交互方式,对设计模式、用户心理有一定要求。

市面上流传的很多“产品经理必读书目”都在介绍用户思维、交互体验。

后端产品经理,更注重业务逻辑和实现方式,对技术基础、逻辑思维有一定要求。

常见于电商、金融等行业。

就我知道的而言,后端产品经理比前端产品经理核心竞争力更强一些。

用户思维、交互体验、数据敏感度逐渐成为产品经理的基础能力,而不是核心竞争力。

“T型人才”将成为未来的发展趋势。“—”代表广播的知识面,“|”代表知识的深度。这对于产品经理的职业发展意义是:

在培养基础能力的同时,也要在某一行业深耕,构建自己的核心竞争力。

简单来讲,前端产品经理更偏重产品的“门面”,后端产品经理更偏重产品的“骨架”。一个好的产品,不光要有优秀的前端用户体验,也要有健康稳定的后端系统支撑。

不管是前端产品经理还是后端产品经理,都要有一颗踏实做事的心,实实在在为用户创造价值。

2. 后端产品经理如何分析需求

2.1 功能需求

功能方面的需求指定系统必须提供的服务。

通过需求分析应该划分出系统必须完成的所有功能,以及功能如何在系统之间实现。

感受一下后端产品经理的日常流程图:

在前端,用户完成简单的商品浏览、商品选定、下单支付过程,就涉及到后端六个系统之间的交互。对于体量更大的公司,系统模块只会更多。

这就要求产品经理不再局限于前端的页面层次,而是基于业务对整体后端系统有一个宏观的认知,能区分各个系统的主功能,搭建一个好的产品架构。

2.2 性能需求

性能需求指定系统必须满足的定时约束或容量约束,常包括速度(响应时间)、信息量速率、安全性等方面的需求。

比如,“支付系统必须在半分钟内返回用户支付状态”就是一项性能需求。

2.3 可靠性需求

可靠性需求定量地指定系统的可靠性。

比如,“商品系统在一个月内不能出现2次以上故障”。

2.4 出错处理需求

出错处理需求说明系统对错误应该怎样响应。

比如,“订单取消后,用户支付已取消订单成功会怎样”。

2.5 逆向需求

逆向需求说明系统不应该做什么。

产品经理应该选取能澄清真实需求且可消除可能发生误解的那些逆向需求。

2.6 将来可能提出的需求

应明确那些虽然不属于当前系统开发范畴,但是据分析将来可能会提出的需求。

比如需求迭代、增加新功能等。

其目的是,对系统将来可能的扩充和修改做准备,以便日后确定需求时能比较容易地实现。

3. 好的系统是什么样子

之前在文章《产品经理的技术思维手册》提到过“模块化思维”。“模块化思维”不仅适用于前端设计,也适用于后端开发。

模块化:把程序划分成独立命名且可独立访问的模块,每个模块完成一些类别相似的子功能。把这些模块集成起来构成一个整体,可以完成指定的功能满足用户需求。

在章节2.1的流程图里,订单系统、商品系统、运营系统等,都是相互独立的模块。

3.1 为什么要系统模块化?

首先来思考一个感性的认知,如果淘宝这么大体量的电商系统,只有一个模块,那么一点小变动就会导致开发人员在海量代码里找寻相关的代码,遗漏、错误的可能性很高,系统安全备受质疑。其次,如果团队加入新的开发人员,他对系统代码的熟悉成本也是巨大的。

再来一个理性的认识:

设函数 c(x)表示问题 x 的复杂度,函数 t(x)表示解决问题 x 需要的工作量(时间)

对于问题 x1 和 x2 ,

如果   c(x1)> c(x2),

则    t (x1)> t(x2)

根据人类解决一般问题的经验,还有一个有趣的规律:

c(x1 + x2)> c(x1)+ c(x2)

则 t(x1 + x2)> t(x1)+ t(x2)

即是:由多个问题组成的问题的复杂度,大于分别考虑每个问题的复杂度之和。

则:解决集合问题的工作量比分别解决每个问题工作量之和更大。

这带给我们的启示是:

利用模块化,可以将总功能拆解为一个个子集,提高系统的分工效率。

3.2 如何界定模块的独立程度?

首先,模块的独立性很重要:

  • 基于有效的模块化(即具有独立性的模块)的系统比较容易开发;
  • 独立的模块比较容易测试和维护。

相对于不进行模块化的系统,有效模块化修改系统需要的工作量更小、错误传播范围更小,需要扩充时也能更容易地加入新模块。

其次,界定模块的独立程度有两个标准:

  • 耦合
  • 内聚

耦合:度量一个产品结构内不同模块之间的互连程度。

耦合强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。

内聚:度量一个模块内各个元素彼此结合的紧密程度。

比较理想的模块化是:低耦合,高内聚。各个子系统便于开发和维护,提高整体分工效率。

4. 总结

后端产品经理一职,要求产品经理非常懂业务。对于系统架构、业务认知以及行业发展的前瞻性都要形成自己独特的思考体系。

想要成为后端产品经理?

我认为主要是两点:

(1)找准想要深耕的行业

电商、金融、B端产品等等,多体验多思考,比如想从事电商行业可以去淘宝开一下店,体验一下面向商家的系统;想从事金融行业,那么基础的金融知识肯定是必须的;实在不行,公司的CRM系统、OA系统也可以观摩学习。

(2)积累一点技术基础,提升逻辑思维

建议阅读《计算机网络》,对OSI模型有一个大体的认识,知道底层数据如何传输、计算机如何互连。像API、RPC这些名词也要知道其作用是什么。可以看看技术同事的开发文档,基于单个功能的系统交互图,不懂多问。

产品经理每天都很忙,沉迷工作是一个好事,但一定要腾出时间思考、学习和总结,长期的输入才能带来思维的提升。

最后,祝愿我们都能成为优秀的产品经理,不忘初心、砥砺前行。

随着互联网行业的兴起,大量新型创业公司和传统产业公司转型互联网。这批资源有限或者不了解计算机科学技术的企业,以为产品就是可视化的产品,对产品在创始之前其背后的愿景完全不懂,也不规划,导致其后台程序维护成本越来越高。

举个例子帮助大家了解下产品规划,也了解下人性。

小王是一个后端产品经理,做的是内容管理系统。前期满足前端的内容需求,前端有“A”需求,后台就增加模块添加内容“A”,前端有素材需求“B”,就增加添加素材需求“B”。生活安逸而舒适,老板经常表扬小王工作认真踏实肯干。

突然,出现了“A”“B”“C”内容的组合,A、B、C之间还有协同和互斥的规则。小王弄了2天。终于捋顺了A、B、C之间的逻辑关系,老板看在眼里记在心上。小王最近可能有点其他事情,人嘛,难免家里有点事情。

突然前端又甩出一个需求,A、B、C组合投放到D、E、F上,还有时间纬度。这回小王彻底麻爪了,这些模块组合非常冗杂,再考虑扩展性,1-2周完全弄不出来。这样小王把扩展性去掉,模块写死。成功在2周内写完,老板一看,小王给力啊,升职加薪。其实小王心里知道,这么做是有隐患的。

又这样过了一段时间,前端又增加了几个模块。小王已经深刻的了解到了,这个系统已经崩了,开始寻找下家,这时候再加的后台需求就是只为满足功能、完全不谈模块设计了,只要能对付过去,就算可以。当然在老板眼里,小王一直是位好员工,踏实肯干,能力强。半个月后,成功找到下家,甩甩屁股走了,走了的时候,前任老板依依不舍,还要升职加薪留人。

小王走了,小张来了,都说程序员要做好代码设计,要不终究有一天你是要还的。产品也是,但是问题落到谁来还这问题上。小张注定接盘侠,小张看了下原来的后台。我去,啥玩意?这模块怎么放在这,他怎么想的?这个东西他考虑这种情况了吗?

最后他决定重做一版,这和让程序员改别人的代码原理极其相同。当他向老板反映说要重做后台的时候,老板虽然嘴里答应,但心里满是不悦,你看小王在的时候啥事情都没有,这又要重做多耽误事情。虽然嘴上不爽,但是毕竟业务还得上啊,答应了。小王要了1个月的时间。老板彻底震惊了,1个月,光设计???开啥玩笑,1个月小王能做5-6个模块了,你一个月就重做一个后台?啥都不变?搞笑吗?这能力也太差了。

小张很努力,开始选择设计模式的时候严格按照Saas和Paas模块去做,甚至数据库表结构都亲自参与设计。他想搞出来一个长久点的东西,至少1年半载的不会重建。

这时候,开发是非常难推动的,原因很简单,相似的业务流程,现在却按照更复杂的流程去设计。开发不开心、任务量也相对较大。小张心好累,项目推进困难重重。

最终第一版终于出来了,小张觉得自己的功夫没白费,可是事实却恰恰相反,小张被扣掉了10%的工资。小张明白了,原来后端产品经理和程序员差不多啊,老板看的是代码量啊。后来小张做东西也不做过多的考虑、也不做更多的规划,后来小张变成了小王。后来,后来……

其实这个故事已经深入的揭示了为啥后端产品经理是个坑,我来盘点几条,欢迎大家发散思维。

从属性上:后端产品经理被赋予工具属性,前端有啥你就得支持啥。都是工具了,当然不值钱了。

从成长上看,越多和交互、前端打交道越能增加自己对用户体验的理解。常说常见常练,肯定成长飞快。相对来说给予后台资源较少,很少产品的后台设计能让人觉得赏心悦目,爱不释手。

从荣誉上看,在一个团队里,负责业务玩法的人,一定是最受欢迎的人,用各种不同的玩法解决问题。而后端产品经理几乎与此无缘,更悲剧的是他与开发的关系可能是最激化的。因为他设计的是业务底层,规划的是产品架构。和他对接的低级的可能是撰写业务流程的PHP,高级的就是软件架构师。说服他们改变原有的工作思维和经验去按照你的搭建系统,你需要非常强大的行政职权,而这是一般的产品经理是没有的。

从薪水上讲,大型公司同级别的产品经理,前端和后端差不多。中型公司,后台的产品经理要高于前端(因为同等薪水招不到)。小型公司,后台产品经理却低于前端产品。

从人性的角度看,你觉得什么时候,上一个后端产品经理会离职,7成做不下去了,3成转岗做前端了。你准备做好接盘了吗?

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/1508.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息