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

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

b）需求文档的书写

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

（2）强化对状态的认知

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

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

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

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

a）状态的独立互斥

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

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

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

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

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

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

d）状态机的流转路线

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

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

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

（3）预留拓展性逻辑

（编辑：惠州站长网）

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