做了几年后台，针对后台来说，我认为这四个能力比较重要：

逻辑思维能力

一种是系统内的逻辑。后端系统在页面设计方面要求不会非常高，只需要做到布局清楚，做好提示减少误操。如同做支付的人经常讲路由和成本，其他后端系统也有类似的考虑，就是信息的路由。

一条请求发过来，不管是要查询信息，还是要执行某个操作，都离不开系统内几个模块的信息流转和同步。这条请求包含哪些数据，对数据需要做哪些处理，处理是人工做还是系统做，如果是人工做，还需要有系统的校验和保存，处理后提供什么要的结果，结果如何展示，是否需要把结果通过接口或批量报表的形式提供给其他后台模块。往往在思考这些问题的时候，一张清晰的数据交互时序图，可以帮助你解决很多问题，也更容易把你的想法传达给开发同事。

另一种是写后台PRD时的逻辑。比如一个功能点，逻辑思维一般的人描述可能就是实现了xxx功能；而一个逻辑思维严谨的人，会清晰的描述出，前置条件，触发因素，产生结果，系统处理规则，默认是什么样，有数是什么样，数据多了是什么样，异常是什么样。总结一下，就是条例清楚的表达出需求的来龙去脉。

充分跟需求方沟通，然后思维导图罗列出功能架构，再基于这些，做逻辑图。思路一定要清晰，否则很难推进下去。一定要尽量想的全面，别到时候需求评审时候，这里有问题，哪里不全面，会被开发笑话的。自己不清楚的时候，别指望别人能清楚的理解你。

熟悉自己在做的业务

熟悉自己在做的业务，是需要对服务体系内的业务流程足够了解的，因为你设计的后台是要去帮助他们更好的处理业务，你对业务流程不够了解的话，设计出来的产品就会不贴合实际的使用场景。

对于业务的理解，可以概括为三点：

1. 前台有什么，后台管什么，比如最基础的用户管理、商品管理、订单管理、内容管理等等
2. 对后台系统的管理，比如个人信息管理、权限管理；
3. 数据管理，一款好的产品一定是用户利益和产品利益的结合体，而最能客观反映产品利益的就是数据，所以平台数据化；其次是逻辑思维，基本业务流程化、特殊场景特殊处理，与前台互动的触发机制等等

以自己在做的代购工具项目，我需要去了解整个代购的接单流程，为此我加了十几个高质量代购群，并且自己把积累的这些认识的核心代购拉了个种子用户群，每日坚持在群里发红包向他们了解最真实的需求。为此我设计的后台中，除了常见的商品管理模块、订单管理模块，在此基础上我加了自建商品库（为了满足代购创建一些销量好，但免税店没有的商品，比如某几类杂志）、委托单管理模块和采购清单管理模块，委托单和采购清单的实际应用场景请自行思考，就当是课后作业。

项目需求管理能力

项目需求管理能力，我认为可以分为两块，需求池管理和明辨真伪需求。

一个比较大的后台项目，可能涉及到多个前端产品的需求，好多功能，比较分散，并且多线并行。这时候需要一个需求池来管理需求，我一般采用excel把负责的需求汇集成一个需求池，并上传公司内网，支持团队内小伙伴的多人在线编辑，随时更新各自跟进的需求的进度。需求池一般需要优先级、提出人、需求进度、预计上线日期等关键字段。

明辨真伪需求的前提，是懂业务！懂业务！懂业务！重要的事情说三遍。业务方的提的要求是一匹可以跑得更快的马，但是实际你要给他的是一辆车。在跟业务方聊天的时候，不一定要记住他要求你做什么，但是你一定要记住他提出来种种的原因和期望实现的目的。

再就是后台除非大版本大改动，否则基本上不会走版本，许多小改动当日改当日上，而且一般后台产品会对接多个业务方，需求排期整理也是个技术活……

另外，有些常见改动模块或者重复类功能，一定要做成灵活可配置，能帮你怼回去N多“白痴”需求。

对后续业务需求和功能的可扩展性

考虑后续业务的扩展，一个后台管理系统，是为了满足老板、运营等角色的管理需求。现在阶段的管理是为了满足现有阶段业务的需要，后续业务量上来了，一定要考虑扩展性。

举一例，运营人员后台上传照片时，如果你简单的想到一个button单张上传，可以满足现有业务的需求。但一旦量大了呢？上千上万张图片，一个一个button的去点么？