B端产品需求池中的泥沙
以下分述，B端产品在做功能设计的时候，需要从业务层面、用户体验层面、数据层面、架构层面去考虑的点。如有错漏，请指正。
01 业务层面
主要有业务流、功能操作流、异常事件流三种。业务流指业务场景中实际会发生的事件顺序。功能操作流，指在实际操作系统时，人为的操作流程。异常事件流，指在正常流程外会发生的异常情况，往往设计正常流程很简单，反而是5%的异常事件会导致增加70%的设计量。在思考业务层面的时候，流程图就是战术画板。
流程是为了达到特定的目标而进行的一系列有逻辑性的操作过程，而流程图是产品将其可视化的过程，以便于对其关键事件的分析，对整个事件的优化和重组。流程图很容易受个人的逻辑思维限制，而且很受个人基于对业务和场景的理解，这里要求我们具备测试的思维：
就是这样一种不断通过增量信息，对存量信息进行质疑和完善的思维。
分享我画流程图的经验和思路：
- 调研，对场景的调研，调研清楚正常的业务逻辑、异常情况、极端情况、隐藏情况（不问就不会知道的一些场景）
- 先画主流程，完成草图。之后用穷举法画枝干，然后考虑01判定，把所有判定逻辑理清。最后进行逻辑优化，解耦和耦合分支。
- 从大局出发重构，然后换角度和维度，打破原有设计框架，调整整个架构，最后考虑延展性，考虑除目前结构，未来可能出现的业务场景。（还有另外一种做法，是直接以未来角度画，再剔除，剩现有的流程。
一般秉持的三个原则：
- 没有最合理的设计，只有更合理的设计。（质疑驱动）
- 无法一步到位，当觉得自己一步到位的时候，绝对是有所疏漏。（墨菲定律）
- 有时考虑后台逻辑的时候，需考虑实现方式，但是业务的逻辑不代表代码实现的逻辑，设计的时候一定要以最简单的方式，不要为了追求代码实现逻辑而导致图变得复杂
例如：判断账号是不是EC或CL，下一步输出四种结果，EC、CL、都不是、都是。但代码的逻辑，是先校验账号是不是EC，输出0、1；再校验CL，输出0、1，然后组合01输出四种结果。
最后再推荐一个方法，穷举法
设计逻辑图的时候，把所有需要走流程的上游输入全部穷举，然后再走一遍，如果都通了即可。
例如：（EC和CL代表两种系统来源的用户）
非EC也非CL、EC未开通权限、EC已开通权限、CL未开通权限、CL已开通权限
既是EC又是CL，其EC未开通权限，其CL未开通权限
既是EC又是CL，其EC已开通权限，其CL未开通权限
既是EC又是CL，其EC未开通权限，其CL已开通权限
既是EC又是CL，其EC已开通权限，其CL已开通权限
02 用户体验层面
B端产品没什么好说的，观察业务员的操作习惯，考虑实际的操作场景便捷高效就行了，此类需求的优先级一般都是被抛弃的。
03 数据层面
这个比较重要，也比较容易被忽略。
1、数据来源：数据库表字段，这张表是否被其他模块消费，是否被其他系统同步消费，新增此数据对于其他模块是否为脏数据。采取什么方式解决脏数据，剔除？假删？过滤？
例如：物流系统，已关闭的物流追踪单，在统计签收率时需要剔除，在运费核算时需要被消费，两者消费的都是物流追踪单表里的数据。
2、脚本运行逻辑：
脚本的触发机制，脚本的运行开始和结束时间，脚本的监控日志，脚本的异常重启、脚本对系统的负载、脚本的延迟和并发问题。
例如：供应链系统，自动计算补货量的脚本，触发机制是预测销量已全量算出，结束时间必须为商家补货之前，监控日志可报警哪些计算失败，脚本因各种因素迭机需有重启机制，并发导致的重复数据需要处理。
3、数据更新（同步）是否实时性，同步时间的先后
被消费的数据延迟，是否造成的影响，哪些数据需要保证实时性，数据同步任务的运行先后时间，怎么安排合理的数据推送时间机制。
例如：仓库系统推送到补货系统的库存量需要实时数据，如果无法实时，需要保证推送时间>补货时间，保证补货时候的库存数据是最新的。
4、新老数据兼容（是否修复老数据）
新上线功能前后，存在终结态的老数据、未终结的老数据，新产生的新数据，新逻辑是否兼容三者，是否需要修复老数据。
例如订单系统，新上线的订单类型，原先的订单数据，是否需要重新跑新的订单类型判断逻辑，已有订单类型的数据是否需要改写订单类型。
5、数据状态的变化
瞬时性状态变化、延迟性状态变化，数据状态变化的前后置条件，数据状态的正常变化逻辑、不可逆逻辑和终止逻辑，数据状态的覆盖关系。
例如财务系统的数据状态，有未审核、已审核、已核销、已结算，这些状态的正常变化流程以及触发变化的前后置条件，已结算是否为终止态，是否可逆，是否可人为覆盖，什么状态可以覆盖什么状态。
6、消费此数据的其他模块和其他逻辑
若数据的定义发生改变，是否有其他模块或者计算公式，消费到此数据
例如：物流系统，签收时效从提货到客户手中的时效区分为，从提货到物流商，物流商到客户，两种时效，原先的签收率计算公式需要修改消费的时效字段。
7、多站点多系统多界面兼容
例如：电商有多个站点，主站，海外站，xx站……，每一个站点是否都有兼容；一个订单类型是否在WMS、OMS、TMS都有兼容；一个数据在系统的各个界面是否兼容。
04 技术架构和产品架构层面
在设计需求的时候，都需要考虑架构的限制，有些需求在架构的限制下是不合理的
例如：网站前端直接查WMS数据库返回的一个字段，在技术架构上因为多站点的原因，所有站点的OMS全部统一为POMS作为唯一的数据接口，所以任何一个站点单独与后端的WMS或者TMS对接都是不合理的
再例如：一个数据字段，其从技术的角度是需要有终结态的，但是产品的架构是希望其状态不被锁死，能够承接其他系统触发条件，使其回滚状态。
总结的这些点，可以作为一个自查表，在设计重要需求的时候，看是否有遗漏。欢迎补充。