你有没有因为需求分析四个字，而感到头发日渐稀少？你有多少个失眠的夜，是在思考领导说的“把系统优化一下”这句简单的话？你又有多少次面对客户无休止的需求变更，而想要拔刀相向的冲动？
这一切的背后，到底是人性的扭曲，还是道德的沦丧？
朋友，你的福音到了，欢迎来到大型情感类专题：如何进行有效需求分析？
左脑喜欢逻辑，右脑喜欢故事；最好的陈述一定是起于故事，终于逻辑。
今天的内容，就让我们从一则生活中的故事开始吧。
生活故事
有一天夜里，资深需求工程师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。
这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”
没想到小孩不依不饶，继续哭闹着。不久老余被吵醒了，他安静地走到客厅，找了一小会儿，果然没找到饼干。
他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。“小子，没有饼干了，吃点面包填肚子吧！”老余边说边把吐司塞到小孩手中。
果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又归了平静。
分析
从故事中我们可以看到：
- 小孩子提了一个需求，即要吃饼干。
- 而妈妈考虑的是，家里没有饼干了，并且是半夜，想要实现这个需求的话，肯定还要起床下楼，并且找到24小时营业的便利店。这个实现成本太高了，于是断然拒绝。
- 而爸爸则透过现象看本质，小孩子半夜要吃饼干，这并不一定真的是想吃饼干，极有可能是饿了。这样的需求，可以通过其他更易实现的方式更好地解决。于是，随手的两块吐司面包，就让这个家庭又重归了平静。
典型的三类人群
孩子=客户
那你也许会问，为什么小孩子不能够直接说“我饿了”，而是一定要“吃饼干”呢？
因为，这就是典型的客户思维方式。
我们先给出这样一个结论：在方案级的探讨，客户是感性的；而在问题级的探讨，客户是理性的。
你是否有过这样的经历：
客户说，xxx功能我们想要，你给我们加一下吧。
这样看似非常明确的需求，但往往很容易发生颠覆性的需求变更，到最后客户自己明确说明的这个功能，自己又把它给亲手砍掉。原因可能很简单，也许就是三个字：不好用。
这种经历，能给我们带来什么样的启发呢？
这句话很关键：客户是问题专家，而非解决方案专家，他提出的方案未必能够完美解决他遇到的问题。
小孩子提出想吃饼干，这是一个方案级需求，这极有可能是因为小孩子脑海中突然回忆起了饼干的味道，并且小孩子才3岁，客户的感性思维，在这里体现的淋漓尽致；而小孩子饿了，这是问题级需求，这才是需求的本质。
我们可以看到，以“吃饼干”这样的方案来解决“饿了”这样的问题，显然是不合适的。
我们再来说客户的理性一面，当你跟客户沟通这样的话题：“在当前工作中，有哪些方面你会觉得有困难呢？”
这个时候，你会发现，客户表达出来的内容，就像滔滔江水、连绵不绝，如黄河泛滥、一发不可收拾，并且还会加上各种事例来佐证他的观点。如果可以，他可能更希望拿个U盘，把他遇到的这些困难直接传到你脑子里。
而这些内容，往往都是理性的，都是客观存在的事实。当然，这也是我们需求分析的突破口，我们后面也会提及。
妈妈=程序员
典型的技术思维，关注的是“方案级需求”，即吃饼干这个方案能否实现。
我们脱离这个故事，在我们的实际工作中，究竟什么是技术思维呢？
- 关注点：实现方式、技术架构、技术价值、开发成本。
- 定义：从功能和工程实现出发，在满足产品需求的同时，寻找可复用技术架构和低开发成本。
爸爸=产品经理
典型的产品思维，关注的是“问题级需求”，即小孩子遇到的本质问题是饿了。
同样，我们看一下在实际工作中，产品思维是怎样的定义？
- 关注点：用户价值、使用场景、商业价值、业务闭环。
- 定义：从用户价值出发，在满足商业战略和业务目标的同时，寻找产品路径满足用户需求。
需求打开的正确方式
通过开篇生活中的故事，我们可以体会到，要做好软件需求工作，业务驱动需求思想是核心。而作为产品经理或者是需求分析师，我们不是简单的“需求传递者”，我们是“问题解决者”的角色。
那么，在与客户进行沟通时，需求打开的正确方式是怎样的呢？
澄清问题→了解背景→建议并确定解决方案
1. 澄清问题
- 想要解决谁的，什么问题？
- 用户现在遇到这个问题会采用什么样的解决方案？
- 这个问题中有需要进一步细化和明确的概念吗？
2. 了解背景
- 该需求谁使用？什么时候使用？具体怎么做？
- 有需要澄清的业务术语吗？它们的格式是什么？
- 不做谁生气？多久生气一次？多久用一次？
3. 建议并确定解决方案
- 要解决这个问题有哪些可行的解决方案？
- 这些方案的实现成本分别有多大？
- 你觉得哪种最合适？
- 该解决方案对用户而言有什么优缺点？
- 有其他需要挖掘的需求吗？
需求全景图
写到这里，不由地想起之前面试的经历。
面试官问我，一个产品研发完整流程分为几个阶段，每个阶段的占比是多少。
我当时做了这样的回答：一个完整的产品研发流程中各部分的占比，大概50%做需求，30%做开发，20%做测试。
然后，面试官紧接着问我，既然需求分析占比这么高，那说一下需求分析的方法论吧。
我突然发现自己对于这方面方法论的研究几乎空白，只知道最终的产物，是利用Xmind列一个功能清单，但至于这个功能清单是如何得出来的，我当时的认知是具体问题具体分析。
当我看到《有效需求分析》这本书中，提出了“需求全景图”的概念时，真犹如哥伦布发现了新大陆一般，不禁惊喜万分。需求全景图，包含了诸多内容，但自己感触最深的还是“功能主线”这一项，毕竟我们每天都在与“功能”打交道。
回到我面试的那个问题，最终的功能清单是如何得出来的呢？
最好的思考角度，就是厘清系统中的所有功能是因何而存在的，这也正是我们前面所说的，需求分析的突破口。
功能主线的梳理，无外乎以下三个角度：
1. 业务支持
- 固化优化业务流程，因此业务流程是核心；
- 业务延伸到新的通道（诸如手机端），这从本质上来说也是一种流程的重构，核心还是业务流程；
- 将个人能力转化为组织能力，这种能力存在于具体的业务场景中，因此“专家场景”是核心（后续的文章会详细论述）。
2. 管理支持
- 事前风险避免，通过增加管理流程；
- 事中风险控制，通过“规则”和“审批”；
- 事后总结优化，通过“数据分析”。
- 前两种通常会在业务支持分析中统一处理，第三种则应该独立进行分析。
3. 维护支持
系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也都需要有相应的功能来支持。
当然，功能是我们的最终落脚点，但需求分析不单单是功能，这里先把需求全景图展现给大家吧：
结语
需求不是一场简单的头脑风暴，也并非高深的诸如马斯洛需求层次理论，更不是领导交代的任务、运营提供的方案或是客户要求添加的功能，需求是一项系统的工程，更是一门生活的艺术。
我们经常在电视中看到，古代的那些位高权重的大臣，几乎每一个都是需求分析高手，没事就在那犯嘀咕：“皇上今天说的这句话是什么意思呢？”
由此可见，需求分析不仅仅是软件领域的方法论，更是存在于我们生活的方方面面，让我们一起探索需求全景图的奥秘吧！
注：我们探讨的需求分析，是基于B端产品。当然，C端的小伙伴也是可以参考的。
欢迎来到大型情感类专题：如何进行有效需求分析——价值需求篇！
所谓价值需求，从结果来说，是我们在项目方案或者PRD文档中所编写的愿景/目标；从过程来说，是我们与客户达成合作的关键步骤，这些内容可以说是组织应用类软件系统需求的灵魂和方向。
但很多时候对于这些内容的定义往往是空洞无物、混沌不清，抑或是放之四海而皆准的描述。这也正是导致项目范围蔓延，无底线需求变更的罪魁祸首。
今天，就让我们一起来探究一下价值需求背后的秘密吧！
内容回顾
本篇文章的内容，会涉及到前篇文章的部分观点，我们先来回顾一下：
- 客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题；
- 技术思维关注点：实现方式、技术架构、技术价值、开发成本；
- 产品思维关注点：用户价值、使用场景、商业价值、业务闭环；
- 需求打开的正确方式：澄清问题—>了解背景—>建议并确定解决方案。
（如果对这些结论感到陌生的同学，可自行翻阅前一篇文章，我会在文章结尾处加入跳转连接。）
问题场景
既然需求打开的第一步骤是澄清问题，那我们就从问题场景开始谈起吧。
参与过用户调研的同学，对这个环节肯定深有体会，有时候用户口若悬河地说了一大堆内容，然而对我们有价值的信息却寥寥无几。
尤其是跟管理层进行沟通时，有哪位同学获取过类似这样的反馈：“我们要打造一套先进的信息化系统，有效地推进管理的提升！”
面对这样的沟通记录，你有何种感受？反正我是如坐针毡、如芒刺背，再加一个词的话，如鲠在喉…
我们上篇文章表达过，指望用户把需求讲清楚是不现实的。既然如此，那我们就需要一些沟通技巧，来引导用户表达出有价值的信息。正所谓一切知道为什么的人，都自然知道怎么干。想要引导沟通，关键就在于搞清楚用户提出需求的背后原因。
用户主动提出项目需求的原因无在乎两种：一种是外因触发的，通常问题不太清晰；另一种是内部提出的，通常已经有了基本思路。为什么这么说呢，我们接着往下看。
外因触发
我们这里先给出结论，外因触发的常见触因有三种：参观考察、竞争对手动向、热点及新技术趋势。
1. 参观考察
作为企业的领导层，经常会有全国各地到处参观考察的机会，而每次归来之时，往往就会带回一些新的想法和思路。但领导嘛，一般不会跟你说太多“为什么”的内容，结果就会导致我们接收到的需求，很容易被抽象成高度总结的定性描述。
例如：“明年我们计划投资一笔钱，打造一套为企业量身定做的、达到国内领先水平的信息系统。”
这种情况下，我们应该还原用户观察的内容，使问题场景化，以便理解他的目标。我们可以发出类似这样的提问：“听说上次您带队出去考察，这么好的学习机会很遗憾自己都没机会能参加，您能和我们分享一下有哪些收获吗？”
放心，领导的话匣子很容易会被这样的提问打开。那么在接下来领导的发言中，一定要注意“xxx能够做到怎么怎么样，我们呢？”这种经典句式。“xxx能够做到怎么怎么样”就是新的预期，“我们呢”就是现状，预期与现状之间存在差距，而这个差距就是需求！
需求触因：参观考察—>应对策略：分享收获。
2. 竞争对手动向
当竞争对手新动向带来一定威胁和挑战时，就会催生出系统升级、建设的需求。
但这种情况下，用户往往只知道不改变就会被淘汰，但究竟如何改变，用户通常更加没有清晰、完整的思路。可能提出的原始需求是类似这样的：“我们的竞争对手都上ERP了，我们也打算上一套，你来给我们看看应该怎么做吧。”
针对这种情况，关键在于我们帮助客户完成“竞品分析”。一份基于客户所在行业，根据不同规模、不同发展阶段、不同核心商业模式分类，再加上对每种类型的企业能够通过ERP改进的关键业务问题、业务机会进行场景化描述的《竞品分析报告》，将会是企业的一剂良方！
需求触因：竞争对手动向—>应对策略：竞品分析。
3. 热点及新技术趋势
如何有效利用各种新技术来提升企业的竞争力，这是各类企业组织面临的重要课题。但对于新技术的价值、用途的理解却也是参差不齐的。
最终的需求很可能演变成，为了使用新技术而使用新技术，将新技术本身作为目标。而这种需求的落地，可能并不会给企业带来实质性的价值，或者是带来收益会远小于付出的成本。
例如领导在参加完大数据的交流会议之后，会提出类似这样的需求：“我们要充分利用大数据技术，全面提高企业管理水平。”而实际上，可能领导利用大数据，只是想解决一下销售数据统计失真的问题。
这种情况下，找到新技术与企业的结合点尤为重要。领导之所以能够成为领导，必然会有他的过人之处。当领导在学习新技术的过程中，一定会想到与企业相关的“一二三”。这时我们可以采取“分享理解”的策略，让领导首先谈一谈自己对于新技术的理解，然后我们再形成与之匹配的解决方案。
提到这个话题，不由地联想到2019年最火的新技术趋势就是5G的应用了，5G必然会催生出众多的新需求。如果有同学对5G有兴趣的话，欢迎阅读我的另外一篇文章，在本篇的结尾处，我同样会加入跳转链接。
需求触因：热点及新趋势—>应对策略：分享理解。
内因触发
如果项目源自于内部的发起人，那么通常用户会有相对成熟的思考，针对这种情况，可以通过有效的访谈，来识别“问题场景”。我们上篇论述的需求打开的正确方式，足以应对这种情况了。
如果再补充一点的话，访谈的重点可以通过三个步骤来进行，即还原表象、分享原因、共商决策。
机会场景
我们上文提到了，在“问题场景”下，需求就是预期与现状之间的差距。那如果用户对于现状满意呢？这个时候，用户也并非就是完全没有需求了，只不过此时需要我们提出新预期来让他产生需求，这就是“机会场景”。
你也许会说，项目启动的第一环节，不应该是销售与客户建立合作关系么，这不是我们产品的工作范畴呀。但往往很多时候，销售只是负责与客户建立初步合作关系，而与客户进行深度的沟通，正式达成合作，通常还是在于产品经理这个环节。
我的理解是这样的：销售负责“眉目传情”，将客户勾搭过来；产品负责“一锤定音”，敲定最终的合作关系！
发现新机会的思考维度与我们上面讲到的，解决“问题场景”的思考维度有相似之处，我们这里，就直接给出结论吧。新机会往往来源于以下三个方面：
（1）新业务
- 追标杆：行业标杆在发展过程中，有何可借鉴点？
- 赛同行：竞争同行有何借鉴点？
- 借他业：其他行业有何借鉴点？
（2）新技术
- 新技术能够解决哪些当前无法解决的业务问题？
- 新技术能够带来哪些新机会？
- 当前新技术应用有何借鉴点？
（3）新人群
- 客户的决策层、管理者是否出现了新人群？
- 客户员工群体有了什么变化？
- 客户的客户群体有了什么变化？
新业务与新技术，我们不再赘述，对于新人群的话，其实也很好理解，我们经常以80后、90后、00后这种维度来对人群进行归类，每一类人群确实有自己独到的特性，这些特性也必然会带来新的机会场景。
小结：需求的定义
从上述的内容中，我们可以思考一下，用户的需求到底是什么？
书中从心理学的角度，给出了一个很有意思的定义，分享给大家：需求=预期-现状。即需求就是用户预期和现状之间的差距。而这种差距，无非就三种结果：
- 预期高于现状：也就是用户不满于现状，希望自己的业务、管理能够开展的更好，甚至有明确的改进预期。这种情况下，用户通常会比较积极地配合需求调研，只要调研方法得当，就能够很好地识别出目标；
- 预期等于现状：这种情况下，他们通过对变化表现的不积极，基本上很难用直接的调研方法来获取需求；
- 预期小于现状：这些用户会常说“想当年我们多么混乱，现状这么好”。这种情况下，用户甚至会抗拒变化，对需求的调研表现出消极的态度。
当用户的预期高于现状，那么他会意识到“问题”所在，进而会主动提出需求，我们需要做的，就是把握用户的问题，这就是我们所说的“问题场景”；当用户的与其等于或小于现状，我们就要想办法提高用户的预期，也就是我们所说的“机会场景”！
干系人
奇虎360的掌门人红衣教主周鸿祎说过：商业的本质就是释放人性。
所以说，一个项目的最终落地，必然绕不开“人”这个环节。但是我们必然满足不了所有人的需求，例如一个信息系统，是方便了领导层及时便捷地获取信息，但往往付出的代价就是执行层增加了采集数据的工作量。
一个项目的成功推进，关键在于我们要说服“stakeholder”。这个词是什么意思呢？
stake表示赌注、堵金、筹码，holder意味持有人、保管人。这个词提醒大家，项目是一个博弈游戏，重要的是获得足够的筹码，也就是需要找到关键的筹码人，赢得足够的筹码就可以赢得项目，并且你也不可能获得所有的筹码。
那么stakeholder是谁呢？有人说是老板，没错，大部分情况下是老板，但绝不仅仅是老板。我们可以从两个维度找到stakeholder：
（1）根据目标识别干系人。
- 部门是否与目标直接相关？如果是，那么部门负责人为关键干系人；
- 相关部门是否有异地分支部门？如果是，那么分支部门也是关键干系人；
- 是否存在资深副职负责人？如果是，该副职也属于关键干系人。
（2）根据风险识别干系人。
- 是否对一大批基层带来负面影响？如果是，该基层用户也是关键干系人；
- 是否具有一票否决权的评价值？如果是，该评价者也是关键干系人；
- 是否技术实施存在高风险？如果是，开发团队也是关键干系人。
干系人分析
找到干系人之后，我们要从两个角度对干系人进行分析：一是他们希望系统解决什么问题、提供什么业务支持；二是他们希望避免出现什么样的负面影响。这样才能够立体地完成干系人分析。
在描述分析结果时，可以包括两个部分：第一部分是干系人关注点/担心点，也就是WHY的部分；第二部分是相应的功能需求，也就是HOW的部分。
结语
价值需求是一个项目的flag，希望通过今天的内容，能够让大家对于价值需求有一个相对清晰的认知。
最后再送给大家一段话，高管关注点的八字真言：“问题、机会、成本、效益。”我们下期不见不散！
如何进行有效需求分析（3）：流程篇
内容回顾
我们近期的文章，是关于需求分析的知识体系，同样，我们还是先来回顾一下上期的关键知识点：
需求的定义：需求=预期-现状。
外因触发需求：
- 参观考察—>应对策略：分享收获；
- 竞争对手动向—>应对策略：竞品分析；
- 热点及新趋势—>应对策略：分享理解；
内因触发需求—>应对策略：还原表象、分享原因、共商决策。
机会场景往往来源于以下三个方面：
- 新业务；
- 新技术；
- 新人群。
stakeholder：项目是一个博弈游戏，重要的是获得足够的筹码，也就是需要找到关键的筹码人，赢得足够的筹码就可以赢得项目，并且你也不可能获得所有的筹码。
上期内容主要是谈论了宏观层面，也就是目标愿景树立的方法。当确定了项目的方向之后，我们就需要逐步深入，从抽象层逐渐将精力转移到具象层。今天就让我们一起解开业务流程的奥秘吧。
身世
我们都知道企业到处存在各种各样的业务流程，但这些流程为何而存在呢？一则小故事，带你探究业务流程的身世之谜！
改革开放伊始，有一个微不足道的小人物，并且他还是个文盲，7岁开始在路边捡烟头挣钱，9岁学徒经商，后来为了维持生计，买了点葵花籽炒了去卖。这个时候，所有的事情都是他一个人负责，自己进货、自己销售、自己发货、自己记账…
他也不知道从哪里偷学了一门手艺，炒出来的瓜子竟然非常好吃，一嗑三瓣，满口清香。就这样，他的生意越来越红火，一天的瓜子可以卖出上千斤，自己一个人显然忙不过来，于是请来了一些人当帮手。
他叫来了张大爷，让他帮忙订货、发货、管理仓库；叫来了大姑，让她帮忙记账、收钱、管钱。然后呢，交代张大爷必须等到大姑收到钱，将收钱证明交给他，并且检查过后才能发货，不然就会出现问题。
然后又过了一段时间，营业额越来越大，这个小人物觉得大姑虽然是亲戚，但他万一眼红，在账上做做手脚拿走一些钱也是麻烦事。因此，他又喊来了大姨，让她们一个人管钱、一个人管账，互相监督。
再后来啊，这个小作坊日益发展，开始要和税务局打交道了。但大姑的水平，能够记账就不错了，根本没法做这种事。怎么办呢，只好再找一个专业的会计来负责这件事了。
最后，由于这个小人物雇佣的员工达到了12人，还引起了他究竟是不是资本主义的轩然大波……
不知道大家有没有猜到，这则故事的人物原型，正是改编自我们历史上赫赫有名的瓜子大王-年广九。那个时代，是上一代人刻骨铭心的激荡时代，也是值得我们当代每个人用心感受的波澜壮阔的历史。有兴趣的同学，可以去阅读一下《激荡三十年》，其中的故事，可谓是精彩纷呈。
让我们回到主题。从故事中我们可以看到，流程产生的原因在于分工，而分工产生的原因，又可以分为三种：规模、风险、专业。
一个人忙不过来了，请了一些人当帮手，这就是规模扩大产生的分工；担心大姑在账上做手脚，于是请来了大姨，让他们一个人管钱、一个人管账，互相监督，这就是风险产生的分工；与税务局打交道，大姑做不了，又找了一个专业的会计，这就是专业产生的分工。
分工之后呢，张大爷负责订货、发货、管理仓库；大姑负责记账、收钱、管钱等等，各司其职。此时，就为张大爷赋予了“仓库管理员”的角色，而张大爷负责的订货、发货、仓库管理这些事情，就是我们所说的“活动”的概念。
而张大爷与大姑之间，并不是完全独立的，他们是存在协作关系的。故事中也提到了，大姑收到客户的钱，将收钱证明交给张大爷，并且检查过后才能发货。这个环节，向我们阐释了“协作”、“产物关系”，以及“规则”、“审核”的概念。其实了解了“协作”，也就厘清了在流程图中各个活动之间的那根连线。
对于协作过程，并非是一成不变的，例如有些客户是VIP客户，可以先不支付费用就可以发货，这就是流程的“分支”。但不支付费用就发货的，肯定会出现有问题的时候，这个问题就是我们所说的“异常”。
我们来总结一下，这则小故事为我们带来的启示如下：
- 分工产生的原因：规模、风险、专业；
- 业务流程三个管理要素：审核、规则、异常；
- 业务流程五个基本要素：分工、活动、协作、产物关系、分支。
姻缘
我开篇提到了，自己仅仅限于会画流程图，现在想想，我画流程图的方法，与业务流程的知识体系，有着千丝万缕的联系，或者说，是业务流程知识体系的冰山一角。但幸好，我的方法没有什么大的纰漏，针对具体问题的解决，还是行之有效的。
具体的作图方法包含了以下五个步骤：
- 整个流程的起始点是什么？整个流程的终结点是什么？
- 在整个流程中，涉及到的角色都是谁？
- 在整个流程中，都需要做什么事情？
- 做每一件事情的条件是什么？
- 分别产出什么结果？
（此方法的具体实践过程，我在另外一篇文章总结过，我会在文章结尾处加入相应链接，欢迎阅读）
我们与之前小故事得到的启示进行比对，可以找到以下的对应关系：
- 在整个流程中，涉及到的角色都是谁？对应：分工、协作；
- 在整个流程中，都需要做什么事情？对应：活动；
- 做每一件事情的条件是什么？对应：规则、审核；
- 分别产出什么结果？对应：分支、异常、产物关系。
其实我们细品的话，业务流程的八个要素，都能够在画流程图的方法中找到对应关系，但唯独流程的起点与终点，我们还未涉及。想要了解此处的猫腻，我们还得从企业价值，这个话题说起。
我们先看一个定义：企业或组织的核心价值在于响应客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业/组织带来价值。
企业、组织中的每个成员的工作都是属于某个流程的，从这个定义中，我们得到以下结论：业务流程的起点即外部服务请求；业务流程的终点即满足服务请求。
其实，判断流程的起点与终点并没有我们想象的那么简单，不信的话，我们一起来做一下这道选择题：
用户投一份意外保险，业务流程的终点是什么？
A、保险到期；B、保单出险；C、保单生效
面对这个题目，有没有让你回想起上学期间，期末考试的纠结感？然后，当我公布答案为”C”的时候，又有多少同学是一脸问号的表情的？如果你正是如此，欢迎在留言板一起吐槽~
这道题的解析过程如下：
我们上述，给出了结论：业务流程的终点即满足服务请求。
单纯地从这个结论来说的话，选择C是没有问题的，但是A和B为什么不对呢？其实也很好理解，试想一下，客户给自己投一份意外保险的目的是什么呢？不可能是为了出险吧？应该没有人买保险，是为了使用~所以B是不对的。至于A这个答案，我们类比一下登录流程也就很容易理解了，没有人会把用户退出系统，当做登录流程的终点吧~
对象
此“对象”，也许非你想的彼“对象”，我们要说的是“面向对象”的这种思维方式。
写到此处，不由地想起，自己之前写PRD文档的经历。当时一个功能模块的文档，写了100多页，写起来想死，改起来更想死，关键是，看的人同样想死……所以，为了活着，我们开发直接告诉我，他决定不看文档了，以后只看原型……
当时我问我们领导，文档有没有必要写这么复杂时，我们领导回复我：“当然有，这份文档是公司领导层做需求评审的依据，是开发团队将来开发产品的标准，同时我们做项目交付的时候，这份文档也是交付内容之一啊。”
我觉得这不是我们把文档写复杂的原因，而恰恰是致使文档复杂的“病因”。领导层关注的是方向，并非细节，所以面向领导层时，有时候一个思维导图即可；面向客户的话，他才不关心你是怎么实现的呢，他想要知道的，是这个产品怎么用，对应的应该是《用户使用手册》。而PRD文档，我们可以定义为就是给开发团队造产品的“工程图纸”！面向对象带来的是简洁和高效！
同样的，对于流程图来说，也应该采取面向对象的思想来将其划分。这里，我们就直接给出结论，业务流程可以分为以下四种：
（这是我手动码出来的图！）
优化
最后，我们再来说一个话题：业务流程的优化。
有很多同学跟我探讨过这样的问题：“我们老板说让我优化一下我们产品，这个该如何下手是好啊？”我也回复过很多同学：业务流程的优化，是产品优化的重要一环。今天我们来具体讨论一下，该怎样优化吧。
医院的流程想必大家都深有体会，幸亏每个医院都设置了“急诊室”这样的环节，不然，一部分病人可能医院的流程还没走完，自己就先走一步了~
我们来吐槽一下医院排队这个环节：找服务人员开单，找收费人员收费，检查科室则是每个体检项目排队一次，最后还要排队到服务人员那里拿最后的报告！其中最令人发指的，就是开单和收费需要分别排队，这简直****（自行脑补）。
面对这样的场景，该如何优化呢？其实优化策略思考起来也很简单：第一种就是，我们把开单和收费的环节整合在一起，开完单子直接缴费，无需二次排队；第二种，我们可以把人工收费改成IC自动收费，大大提升效率。
我们将其上升到方法论的层面，总结一下，业务流程的优化策略即为“ESIA”。
- Eliminate：即清除无效。找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除。
- Smiply：即简化高频。对频率最高的环节进行优化，流程效率将提升。
- Integer：即整合依赖。将相互依赖的环节整合在一起，提高效率。
- Automate：把人做起来麻烦的事，让电脑来干，提升效率。
当然，一切的优化都必须考虑实际的场景，关于场景这个课题，就让我们下一篇文章再细说吧。
如何进行有效需求分析（4）：场景篇
内容回顾
上一期我们讲述了业务流程的相关知识，按照惯例，我们先来一起回顾一下：
- 分工产生的原因：规模、风险、专业；
- 业务流程三个管理要素：审核、规则、异常；
- 业务流程五个基本要素：分工、活动、协作、产物关系、分支；
- 业务流程的起点即外部服务请求；业务流程的终点即满足服务请求；
- 业务流程的优化策略：“ESIA分析法”。
业务流程与业务场景是环环相扣、层层递进的关系，在开始本文的正题之前，先把这样两句话送给大家：
- 业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动；
- 管理层用户关注事到事的逻辑，他们关注的核心是业务流程；而操作层用户则更关注人到事的逻辑，他们关注的核心是业务场景。
思维方式
一切行为的改变，都源自于思维方式的转变。我单独将这两句话做成一张图片，也是为了能够引起大家的重视。
在我们需求分析系列的第一篇文章中，我们就探讨了“产品思维”与“技术思维”的两种不同思维方式，而以上图中的两句话，则是两种思维方式在用户场景这个阶段的进一步体现。
图中的红色箭头，不知是多少人难以逾越的鸿沟。大多数情况下，我们都在“以需求分析之名，行功能分解之实！”（对号入座的同学请举手~）
思维方式的转变，真的很难，这不仅需要我们坚定不移的信念，更需要我们千锤百炼的实践。
目的意义
先来说一下，我们研究业务场景的目的意义是什么呢？你也许会说，研究业务场景肯定是为了进一步的需求分析呀。没错，这的确是目的意义之所在，但这个描述太过笼统，而且业务场景所能带来的，也绝不止这些。
价值传递的介质
我曾经在自己的转正述职报告中，提到过价值驱动与任务驱动的相关内容。我觉得我们做任何一件事情，都应该明确其目的和意义，而不是单纯地去为了完成上级交代的任务而去开展工作。
而需求这种东西，经过层层传递，最终开发接收到的，可能就只剩功能了。于是，我们或许经常会听到这种声音：“这个需求当初为什么这么定呢？”“我也不知道，产品经理就是这么定的。”并且随着时间的推移，产品经理可能自己也会忘记当初为什么要做这个需求了。
这会造成团队的后劲不足，当一个人对正在做的事情，不知道有何意义时，是很痛苦的。而业务场景，则完美地充当了价值传递的介质，为整个团队带来自驱力。
沟通交流的基准
有多少位同学的需求评审会议，开着开着最后开成了产品经理吐槽大会。那些开发与售前，本着让产品更好的“初心”，在吐槽的道路上越走越远、无法自拔，毕竟怒怼产品的机会，那可是机不可失时不再来呀。
天使的脸庞，魔鬼的心肠，一大堆问题就像脱了缰的野马一样狂奔不止！“你看人家某某产品做的这个功能多好，为什么我们不加上呢？”，“这些功能我们竞争对手也都有啊，我们也做这些有什么优势呢？”，“一个小小的功能，你搞这么复杂，你考虑过开发成本吗？”……
纵使你有三寸不烂之舌，此时也难以抵御众人的口若悬河啊，因为他们全是以发散性的思维方式提的问题。既然招式无形，你也就无法有效地进行防御与反击。最后身心疲惫，不得已说一句：“老板/客户就是这么要求的！”然后在一万只草泥马奔腾而过的心态中，会议结束。而他们也都投来了质问和鄙夷的目光：“原来这些都是你YY的需求啊！”
那怎样才能让他们“迷途知返”呢？其实也很简单，所有的沟通都要有一个基准，不然就会演变成喋喋不休的争论。而需求沟通的基准就是业务场景。我们只从一个维度进行沟通：作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>。
呈现形式
既然业务场景这么重要，那我们怎么把它给呈现出来呢？业务场景最经典的呈现形式莫过于两种，一种是用户故事，另外一种是用例图。
用户故事
其实在刚才，我们已经接触过用户故事了：作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>。这就是用户故事的经典描述格式。
用户故事三要素：
1. 角色（who）：谁要使用这个；
2. 活动（what）：要完成什么活动；
3. 价值（value）：为什么要这么做，这么做能带来什么价值。
用户故事3C原则：
- 卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等；
- 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
- 确认（Confirmation）：通过验收测试确认用户故事被正确完成。
这些抽象的理论介绍完了，那我们来看看，到底怎样记录这个用户故事吧：
我们可以看到，用户故事小卡片包含三类信息：
- 故事标题；
- 故事描述；
- 规则描述：为了完成故事，有时需要制定故事的实现规则，涉及的名词定义等。规则描述由产品经理初步制定，在故事讨论后，进行修订确认。写作方式就是一条条穷举列出。
用例图
不知道有没有同学画过这样的用例图：
嗯，不瞒各位，反正我之前是这样画的~
然鹅，这就是非常典型的技术动词+业务名词命名的伪用例！
从用例图中，我们能看到什么？
增删改查的功能，这跟场景没有半毛钱关系啊，并且一句话能说清楚的事情，还画个图有什么意义啊…..
我们再来看一张用例图：
这次大家看到的是什么？是不是这样就能够看到用户场景了？其实这样难么？答案是一点都不难，两张图对应一下，同样表达的仍然是增删改查嘛。这就回到了我们开篇所说的内容了，最重要的，还是思维方式的转变！
关于用例图的画法已经很成熟了，这里不再赘述，大家有兴趣的可自行查阅资料。
场景分析
在目的意义的段落里面，我们说到了，研究场景的目的在于进一步的需求分析。那么我们接下来看一下，应该如何对场景进行分析呢？
分析方法：场景—挑战—方案三步法
- 第一步，场景细化：将场景细化为事件流，先整理出用户预期的正常步骤，然后写出变化的情况；
- 第二步，问题/挑战识别：针对每一步骤，站在用户的角度来思考他们会遇到什么问题，面对什么样的挑战；
- 第三步，思考应对方案：针对这些问题，思考系统应该提供什么样的解决方案。
莫急，莫急，是不是觉得这些加粗的知识点太干了，我们这就给出一个案例来润润喉：
旅游这个事情大家肯定都有所体会，那如果是让我们做一个在线旅游服务网站的需求分析，我们该怎么做呢？我们就拿“行程计划”这个场景为例，一起来分析一下吧。
第一步
将场景细化为事件流，这个根据大家的自身经历，是很容易列举出来的，我这里直接给出答案：
然后呢，我们写出变化的情况。我们分析一下，在第二步是不是可能发生变化？比如这种安排时间不够，或者是钱不够……然后我们把这两种可能存在的变化情况，也记录下来：
第二步
我们来思考一下，整个过程中用户都会遇到什么问题或者挑战吧。
确定计划去的景食娱购点，大家想一下自己旅游的经历，这里最大的问题，是不是一直纠结到底去哪里好呢？旅行回来，如果大家问起你去了某某地方没，如果说没，别人说那你这旅游都白去了，这将是多么郁闷的一件事情啊。
确定先后顺序以及预计花费时间，这个最大的困难莫过于不知道这些兴趣点之间的距离，应该如何换乘交通工具，以及每个兴趣点需要花费多长时间。
同样的，准备相应的行李这一步，我们是不是也会纠结带一些什么行李好呢？用不用防晒霜，穿运动服呢，还是休闲装也行，用不用防虫剂等等。
我们把这些也都记录到表格当中：
第三步
我们来看看针对这些问题，应该提供什么样的解决方案吧。
对于不知道有哪些，怕遗漏这种问题，我们设计成类似购物车如何？然后加上“十大建议”、“分类查看”、“游客必去”等推荐功能，来强化体验；
对于不知道距离、游玩时间以及交通的问题，我们在地图上显示出所有的兴趣点，然后标注出每个景点的游玩时间，推荐路径、两点间交通建议以及预计耗时，同时统计总时、总钱，这样是不是就能够解决问题了；
对于该带哪些行李这个问题，就更好解决了，我们给出一个必备物品清单，以及天气情况，注意事项等，这些足够让用户确定带什么行李了吧；
对于时间不够、钱不够的变化情况，我们直接在地图上将某个景点剔除，系统自动重新计算花费的总时、总钱，这就OK啦。
最终，我们对于场景分析，会得出这样的表格：
好了，一份完整的场景分析到此结束，接下来是不是就可以探讨技术可行性了？
再多说一句吧，以上的分析内容，我是站在“先知”的视角，给出的总结性内容。大家在分析的过程中，肯定会遇到诸多困难，也有很多额外的工作要做，例如业务理解啊，竞品分析啊等等。这里提供给大家最重要的，还是这种思维方式。
彩蛋
用户听你说话的感受
足球解说一般都是这样的：
“有个球员接到球后，有路沉底、底部传中、中路突破，球进了！”
而用户听你说话时，似乎在听这样的足球解说：
“有个球员接到球，向自己右上方45°角传球7米，另外一个球员接球后向自己的右上方30°角传球3米，这时跟上的球员向正前方推射1米，球进了……”
这就是与客户沟通时，你带给他的感觉。所以说，赶紧转变思维方式吧，不然你就是用户眼中的“code monkey”！
结语
个人觉得“业务流程”与“业务场景”是需求分析过程中最最重要的内容了，当二者分析完毕之后，我们就可以“明目张胆”地开始讨论功能了。
如何进行有效需求分析（5）：数据篇
欢迎来到大型情感类专题：如何进行有效需求分析：数据篇。
我们在需求分析系列的第一篇中就提到过，功能主线梳理的其中一个角度就是管理支持，而管理支持又包含了三方面：
- 事前风险避免，通过增加“管理流程”；
- 事中风险控制，通过“规则”和“审批”；
- 事后总结优化，通过“数据分析”。
事前与事中两个阶段，我们已经在“流程篇”中讨论过了，今天我们一起来探究一下事后阶段的数据分析，有着怎样的奥秘。
数据与信息
风起于青萍之末。
想要对数据进行研究，首先我们需要先厘清数据与信息之间的关系。
我们在“场景篇”中讨论了关于在线旅游服务网站的内容，并且在用户不知道准备哪些相应行李的场景下，在解决方案中提出了“天气预报”的功能，就让我们来继续这个课题的研究。
提到“天气预报”，我们首先想到的，应该是温度这个数据吧。
说出来你可能不信，温度这个数据本身是毫无意义的。我们之所以看到第二天的温度是0℃时，会穿上厚厚的衣服，是由于我们日复一日对于所处环境的切身感受而形成的认知。
当我们脱离熟悉的环境，比如到从未去过的远方旅游时，这个温度数据的参考价值就会大打折扣。城市的0℃，草原的0℃，山区的0℃，以及海边的0℃所代表的含义，我相信相去甚远吧。
所以，用户想获知的是温度数据吗？
其实并不是，用户想知道的是应该涂抹什么样的护肤品，需要穿什么样的衣服，以什么样的交通方式出行合适等等。墨迹天气，提供了用户想知道的天气预报。
（墨迹天气界面）
从以上的事例中，我们可以得到以下启示：
- 数据反映事物的表象，信息反映事物的本质；
- 数据经过加工处理之后就成为了信息，而信息需要经过数字化转变成数据之后才能存储和传输；
- 数据是用于表示客观事物的未经过加工的原始材料，信息的基本作用是消除人们对于事物了解的不确定性；
- 数据更多代表的是实现方式，是我们所说的技术思维，而信息代表的则是用户价值，是需求分析过程中我们应该把握的产品思维。
数据与信息是有距离的，而这个距离就是“why”所带来的，多问问用户为什么要看到这些数据，甚至于这些数据有什么作用，我们就会“发现新大陆”，也就能够更深入地理解其中的需求。
信息管控
我之前看到过一句对于当前时代的评价话语，感觉特别有意思：
这个时代数据是爆炸了，但信息却很贫瘠。
我觉得这句话还真的挺有道理，不信的话，我们接着往下看。
考勤系统，大家就算没有设计过，也都使用过吧。我们知道，考勤系统最主要的内容，就是各种数据了
。那什么样的考勤系统，才是最完美的考勤系统呢？
是收集了所有竞品的软件说明书之后，做到人无我有，人有我优么？
非也，这种设计思路，正是导致上面那句时代评语的原因所在。
我们来看一个事例，员工迟到统计报表，这是最常见的考勤系统的报表了吧。我们有多少人，深入思考过企业为什么需要这张报表呢？
我们来试着深入分析一下：
员工迟到统计报表>统计哪些员工出现了迟到行为>统计出来扣钱>评估员工的积极性
我们可以看到，前三步全都是方案级需求，而第四步才是问题级需求，这一步也正是企业的信息管控点所在。如果我们只是单纯地收集了竞品内容，而加上相应报表的话，那只是单纯地仿其形，而未悟其神。
那我们该如何思考呢？
既然我们知道了，企业的问题级需求是评价员工的积极性，那我们可以咨询企业用户，什么样的员工是不积极的。然后，本着用数据把这样的员工找出来的思路，就可以找到更多潜在的业务报表了。
例如离岗时间统计报表，因为老板发现有些烟民会在工作过程中出去抽烟，一根5分钟，一天一包就是100分钟，我们可以用数据把他们抓出来。再比如员工代打卡分析，我们把两张工卡在多次出现1-3秒钟内打卡成功的记录都抽出来，这样他们就无处逃避了。
针对以上的案例，我们可以看到，“员工积极性评价”是信息管控点，是why；“员工迟到统计报表”是解决方案，是how；而出勤情况、代打卡、有效工时，则是针对员工积极性评价的“指标”。
信息管控点的“why”与解决方案的“how”之间存在断层，补充这个断层的方法就是思考出“指标”。
需要指出的是，针对同一信息管控点，不同的企业、不同的组织、不同的管理者都有可能会使用不同的“指标”来实现这一管理意图。
所以说，因地制宜，在需求分析的过程中就显得尤为重要。
数据分析
我们上文给出了一个观点：数据更多代表的是实现方式，是我们所说的技术思维。
那我们来看一下，针对数据层面，我们应该如何思考，然后在原型或者PRD文档中，又应该给我们的研发人员传递怎样的内容吧。
数据应用分析
哪些流程会用到该数据？
在这些流程中会创建、查询、修改、删除该数据的记录吗？
每个流程需要使用的数据字段有哪些？
数据构成分析
- 该业务数据由哪些字段构成？
- 这些字段是什么类型的？
- 这些字段的最大长度是？
- 它们有取值范围吗？
- 它们是非空的吗？
- 它们是自动编号的吗？
数据特点分析
- 哪些字段是常用的？
- 哪些字段常为空值？
- 哪些字段会作为关键字搜索？
- 哪些是稳定的，哪些有扩展需求？
- 数据记录的增长速度有相应的规律吗？
- 多长周期的数据可视为历史数据？
结语
好了，以上就是我们今天的所有的内容了，至此为止，我们需求分析的系列文章，也就全部解读完毕了。
最后，说一下自己的感悟吧。
此系列文章，我们从一个生活中的故事入手，我们讲述了用户思维的孩子，技术思维的妈妈与产品思维的爸爸，探讨了不同的思维方式。
而后，我们又沟通了价值需求的内容，我们知道了，如何将那些放之四海而皆准的目标愿景进行细化。
接下来，我们对于整天都在探讨的业务流程与业务场景进行了系统的学习。
最后，我们厘清了数据与信息之间的关系。
我最大的收获是明白了，需求分析并不是什么高深的理论模型，而是一种思维方式，是一种思考角度。很多时候我们都知道，需求是客观存在的，就在用户那里，但是我们往往面临着无从下手的窘境，或者是如“鬼打墙”一般无法走出去的困境。
此系列内容，似乎让我找到了前进方向的灯塔。
不知道，一路走来的你，又有何感悟呢？
我们在开篇中给出了一张贯穿始末的“需求全景图”，最后的最后，我们还是以这张图收个尾吧。
