1.业务价值分析
1.1to项目发起人，确认产品价值
价值分析的定义：确定系统要解决的关键问题，以及如何解决问题的价值，以及如何衡量业务的价值。
宏观：充分理解业务价值，可以系统性的了解到解决方案的IRO,因为企业业务中需要解决的问题有n多个，n个多问题中解决方案有些需要靠组织，靠培训，考流程都可以解决，有些是需要考系统去解决方案，所以这个时候就会出现的问题，那一种解决方案带来的成本最低，效益最高就是领导层最关注的问题，所以清楚知道这个可以锻炼产品经理思考问题，其实就是站在全局的角度去看问题。
微观：业务价值具象的说就是提高效率，降低企业成本，提高线索质量等等。
可能出现风险点：从下而上看问题，可能出现方向性的偏差，因为利益，思考的高度，深度等的不同，会导致每个人对系统的期望值是不一样的，直接上来从下而上，可能会造成方向性的偏差，导致产品整个价值点不突出，资源浪费，产品不被认可等局面。举个例子：领导想让你买一把刀，用来切西瓜，但是业务上也需要一把刀，但这个刀仅仅是用来切割纸片，所以同样的诉求，但是用处的不一样，要解决的问题不一样，就会导致需求测产生偏移，足以可见，价值分析十分重要。
业务干系人以及阻力点也是需要包含的一部分，笔者在公司做功能时候，遇到的最大的阻碍来自于线下经销商团队，因为经销商团队的个别造反团队的鼓吹，说上了该功能，意味着就是资源的收割，所以在产品设计的初衷就遇到了特别大的阻碍，所以在业务前期，最高领导层和骨干层，以及公司相关的培训部分，以及合作的经销商一起做了多轮的组织培训，到功能上线后，功能的敌对情绪相对能缓解
1.2价值分析实战
1.3项目想要达成的效果
按照SMART的原则分解目标，尽可能的可以量化。比如全量学习人员占比为80%，累计学习时长xx小时，这个具体的可以和业务方去商量。分析的维度尽可能穷尽又相互独立
2.业务分析
2.1业务中层调研
业务中层是知森林，也知树木的人，他们不但理解项目的业务价值，同时针对业务流程中相对清晰，所以要和管理层去确认系统之间组织如何流转，部门之间流程如何流转，系统的边界在哪里，系统的端到端的流程是哪里?
2.2业务中层调研输出
2.2.1业务层面
组织结构图：代表的是公司的组织架构，组织架构下是否有某些人有特权，比如一人身兼多职等异常情况，这个和权限功能相关，所以要重点关注。
跨职能流程图:代表的各个部门之间的业务如何流转，方便整体的理解整个业务架构包含那些内容。
系统与外部系统的关系：代表的是已有系统和现有新系统的之间的调用，整合关系。
线上业务流程图：跨职能流程图中的所有节点不一定是需要系统去解决的问题或者用系统解决投入产出比不如线下处理方便，或者是业务规范要求如此，所以针对该业务需要单独的标记处理。
子业务流程框架：跨流程图中的某一些子流程的详细流程。
关于业务流程分析不会画的可以参照上篇文章https://www.jianshu.com/p/4f247ae8eff0
2.2.2管理诉求
管理的诉求一般是比较笼统，比如他想看全国经理群的活跃程度，如果不活跃的话则会联系对应的商品经理联系大区经理，检查对应的问题，所以在领导层表述的指标比较泛化的时候，需要明确一下怎么把泛化的指标拆解成为可以衡量的目标的。
Tips
一定一定不要和中层管理者对需求的细节，但是思考的框架是需要界线。要找真的使用者，因为中间方的角色传达过程中有噪音，所以要和使用者传达。
一般这种问题不建议用太开放的方式去问答，因为一旦开放，则用户针对管理这块的报表则会无限扩大，所以我的一般做法就是先让业务部门输出现在需要手工出的报表的内容，以及报表中的计算规则，看的表具体频率，这样出来的报表需求八九不离十，不会出现伪需求的情况。
2.3业务细则调研
指的是实际使用系统的人进行调研，他们是系统的直接使用者，比如商务专员，仓库专员等等这类，他们对整个流程的各自负责的部分相对比较熟悉，所以搞清楚在访问的时确认2个事情：1.业务主流程、变体流程、分支的流程。2.确认业务场景、使用频次。比如涉及到这个流程中的人，事，流程的流转，以及流程中断后的处理情况。但是也要注意代入角色时不能完全被业务的思维左右 ，因为思考容易缺乏全局视角。
与业务层沟通的方式可以采用单点沟通（面对面沟通），线性沟通（业务有关联关系的，需要把双方当事人都叫出来），聊清楚之间的衔接关系，以及逆向流程相互之间的处理关系，但是如果这个逆向流程如果会给当事人造成工作量，这个时候都没有人愿意处理，需要叫关键决策人一起决策流程的处理着。一般业务具体的实施者，会直接罗列对应的产品功能，所以这个时候，我们应该搞清楚业务之间的逻辑关系，以及产品的使用功能，使用场景。比如表格中提到的要在企业知识培训中增加发朋友圈的功能，这个时候就要问下什么情况什么动机，什么原因想要发朋友圈，和朋友圈发微信的差别在什么地方，如果业务方回答不了这样的问题，那么可以基本判断该需求是伪需求。2.以功能的使用频次确认需求的真伪性，比如一周，一天之内执行该业务的次数，则也可以作为判断依据。3.业务流程永远大于页面功能，不要过早的陷入页面的细节中去，所以需要先完整的规划系统之间的业务流程以及外部系统的接口处理，用业务流程图先绘制走查，在业务流程处理的时候需要考虑哪一些流程需要固化在流程中，那些适合在线下做（线下表示私下进行，不进入系统流程），举例在我司规划经销商晋升体系，在晋升体系中各个职能会有对应的要求，比如初级业务员晋升业务主管时候，单独会考核单个产品的售出量，但是主管晋升副经理时候，不但考核本身的业绩，还需要考虑团队中的人员的稳定性，团队保持在6-8个人之间，当功能做出来，蒙蔽了，6-8，因经销商体系极其灵活，比如6-8的团队，可能一直在变，而且还有预入职的这些人，也是要纳入到体系，所以导致系统中标记不可以晋升的这部分人，所以产品业务流程在设计过程中一定充分考虑其他异常情况对系统的影响。4.业务流程确定后，需要在继续针对系统中的子系统的业务流程，没有问题就可以基于子流程确认对应的页面系统，以及页面跳转系统，在就是对应的原型设计。
2.4业务细则调研输出
业务详细流程，需要解决的问题点，
tips：业务具体实施者很容易起缺乏全局视角，所以一定要对实施者的内容进行降噪，过滤后方可进行实施。比如笔者在调研产品某个模块的功能使用情况时候，业务经理告诉笔者希望库存可以自由编辑，笔者问什么原因需要直接增减库存，原因是因为有些别的人会相互之间接库存。
要注意鉴别需求的提供者的个人特色，有些人是可以满口胡说，也可以是实干者，所以在需求讨论完成后，要针对需求访问着，进行多次的观察，如果资料不够夯实，则需要有一个补充着的角色。
3.需求分析产出物品
宏观：业务价值分析（项目背景，项目解决的事项，项目的目标），业务场景，业务架构。
微观：业务流程，线下业务流程，业务流程细则，页面关系流程，功能排期表，原型设计，场景分析，用户分析。
