标签：
在一个没毕业的大学生都能对你设计的app前端页面品头论足的时代，一个合格的后台产品经理就愈发珍贵。
以我自己经历的项目和身边同行朋友的经验，项目的产品leader都是在全部或部分职业生涯中做过后台产品的；直白的来说，同样的工作经验，后台pm的工资是同样优秀的前台pm的1.5倍以上。
自己刚毕业时做过一年的前端产品，后来临危受命负责项目的整个后台，并逐渐迷上了这块。结合2年的后台经验，我认为后台pm最看重逻辑思维能力、对所做业务足够熟悉、项目需求管理和推进能力、后台设计架构可扩展性兼容性高这几块。
逻辑思维能力
一种是系统内的逻辑。后端系统在页面设计方面要求不会非常高，只需要做到布局清楚，做好提示减少误操。如同做支付的人经常讲路由和成本，其他后端系统也有类似的考虑，就是信息的路由。
一条请求发过来，不管是要查询信息，还是要执行某个操作，都离不开系统内几个模块的信息流转和同步。这条请求包含哪些数据，对数据需要做哪些处理，处理是人工做还是系统做，如果是人工做，还需要有系统的校验和保存，处理后提供什么要的结果，结果如何展示，是否需要把结果通过接口或批量报表的形式提供给其他后台模块。往往在思考这些问题的时候，一张清晰的数据交互时序图，可以帮助你解决很多问题，也更容易把你的想法传达给开发同事。
另一种是写后台PRD时的逻辑。比如一个功能点，逻辑思维一般的人描述可能就是实现了xxx功能；而一个逻辑思维严谨的人，会清晰的描述出，前置条件，触发因素，产生结果，系统处理规则，默认是什么样，有数是什么样，数据多了是什么样，异常是什么样。总结一下，就是条例清楚的表达出需求的来龙去脉。
充分跟需求方沟通，然后思维导图罗列出功能架构，再基于这些，做逻辑图。思路一定要清晰，否则很难推进下去。一定要尽量想的全面，别到时候需求评审时候，这里有问题，哪里不全面，会被开发笑话的。自己不清楚的时候，别指望别人能清楚的理解你。
熟悉自己在做的业务
熟悉自己在做的业务，是需要对服务体系内的业务流程足够了解的，因为你设计的后台是要去帮助他们更好的处理业务，你对业务流程不够了解的话，设计出来的产品就会不贴合实际的使用场景。
对于业务的理解，可以概括为三点：
1. 前台有什么，后台管什么，比如最基础的用户管理、商品管理、订单管理、内容管理等等
2. 对后台系统的管理，比如个人信息管理、权限管理；
3. 数据管理，一款好的产品一定是用户利益和产品利益的结合体，而最能客观反映产品利益的就是数据，所以平台数据化；其次是逻辑思维，基本业务流程化、特殊场景特殊处理，与前台互动的触发机制等等
以自己在做的代购工具项目（自创业，已经成功卖给某电商平台），我需要去了解整个代购的接单流程，为此我加了十几个高质量代购群，并且自己把积累的这些认识的核心代购拉了个种子用户群，每日坚持在群里发红包向他们了解最真实的需求。为此我设计的后台中，除了常见的商品管理模块、订单管理模块，在此基础上我加了自建商品库（为了满足代购创建一些销量好，但免税店没有的商品，比如某几类杂志）、委托单管理模块和采购清单管理模块，委托单和采购清单的实际应用场景请自行思考，就当是课后作业，答对有微信红包。
项目需求管理能力
项目需求管理能力，我认为可以分为两块，需求池管理和明辨真伪需求。
一个比较大的后台项目，可能涉及到多个前端产品的需求，好多功能，比较分散，并且多线并行。这时候需要一个需求池来管理需求，我一般采用excel把负责的需求汇集成一个需求池，并上传公司内网，支持团队内小伙伴的多人在线编辑，随时更新各自跟进的需求的进度。需求池一般需要优先级、提出人、需求进度、预计上线日期等关键字段。
明辨真伪需求的前提，是懂业务！懂业务！懂业务！重要的事情说三遍。业务方的提的要求是一匹可以跑得更快的马，但是实际你要给他的是一辆车。在跟业务方聊天的时候，不一定要记住他要求你做什么，但是你一定要记住他提出来种种的原因和期望实现的目的。
再就是后台除非大版本大改动，否则基本上不会走版本，许多小改动当日改当日上，而且一般后台产品会对接多个业务方，需求排期整理也是个技术活……
另外，有些常见改动模块或者重复类功能，一定要做成灵活可配置，能帮你怼回去N多“白痴”需求。
对后续业务需求和功能的可扩展性
考虑后续业务的扩展，一个后台管理系统，是为了满足老板、运营等角色的管理需求。现在阶段的管理是为了满足现有阶段业务的需要，后续业务量上来了，一定要考虑扩展性。
举一例，运营人员后台上传照片时，如果你简单的想到一个button单张上传，可以满足现有业务的需求。但一旦量大了呢？上千上万张图片，一个一个button的去点么？
来源：人人都是产品经理
标签：