「产品经理」必备大招—不要写死

一年级的PM们关注点主要集中在交互+新功能，偏前端，喜酷炫。这是入门必经的阶段。

更高级别的PM关注信息元素、信息架构和产品功能流程，还有，技术架构。

这里的技术架构并不是指产品经理要了解后端用什么语言和框架？代码稳健性如何？而是指——考虑产品功能时，资深的产品能预见功能如何进化，从而反推当前的技术架构要有怎样的延展性从而cover产品的演进。

对于晋级中的产品经理来说，总得备几副良药，今天我们要说说这里面的大招之一，不要写死。

踩过坑的人都知道，不要写死，是解救线上BUG的大招，更是配置动态化的良药。

至于为什么不要写死，是因为：

第一，没有不会改的功能，迭代是永恒的话题。

第二，没有无bug的产品，哪怕测试100%通过，也不能保证线上不会引入新bug。bug是永恒存在的。

配置动态化，也是移动开发中的重要议题。尤其对于大型的APP，写死的代价是坑爹的，坑到产品都填不满。

我们来看一下常见的配置化大致有哪些类型。

第一，文字的动态配置。

道理很简单，你总不能为了改几个文字等到下一次发版吧？

第二，颜色的个性定制。

和文字异曲同工，配合运营和业务的需求，颜色灵活配置，想怎么换就怎么换好了。

第三，模块的灵活调整。

模块怎么定义，要看你负责的产品或者频道或者功能如何划分层次，如果频道以楼层为组织形式，你需要将楼层顺序做成配置化，方便产品验证怎么放置楼层的效果最好，诸如此类。这里要看具体的情况。

想象你的产品是乐高积木，乐高的哲学就是，统一最小模块的自由组合。

第四，功能的开闭自如。

这可是关键时刻能救命的设置。永远不要觉得测试没有测出bug线上就会运行自如了，要留一手。尤其是对于新增的有待检验的功能，在服务端做成开关。

第五，内容的无缝更新。

比较合理的服务端和客户端的分工是，客户端负责搭建架构，服务端负责数据\内容的下发和控制，客户端的架构是产品的框架，框架相对是稳定的，除非产品经理本身对产品的把握还不准，后端负责的是填充这个框架的所有元素，所有内容。 内容和元素是随时可变的，尤其是要考虑到能否平滑上线无缝更新或者修复。