做后台产品，就是做管理
一、背景
通过完整设计彩票产品的前后，以及之前一些对后台产品的接触，简单说一下个人总结的设计后台产品的方法。
二、理念
如果说前端产品更多是对用户的琢磨以及对场景的理解，那么后台产品则更偏向于对业务模式的解构，流程的梳理，以及对商业的理解，所以在设计后台产品时，总体理念上，是在为业务的顺利进行做效率支撑。
在这一过程中，准确性＞操作效率＞易用性＞美观。不过对于初创团队来说，为了快速验证产品，初期效率会大于准确性。
三、业务流程那些事儿
做后台产品，说白了也就一句话，弄清楚谁在什么时候该干啥事，即梳理清楚业务流程，并在准确性和效率之间不断做平衡。说起来简单，做起来会越到各种问题，项目管理那套理论就不多说了，就说一些经验之谈。
设计中不要相信任何现成的资料。啥意思？别以为各部门都有自己的管理方法，你可以直接用现成的，跟记者拿台本一样，完全不是这么回事，尤其是在初创公司，管理者对于具体的业务执行，其实模棱两可。同时，在很多具体事务上，其实没有清晰的权责界定，必须要大boss当场拍板指派给谁来操作。
那么，最靠谱、最负责、也是最锻炼自身的办法，就是自己先设计一个版本的业务流程，开个会让大家坐一起，带上大Boss或高级别见证人，让对应业务部门来挑刺。点名让具体要操作的相关执行人员来提出问题。设计完毕，三审三校。
注意的是，别以为随便弄弄，发个邮件确认就行了，最后系统不好用，大家不会记住你们确认过需求，只会认为你设计能力有限。再者言，不好用，该填坑的还是你自己。
作为一个有责任感的职业经理人，该明白专业的事交个专业的人，但也要明白，手头容易出现风险的工作，要防患于未然，支撑这件事，做得好没有人会记得，但是如果出了问题，却最容易被追责。而你的价值就在于，能够让业务团队毫无顾忌地放手一搏。同时能够帮助管理者明确，出了问题该谁来负责，以及如何挽回。
一句话总结，做后台，就是做管理。
四、后台产品三大部分
1、划分以及依据
核心业务部分、业务支撑部分、非业务部分。
为啥要这样划分？首先说明这里的后台只有公司内部员工使用，按照这个划分的主要原因是：
·让每个业务流程耦合地恰到好处，不会太短或太长，如此一来，考虑问题的时候，不会过于复杂（越复杂越容易出错）。
·保证业务流程的相对独立。
·便于分工，让新人得到独立的模块进行锻炼，从非业务部分逐渐入手。
下面会以彩票为例说明。
2、核心业务部分
核心业务部分，简单说，就是能够用MVP来理解的部分，即最小业务单元。其迭代主要驱动因素在于公司外部的市场情况。
以彩票为例，即你的核心业务流程就是：购彩→开奖→兑奖。那么，彩种、开奖、兑奖部分的流程即为你的核心业务。其他的业务支线，都可以算作业务支撑部分。
3、业务支撑部分
业务支撑部分，即核心业务支线，其特点在于，与核心业务有耦合但耦合程度轻，同时操作上相对低频，并且涉及到的干系人会更广，迭代主要驱动因素在公司内部，而非外部。
在彩票过程中，开户流程就是业务支撑部分的典型案例，完成开户流程，需要多个部门的配合。首先需要销售部门在行政资管部门领取编号合同，再至代理商处签字同时领取预收款，财务确认后，由技术部门负责开户，行政资管部门需要发放物料，同时进行合同的存档。
开户对于系统本身来说，不同规模，不同阶段的公司，可以有不同的做法，严谨一些的，需要在开户时上传合同至系统，或者将其他操作全部线上化，而初创团队，在业务量未起来时，其实只需要将账号信息录入即可。但由于涉及到法律以及财务等相关问题，PM在设计时，不能只考虑自己的后台功能部分，而应该从整体的业务支撑上去作分析，什么部分应该优先线上化。
同理，像是充值、提现、销户等等环节，都属于业务支撑部分。
4、非业务部分
非业务部分并非完全与业务无关，毕竟从宏观来说，所有公司雇员都是业务的直接或间接干系人。此部分的功能，其特点在于，相对核心业务较为独立，业务流程短且干系人单一，甚至完全可以独立于业务存在。
举例，后台的系统设置、App升级、内容管理、Push推送等等都是属于非业务部分，相对来说，可以完全独立业务进行功能迭代。
五、设计中的经验之谈
1、模块之间尽量独立
解释：PM没到一定层次，或者说对于市场没有足够了解的情况下，很难纵观全局，设计出来的业务流程往往较为理想化，干系人较为容易混淆，与其减少页面提升效率，不如分开将步骤拆开，页面分开，如有需求，后期再整合，起码保障业务通畅。
2、没想好的东西，做活
有些东西是你没想好，有时候是短时间内根本想不好。粗浅来看，变更频繁的东西，要做活，如常见的运营需求，就算运营给你打100个包票说以后不改了，提需求的时候，还是要做活，不要坑自己。细看，你难以把握的东西，问问老板，老板如果不是很坚定说写死，也都做活。以上观念，对于单体架构的App产品尤为注意，Web端微服务架构的产品，可以写死的东西更多。
3、权限分配，分三级
按照传统套路，按照页面、功能、数据来分。
页面权限就是登陆后能否看到某个页面，要注意的就是第1点，注意页面之间独立，要不然这个就是摆设。
功能权限就是进入一个页面后，你能使用什么功能，比如说，财务总监看财务表，能做全局导出，出纳看表，只能做搜索，或者限制导出一个月的表。
数据权限就是，进去同一个页面，看到的是不同的数据，比如说，为保护销售数据不被泄露，不同销售大区的人员，进入销售表，只能看到自己区的数据。销售副总及以上成员，能看到所有大区的销售情况。
另外，如果员工很多，加个角色的中间概念，可以用于快捷设置权限。
4、数据需求，做精
数据报表化的程度越高，信息泄露风险越大。权限也是人分配的，总归容易出错。故此非必须高频的数据表，宁愿麻烦数据运维多操作一下，不要轻易报表化。另外就是非要呈现时，表比文好，图比表好，图不如导出好。
5、注意生效时间以及修改频次
不像App产品大多2C，后台产品的设置在保存时，要注意生效时间。举例，彩票账款是要日结的，在修改代理商层级关系的时候，如果即刻生效或者修改频次过高，则可能导致结算时出现问题，故此在一般情况下，限制当日的修改在当日24点生效。
6、多给说明
后台产品的专业名词是很多的，相对来说并不好理解。对于规模小的公司，同时PM也预见到这个后台使用人数有限，直接靠培训解决问题其实是最好，但是对于规模比较大，且使用者水平层次不齐的后台产品，比如说做销售管理的后台产品，在设计中给予足够多的注释是非常有必要的。
7、没东西抄怎么办？
后台产品不像App产品可以随便找竞品抄，一个实在的建议是，业务逻辑必须自己解构，交互思路上，钉钉的后台。
