后端产品经理要懂的知识点.doc

/NUMPAGES10后端产品经理要懂的知识点本文从我自身的角度，介绍了关于前后端产品经理的区别和一些关于系统的认知，欢迎交流，不喜轻喷。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）即是：由多个问题组成的问题的复杂度，