之前写过一篇文章讲《实战经验｜我在做后端产品中收获的5条经验》，如果你没看过这篇文章，阅读本文前，建议先读一下这篇文章。这篇文章接着这个话题，继续分享我在做后端产品中收获的经验，这次主要讲四点。
在产品设计上要注重逻辑的合理性，我曾经做过一个产品，有个功能是分类筛选，我们根据内容类型把不同的内容进行归类，运营人员可以根据不同的分类筛选内容，也只能分类查看。这样一来在后续的运营过程中运营人员无法统筹查看全部的内容，如果想看一下最近更新的内容或者内容总数，只能各个分类查看后才知道，很麻烦，还挺考验人的记忆力的。
再举一个例子，我曾经看过一个产品有个业务逻辑，两个管理模块A和B，A模块是B模块的内容源且有信息的第一管理权。A模块的信息被下架后，B模块也同时下架，但是后台使用者却可以手动把B模块的信息再上架。这样就不合理了，内容源中已经没有该信息了，但是B模块却依然显示着。两者有时关联，有时不关联。
其实从技术上来讲，怎么做都可以，完成由人定义。但是如果逻辑上不合理的话，不仅开发过程中难以沟通，而且运营人员在使用过程中也会觉得很乱。
我之前讲后端产品受使用者干预性比较大，因为本身就是供他们使用的，所以我们在设计功能的时候也会收集运营人员的需求。在这个过程中有时候运营人员的需求是合理的，有必要的，但有时候也不合理，纯属那种拍脑门的决定。
这种拍脑门的后果就是对需求的定义随心所欲，造成的结果是功能很多，加大了开发量，某些比较小的功能即便运营人员让加了，但实际过程中基本不会使用。所以在这个过程中，产品经理就要控制运营人员的欲望。
逻辑上的合理性，也可以成为产品经理评判某个需求的标准。
2.保持灵活性之所以要做到灵活性，主要原因有两个，一个是对于运营需求的满足，另一个是某些功能需求的不确定性。
先说第一点，我原来做个功能当时我们想把游戏官网的设计模块化，这样可以提高游戏官网上线的速度。虽然从功能的角度来讲可以这么做，但是从设计的角度来讲并不合适，出于营销的目的官网还需要展现游戏的个性化。所以当时我们做了样式替换的功能，运营人员如果不想使用模板，可以依靠替换CSS文件来做到官网的个性化。
有些功能的需求是不确定的。比如说一个电台节目的简介最大字数该限制多少，说实话有时候我也不知道，运营人员也说不准。如果一旦限制的字符比较短，那在以后的使用中发现不够用，还得修改。要不就设置的非常长，比如说十万字，我们能够预想到肯定够用了。但这样就没太大意义。这种时候我觉得可以不做限制，完全由人为定义就好。
做技术的人流行一种说法，不要写死。保持灵活性，也是为了避免某些地方写死而给自己造成一些麻烦。
给大家一个建议，因为大家的上班时间是固定的，周一到周五每天八个小时，某些功能如定时器很大程度上是为了让方便大家在非工作时间管理内容。判定某个功能如果完全可以在工作时间控制，而且即便发生错误影响也不大，那么就可以考虑保持其灵活性。
3.不追求完美产品经理都会追求好的用户体验，用户体验的优秀很大程度上体验在细节上，可要知道在追求用户体验这条路上是没有尽头的。其实不仅是前端产品，做后端产品也要控制自己的欲望。如果对细节要求的太多，磨的太细，恐怕你的产品就永远不要上线了。
我曾经就经历过这种情况，部门中的一个项目，开发测试完成，由于服务器的原因耽误了上线时间。在这个过程中产品经理就在逐渐优化细节，按理说也没问题，但是技术人员对代码的每次改动都意味着增加了一次风险，说不定会引起别的问题。
除了用户体验外，功能也是如此。有些需求其实运营人员也没有考虑清楚，即便是提出来了，也是一时兴起，缺乏说服力。如果是这样，在满足基础需求的前提下，我们不妨暂且把新功能放一放。等最终考虑清楚了再开发，免得做无用功。
相比较前端产品，特别是APP，后端产品有个优势就是技术上的改动随时可以生效。而不需要用户更新版本，这对产品经理来说是好事，如果出错了补救的成本小一些。
4.产品功能的优劣会受数据规模影响拿我之前做过一个排序功能来说，如果想调整某个内容的顺序，可以手动输入序号，序号越大排序越靠前。虽然这样能满足需求，但是随着使用的时间久了，积累的数据越来越多，出现了一个问题。运营人员在使用过程中并不规范，他们输入的序号数值很随意，往往会把新增加的信息序号数值设置的很大。一共90条数据，但序号数值可能已经到了200。序号并没有连着，时间长了列表中的序号就会非常乱。
所以说功能设计的好坏也跟数据的规模有关，有些功能在数据少的情况下使用没问题，但是随着数据量增大就会暴露出功能设计上的缺陷。
结语之前行业内有一种议论说，有些产品经理非常不愿意做后端产品，我在工作经历也发现，确实存在这种现象，有的产品经理在接后台产品时就是抱着一种应付的态度。
有时候你会发现，在产品设计上虽然我们把功能都给完善了，在原型设计阶段不觉得有问题，但是等到产品上线后自己体验后却发现体验很差。后台产品也是要经过版本迭代的，如果体验太差的话那新版本迭代的速度就要快一些了。
#关于作者#云瑞，微信公众号：马虎眼，人人都是产品经理关于作者。片刻产品经理，五年产品人，走在内容社交产品路上，死磕产品设计，喜欢玩各种APP，玩桌球，打羽毛球，欢迎与大家交流。
本文未经许可，禁止转载。
