v1.需求的概念
（1）什么是需求？
需求-人们所处的当前状态与心中欲望之间的差距。
tips:①不要问用户想要什么？（用户自己也不知道自己想要什么）
比如经典故事：
亨利·福特先生到处跑去问客户：“你需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马。”很多人听到这个答案，都立刻跑到马场去选马配种，以满足客户的需求。但是福特先生没有立即往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为这样我就可以更早到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
于是，福特先生不再往马场跑，而是将客户的需求充分提炼并抽象化，然后制造了福特汽车。
再比如说，现在炒的很热的共享充电宝，业内持有的看法也大相径庭，就我个人看来，其实设计者在借用共享经济的概念做很多文章，可是并没有考虑到为什么要做这个，可能这个产品刚做出来的时候会刚好满足一小部分薅羊毛的人的需求，但是却没有多大的帮助。，因为用户真正的痛点是手机的续航能力的减弱而导致手机没电，因此就需求本身而言去解决的方案有很多，通过更强大的电子信息技术将我们的手机电池得续航能力提高。其次，充电宝并不像用户的手机那样容易携带，更有遗失的可能性，很多用户莫非是紧急情况，不会冒风险去使用。
②用户想的和实际做的不一样
③单一数据/少数的用户反馈不能百分百说明问题。
再比如下面的经典故事：
（2）需求要不要听市场和业务的？
当然要！
看图说话
（3）什么是干系人
简单来说,干系人是与需求相关的人或者组织。根据定义可以将干系人分为两类
参与项目的、受项目影响或影响项目的
参与项目的包含：项目团队、项目经理、职能经理等；项目发起人；业务伙伴、合作厂商、第三方资源等等。
受项目影响或影响项目的包含：客户/用户；政府或社会团体机构；普通公众。
2.需求分析
（1）为什么需要做需求分析？
举个例子
（2）需求的三个概念
官方版本
业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。
用户需求（ user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求
以下为引述，我觉得很容易理解：
这个解释其实还是很明确的，其实理解这三者的关键点，是要先认清楚每个需求针对的对象不一样：
业务需求---------对应的是组织或者客户，实质就是业务的建设方；你也可以类比房地产市场的开发商；
用户需求---------对应的是使用产品的用户；你也可以类比买房的人；
功能需求---------对应的是产品，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求；类比房地产市场，那就是房子本身
类比成房地产三个角色后，你发现，开发商通常的诉求是想多赚钱，买房的人诉求是买到物有所值，甚至物超所值的房子；但不管二者怎么想，最终都是需要通过房子来实现，必须建设的房子的属性达到某个标准才能满足二者的诉求；
所以，这么一看，你就明白了，其实这三者之间的关系是：
即，业务需求和用户需求，只有经过需求分析的转化，变成产品的功能需求后，才能得到实现；
举个例子：
案例：用户自助寄件的需求
业务建设方：某快递公司
需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求；
很容易地能够找到以下的两个需求方的信息
但是我们还需要进一步地做转化分析，才能最后实现产品和软件的需求。
通过以上的分析，我们可以理出产品大致的使用场景：
①用户能够完成填写物流信息的操作。
②用户能够顺利找到自助投递的柜子。
③用户能够完成称重、计费、支付等操作。
简单地流程就应该是：
填单→找柜子→支付
对每一个阶段进行分析
填单阶段：
找柜子阶段：
对于功能需求方面会稍稍复杂一些
因此通过分析就发现在业务需求方面可能涉及到地理位置（导航），扫描验证，动态信息管理等几个方面的内容，当然只是较为粗略的思考。
支付阶段：
当然还需要从多样的场景中去细化分析
比如：在上面的开启柜子的方式中，到底用扫描开启还是验证码的方式呢？
其实用“验证码开启”会更合适；因为会存在很多这样的场景，某个寄快递的人，刚好家里有人下楼，或者认识的邻居下楼，而快递柜就在小区门口，那么找人代劳一下放件是一种很正常的事情，那么这时候，使用验证码就是一种最合适、简便的方式；
又比如：某用户希望自己的快递能更快的被寄出去；
那么，如果在给用户呈现周边分布的快递柜的同时，还告诉用户，该快递柜的收件时间，目前快递员的分布位置，是不是能让用户更好的去选择呢；
因此，“我们在解决任何问题时，应该在具体的场景中才能做出判断”。
3.关于VIP路线
（1）传统软件工程路线——瀑布式
（2）敏捷开发
MVP
开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP对于创业团队来说是很重要的，可以快速验证团队的目标，快速试错。
三个MVP过程的小故事：
①老罗做手机的故事
②自动果汁贩卖机
③健身房的故事
关键在于可用性
另一个故事:
亚马逊在2014年发布的Fire Phone ,具有牛逼的四个角都带有摄像头，且主打识别技术，但是用户发现其倡导的3D部分，在一个4.7寸、分辨率只有720P的手机上并不能带来舒适体验。
（3）想法的发散（头脑风暴）——思维导图——解决方法的收敛（关注细节）
思维导图
（4）对市场的洞察能力。
锤子——小米
（5）少即是多
产品的形态越少越好（非绝对的）
对市场和业务的洞察
业务背景画布——针对现状，调查企业目前做了什么。
①分析现状
②给老板看
怎样了解一家企业
电梯演讲（面向未来）
麦肯锡要求公司员工凡事要在最短的时间内把结果表达清楚，凡事要直奔主题、直奔结果。麦肯锡认为，一般情况下人们最多记得住一二三，记不住四五六，所以凡事要归纳在3条以内。这就是如今在商界流传甚广的“30秒钟电梯理论”或称“电梯演讲”。
如何向不熟悉你公司业务的人一句话介绍你的产品:
①优酷——我是中国版的Youtube 。
②苹果刚上的apple pay 面对面支付——我们做了一款和微信一样的面对面支付。
精益画布
精益画布的分析方法可参考下面这本书
问题和客户
1. 针对每个目标客户群，列出一到三个最重要的问题
2. 列出现有的备选解决方案。在产品出来之前，别人是如何解决的。
3. 找出其他可能会和目标客户互动的用户角色。
4. 细分目标客户群体，锁定潜在的早期用户，而不是主流客户。
独特卖点
你的第一个挑战不是卖产品，而是得到潜在用户的关注。
独特卖点是人们和你产品之间的第一次互动，设计得好，他们就会留下来。
如何设计独特卖点
1. 要与众不同，有独到之处
2. 针对早期接纳者设计，而不是针对普通人设计
3. 着重表现最终的成效
4. 认真选择词汇，并经常使用
5. 回答产品是什么？用户是谁？
6. 研究其他优秀产品的独特卖点
7. 写一个简短有力的口号
解决方案
先粗略想想，针对每个问题，你能提供的解决方案是什么。
渠道
创业公司的首要任务是学习，刚开始任何能把产品介绍给潜在用户的渠道都应该利用。
博客、SEO、电子书、白皮书、网络讲堂
SEM、传统媒体或电视广告、展销会、电话
亲力亲为销售产品，并带动他人
在口碑之前，先做一个值得让人宣传的产品
收入分析
MVP解决的是用户最看重的问题，并让他们愿意掏钱。
大部分在做新产品时会注意降低用户门槛，这种做法的问题在于，风险最大的部门无法得到充分验证。
价格也是产品的组成部分。
什么样的价格配什么样的客户。
让人掏钱是首先要验证的。
成本分析
准确预测未来的成本很困难，估算当前的成本，包括MVP的成本，资金消耗率是多少等。
收入和成本结合，计算出平衡点。
关键指标
可视化让交流的水平在同一个层面上
敏捷开发——用户故事地图
敏捷开发模式中的“用户故事”。当然，这并不代表人们不用再写那些恼人的文档，“用户故事”的创建依然要有文档作为依据，只不过文档的篇幅和格式已经大大优化。通过“用户故事”这一步骤，避免了团队成员的主观影响，可以客观的搜集整理大量用户需求，形成一个个用户问题、客户问题、公司问题的解决方案。
但是问题又来了，因为对于大型产品的开发，用户需求的内容会很多，像是一个庞大的地图，而“用户故事”擅长聚焦于构建小的特性，专注于小的细节就没法掌握整体，所以会带给人们困惑，不知何时才能完成开发和发布。不同的用户故事块也容易出现互不相匹配的产品部分，所以，为了避免这种管中窥豹的错误出现，人们改进了用户故事的处理方法，这种新的方法就是“用户故事地图“。
如何创建用户故事地图？
1.前期准备
相关人员：产品负责人、项目经理、业务分析、架构师等
一面白板或白墙，若干颜色的便利贴，彩色胶带等
2.创意框架
①产品的整体目标是什么?
②为用户解决哪些问题？
③公司和用户都能获得哪些收益？
大家统一好答案，将目标按优先级排列好。
3.描绘用户画像
下面针对优先级最高的目标开始讨论，开始头脑风暴：
产品面向的主要用户群是那些？
产品的潜在用户群有哪些？
谁会为我们的产品付钱？
基于这些问题，罗列不同类型的用户，讨论他们能从中得到什么好处，使用的动机，需要的功能等。精炼出若干类用户，制成“用户画像”卡片，卡片上的内容不用很详细，可以描述出基本特征即可，给每个类型的人群起一个人的名字，张三李四随意，目的是方便日后讨论，以后这个名字就代表这一类人群，再对每个用户做一下简单的诉求描述。最后，把这些写着用户类型的卡片，按照优先级排好，重要的用户放在上面，贴在白板上。
根据之前设计过的一款表单产品来梳理用户故事地图
简单地介绍一下用户画像
4.大故事
从最重要的用户类型下手，这里依然使用头脑风暴，可以按照时间顺序挖掘，描述这个人在一天中使用产品的情景，“首先他会怎样，然后怎样，然后……“这些故事可以比较概括，如“用户注册”或“修改日程”，团队中安排专门的人负责记录把每一件事都写到一张便利贴中，按照时间顺序从左到右排好便利贴。当有遗漏的故事被挖掘出来时，可以随时调整卡片顺序。在这个过程中，做到了团队成员对所要做的东西达成了一致，产品创意精彩的细节部分被所有人所消化。
下图以其中的一个用户类型为例，写出大故事：
5、深挖细节
在完成第五步的“大故事”后，“用户故事地图”的框架已经结束，下面要做的是深挖细节。白板上的卡片已经出现了第一列，这些都是大故事，我们要在每一个大故事上深挖，写出包括的细节：
用户在这一步具体要做什么事情？
用户在这一步还有其他选择么？
如何做才能更符合用户的习惯？
出现问题时如何解决？
在完成以上等等问题后，记录员要把每一个小细节都写在便利贴上，竖向排列在“大故事”卡片的下面，如果有与大故事无关的其他细节，可以放在“用户卡片”的上方区域。到此为止，一个巨大的恐龙骨骼一样的“用户故事地图”出现在白板上，甚至，它可以占满一面墙。
6、划分MVP发布计划
在第五步我们所创建的“用户故事地图”涵盖了多个用户故事和叙事主线，包含了项目人员所有的愿景，但是它太庞大了，如果同时研发这些功能点，可能几年时间都做不完，“敏捷开发”也不允许我们这么做。所以，为了缩短项目周期，我们要在“用户故事地图”上进行MVP的内容筛选，把最重要的内容放在前面。横向移动用户目标，纵向移动深挖出的细节，然后用胶带做出分隔，如下面这个例子，在第一个版本中，我只开发标号为1的部分，随着软件的不断迭代，用户故事地图也不断向下推移。此时已经完成了这个产品的发布路线图。
感谢小伙伴@没有背包的阿夫的讲授
参考阅读@再走点心《产品敏捷开发之——创建用户故事地图》
@kafkaliu《制作精益画布》
说明:本文只是来自于阅读整理，内容并非全部原创。
