作者：云瑞
全文共 4241 字，阅读需要 7 分钟
—— BEGIN ——
后台产品也分很多种，从使用者的角度分：公司内部人员使用的运营管理系统，面向合作伙伴的CRM系统，还有的公司就是专门销售管理系统的，典型的如OA。
我在这里讲的只是面向公司内部人员使用的系统。
在做后端产品的过程中我更加理解了产品理念的重要性，很多事如果我们的理念相同，会极大的降低沟通成本，沟通的双方会很快达成共识。
1. 名词概念统一
在产品设计时，我们会给不同的功能定义不同的名词。有些名词已经非常通用，大家一说都明白，例如删除、添加；但由于各个公司的运营需求不同，对功能要求也可能不一样。即便都叫运营管理系统，但也需要针对公司自身的情况开发一些定制功能。
名词的定义除了关系到使用者的理解之外，也会关系到跟技术人员的沟通。要不然就会出现大家心中想的是一个事情，但是语言用词上不一致；造成一些误会不说，可能还需要每次沟通前都得把名词强调一遍。所以产品经理
在开发前就应该跟技术人员先把名词定义好。
有些功能可能一时想不到适合的词汇也没关系，只要大家在内部对名词的理解统一即可。
2. 节省效率
先说一下产品背景，拿CMS产品来说，主要是用来供公司运营人员使用的，用来发布并管理内容。这类产品有个很重要的原则是：
一定要快，节省使用者的工作效率。
其实不光CMS，很多系统也都会坚持这个原则，例如超市的收银系统，即使结一单只提升几秒，一天下来可能就会节省几十分钟。
我见过有的产品经理会因为一个电脑页面显示不完，为了样式的好看而隐藏一些用户所关心的信息。这样在操作的时候大家还得去点击详情查看，需要二次操作。
不要因为样式上的美观而降低效率。后台系统中肯定会有很多列表，不同的列表会显示不同的信息。如果一个列表中运营人员所关心的信息太多，那么全部显示出来即可。所以在界面设计上也要尽量利用空间，这个思路跟手机界面的留白就不一样了。
为了节省效率还有一个很重要的原则：
优先显示运营人员关注的信息。
例如信息审核系统，对于运营人员而言，他们最在乎的是待审核的信息（提交的用户还在等着呢)。所以应该优先显示这类信息，这是急切需要运营人员操作的；而审核通过和审核失败的，可能只是在需要时才会查询一下。
举个例子：为了效率提升，产品设计的改变。在信息操作的时候，我们可以将操作目的直接做成按钮，而不需要使用单选按钮再点击提交操作。
3. 严谨，准确性，降低误操作
从某种程度上说这一点跟第二点是相矛盾的。
如果你在用户进行某项操作时还需要他进行确认操作，这个过程势必不会那么顺畅。
但确认操作又是必须的。之所以需要确认操作主要是为了降低运营人员因为误操作而带来的损失（当然这并不能保证万无一失，只是降低出错的风险）。
产品经理在设定某个功能需要确认操作时也要考虑清楚，什么样的功能该有确认操作，什么样的功能不需要。要是所有的功能都需要确认操作，那真的就没效率可言了。
判定的标准就是看能功能产生的影响。
之前媒体有报道过惠普和当当网有标错价格的情况，把几千块钱的商品标注成了几块钱，面临的是经济损失。这应该是误操作带来的最严重的影响了。
对运营系统而言，更多的情况是给页面显示带来一些错误。例如把本来不该显示的信息提前上架了。还有可能是误删除了信息，这时候就要自己重新添加了。
如果某些信息操作后的效果并不严重且有补救措施，那就可以没有确认操作。
4. 该不该用技术的方式约束人性
该不该用技术的方式控制人性？这也是一个挺纠结的问题。
还是拿我上面举的确认操作的例子来说：
有的人会觉得其实这个是使用者自己的行为，他们在操作前本身应该看清楚，何况后台系统都有操作日志，如果谁犯错了，看下操作日志找到当事人，给予相应的惩罚。
这样也会提醒别人，大家以后误操作的几率也会降低。这个观点也会成为我们砍掉某些功能的理由。
这种话我多半以为都是气话。且不说在工作中实际操作性有多大，即便可以对员工罚款，但是事件对外界造成的影响呢？即便有人负责也晚了，所以还是要提前避免。
对于信息的管理，只要是人控制的就充满了太多不确定性。
通过在技术上加以限制还是有必要的。但也要有度，有些限制做不好会适得其反。
讲一个案例：
一家公司的信息审核系统，运营人员在审核信息时，系统设定了60秒的时间，不管运营人员有没有看完信息，审核通过的按钮只有在60秒后才能点击。
本意是希望让运营人员必须查看后才审核，防止他们办事马虎。但实际过程中却发现这种做法降低了运营人员的效率，因为他们看完一条信息不需要60秒。
有的人可能会说那就设为30秒，由于经验不同，运营人员的审核效率不同。而且出于信任有的用户的信息运营人员的审核也会松懈很多，时间设置太短也没有意义。后来就干脆把这功能撤下了。
5. 目的达到即可，节约开发成本
在设计后台系统时，除了从使用者的角度去考虑外，也要为技术人员的实现方式和开发成本考虑一下。
不要因为无所谓的功能，而给技术人员增加工作量
，很多时候只要达到目的即可。
曾经做过一个上下架功能，需要用到一个日历插件，选择时间，当时产品经理非得让技术人员把日历上的已过去的时间置灰。
日历插件主要是用于选择上下架时间，而已过期时间是否置灰对于这个功能都不会有影响。当然如果做了，用户体验会更好。但有些后台产品毕竟只是公司内部使用，只要目的达到了即可，没必要让技术人员去做一些锦上添花的功能。
积少成多，单个功能简单，时间短。但做多了，成本也就不低了。
6. 逻辑上的合理性
在产品设计上要注重逻辑的合理性。
我曾经做过一个产品，有个功能是分类筛选，我们根据内容类型把不同的内容进行归类，运营人员可以根据不同的分类筛选内容，也只能分类查看。
这样一来在后续的运营过程中，运营人员无法统筹查看全部的内容。如果想看一下最近更新的内容或者内容总数，只能各个分类查看后才知道，很麻烦，还挺考验人的记忆力的。
再举一个例子：
我曾经看过一个产品有个业务逻辑，两个管理模块A和B，A模块是B模块的内容源且有信息的第一管理权。
A模块的信息被下架后，B模块也同时下架，但是后台使用者却可以手动把B模块的信息再上架。这样就不合理了，内容源中已经没有该信息了，但是B模块却依然显示着。两者有时关联，有时不关联。
其实从技术上来讲，怎么做都可以，完全由人定义。但是如果逻辑上不合理的话，不仅开发过程中难以沟通，而且运营人员在使用过程中也会觉得很乱。
我之前讲后端产品受使用者干预性比较大，因为本身就是供他们使用的，所以我们在设计功能的时候也会收集运营人员的需求。在这个过程中有时候运营人员的需求是合理的，有必要的，但有时候也不合理，纯属那种拍脑门的决定。
这种拍脑门的后果就是对需求的定义随心所欲，造成的结果是功能很多，加大了开发量，某些比较小的功能即便运营人员让加了，但实际过程中基本不会使用。所以在这个过程中，产品经理就要控制运营人员的欲望。
逻辑上的合理性，也可以成为产品经理评判某个需求的标准。
7. 保持灵活性
之所以要做到灵活性，主要原因有两个：一个是对于运营需求的满足，另一个是某些功能需求的不确定性。
先说第一点：
我原来做个功能当时我们想把游戏官网的设计模块化，这样可以提高游戏官网上线的速度。
虽然从功能的角度来讲可以这么做，但是从设计的角度来讲并不合适，出于营销的目的，官网还需要展现游戏的个性化。所以当时我们做了样式替换的功能，运营人员如果不想使用模板，可以依靠替换CSS文件来做到官网的个性化。
有些功能的需求是不确定的。
比如说一个电台节目的简介最大字数该限制多少，说实话有时候我也不知道，运营人员也说不准。
如果一旦限制的字符比较短，那在以后的使用中发现不够用，还得修改。
要不就设置的非常长，比如说十万字，我们能够预想到肯定够用了。但这样就没太大意义。
这种时候我觉得可以不做限制，完全由人为定义就好。
做技术的人流行一种说法：
不要写死。
保持灵活性，也是为了避免某些地方写死而给自己造成一些麻烦。
给大家一个建议：因为大家的上班时间是固定的，周一到周五每天八个小时，某些功能如定时器很大程度上是为了让方便大家在非工作时间管理内容。
判定
某个功能如果完全可以在工作时间控制，而且即便发生错误影响也不大，那么就可以考虑保持其灵活性。
8.不追求完美
产品经理都会追求好的用户体验，用户体验的优秀很大程度上体验在细节上，可要知道在追求用户体验这条路上是没有尽头的。
其实不仅是前端产品，做后端产品也要控制自己的欲望。如果对细节要求的太多，磨的太细，恐怕你的产品就永远不要上线了。
我曾经就经历过这种情况，部门中的一个项目，开发测试完成，由于服务器的原因耽误了上线时间。在这个过程中产品经理就在逐渐优化细节，按理说也没问题，但是技术人员对代码的每次改动都意味着增加了一次风险，说不定会引起别的问题。
