作为产品经理，需求分析很重要，但你真的弄懂需求，分析对用户的真实需求了吗？产品经理到底如何做需求分析？作者深度解析了相关步骤，希望对你有所帮助。
友情提示：这篇文章比较长，全是干货！建议先收藏再阅读，如果你觉得内容不错，记得帮刀哥分享一下，本文目录：
产品经理在平时的工作中，需求这个词，出现的频率绝对是最高的，没有之一。
当我们说到需求时，其实有用户需求、功能需求、市场需求、商业需求等。
你真的弄清楚了这些需求分别代表着什么意思吗？又知道这些需求之间的区别吗？
如果没弄懂的话，你做需求分析的逻辑可能都是错的，更不可能做出优秀的产品方案。
因为不同的需求，分析的逻辑和使用的方法都是不一样的。
比如，分析用户需求，需要使用逆向设计法，探索用户更底层的需求。
比如，分析功能需求，需要使用UML建模，将用户需求转为可实现的产品需求。
比如，分析商业需求，需要使用精益画布，从产品和市场的角度，从成本和营收的角度，从问题和解决方案的角度，去分析商业模式是否成立，能否让公司盈利。
这篇文章，刀哥跟你一起探索需求，为您开启正确的需求分析之旅。
需求，简单的来说，就是一种需要。
需求方可能是用户、市场、企业或者产品。
需求方是用户时，是用户需求，用户遇到问题或者无聊时，需要通过产品/服务来解决。
需求方是市场时，是市场需求，市场需求是用户需求的集合，需要更多的产品/服务来解决。
需求方是企业时，通常是商业需求，企业需要通过产品实现盈利。
需求方是产品时，是产品需求，产品需求包括功能需求和非功能需求。
作为产品经理，我们经常接触到的是用户需求和功能需求。
本文，也将重点讨论这两个需求。
相信大家对这张图不陌生，虽然是个段子，但却真实体现了需求分析过程中的失真。
首先，在用户需求分析的时候，如果没有抓到本质，可能直接导致后面的工作没有意义。
做完了以后发现，和预期不符，要么变更需求重新做，要么直接失败，做出一堆没用的产品/功能。
其次，在做产品需求分析时，如果没有有效的方法，需求描述不清楚，后面的研发过程会非常痛苦。
总之，需求，是任何产品的起点，为产品的直接负责人，产品经理要准确的定义这个起点，让正确的事情相继发生，否则，就会出现方向不对，努力白费。
要准确识别用户需求，我们必须要了解场景，因为用户的需求，一定是来自于场景。
用户需求场景是指用户在某种环境下，做某件事来满足某种需求。
影响需求有两个核心要素，一个是环境，一个是用户当前的状态。
我们举一些例子，来理解场景对需求的影响。
胖子一定会有减肥的需求吗？并不一定，有些胖子天天喝快乐肥宅水，吃油炸食品，过得很快乐，并不一定需要减肥。
只有当胖子因为自己血糖高、血压高，身体因为肥胖而不健康的时候（用户状态），或者因为肥胖被人耻笑，找不到对象时，他才会减肥（环境）。
而当他真正去减肥的时候，他的需求可能是身体健康（如果胖且健康，就不会减肥），或者是找到彼此欣赏的对象（如果胖也能得到赞赏，并且能找到对象，就不减肥了）。
慢性子的人永远都是不慌不慌吗？并不一定，当他上班快迟到的时候，他也很慌。
大龄单身狗一定会焦虑找不到对象吗？并不一定，他本身就是不婚主义者，很享受单身生活，毫无焦虑。
需求，一定来自于特定的场景！
需求，一定来自于特定的场景！
需求，一定来自于特定的场景！
只有真正理解了这个道理，才能真正理解用户，做出合适的解决方案。
前段时间我到商场玩，花了300块钱，换来了一堆没啥用的小玩偶，小玩具，市场价最多50元。
在任何一个理智人看来，这都是不划算的，难道是因为我傻吗？
并不是。而是因为我在特定的场景里，产生了需求，做出了消费的行为。
这个场景就是电玩城。
那天我带着孩子去商场玩，见到商场里有个电玩城，有很多夹娃娃的、夹玩具的……
孩子看到这些玩具，兴奋得很，非得让我去夹。
刚开始我买了100块的币，想着夹完就不完了，结果币块用完的时候，有一个孩子想要的玩具，始终夹不到。
我不想让孩子失望，就又花了100，夹了很久，终于夹到了，币也差不多用完了。
后来又看了一些其他玩具，又花了100。
最后看夹到的这些玩具，市场价可能就50块钱，300块可以买很多更好的玩具了。
这就是在特定场景，产生特定需求的案例，在电玩城的环境里，已经在我们在商场玩耍的这个状态下，我们产生的可能并不一定是获得某个物品的需求，而是获得通过概率游戏，去获得物质奖励的刺激感。
我们做需求分析，概括起来，可以分为两步：
在识别用户需求，并转为功能的过程中，有几个关键要素：用户、功能和希望达成的目标。
使用用户故事，刚好可以把这几个关键要素串联起来。
用户故事可以发现用户需求，并定义解决方案，即功能。
通过团队一起头脑风暴，梳理用户故事地图，就可以做到既见森林又见树木。
用户故事地图，是由用户故事组成的全景图，用户故事由核心步骤和用户故事组成。
核心步骤是完成目标需要完成的关键环节，用户故事是根据核心步骤拆分出来的更具体的小任务。
例如，用户在电商产品中，核心步骤可以分为：浏览商品——下单——付款——收货——评价，在浏览商品这个步骤里，可以分为更具体的用户故事，如查看首页、搜索、对比、查看详情、查看评论等。
用户故事地图，有这样几个作用：
1、和业务、研发，甚至用户一起梳理需求，不遗漏关键功能；
2、在团队内达成共识，让项目成员有全局感，既见树木，又见森林；
3、更好的规划版本，每次新迭代，都是做的当前最重要的功能，不浪费研发资源；
梳理用户故事地图，需要组织一次头脑风暴会议，参与人须是各岗位关键角色，包括产品负责人、项目负责人、业务负责人、技术和老板等，人数控制在7人以内，但不要少于3人。
这些角色可以从多个角度提供建议，使产品/功能更加完善。
开会前，要提前准备一些材料。最好准备一个白板、不同颜色的便利贴、胶带等等。
如果没有条件，也可以使用线上工具。
图片来自网络，侵删
1、第一步，进行产品定义。我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。
2、第二步，梳理骨干故事。梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。
3、第三步，拆分故事。在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。围绕这个故事写更多细节。
在这个过程中，先让大家在一定时间内按照自己的想法写出来，把每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。
项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：
在真实业务当中，发生特殊情况该怎么办？所以这一步我们将尽量多地关注到所有场景的故事。
做完这步，我们已经获取到了足够多的细节信息，整个团队都会做到对产品又见森林又见树木的状态。
4、第四步，沟通确认。这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。
完成所有故事梳理后，就出现了下面这张图：用户故事地图。
当我们梳理用户故事时，会有一个常见的误区，把用户提出的方案，当作我们最终的解决方案。
用户想要一匹更快的马，如果我们把用户的方案当最终的方案，就永远只会去想，如何给用户提供更快的马。
更加科学的做法是，当我们接到用户提的方案时，先不要着急定方案，而是按照下面的步骤去思考。
用户为什么会有这样的需求，背后的真实目的是什么，可以借助黄金思维圈工具，从What到How再到Why。
比如，用户想要一匹更快的马，只是表象，真实的动机是，想更快地到达目的地。【更快的马】只是他能想到的最好的方案。
继续往下面挖掘，用户想更快的到达目的时，是为了更快地完成交货。
更快地交货，是为了促进更多的成交，赚到更多的钱。
赚更多的钱，是为了过上美好的生活，实现自由、快乐。
……
每个需求，挖到最后，都是人性的需求。
不过，我们应该重点关注，我们可以影响的那个层级，不必无限往下挖掘。
挖掘到用户的真实需求后，就可以着手调研解决方案了。
用户的提案，是基于用户的认知，用户只会基于自己的认知提出解决方案。
我们通过调研，是要找到更好的方案，我们的认知一定是要能高于用户的。
用户想要一匹更快的马，我们发现用户是想更快地到达目的地。
于是我们去调研，有没有更好的让用户从A到B的方案。
经过调研，我们发现，根据目前人类最先进的技术，可以制造一辆四个轮子的汽车，比马更快。
再往后，技术还会发展，可能还有高铁、飞机。
基本明确方案后，就可以假设一个方案，并着手设计。
通过设计方案，实现方案，去验证我们的方案是否达到预期，形成一个闭环。
这一步可以使用OSM模型，即目标、策略和度量。
制定一个方案想要达成的目标（O），然后，围绕这个目标，去设计方案（S），最后，通过关键数据指标（M）来衡量所采用的策略是否达到预期。
在完成用户需求分析后，我们需要将分析出来的功能，转化成产品需求，并交付给研发团队来实施。
交付的形式是PRD。PRD里面包含功能需求和非功能需求。
功能需求里面包含业务流程、业务规则、界面交互等。
在推导功能需求之前，我们要对需求建模。
产品经理，需求建模有3个常用的工具：ER图、业务流程图和状态机。
1）什么是ER图？
E-R图，也叫做实体关系图，是用来描述现实世界的模型。ER图是由美籍华人陈品山于1976年提出的一种数据建模工具。
实体是指客观存在的事物，比如人、对象、概念、事件，都可以看作实体，通过梳理实体，以及实体之间的关系，可以梳理出产品的大致信息结构。
通过E-R图来梳理信息结构，对产品经理来说，有以下帮助：
1、给开发提供数据库建表依据。程序=数据结构+算法，有了数据结构，对开发来说，对即将开发的系统就有了更清晰的框架。
2、可以指导产品经理进行原型设计。在动手画原型之前，梳理ER图，根据已知的信息画在原型上就行，而不用一边画原型，一边想字段。
3、提升产品经理的抽象及归纳能力。梳理E-R图，是一个建模的过程，建模需要通过业务沟通、流程梳理，从这些分析活动中提炼出核心实体。
2）ER图的核心组成
E-R图由实体、属性和联系组成。实体是抽象出来的人（如学生、讲师）、对象（如课程）、概念（如章节）。实体一般是个名词，用一个方框来描述。
属性是对实体不同维度的描述，用椭圆来表示，并和实体连接起来。但是大部分情况下，我更喜欢直接在实体里面去添加属性，维护成本更低，可扩展性更强。
实体与实体之间，通过一个菱形来连接，菱形里描述实体之间的联系，比如用户<创建>订单，课程<关联>讲师，菱形里一般是个动词。
实体和实体之间，有几种数量对应关系，即基数，基数有1对1，1对多，多对多。在菱形两边的线上，通过1、N、M来表达数量关系。
以下是标准的ER图：
3）ER图的三种模型
ER图按照其目的，可以分为三种类型的模型，分别是概念模型、逻辑模型和物理模型。
产品经理平时用到的，主要是概念模型和逻辑模型，在需求分析阶段输出时，可以利用其指导我们进行原型设计即可。
逻辑模型也可以作为开发创建数据库的依据，开发在创建数据库的时候，会使用物理模型。
以下是三个模型的对比：
所谓的列，你可以理解为属性，列的类型是属性的数据类型。
比如，用户作为一个实体，有姓名、年龄、生日等属性，姓名是字符、年龄是数字、年龄是日期。
4）ER图示例
逻辑模型ER图
物理模型ER图
ER图的画法非常简单，但是用处特别大，实体关系更是一种思考模型，可以让产品经理“透过现象看本质”。ER图可以指导产品进行需求分析，产品设计，还可以作为开发人员建表的依据。
ER图包括实体、属性和关系，分为概念模型、逻辑模型和物理模型，产品经理经常用到的是概念模型和逻辑模型，开发人员使用物理模型。
ER图的工具，刀哥推荐使用processon，当然Axure也可以，因为ER图相对简单，其实使用什么工具差异都不太大。
1）什么是业务流程
业务流程是不同角色，完成业务目标的先后顺序，是一系列步骤、程序，是对每个环节进行的程序化处理。
角色可以是任何对象，例如人、系统、部门、公司…
一个业务流程由多个连续的活动组成，复杂的业务流程还分为子流程。
业务流程有多种类型，例如部门人与人之间的业务流程、用户(人)与系统(产品)的交互业务流程、系统与系统之间的业务流程。
人与人之间的业务流程如公司的请假、调休、转岗、离职等，OA系统里面会有很多这种流程。
人与系统的业务流程如注册、登录、找回密码这些基础流程，还有如打车、叫外卖、购物的业务流程。系统可以看作是一个黑箱子，箱子里面又包含有前端和后端等。
系统与系统的业务流程主要在于进行数据交互，系统使用结构化设计，将整个系统拆分成很多聚合度很高、耦合度很低的模块，模块之间除了内部交互外，还需要外部系统进行交互，系统之间的交互通常使用接口。
每个业务流程都由多个连续的活动组成，例如请假这个业务流程，里面的活动有填写请假单、审批请假单等活动。注册的流程涉及填写手机号、获取验证码、输入密码等活动。
2）业务流程分析
业务流程分析就是在开始动手画之前对业务和执行过程进行详细的调查，并回答以下问题：
（1）业务流程的目的或者想达到的目标是什么？
（2）业务流程从哪里开始？如何完成？包含哪些活动和步骤？结束的条件是什么？
（3）这个业务流程有哪些角色参与？
（4）流程的活动之间有哪些控制流（判断、同步分支和汇合，稍后会说到）业务流程画法
3）业务流程图的基本元素
业务流程图的基本元素包括：活动、判定、开始和结束、文档、数据、控制元素，如下图：
不论用什么工具，记住这几个基本元素，就可以覆盖所有的业务流程。不管什么流程图，都可以仅用以上几个元素表达，比如跨部门职能流程图，就是加泳道而以，页面流程图，可以用『文档/数据』那个元素表示。
4）绘制业务流程图的注意事项
绘制业务流程图，应该注意以下几点：
a. 首先从核心业务流程图入手，它们是系统中起关键作用的部分。
b. 绘图应该根据流程方向尽量从上至下、从左至右，保持一致性。
c. 使用统一的符号。
d. 一个流程只有一个起点，有一个或多个终点。
e. 尽量避免交叉，并行的活动采用并行元素。
f. 尽量识别出表格和文档。
5）几种常见流程示例
① 人与人
以某高校期末考试流程为例，期末考试前，教务处负责安排全校课程的考试时间和地点，下发『考试安排表』。
正式考试之前，各任课老师准备好试卷，填写『试卷审批表』，交由系主任审批签字，签字后再交由教务处打印试卷。
学生参加考试并答卷，产出成绩单，任课老师阅出成绩，并将答卷封装存档，如果不及格，教务处安排补考。
② 人与系统
③ 系统与系统
在梳理系统与系统之间的业务流程图时，切记不要梳理得太细。
不要在流程图上体现太多的分支流程和异常流程。
如果过细的话，会把这份流程图变得非常复杂，可读性太差。
最后，因为过于复杂而没人愿意看，自己后面看的时候可能都会绕晕，开发测试更是不愿意看。
最好的做法是，核心系统间的流程图简要描述即可，通过这个图重点描述几个事情：
1、核心业务，涉及到多少个系统。
2、系统之间，如何进行交互和流转。
3、在这些流转过程中，分为几个大的步骤（纵向分阶段）。
然后，对复杂的业务逻辑，通过单个业务流程图来进行拆解。
在单个业务流程图中，尽量广而全地描述分支流程和异常流程。
状态图，用于描述某个实体的状态变化和流转规则。
状态机图对于梳理业务逻辑和开发实现，有很大的帮助。在实际工作场景中，写一大堆文字来描述状态流转，效果通常都不太好。对于状态定义及流转的描述，状态机图是最好的工具，没有之一。
状态描述最常见的应用场景，是对各类订单的描述，如电商的订单状态、快递物流状态、支付状态等。
状态机也不复杂，只需遵循以下几个原则，即可画出高质量的状态机图：
1、有限集合。状态都是有限的，需要枚举所有状态。并且每个状态都能体现一个实体的某个阶段。
2、状态互斥。状态之间，一定没有重合的地方，必须互斥。
3、可能具备子状态。子状态的前提，是有子订单，比如，电商的主订单是购物订单，基于这个购物订单，衍生出了支付订单、物流订单、售后订单，在待发货这个状态下，有退款中和退款完成两个子状态。
4、持续一定时长。状态是能持续一定时长的，而不是瞬间状态，比如创建一个订单，创建这个过程，由代码执行，需要一定的时间，但是很短暂，我们如果定义一个“创建中”的状态，就没有必要。
5、包括已中待其中一个词。定义一个状态时，通常使用“已”、“中”、“待”其中一个。
以下是一个电商订单的实例：
从示例图中，我们可以看出，一个完整的状态机图，包含几个核心要素：
1、开始和结束。开始通常代表产生对象的开始，结束代表状态已经进入终态。
2、状态流转的条件。从一个状态流转到另外一个状态，必定有1个或多个事件。
3、状态本身。定义订单当前的阶段。
状态机图跟实体关系图一样，画法很简单，但是代表的是对状态的定义和规则的思考，帮助巨大。
可以使用ProcessOn、Visio、Axure就可以很方便地画出来。
对产品/功能完成建模后，我们就完成需求分析很重要的一步，我们来总结下这三个建模工具：
使用ER建模和流程建模，其实背后还代表着一种设计思想。
ER图代表DDD，即领域驱动设计，我们在梳理ER图的时候，可以识别所有业务对象，这本身也是一个熟悉陌生领域的过程。
流程图代表PDD，即流程驱动设计，在梳理业务流程图的过程中，考虑更细节的分支流程和异常流程，从而可以补全用户故事地图，从而真正做到既有广度，又有深度。
另外，其实还有一些其他的建模工具，如用例图、时序图。感兴趣的朋友可以自行去研究，刀哥公众号也有相关的文章。
刀哥认为，熟练掌握这3个建模工具，就可以覆盖工作中大部分的场景了。
前面我们说过，需求有用户需求和产品需求。
用户提交的需求，还没有经过深入思考，整理解决方案的，叫做原始需求。
使用逆向分析法，对原始需求进行进一步的挖掘，然后整理出可交付给研发实施的需求，叫产品需求。
原始需求和产品需求是多对多的关系，多个原始需求可能对应同一个产品需求。
一个原始需求，也可能对应多个产品需求。
比如在B端系统上，业务方提出，希望做一个会员系统，这是一个原始需求。
但是对应的产品需求，可能包括积分模块、成长值模块、优惠券模块、还有对前端APP的改造，包括很多模块。
原始需求，提交方通常是带着方案来的，我们千万不要把用户的方案当方案，而是用户提案背后的真实目的。
C端产品，可能对应到马斯洛模型。B端产品，可以使用逆向分析法。
C端产品，用户可能并不会直接提出需求，需要很强的洞察力和同理心，去感知用户的需求。
B端产品，可以让提交人提交一个需求提报表，让提交人重点描述背后的期望以及想实现的价值。
需求提报表，核心包括提交人、优先级、问题描述、预期目标、预期收益、期待解决方案、期待上线日期等字段。
需求提交的模板可以在刀哥产品资料集里面获取，关注刀哥公众号，即可获取。
需求按照软件工程这个维度分，可以分为功能需求和非功能需求。
按照不同提交主体，又可以分为业务需求、用户需求和技术需求。
业务需求是由中高层提出，主要是一些策略和管理制度等，如绩效规则、风控策略、规则制度……
用户需求由一线产品直接使用者提出，主要使用产品具体的体验以及相关利益，可以使用客户旅行地图这个模型去分析。
技术需求是由技术提出，为了提升系统的扩展性、易用性，更好的服务业务，技术要做一些技术优化，很多时候，随着业务的发展，技术架构不能满足业务发展的需求时，需要进行重构。
在做任何一个需求时，我们都需要思考实现这个需求的价值，从不同的角度出发，需求有以下几种价值：
商业价值。能否为公司带来收益？
业务价值。能否降本增效或者提高安全、风控？
用户价值。能否解决用户问题，或带来“效用”？
技术价值。能否提升产品的扩展性、易用性？
不管从什么渠道，接到什么需求，第一步我们都记录到原始需求池。
然后根据模块，由不同的产品人员负责并分析，然后变更原始需求池的状态。
原始需求经过分析后，有些可能是伪需求，有些实现后可能也没什么价值，有些转成了产品需求。
转成产品需求后，再记录到产品需求池里，根据项目进度进行维护更新。
还记得之前说的ER图吗？我们把原始需求和产品需求看成两个实体，就是以下关系：
管理需求池，可以用TAPD或禅道这样的工具，在项目团队内可以很好的流转，如果团队配合得好，使用规范的话，可以导出需求池，随时知晓需求的整体进度。
但是项目工具使用不规范，我们有时还得借助Excel的工具，由专人进行维护（通常是项目经理），才能更好的管理好需求池。刀哥的公众号有Excel版本的需求池模板，大家可以自行去获取并下载。
需求的优先级，需要从多个维度进行综合评估，包括公司战略、市场动态、竞争对手、内部资源等。
但是归纳起来，就这几个核心点：
但是，我们做任何一个需求，尽量都要去量化。
刀哥一直记得一句很经典的话，没有量化的产品，就像没有仪表盘的飞机，是盲飞，你敢坐盲飞的飞机吗？
量化后的数据，可以给产品经理提供决策依据。量化后才能更好的验证需求是否达成了预期。
量化有几个思路。
1、看业务指标。看上线后的需求是否带来业务增量。
2、看行为指标。通过埋点，统计使用次数、人数及转化率。看功能的使用情况，
2、看NPS。通过净推荐值，看用户的综合主观评价。
需求分为原始需求和产品需求，原始需求是用户提出的，产品需求是产品经理经过思考和分析提出的。
需求有业务需求、用户需求和价值需求。需求的价值有商业价值、业务价值、用户价值和技术价值。产品经理要能够识别需求的类型和价值，才能做出更好的分析。
管理需求池可以利用项目管理工具，也可以简单地用excel，管理的重点是跟进与维护。
需求的优先级可以通过投产比，安全，合规等几个方面去考虑。
做需求，一定要量化，有量化，才能验证需求是否符合预期，通过收集需求，做方案，看数据，才能形成有效的项目循环，并提升能力。
一个需求，从挖掘到分析、调研，再到整理成产品需求，再到研发测试上线，用下面这张图，可以很好呈现。
这张图来自腾讯的TAPD，这里又要安利下这个项目管理工具，可以管理从需求到交付的全过程。
了解需求的全生命周期，也就掌握了项目管理的核心方法，项目管理的起点，就是需求。
首先，产品经理规划需求，需求可能来自于业务、技术或者用户，经过分析，将这些需求按照一个一定颗粒度拆分，每个需求都有可能研发的详细需求文档。
然后，将这些需求组合，按照优先级，形成发布计划。研发根据发布计划拆分任务，规划迭代，进入研发，研发完成后，产品经理验收，并交付给需求方。
最后，需求对应的功能上线后，产品经理去收集用户反馈，分析功能的使用情况，是否有达到预期，然后根据分析结果，再次迭代优化。
需求分为用户需求、产品需求、市场需求和商业需求。用户需求使用逆向分析法、产品需求使用UML、市场需求商业需求使用精益画布，不同需求，分析的工具和方法论不一样。
做好需求分析，可以让正确的事情相继发生，让产品有价值、研发有价值。
需求来自于场景，产品经理必须认知到这一点，只有熟悉了场景，才能理解用户，做出好的解决方案。
分析用户需求，可以使用用户故事地图法，使用用户故事地图，可以做到既见森林，又见树木。
挖掘用户真实的需求，可以使用逆向分析法，用户会说需要一匹更快的马，但想要的是更安全快速到达目的地。
产品需求建模三大工具，掌握这3个工具，就能梳理逻辑缜密的需求方案，这三个工具是ER图、流程图和状态机。
需求有业务需求、技术需求和用户需求，不同的需求对应的价值也不一样。
需求的优先级，可以从投产比、风控、合规等方面考虑，需求一定要量化，量化才能衡量，量化可以从几个角度去考虑，业务指标、行为指标和NPS。
一个需求，从诞生到最后实现，需要经过一系列的过程，可以使用敏捷开发的思路，认识了需求的生命周期，是做好项目管理的基础。
专栏作家
刀哥，微信公众号：刀哥说，人人都是产品经理专栏作家。7年产品老司机，现任某互联网公司高级产品专家，有丰富的金融项目经验，丰富的实操经验，擅于输出接地气的实用干货，帮助成千上万的产品经理晋升成长。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。