万字干货 | 初级产品经理工作技巧指南

我之前经常遇到一种情况，当我做一个功能上线之后，业务方有时会再提一个与这个非常类似的需求，有时候仅仅只是改动很少的内容。如果在第一次设计时并没有预留可能的拓展性，就算只是很少的改动，还是要排期开发和测试，特别是有的功能还需回归测试，非常浪费开发资源，而且影响迭代速度。这时就考验在设计之初能否大概看出可能有的拓展性，在开发工作量几乎不变的情况下预留一些类似的逻辑，这样会非常便于类似功能的迭代。

举个例子，对于一个人工审核的结论页，有多种状态，每种状态下结论页的不同模块的元素、文案、以及对用户的触达文案，都是首次开发时配置好的。

首次开发时业务方提出有三种状态，上线之后业务方说要再加一种特殊的状态，如果事先在状态机中预留了待定的状态，只需要把该待定状态下页面的元素、文案、对用户的触达进行设置即可，改动的工作量很小，可以快速的上线。

不过值得注意的一点是，在预留拓展性时尽量保证首次开发的工作量影响很小，如果为了暂时使用不到的预留需求消耗过多开发资源，就有点本末倒置了。最好的针对复制一份代码、预留一个状态这种相似功能进行考虑。

（4）对变量的抽象

对变量的抽象是一种模块化思维，能够减少很多重复的工作量，提高后期的开发效率，我将分成两种情况来描述。

一种是当多个页面都用到同一个内容时，该内容应该被抽象为公共变量，供各页面调用。比如一个常用联系人组件包含姓名、证件类型、证件号码、性别、出生日期这五要素，那么可以把这五要素设置成一个公共变量模块，在不同产品下单需要用到时直接调用即可。如果有的产品下单时只需要用到姓名、证件类型、证件号码三要素，则可以把五要素的变量模块拆细为五个变量元素，这样可以达到最大自由度的组合。

另一种情况是两个页面绝大部分内容相同，只有几个元素有差异时，这几个有差异的元素应该抽象为配置变量，做成一个配置文件或者管理后台，这样在调整该配置时就不用再写代码。有的同学可能对配置文件不太懂，它可以理解为一段未被编译器编译的配置代码，是对一个软件运行时状态的本地储存形式，可以实现对软件灵活的实时调整。

比如：同样一个商品的详情页需要在A平台是红色背景，有评论模块，在B平台是绿色背景，不要评论模块。如果事先将背景色、有无评论模块这两个变量做成配置项，只需要更改配置文件或在管理后台做相应勾选即可。

（5）时刻考虑系统的灵活性

讲完两种基本的变量抽象方式，我再讲讲整个系统的灵活性。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!