从一个“设计型”产品经理，转变为“方案型”产品经理，通常只需要一段中后台产品经历就好了。
二者的差别就是，不再只说“我要xx”（潜台词怎么实现我不管），而是思考“如何实现xx”（潜台词是我已做可深入有理有据分析）。方案设计不仅体现在界面和交互的定义上，更体现在逻辑规则与整体架构的契合度上。相反，差的需求方案往往让开发过程反复拉锯，事倍功半。
需求与方案的融合，对团队和谐、产品扩展，大有裨益！是产品经理的价值体现之一。
案例：
在一个Excel导入功能的需求中，要导入的内容是不同重量区间对应的费用计算规则。因此需求文档中，要体现不允许重量区间交叉。
描述一：同一规则的任意两条数据，其重量区间不能有交叉；
看起来比较需求化，但实际上存在一个问题，就是没有定义什么样才算是交叉。
如果产品经理认为交叉是个白痴问题，无需定义（实际确实如此），但是开发的代码如果写错，就会出现对标不一致。
换句话说，产品理解这句话，开发也理解这句话的意思，测试也理解，但是没有确保大家的理解是一致的。
描述二：同一规则的任意两条数据，假设重量区间分别为a-b、c-d，那么若出现a<e<b、a<f<b、e<b<f、e<a<f中的任意一种情况，则视为这两个重量区间交叉。
但是实际上遇到的情况是，开发自己把自己搞糊涂了，最后开发看着描述三，才把代码写清楚。
描述三：同一规则的各条数据，每一条数据的起点或终点，都不能介于其余各行的起点和终点之间。
比起描述二，描述三的本质是一样的，但是你会发现，换了一个简单的描述方式，避免了一个先入为主的限制，给开发一些留白，又能不遗漏地去想自己的代码。
在一个页面当中，我们看到不同的位置摆放不同的元素，就像被割开一块一块的。这是由于HTML本身就划定了页面元素的坐标，因此在规划页面的时候就要遵从或利用这些规则。比如：在一个表单当中，当你要在二维栏中加一行描述的时候，如下图这样地设计就有点含糊：因为，页面的这个位置就像是一个两列的表格，而截图批注的内容却是在一个表格展示的。所以开发会困惑：你是要让重新插入一个新的区域做成一维单元格，还是在原来的表格中分两列展示呢？举个例子：客户等级规则设置功能，参数多，每个参数存在大于、等于、介于三种情况。常规的设计思路是不同的参数分开存储，也就是一条完整数据要分多条存储。比如，“id”为“001”的规则选择了三个参数，就要出现三行数据，且每一行数据都要对应考虑四组数据关系(大于、大于等于、小于、小于等于)。如下所示：这样的设计导致字段较多（列较多），且每个规则又会随着参数的增多而导致行数增多的问题。
由于这些规则要传递给另一个系统去识别和运算，那么就更显得冗余沉重，是否能更简单点呢？进一步调研获知，这个功能运算出来的数据本身就有结果偏差。因此对精确度的要求不高。于是，重新和业务用户沟通后，优化了数据存储方案为：每个参数都用一个列，而每列的取值约定双侧为闭区间，用逗号隔开。如果业务用户想表达大于100，那就写“100.01,”，即“大于100”约等于“大于等于100.01”。同样，小于80.01约等于“小于等于80.00”。因此只需要简单如下所示的存储结构即可（注意逗号是取值区间的分割符号）：结论：
尽量使用从简的设计方案。发现复杂的时候回到问题源头，结合业务场景灵活设计。比如：设计页面搜索项，搜索条件的多少和搜索速度并没有必然的线性关系。有时候将筛选条件细化，即增加筛选项，反而可能加快速度。这与筛选字段的索引情况、数据量、数据存储在表的结构（如分表存储）都有关系。比如：查学生姓名之前先选班级，会比不选班级的查询速度稍微快一点。因此,在设计方案的时候，并不能一概地通过减少搜索项试图提高搜索速度。
而应当根据具体的情况，结合一定的技术常识进行判断，而不是想当然地设计方案。以并发为例，后台的业务人员虽然不多，但是也常常会出现多个用户同时操作同一个数据的情况。比如：两个客服都看到了同一个待编辑订单，于是两人都要进行编进，碰巧时间相同，那么这就是会出现并发冲突。这种问题不仅会造成出错的风险，而且对业务人员是一种重复操作，浪费时间。因此如果遇到这样的场景，产品经理设计方案的时候就跟业务沟通，可能业务的一个简单的分组就化解了这种问题。又比如做推送机制的时候将数据分别推送给两个客服，或者直接将订单数据分组，不同组的客服分别处理自己组的。作为产品经理，需要在方案的时候告诉特殊场景或特殊操作，然后具体的处理机制由开发设计。跨境网站如果抓取订单，海外的平台采用的时区和我们的并不一样。并且某些平台在不同国家站点所采用的时区也不一样。所以在抓单时需要把订单所属的时区转换成北京时间，才能根据北京时间把订单抓回来。
了解后端产品知识之后这些就很容易，需要的话推荐一本书籍：举一个案例：A系统需要用到手续费，手续费比例是由业务自己配置的。在做这个需求的时候，了解到另一个系统已经有这套配置功能了,并且已经有了正常的手续费数据。那么A系统是继续在自己系统新建一个配置功能，还是创建接口从对方系统获取现成的呢?分析：这个问题的关键在于两种方案哪个综合性价比更高。接口获取案看似简单，但存在系统的耦合性，需要进行跨系统的联测；而新建看似复杂，但是只是一个简常规的规则配置，无需联调测试。因此，最后采用新建配置规则的方案。这说明：表面上看起来省事的方案，可能真实执行起来反而会麻烦。因此产品经理要充分思考，A/B方案对比后做出选择。
分享本文，并在公众号“唧唧歪歪PM”发消息“需求”，既可获取<需求探索>电子版。
