1:抓核心点，不是所有用户诉求都是需求
我们每做一个项目迭代或者新项目一定有目的，而需求分析阶段，需求采集渠道中的需求往往是零散的、无重点的、逻辑性不强的，所以我们需要从这些离散的需求点中要抓住核心，梳理实际使用场景去分析问题，所有的核心点一定是以最终目的为导向的，不是所有用户诉求都是需求。
以我的项目为例，由于历史原因，自配送人员关系没有进入OA系统，所以配送员工资结算数据只能做进配送系统，相当于是一个简单考勤记录，其实最早之前系统是有这个功能的，但是由于之前没有仔细整理需求，导致这个功能白做了，所以这次我接手几乎从做，我以为这个事情比较简单就让一个产品助理先去整理需求，当把原型图出出来时发现并不能解决结算工资的功能，只是一个简单的排班。
所以，当时我就跟那小兄弟说，你这东西只是完成了排班，然而排班的目的为了结算工资这还不能满足需求。所以我跟他强调，我们做这个需求的目的是为了考勤，诸如请假、值班、加班工时、轮休日加班等数据要能提供出来，他的第一版原型其实没有充分了解到我们为什么要做这个排班功能，所以在了解需求过程中没有抓住核心点，导致需求不明确。
2:制定规则、改善复杂流程
我的上一家企业做的是互联网电商，其实在我看来电商和O2O有很大的区别点就是电商在当下盛行的情况下已经变的很有规则了，首页、产品列表页、详情页、下单页等等，每个页面展示的信息也大相径庭，而O2O不一样，一方面是O2O差不多13年才兴起，到目前为止（15年）还没有一个标杆行业，另一方面是O2O与日常生活联系的太紧密，落地下来就是很复杂的业务流，这些是to C产品的规则化和流程化，而流程化的东西在to B产品上体现的尤为明显，to B产品最经典的例子就是公司后台系统。
不论是一个to C的产品还是to B的产品，我们都要考虑到用户使用场景，PM需要把自己当作用户，充分考虑各种情况下的用户思维才能设计一个满足用户需求的产品，这里并不是一味的去迎合用户，做互联网的都知道当一个业务不是规则化时很难用产品去满足用户，所以我们有必要制定规则，或者优化不完善、流程复杂的
规则。
下面说说制定规则，其实统一规则有利有弊，举个例子，滴滴打车的订单是抢的，uber打车的订单是系统自动分配的，滴滴那种做法能提高司机积极性、自主性，司机可以选择高金额的订单，但是这种做法也会影响用户体验，比如说万一以后不补贴了，我只是一个起步价，有些司机就不愿意接单，要等待很久；而uber打车制定了自动分配的规则，先分配目前离乘客最近的空闲司机，如果他不接再分配给下一个，这种做法能不能满足用户我不说，我只说这种规则简化了下单流程，司机和乘客只有两个选项，接还是不接，坐还是不坐，司机如果不接，但他并不知道下一单能等到什么时候，订单金额有多大？虽然司机间的积极性和自主性减少，但是对用户来说体验很好。
说完了制定规则，再说一下改善流程，我上面说了这种流程化精简在to B产品上尤为明显，很多人有个看法就是后台系统反正是自己人或者其他企业人员用的，完成功能就行，没必要做的这么便捷和细致，其实不然，优秀的PM在这方面总能善始善终，因为在他们眼里一点点的产品优化或者流程优化能为企业带来很多的效益，这个我有切身的体会。
之前做的多个项目，其中有两个就是我在做需求的时候发现业务部门在实际运营中思维定势或者每日重复做属于他的工作，但是他们并没有发现这样做其实效率很低，在没人观察流程有问题的时候，业务部门已经形成规范，但是这种规范并不是最优的，当PM做需求分析的时候需要细致观察他们部门或者个人的工作内容，想一想为什么这么样做，有没有其他方案能提高其工作效率。
在做数据统计需求的时候我发现业务部门某同事每天要先导出所有新用户电话、订单号、餐厅金额、订单金额等数据用于考察配送员满意度、用户满意度，然而她每天导出的数据其实有另外两个同事也需要用，只是使用目的不一样，但是他们都很死板，他们三个每天导出一份完整数据，然后筛选条件，组合成自己要的数据，这种工作其实很没必要，我们可以每天为他们部门发一份当日订单报表，标注新用户即可。
还有个例子是，财务在结算物流人员工资的时候很多计算公式是相互关联的，比如说A=B+C，D=A*E+B-C，然而他们就计算成D=(B+C)*E+B-C，暂且不说他们部门管理流程怎么样，但是PM在遇到这样业务流程的时候结合产品设计考虑是否可以精简流程，实现产品设计的初衷的同时也能简化流程。
3:离散需求整合
在和业务部门打交道的时候发现他们的思维逻辑性可能稍微差点，在PM了解需求的时候业务人员或者用户表述的没有前因后果，也就是没有逻辑性，这时如果PM不追问下去自己很容易被带到坑里面，合格的PM应该在这种情况下峰回路转，把问题再阐述一遍，如遇到稍微强势一点的PM，此时应该会指出刚才的表述有错误。
还有的业务部门人员在你去沟通的时候哗啦啦的说了一大推产品改进意见或者新需求想法，此时PM应该细心聆听，记录下需求点，千万不要给他们答复这个功能什么时候做、什么时候上线，因为系统永远是不完善的、需求却永远是数不尽的，而资源是有限的，你给的答复实现不了别人会有不好的看法，优秀的PM需要大局观，能够和团队一起评估需求优先级，规划产品生命周期，这才能推进产品迭代。
4:技术人员参与需求分析阶段
现在很多互联网公司基本上都是产品驱动，很难说技术驱动，因为产品团队可以知道用户想要什么，我在参与需求分析过程中事业部技术负责人喜欢跟着我一起去了解需求，这在我之前的工作组中没遇到过，现在做需求的时候他参与进来后我发现整个产品需求被乱了，阻碍了我需求分析进度，因为他总是以技术的角度考虑这样实现的难度，由于他是技术负责人，逻辑思维能力很强，每当听到这个数据没有需要新增一个入口去维护时他就站出来说为什么要这样做，然后劝说业务部门说这个数据提供不了，能不能先不做。
但是从产品角度上考虑，既然选择做这个项目那么就该从产品角度去设计好，等一整套产品方案出来之后再去精简功能是一个很好的方法，还有一些情况是当有一个比较好的idea产生时技术人员会首先考虑能不能实现、实现的复杂度，如果有一点困难或者技术可行方案不能当场给出时，这个功能就暂且搁置了，也许就会提出另一个不会错但是并不是最好的方案，所以技术人员参与需求分析阶段最容易把原本一个好的产品扼杀在摇篮之中。综上考虑，我的理解是技术人员在需求分析阶段暂且不要参与进来，等产品团队内部讨论之后技术团队参与审评，这样也许能达到事半功倍的作用。
针对如何做需求分析，是产品经理等岗位避不开的一个课题，下面我们从这四个维度来解答：
一、为什么要做需求分析
二、需求分析的时机
三、需求分析的步骤
四、需求分析的工具
先说两个场景让大家感受一下。
场景一：一家通讯服务公司，最近有用户反馈，电话座机听筒电缆太短了，应该延长到10米！！！于是秉承用户至上的原则，我们把所有的电话线做成10米的。但是发现后面又有用户说还是太短了，需要100米的。
场景二：一家做电商平台的公司，最近领导打算针对平台做一些营销工具方便运营进行运营推广。接到需求后，直接就参照现在市面上的营销工具做了优惠券方案。提交领导后，被领导批他要的不是优惠券，而是做一些促销活动，要我们推倒重做。
通过上面两个场景，我们不难发现，在接到需求之后，没有去了解需求的背景，深挖需求原因，就很容易导致做出来的方案是不符合公司的要求，导致大量的人力、时间、资源的浪费，甚至会导致老板怀疑你的工作能力。
接下来，我们对场景一的需求做一个简单分析：
通过上图可以得出一个结论：需求分析的本质就是将用户反馈的原始需求，转化为产品需求，进而推导为产品方案。如下图所示：
那么在工作中，产品经理一般是在什么时候进行需求分析呢？我们再来看两个场景。
场景一：你刚入职了一家做物流的公司，该公司主要是承接其他公司的运输业务。不久你接到了来自于业务方的需求，业务方告诉你，目前有些司机没有办法按时到达装卸货的地址，想通过产品层面进行优化。
你会发现在收集需求时，如果只是把前面的一句话需求记录到需求池里，会有很多疑问点。
比如：目前业务是怎样的？司机是如何分配的？司机为何会出现迟到的情况？迟到对客户会造成什么影响？而业务方既然是采用跟你面对面的沟通方式在提出需求，其实就可以及时去了解需求的一些背景。
从某种程度上来说，在这里收集需求的同时，也已经涉及到了一部分需求分析的工作。
场景二：你们公司设计了一款App，其中有一个入口是用户反馈，用户可以通过该功能反馈在产品使用当中的Bug、使用情况等，反馈后的内容可以在后台的用户反馈列表当中进行查看。
作为产品经理则需要定期（比如每周或者每月）去用户反馈列表当中查看，并将用户的相关需求记录到需求池里面，由于需求可能会很多，所以一般保持每周或每月的进度，以产品经理团队内部讨论的方式，对需求池当中的需求进行分析和处理。
需求分析的时机：
收集需求时：作为产品经理则需要定期（比如每周或者每月）去用户反馈列表当中查看，并将用户的相关需求记录到需求池里面。
收集需求后：将需求方的原始需求记录到需求池之后，后续对需求池当中的需求进行分析。
主要由四个步骤组成：
①需求澄清
②需求甄别（也叫判断真伪需求）
③需求优先级
④确认需求方案
先说需求澄清，在工作当中，很多情况下产品经理所收集到的原始需求，可能相对很完善，但也有很多情况下，我们收到的需求都是不太明确的。
所以，在对需求进行分析时，需要先明确各个需求的背景是什么，这里给大家介绍一个方法论：3W1H。
3W：WHY、WHO、WHAT
1H：HOW
接下来，通过一个场景来做一次需求澄清：
一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：“希望可以在上课时，在网页版的直播间里可以打字进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
WHY：Zoe为什么想要在直播间打字？Zoe为什么需要邀请某人语音的功能？
WHO：Zoe
WHAT：授课的时候需要让学员回答问题
HOW：目前不确定，但是Zoe给出了期望方案
以上内容就是需求澄清的方法论和案例了，接下来我们聊一下需求甄别。
现实工作中，各种人员都会跟产品经理提各种需求，有些需求值得做，但是有些需求是不值得做的。在开始进行产品方案设计之前，需要先确定需求到底值不值得做。
来看三个对应的场景，加深对于这三个特性的判断：
场景一：一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：
“希望可以在上课时在网页版的直播间里可以打字，进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
经过调研发现除了这个老师之外，没有其他老师有这种需求，并且很多老师觉得没必要。
调研之后发现这个需求不太符合普遍性，因此判断为伪需求。
场景二：公司使用微信进行工作交流，由于公司在全国有多个分公司，在进行工作对接的时候经常需要传输文件，但是在使用过程中发现了两个这样的问题，①有些工作文件因为较大，无法发送，②有些文件因为暂时用不上，就没去下载，等到要用的时候发现文件已经过期，因此给微信产品经理提出了两个需求：
“①希望微信支持大文件传输；②希望微信文件永不过期。”
调研之后发现这个需求不太符合痛点性，因此判断为伪需求。
场景三：一家IT培训公司的老师，在教学过程中使用TAPD让学员提交每日作业，在批改作业的时候发现一个问题，学员的作业无法批量下载，于是给TAPD的产品经理提出了建议：
“希望TAPD支持文件批量下载。”
调研之后发现这个需求不太符合高频性，这个场景可能不太好理解，这里说高频性是指站在公司的维度去看的，TAPD这款软件本身就是研发给有项目管理需求的公司使用的，不是专门研发给培训公司使用的，TAPD所在公司调研了很多客户发现除了这家培训公司其他公司几乎没有批量下载的需求，因此判断为伪需求。
除了普遍性、痛点性、高频性以外，在工作中还有两个点也是产品经理必须考虑的两个点，只不过思考的维度较高，可能有些产品经理容易遗忘。
产品经理在判断需求真伪的时候也需要站在公司的维度上考虑下成本能否覆盖，也需要站在项目组的维度上考虑上技术上能否实现。
需求甄别完成之后，剩余的需求都是产品经理要做的需求了，那这么多需求产品经理应该先做哪个需求呢？下面我们聊需求优先级的排序。
这里给大家介绍两个方法论：四象限法则、P序列。
四象限法则：根据重要和紧急程度划分为四个维度，如下图所示：
P序列：按照优先级划分P0>P1>P2>P3>...>Pn，如下图所示：在工作中产品经理经常会碰到多个需求，没办法绝对判断出哪个需求是P1、哪个需求是P2的顺序。这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。
确认需求方案，其实就是根据前面在需求分析的过程中，所提炼出的目的及流程，针对性的去设计出满足需求的产品方案。包括但不限于：产品业务流程、产品的功能、页面承载的信息、甚至用户使用的场景等等。
在确认具体方案之前，需要先对需求进行更加详细的分析，才能更好的得出方案，我们结合场景看下，可以如何进行分析。
还是拿前面说过的一个场景：一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：
“希望可以在上课时在网页版的直播间里可以打字，进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
我先给大伙说一个方法论：角色-场景-目的
角色：Zoe（外籍老师）、直播间学员（中国学员）
场景如下图所示：
目的：
经过以上的分析，我们最终会发现，在基于用户原始需求分析出最终的需求，实际上是：
1.目前直播间没有聊天功能，但很多学员都在听课过程中有些不明白的问题，于是希望有可以及时提出问题的地方，老师也可以方便回答。
2.外籍教师在直播间上课过程当中，涉及到想要点学生发言，但老师由于不认识中文，所以没法直接在直播间点名，所以他自己想出的方案是，在直播间让学生能直接举手并邀请对应的人进行问题的回答。
我们汇总一下需求场景和需求目的，如下图所示：
接下来我们基于场景和目的梳理一下业务流程，如下图所示：
推导一下不同场景下可能会产生的功能：
聊到这里，我们可以发现针对原始需求，已经讨论出了多个方案，那最终产品要使用哪套方案去执行呢？有没有一个判断依据呢？
有的！在这里提供一个参考思路：
我们在前面对需求进行了大量的分析，在过程当中一般会考虑好几种方案，但最终去设计的时候一般只会按照其中一种去执行，怎么去让团队或者需求方也明确结果呢？通常会产出下图所示的需求分析记录表：
既然是表格，能用到的工具还是比较多的：
高频使用工具：Excel
项目管理工具：禅道、TAPD、Tower……
总结一下需求分析的两个高频使用的方法论：
①需求澄清用：3W1H
②需求分析用：角色-场景-目的-方案
最后送给大家一句话：工具毕竟就只是工具，用啥工具不重要，重要的是你会使用方法论进行需求分析！
看完如果对你有用，请点赞、收藏 +关注！
正在持续更新干货中~
产品的构思初期，我们会罗列尽可能多需求，也会收集到很多需求。但有些需求是伪需求，有些需求也不具备实现价值，那我们如何做判断呢？
每天有无数产品诞生，也有无数产品陨落，很多时候会谈到一个原因，没有把握住用户需求，吸引不了用户。那如何把握住用户需求呢？
各种各样的需求，如何毫无克制地加载功能去满足用户，最终也会导致产品变得臃肿和失去核心定位。那怎么提炼呢？
这也就是这篇文章的思考主题，我们如何做需求分析？
1.用户需求与产品需求
用户需求是用户从自身角度出发，自以为的需求。
用户经常提出的需求，从他们角度而言都是正确的，但更多是从自身情况考虑，对于产品的某个功能有自己的期望，但对产品定位、设计的依据等情况不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。
产品需求是提炼分析用户真实需求，并符合产品定位的解决方案。
解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。
需求分析：从用户提出的需求出发，挖掘用户内心真正的目标，并转为为产品需求的过程。
我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。
所以，更应该思考，需求分析的过程，是如何把用户需求转为为产品需求，中间的纽带是什么？
什么可以把产品需求转化为用户需求？
2.人性
在想如何把用户需求转化为产品需求的中间纽带是什么，不禁要问一个问题，用户需求是怎么产生的？我们只用把原因研究清楚了，才有可能通过产品需求去迎合用户需求。我们追本溯源，用户的需求或者说是欲望究竟缘何而生？
分析人性这个问题有两个理论思维可以给我们切入去思考。
2.1马斯洛需求理论
马斯洛需求理论
出自经典著作《人的动机理论》的马斯洛需求理论，它阐述了人类的需求源于五类，即生理需求、安全需求、社交需求、尊重需求和自我实现需求。
人类最基本生理需求是衣食住行，若无法满足，人类无法生存。这也是我们提及最多的用户刚需，每一天都离不开，也就蕴含着巨大的市场空间，是众多创业公司和巨头一直抢占的各个山头。
随之产生的是安全需求，希望生活有所保障，避免被物理伤害。这是医疗人身保障等社会基础设施的建设，是“互联网+”正在升级的主要领域。
两个需求得到满足后个体会产生友谊、爱情、亲情等各种感情诉求，也渴望成为集体的一部分，几乎没有人希望过着孤独，不与外界产生联系的生活。这块目前最主要便是企鹅帝国的两大关系链产品。
随后希望被人尊重，得到认可和赞赏，名誉、声望和地位的尊重需求，这种需求很少得到充分满足。
自我实现是最高层次的一种需求，实现个人抱负、理想、价值的需要。
2.2七宗罪
七宗罪
在圣经中，人类有七宗罪：淫欲、贪食、贪婪、懒惰、暴怒、妒忌、 傲慢。
淫欲，情色网站是被中国政府和法律所禁止的，可依旧屡禁不止的，可想是多么痛的痛点需求呀。典型代表有陌陌、快播、微信的摇一摇、附近的人、YY美女主播等。
贪食，每个人都有一个胃，每天三餐，美味和食物总对人有着强大的诱惑力，美味分享生活分享类的网站，正是满足了饕餮的特性。
贪婪，总是渴求得更多，永远不会满足，于是淘宝的双十一，京东一轮又一轮的促销，各种团队促销优惠卷红包不停。
懒惰，这是互联网原则，互联网的存在就是让我们能更“懒”地完成事情，世界为“懒”人所创造，科技为“懒”人所进步。
暴怒，网络游戏的杀戮与游戏装备热卖，玩的就是人性暴怒的本质。
妒忌，网络是个分享的社会，一个贫富共通的平台，于是在网络上总凝聚了不同的声音，总有人在上面咒骂这个社会，总有人在抱怨着不满意，而这些均由妒忌所生。
傲慢，亦是虚荣，分享有时是快乐的，而满足虚荣有时也能产生快感，某些事物从不产生实际价值，只是一份虚荣心，比如QQ秀、各种钻、微博、朋友圈晒、点赞等。
一款好的产品，一定是迎合人性的。
张小龙也表示把握人性是一款产品很重要的一个环节，知道用户内心最需要什么，才能真正做出让用户喜欢的产品，当然有些东西会突破道德底线，甚至可能会触犯法律，总之既要满足人内心的欲望，又要让产品生存下去，所以打擦边球很重要，这也是一个度的控制。
3.用户动机
用户的底层欲望就是源于这些人性，而人性产生的欲望，在不同的环境中，因不同的形式、不同的行为之下，会产生各种各样动机，想要达到某种目标，而产品需求，正是迎合用户的动机，来帮助用户更好地实现目标。
被引用最多的一个例子，便是福特汽车创始人 - 亨利福特说的：“如果听用户的，我们根本造不出汽车来，用户就是需要一匹快马。”
其实，用户究竟需要一匹马还是一辆车，就是需要分析用户情境之下的动机是什么？如果是赛马想获得成绩，那确实需要一匹更快的马；如果是想更快地去另一个地方，汽车就是更好地满足用户的需求。
在挖掘用户动机之时，就可以尝试判断是伪需求还是真需求。
4.如何挖掘用户动机？
如果只是看需求和产品本身，是很难看出产品设计背后逻辑，如果放到场景里去，放到人和产品的交互里去，可以更好地看出产品设计的奥妙在哪里。
用户的动机会被很当时环境下的复杂因素所影响，这是非常考验用户研究和产品经理的硬本事。
但我们也可以尝试从几个关键因素来进行场景分析。
基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去
基于什么用户：具备什么特征，比如身份、收入、区域.....
基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......
场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
可能还有辅以用户访谈、问卷调查等各种用户调研方法，进行信息的收集和补充。
基于这些分析出场景中对用户动机和完成目标真正起作用的因素，而后转换为产品语言描述产品需求。
5.如何筛选需求？
前面说到用户需求只是用户自以为的需求，不够专业，而且有时用户说的并非心中所想，也可能不会表达内心真实需求。
所以，在筛选需求的时候，除了需要挖掘用户动机寻找真实需求的同时，还需要考虑一下几点：
该用户是否为目标用户：如果不是产品针对的目标用户，其建议或需求的参考价值可能没那么大。
该需求是否符合产品定位：该需求的满足可能会影响产品的核心服务，破坏用户体验。
该需求是否能实现：评估这个需求需要多少开发资源或运营能力，价值有多大？
在考虑需求价值时候，可以从四个维度考虑：
广度：该需求的受众面有多大？
频率：该需求的使用频露是以日/周/月为周期？
强度：该需求对用户有多强烈需要？
时机：该需求是否符合产品的规划，当下的环境？
“满足需求的产品”与“让用户尖叫的产品”之间，区别就在于对人性的把握。
---------
文/小徐同学
需求分析师主要就是通过一些市场上搜集来的数据。来结合一些当前的生产经营状况。进而估算出在未来一段时间某个产品在市场上的需求量。
这个工作总体上说是比较劳累的，因为需要一直坐在那里计算。所以比较适合女生，女生做的话比较心细，可是能得出很好的结论，比较正确的统计。
1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力
民以食为天！任何朝代，任何时代都需要厨师的辛勤劳作！现在的青年人选择做厨师职业的已经很少了！所以未来会有机器人替代厨师岗作操作的一些程序，总体来说以后的餐饮行业。厨师需求量很大
需求分析就是分析用户需求背后的动机、所处的场景、期望达到的目的，将用户需求转化为可实现的产品需求
发现网上关于商业分析师的各种回答都是产品经理的答案，产品经理(Product manager) 和项目经理(Project Manager)不同，虽然都叫PM. 但是区别还是蛮大的，另外国内很多人把商业分析师和产品经理当作一个工作职能也是有一定的误解。
我的理解产品经理是跟特定的产品的，对产品和用户负责，可能也会对这个产品的盈利模式和未来的发展作全程跟踪，有点像妈妈和孩子的关系，中心思想是关心产品的未来发展。
项目经理有点像班主任和孩子的关系，每个项目的产出都有不同，在项目上线以后就交给产品经理和运营团队了，对于产品未来或者否盈利不是特别的关心，就像是班主任保证学生都顺利升学，没有留级挂科就好，将来干什么一般不关心。中心思想是在规定时间内按照需求交付产品。
而商业分析师侧重在于整个的细致流程的，有点像学校的教务处，比如课程表的制定，由哪个老师教，学生在整个学期内中什么时候做什么样的事情进行细致规划。中心思想在于保证流程的通畅，不至于学生来了学校上了数学课之后下一堂课进行不下去不知道应该做什么，这是甲方的商业分析师。而乙方的商业分析师有点像具体的某个专业课的授课老师，区别下文会详细说明。
在这里简单的回答一下项目的需求分析，算是抛砖引玉吧，欢迎交流，未经许可禁止转载。================================================
首先商业分析师 （Business Analyst）所要涉及的知识面非常多。根据题主的问题简单的回答一下，然后再慢慢更新。
1. 什么是Business Analysis (BA)?
商业分析师这个工作最早产生于90年代，是组织机构为了对内部的线下各部门的运营流程衔接以及线上的计算机系统进行整合（因为最容易出现问题的地方往往是各个部门衔接的地方）使之对公司产生好的经济效益。
提主没有特别说明这个需求分析师是针对甲方还是乙方的，这两个地方侧重的方面均有不同，那么我就分开来说吧，两个位置我都做过。
对于甲方的商业分析师来说，你的分析一般需要涵盖自始至终的流程，包含手动和自动任务， 产出是BRD (Business Requirement Doc) 而最终的目的是每部分都可以进行有效的测量，包含生产的产品或服务，方便项目结束以后对每一部分进行追踪，比如从客户登陆网页购买产品开始，order number传给公司后台，包装部门线下进行包装配送，更新配送信息到系统，会计部门准备发票，等等。一般来说系统上线项目交接给运营部门会对该项目进行营利率追踪，普遍为5-10年，然后在追踪过程中，会对线上线下的流程进行优化，也就是我们说的项目之后的phase 2， phase 3 等等。
而甲方的项目往往会拆分成很多的小项目，分配给不同的服务供应商（一般是IT公司）他们所要提供的一般是这个项目的一部分IT系统的研发，比如CRM系统交给乙方1来做，会计系统交给乙方2来做，等等，最后和线下的流程一起交付给甲方的运营部门，那么对于每个乙方项目也会有商业分析师(BA) 偏IT系统技能的，而产出是根据BRD 产出的FRD (Functional Requirement Doc)和TD (Technical Design Doc).
对于甲方的商业分析师，一般用来作商业分析都会会采用Business Process Diagram进说明，这样可以使各个部门以及所对应的工作内容清晰化，并且能够找到流程上的瓶颈，低效率的部门，链接不畅等问题，说明现有流程(As is)，以及将来流程(To be), 这里面涉及到 High level的Business Requirements, 和干系人需求（Stakeholder requirements）以及Low level的解决需求(Solution Requirements) 这个Topic 很大就不展开讲了。
2. 需求记录（注意这里面首先是要记录需求，而不是排序或是辨别伪需求）
根据我的经验一般项目开始作为一个商业分析师，第一阶段首先跟项目发起人沟通，首先项目发起人对自己所要的一定是非常清楚的，但是很可能他要的idea 的范围很大，大到即使他自己也不知道有多大。不要紧，这里需要弄清楚的是项目干系人都有谁，所涉及到的整个流程都有哪些部门，负责人都有谁。并且和项目发起人的沟通过程中我们会产生很多问题，将这些问题写下来，做一个需求Burn down chart, 第一列写上出现的问题，第二列写谁提出的问题，第三列写提出问题的日期，第四列写出期望谁来回答这个问题，第五列记录得到回答的时间，第六列记录答案。
第二阶段就是开很多的work shop和约谈这些项目干系人，这时候当我们约谈越来越多的人时候Burn down chart里面的问题也会增多，一些问题将会被解决，一些问题会出现，我们都将这些需求记录并更新最新的答案。
3.辨别伪需求
第二阶段约谈项目干系人的时候我们可同时进行需求的鉴别。主要有4个部分：
3.1 这个需求是否是真正的需求？很多时候项目干系人给出的问题或者需求其实已经给了我们解决问题的方法，比如Digital的经理说，我们需要一个网上博客，这就已经给了你解决方案，但是这并不足够，你的分析是为什么需要博客账号？解决了什么。分析之后会发现因为我们没有博客，而且没有频繁更新，导致我们在网络搜索排名下降，网络无法导流到我们公司的产品主页。Root Cause 是流量导入，那么我分析可以给出很多导流的方案，比如微信，微博，百度购买关键字等。
如果决定了使用博客，那么我们需要分析的是，是我们自主开发博客，还是购买现成的模板，或是直接找公关公司替我们维护等等，我就不展开说了。
3.2 干系人提出的问题是症状还是病根？比如一个人说他腰疼，那么如果我是医生给他去疼片，吃过之后他感觉不到腰疼了，那我们是在处理他的症状而不是病根，当药效停止之后他肯定还会腰疼的，那么我们需要提供的解决方案是多运动，或者提议作腰部手术，将病根解决，这才是真正的需求。
3.3 如果病根解决之后是否其他的需求也会一并解决？对照burn down chart 进行需求归类，总结 Root cause, 例如可以将如腰疼导致的腿脚酸软一并解决。
3.4很多情况下在解决root cause 的时候会产生新需求，我们需要再按照3.1到3.3的流程解决一遍。
4 项目范围的界定以及假定。经过上面的流程我们应该得到大部分的答案了，对于没有解答的问题我们需要进行进一步的分析。
4.1不在项目范围内如果一个问题即使项目发起人都无法回答，那么大部分是因为这个需求不在项目范围内，这时候我们需要跟项目发起者和关系人声明这一点，并且明确写在商业需求分析文档内，4.2根据自己的分析理解写出假定的分析记住将你的假定分析以邮件文本形式发给所有人，告知因为在规定时间内我们无法得到答案，所以我们进行如下假定XYZ.
4.3 将总结好的需求文档给大家审阅，进行MOSCOW分析，哪些功能是Must have, Should have, Could have, Won't have, 并在会上通过。
最简单的需求文档的格式一般包含以下几部分。a. 交代背景/ 项目的发起原因/ 解决什么样的问题/ 达到什么样的 goalb. 交代项目大概涉及到什么功能/ 牵扯哪些部门c. 项目的假设/ 依附关系/ 项目风险/ 声明非本文档内所提及的需求之外的需求皆不在项目范围内。d. 具体的项目需求/ 流程 等*（主要部分）e. 非功能性需求f. 系统需求及权限配置g. 项目发起人，和关系人对该文档的批准邮件h. 附录
5.需求表总结。对于一个高级的商业分析师，可以根据burn down chart来做出很多数据透视表，比如根据问题提出的时间和得到答案的时间大概算出该问题在回答者心目中的重要性，以及在escalation的情况下以此做为你的依据；还有真实需求和伪需求的占比，得出大家对项目的理解程度；最后如果你离职了，也可以把这个表给新人，让他迅速投入到工作中去。
... 以上。
===============================
有对该业务或企业咨询感兴趣的朋友欢迎勾搭
微信号：红色共产
电邮：crossrnbw@163.com
本文欢迎有兴趣的朋友进行转载，转载时请务必添加本人简介于文末，若有商业用途，烦请尽量联系告知作者。
设计app候首先应该想清楚:1app界面设计发;2app发软件注意切割编码;3发布app应用并进行跟踪监测;4APP软件用户需求析;5APP软件原型设计等发app候要经历阶段包括:1需求调研阶段;2app案例系统台代码编写阶段;3app应用发布试行阶段;4式运行app软件阶段;5运行维护app阶段等每阶段都必须谨慎待
（1）分析市场需要量及质量要求 要对目标市场的需要量和质量要求进行分析。
目标市场对某种商品需要的数量是多少？常年的销售量有多大变化？有什么质量要求？应该有一个清醒的认识，切忌从某一个或数个特例来指导对整个目标市场的分析，“一叶障目”。那样会对创业者进行误导，甚至使创业者的事业走向失败。（2）分析商品供应量及质量情况 分析相应商品的供应数量及其质量情况，可以对其竞争对手有一个大致的了解，为自己的商品进入市场做一个铺垫，做到知己知彼。（3）分析商品数量和质量变化对市场的影响 还应该分析创业者产品的数量和质量对市场的影响。在市场供求关系趋于平衡的状态下，如果创业者的产品注入市场，就会产生波动。在注入量并不是很大的情况下，这个波动不会有较大影响；如果数量达到一定规模，则会产生较大的波动，加上一些市场操盘者的运作，这种波动会放大，直至产生很大的影响。如果产品的耐储藏性越差，这种影响就越大。其实，每一种新产品进入市场时，总会打破原有的供求平衡。作为一个创业者，要想在市场大潮中获得收益，应该了解这些变化，才能减少损失，增加胜算的把握。（4）成本核算 此外，创业者还需要了解自己产品到达市场的综合成本，包括生产成本、运输成本、管理成本等，作为确定产品是否上市的依据。显示全部
收起
