洞察业务模式，我们就能理解企业决策的考量因素
把控用户需求，避免被用户牵着鼻子走。
业务模式反映的是企业的业务如何开展。比如如何获取资金、如何盈利，以及如何控制风险等等。
1、业务模式的洞察
对于厂家，往往需要大量运营资金，用于采购固定资产并规模化生产。这使得他们往往是负债经营，拥有较高的资金成本；同时，每个月巨大的现金支出（比如工资和材料采购款），使得生产厂家非常注重坏账的控制：
相对于经营亏损，更大的风险是现金流枯竭。
而经销商大多属于小微企业，仅负责特定区域的商品分销工作，资金需求相对较小；同时，由于顾客大多为合作多年的小店，因此坏账的风险相对较小。但是，市场充分的竞争，使得经销商只能通过低毛利、高周转的方式获得利润，因此经销商对毛利率非常关注。
曾经我在一家快消品SaaS公司担任高级产品经理。有一天，公司提出需要推出微信支付功能，我马上敏锐的意识到，这个功能更适合快消品厂家，但是并不适合经销商。
微信支付虽然降低了现金流的风险（微信收款使得偏远地区的收款更加容易，也避免了业务员持有大量现金），但同时降低了毛利率（对公支付有不高于千分之6的手续费）。最后，通过用户调研，确认了我的判断，这样就避免了研发不必要的功能。
2、用户心理的洞察
用户心理则反映了用户的愿望和担忧。
洞察用户心理，能帮助我们拿下订单，搞定干系人，顺利推进项目！
用一句非常经典的话来总结，就是：买得起、买得到、乐得买。
那么接下来我要说的是:0-1阶段系统架构初步优化性，每一步目的是什么？
一个系统从0-1大致会经历这几个步骤：
一、项目背景
二、商业模式（如果涉及）
三、核心业务流程
四、业务流程
五、涉及到系统
六、涉及到角色
七、涉及到实体
八、涉及到策略
九、系统架构
十、功能清单
十一、规划排期
十二、针对功能细致的流程、功能、原型的设计
一、项目背景
先思考：我们做系统为什么要做项目背景？
1）为了把握方向，别偏了呀
2）理清资源和限制，别超纲
3）思考理清项目的关键点
比如：我们要做一个电商系统，为什么要做电商系统呀？解决什么问题呀？有什么资源呀？有什么限制呀？这个项目如果要成功，那些点是关键点，是必须要要解决的呀？
把整个项目背景捋清楚了，我们做到心里有底。如西游记：我们要去西天取经，为了大唐百姓安康幸福。我们有齐天大圣这个能打的，也有唐僧肉身凡胎，要想把西天的真经取到，就必须解决取经路上的各种各样的妖怪。
二、商业模式
先思考：为什么要做商业模式？
1）比项目背景更细一点的掌握方向，明白我们设计系统的重点。
比如：拼多多，最初的商业模式可能是以廉价的商品去打开下沉市场，让更多对质量和品牌要求不高的人在系统上购买廉价的商品。这样我们就清楚我们在设计系统时的重点放在哪？我们应该减少商品的品牌漏出，突出价格优势，做一些占小便宜的设计等。
三、核心业务流程
先思考：1）为什么要做核心业务流程；2）应该做到什么程度？
明白我们主要是做一件什么事情？其他的工作都是围绕着这个事情做支持和服务的，以这个事情为中心向外延展扩散我们要做的所有的事情，找到一个主的前提。同时也是我们做版本规划的一个依据。
做到什么程度呢？做到可以验证商业模式能不能走得通就可以。
比如：抖音的核心业务流程就是：创造者创造视频-发布-内容消费者观看视频。其他所有的事情都是围绕着这个核心来做。
四、业务流程
先思考：为什么要做业务流程？
1）梳理出我们这个项目要做的所有的事情，定好我们的蓝图；
2）保证我们不会遗漏业务；
3）确定业务流程是正确的，无误的，防止已经开始做了，才发现业务流程错误；
4）为后来我们梳理系统、角色、实体、策略做基础
五、涉及到的系统
先思考：1）为什么要梳理涉及到的系统？2）应该做到什么程度？
1）确定需要的资源，有利于我们后期的工作人员安排
2）梳理整体信息架构
做到什么程度呢？
如果你的项目全部都是新系统，我们只需要罗列出系统以及系统主要承担的责任即可。如果你的项目还设计到原来的老系统，则需要列出我们需要和老系统做什么交互，需要老系统怎么配合？
这里说一个小知识点：如果涉及到的系统不是你负责的，在系统交互的时候，要按照对接第三方的标准去做，思考交互的部分，有没有一些限制？具体的字段，包含字段的限制和格式，是否必填，是整数还是小数。很多时候就是以为是一个公司的没那么认真，上线了就发现各种问题。
六、涉及到角色
先思考：1）为什么要梳理涉及到的角色？2）应该做到什么程度？
1）有助于我们后面按照角色梳理功能
2）分析角色的不同状态，也有助于我们设计系统的时候考虑的更加完善
3）有助于我们设计权限和账户体系
做到什么程度呢？
分析出所有的角色和角色的状态。这一步很多人只是列出来角色和角色承担的主要职责。但是我们列出角色的不同状态也是重要的一个工作。角色的状态分两种，一种是系统状态，比如在职、离职、隐身等。第二种是现实环境状态，角色在使用系统的时候，有没有比较明显的不同的状态。比如呼叫系统的：正常接听、喝水上厕所。
七、涉及到实体
先思考：1）为什么要梳理涉及到的实体？2）应该做到什么程度？
1）梳理实体有助于我们后面做功能梳理
2）有助于我们后面做模块化设计
做到什么程度？
梳理出实体，实体的所有字段，以及实体的状态。
八、涉及到策略
先思考：1）为什么要梳理涉及到的策略？
我们提前把系统中的策略和规则提前写出来，可以在系统研发之前就进入到一个初步判断的阶段。这个策略和规则研发容不容易实现，涉及到的角色和部门是否接受。反正我们闷声干活，到后期研发不可实现，或者系统做出来之后涉及到的角色并不接受，那个时候就难了。
九、系统架构
先思考：1）为什么要画系统架构图？
系统架构，也就是系统蓝图。把我们涉及到的系统，系统之间的关联和系统的主要功能用一张图画出来。有助于我们全面的理解我们的项目。做完这一步，我们脑子中已经有了整体项目的一个框架了，做到了心中有数。有助于我们的版本规划和研发节奏。也能帮助研发做开发的时候做参考，防止研发目前设计的技术机构到后期不适用修改成本过大。
十、功能清单
先思考：1）为什么要做功能清单？
功能清单，按照角色罗列功能清单，把一个角色涉及到的所有功能、每个功能包含的具体的实体，每一个实体的字段都需要罗列清楚，这样有助于我们发现，在所有的角色中那些模块是共同通用的，是可以通过权限配置的。
比如：客服和财务都需要订单模块，只是他们需要看的一些字段和状态不同。或者订单流转的角色可能经常变和不确定，是不是可以做一个订单流转配置模块？系统中有多个审核机制？是不是做一个审核流转机制？或者做添加商品时，目前知道的商品字段10个足以了，但是我们可能马上就要扩品类，那么是不是要做一个商品模版，可以按照商品类别给商品自定义一些字段。
并且把罗列出的功能清单可以给到对应的角色，确定功能是否正确和满足需求。
我们要清楚：在做后台系统的时候，我们虽然是按照角色去梳理功能清单，是因为基于角色梳理，可以方便我们梳理功能，并且不遗漏功能。但是我们的系统设计和研发的时候一定不是基于角色进行，而是基于功能进行，所有的角色都是有若干个功能组合成一个角色。
十一、规划排期
人不可能一口吃下一个大胖子，系统也不可能一次就做到尽善尽美，只能一步一步的走。做版本规划的时候分阶段制定，要清楚每一个阶段的目的是啥，根据阶段的目的和资源制定版本规划。
新的复盘纪要-初创
对整体复盘可以用PDCA，但这个模型被讲烂了，说个新鲜的。
当我们对事件整体复盘时，可以应用ORID，这个模型比较适合经验总结和成熟心态。使用的时候可以把PDCA的PDC放在ORID中O的环节。
Objective 客观：
事件中的人事物有什么？
哪个场景令我印象深刻？
我观察到了什么事实和现象？
Reflection 感受：
我当时的感想是射手那么？
我为什么会情绪波动？产生了什么情绪？
Interpretive 反思：
这件事的意义是什么？
关键转折电视是什么？
Decisional 行动
之后的行动是什么？
ORID区别于PDCA的点在于，不仅仅关注事件本身，可以把成熟心态方法化。
没有什么比时间更具有说服力了因为时间无需通知，我们就可以改变一切
——韩大师
