本文从我自身的角度，介绍了关于前后端产品经理的区别和一些关于系统的认知，欢迎交流，不喜轻喷。

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这些名词也要知道其作用是什么。可以看看技术同事的开发文档，基于单个功能的系统交互图，不懂多问。

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

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

作者：苒苒上升，公众号：苒苒上升，互联网金融产品经理，负责3亿用户平台

本文由 @苒苒上升 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议