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

我们假设这里的业务需求都是相对合理的需要实现的。那设计的产品方案需要对应满足这些业务需求，不能遗漏任何一个，同时也不能让产品方案内部出现重叠的功能，而是刚好完美的满足了业务需求，也使开发的系统内部达到软件工程上的最优解，这就叫满足MECE原则。

b）需求文档的书写

落实到具体的执行，需求文档中描述功能时也需要尽量满足这个原则。首先做到描述不遗漏，充分考虑异常流、特殊逻辑；然后需要语言精简客观，对同一功能和模块不必重复赘述，对于有耦合关系的模块，用语言上的逻辑因果、时间先后来进行描述。

（2）强化对状态的认知

对于一个后台系统，状态无处不在，灵活多变的业务需求是靠一张张数据库的表在记录的，除了业务数据的记录，状态是非常重要的基础。订

单必须有状态，用于区分不同业务环节：一个上线的活动必须要有状态，是进行中、已暂停、还是已下线；一个员工账号也要有状态，是启用中、禁用中还是已注销。

设计一个功能或系统通常需要先绘制流程图，而流程图中一个个状态的连接支撑起了整个功能设计的骨架，然后才是具体细节的设计。

如何正确的强化对状态的认知和理解，我大概总结以下几点：

a）状态的独立互斥

这点与上面说的唯一判断字段有点类似，但实际不是一回事。因为状态是用于描述不同业务节点的，每个状态要与实际业务的关键节点进行一一对应，状态之间不能出现二义性，否则会出现多个状态对应同一个业务关键节点，不但会造成理解混淆，还可能使系统做具体判断时出问题。

b）状态在时间维度上是稳定的

这点其实也很好理解，一个具体业务的发展是有阶段性的，而状态就是在每个阶段取一个值，各个值连接起来就串联的业务，但如果状态的值取在各个阶段的临界点，这就很不好描述业务了。比如一个运营活动，可以用“进行中”和“已下线”两个状态来区分发生和不发生两个阶段，这是合理的，但如果状态叫做“下线中”，这就不是处在一个稳定的状态，而像一个瞬时态，到底是上线还是下线，我们从状态命名中就感觉很模糊。

c）注意子状态和组合状态

当业务相当复杂时，一个状态下面还可以设置子状态，比如单据的撤销状态，可以包括用户主动撤销、系统撤销、人工撤销，用于区分具体是怎么被撤销的。

而组合状态的意思是在用户侧展示的状态不单是订单表里存的状态名称，而是一个组合状态，比如在用户侧显示“已发货”，其实包含了订单状态为“创建成功”、支付状态为“已付款”、物流状态为“已出库”。像比较复杂的保险订单状态，还会包含订单状态、支付状态、续保状态等，因此不能用一维的线性的来看待状态。

d）状态机的流转路线

状态机图的确定，基本确定了系统和功能主体结构，各状态之间的起点终点、流转路线、判断条件决定了功能的玩法和限制，状态机图是梳理并对照实际业务的必备工具。当业务有功能拓展时，首先查看状态机图是否满足，如何调整才能满足，已经涉及到哪些相关调整，都需要用到这个图。

e）合理的状态有利于数据统计

当状态的设计都按照上述原则进行，状态与状态之间非常清晰，这对数据统计是非常有益的。因为很多的数据统计都强依赖对状态的定义，如果你在做数据统计的时候发现很难准确的提需求，或者发现无法按照业务需要的维度来进行统计，可以反思下系统的状态是否合理。

（3）预留拓展性逻辑

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

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

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

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

（4）对变量的抽象

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

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

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

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

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

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

（编辑：核心网）

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