需求接收，想方案，脑子里跑一遍全流程，走通之后再把场景补全上去。
第一个是统一规则，第二个是边界定义产品的价值观，第三个是调研报告
我需要重新调研
案例一：资金扣减跨经营组织
首先分类吧，当初需求不是这样的
作为我个人来讲我觉得这种方式会做的很恶心，甚至都违反了行业设计基础规范，我会提我个人建议；但是我们的项目既然是定制化的，甲方需要我就会集成上去，做出来效果会比较差，工期找项目经理评估，不喜欢扯皮，缺陷是我们负责的
在跟客户做新产品的时候我来，用户来告诉我整个需求；我来根据行业特性制定整个规则，把规则交易线作为中心化剥离出来；帮助企业做数字化赋能转型；有些点上可能会优化整个链路环节，打破原有用户习惯；但是原有的经验告诉我让用户来做整个规划，因为一些规则的没有想清楚或者一些细节点考虑不全；会让整个链路无限拉长，系统臃肿，项目最后基本都会往失控方向发展。
跟客户讲业务的时候可以使用耦合功能：
1.看一下我在执行一个操作的时候是否有其他功能模块共同执行这个操作，如果是共同执行，那就会有问题。
2.在执行操作时哪些状态字段会发生变化，如果第一个动作附属于第二步完成才会产生结果；那么同时做第一步操作，不同时间点做第二部操作；极端值就会出现问题，例如价目审核
3.第一个按照流程图，就是把每个功能点之间的耦合连接成一根线，比如用户新增加一个代客下单，下单之后就会走订单流程，订单流程会走售后流程，中间会涉及涨亏吨，订单结算，哪个截点增加功能，把这个生命流程走完，是否会有影响。这是流程支线影响，
- 第二种系统耦合影响，把相关的耦合性功能都列举出来，商品会涉及区域，区域又会关联经营，商品现有又有经营组织，积分管理，修改其中一个模块，把所有耦合线路上的模块都串联一遍找出2哥叠加项，把客户需求推翻
做产品设计的时候可以考虑二叉树：
正流程，异常流程，逆流程使用产品五要素
《主要看产品设计全局方法论》
1.产品层面的，高内聚低耦合，链路优化
2.行业层面，行业经验引导
3.产品本质定义角度，当我为了实现一个简单的功能需要去改造整个顶层的设计，产品战略层初衷
4.功能逻辑层面
5.统一性规则
外部层面：
需求不清晰：政策这块就是个典型的例子，当我们去全做的时候就是没有任何意义，因为做了还会在改，去做这个功能本身就是为了填写工时；我们去调研永远不知道客户后面还会有多少需求，因为客户也没有办法表达清楚它所有的规则；这个时候只能两种方式，第一种，直接封版本，第二种满足二期
产品设计设计规则：最底层表现层主要做页面和制定，表现层由框架层决定，框架层根据结构层指定，结构层是由设计产品的战略目标，战略目标是基于我京博本身的所处背景，产生的冲突，所以需要借助于产品实现商业目标；这就是我的决定没有和上层保持一致，项目就会偏离正常轨道，完成日期延期。而在开发团队尝试着把不匹配的要素勉强拼凑在一起的时候，我们真的有考虑过这是产品需要的还是业务方需要的；合理的需求我个人非常赞同，但是今天我们在讨论的包括和我对接的人是否能跟当初规划这个产品的人站在同一个视角去看待这个产品的设计，我打了一个问号。
我说的直白一点，做这个功能可能只是为了满足业务方的需求，但确实不是违背了产品的初衷，当初建设产品的人和业务方会有不同的诉求，我们需要克制；
第一方面，产品的边界定义性，我们是属于什么系统
第二部分，产品的统一性原则
第三部分，产品的设计高内聚低耦合
第四部分，层级架构实现
