资源位|设计后台系统的几项原则和注意事项( 二 ) 车路协同|l5|车联|蘑菇|apollo|阿

如果是在小公司其实后面那种情况遇到的概率会非常大，业务领导都是上来就问明天能不能上，完全没有合理性的概念，不必纠结。如果技术靠谱点问题就少，如果不是很靠谱那就问题非常多。
我最近的经验就是开发了2天，bug断断续续修了3天。你感受一下。
四、后台设计需要注意哪些问题1. 后台要好用因为是内部使用的后台，其实很多小公司都是很不重视后台的可用性的，界面难看、难用，模块划分不清晰。如果遇到这种情况可以让技术选一个好的框架，在开发的时候注意一下页面干净和布局清晰一点。
我就遇到了这种情况，后台整个界面扭七扭八的，非常难看。
2. 后台尽可能少我现在的公司功能后台有6个，更新一下app版本要同时登录3个后台修改数据，这TM真是绝了。如果有条件的话尽可能合并成1-2个后台，或者在设计的时候就不用分开设计。
但也不是说合并成一个最好，譬如如果涉及到电销系统，系统本身就很复杂且只有电销部门使用，这种情况下其实是可以单独做后台的。
从实际的情况来看其实合并后台是不大现实的，因为成本高、周期长、风险大以及对于业绩的提升难以估量，公司层面比较难通过。我做过一次后台合并，开发了3个月，修bug断断续续修了2个月，惨不忍睹。
所以如果不是领导提这个事情，尽量不要主动提，因为绩效上来说很难给你加分，甚至搞不好会减分。
3. 权限设计要合理权限设计有两种方式：
一种是根据岗位设计，不同的岗位权限不同，同一个岗位权限一致。这种方式的好处是设置一次后，来新人只要挂一下部门，权限就有了，比较适合规模比较大的公司，职能比较清晰，变动也比较少；
一种是根据用户进行选择，每次来一个人都需要配置权限，好处是非常灵活，比较适合初创型企业，一切都还在变化，人员也不多，所以需要这种方式。
这里面可能需要注意一下，在页面内可能还会细分权限，譬如页面上有导出按钮，有的公司要求比较细就会针对这个导出功能也会有单独的权限。
有的公司会做成和钉钉的组织架构关联的方式，也可以，扫一下登录，安全性也挺好，而且产品经理就不需要设计权限系统了。
4. 分类要合理这个比较容易把握，一般是按部门和职能组合后台就行。
但是一定要说明的是，最好不要把数据和功能混在一个后台上，不伦不类的。倒不是说实现上有问题，但是这就会导致分散在不同的地方，使用起来并不方便的问题。以及很多公司都有单独的BI系统，然后就会导致两边都有数据，两边还不一定对的上的问题，处理起来更麻烦。
然后一定要注意的是对原有功能的适配。
大量的情况下并不是新增全新的功能，而是针对原有功能进行优化和新增，这就涉及到对原有功能的适配问题，如果产品不提的话技术很可能是不会做额外的处理的，建议在提需求的时候提一下适配问题。
我最近的经验就是在原有功能上加了一个新功能点，但是技术发布之后没有任何说明，等到业务部门观察数据的时候才知道，需要做一次更新保存新功能才会生效，我真的是服了，没做处理没关系，连个说明都没有。
5. 最好有一个后台功能使用说明书因为总是会有新人来，一些功能可能会更新，没有记录就每次都会问产品经理，还不如写一个说明文档，让各部门查看使用比较好。
当然我也知道会遇到有些同事就是不看文档，就喜欢问你，这也是很烦人的。你看情况处理，关系还行就说一下，关系一般就告诉他文档里面有，可以自行查阅。
五、应不应该做后台产品经理最后聊一下这个问题，可能还是有朋友是有点困惑的。
这个问题每个人的见解不一样，但我们认为判断的标准在于可迁移性好不好，也就是你这个经验拿到其他公司是否可以沿用，如果不可以那就不行，如果可以那就行。这个其实和是什么类型的产品经理没关系，主要是考虑经验和技能的可迁移性。
举个例子，在电商做仓储履约的产品经理，就是归属到后台产品的大类下面的，这种产品经理目前还是蛮吃香的，经验和技能的可迁移性也很好。这种需要考虑系统和现场人员如何互动的产品经理其实蛮考验经验和洞察的，核心是优化流程提升效率，没有足够的经验是不可能做好的。
做后台在大部分时候都是一件重要但对于绩效来说性价比不高的一件事情，所以大部分情况下也没办法投入大多精力去做。尽可能的在设计的时候就把架构设计的好一点，然后在框架里设计，做了之后如非必要不改动，一改动的话就涉及到对于历史功能的适配问题，其实很麻烦。