mvp方法如何准确采集产品需求

㈠ 产品思维（4）利用MVP快速解决用户痛点

MVP(Minimum Viable Proct)最小可用产品，创业前期资源有限，经常会有很多创意因为这个而夭折，在有限的资源和市场极大不确定的情况下，利用MVP验证产品需求是否存在，市场是否能够接受，是否能够创造盈利。

MVP让我们能够去试错，不停的验证，不停的优化，找到最大的用户爆发点，将痛点挖掘出来，痛点是核心需求的直接体现。

在很多产品经理刚开始的产品设计中，经常将产品设计的面面俱到，而运营起来找不到重点，找不到定位，首吵很多app都是因为这个导致的用户流失。

在残缺与可用性之间找到平衡点是最关键的一步，那就利用排除法，最好在猛芹让用户调研后将不必要的功能去除，尽可能用手动替代程序开发自动处理的功能，减少用户决策与填写。

在知道用户的痛点之后，要继续深挖需求，快速迭代，和枝局做市场业务类似，发现一条渠道十分有优势，不断的制定策略，完善细节，专攻实现业务量爆发式增长。

在实现过程中，技术所需资源上，前期尽可能的使用第三方组件、框架、平台，先轻资产，不要将眼光放的太长，验证最后才不断把核心竞争力攥到自己手里，减少依赖的风险。

㈡ 如何借助“敏捷开发”快速实现MVP

在敏捷实践体系中，迭代交付模式是敏捷开发的核心要素。敏捷开发方法有很多，Scrum提供了迭代管理和持续改进的框架，如图5-15所示。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

图5-16 用户需求列表（产品功能需求）

步骤2. 召开计划会议和制定开发计划（计划版）

Scrum Master负责组织召开计划会议，产品经理和团队一起根据需求的重要性、开发量来确定开发优先级，做工作量预估，制定迭代开发计划（从需求列表中挑选出高优先级 Story（用户需求）[张乐飞3] 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog（迭代代办事项）[张乐飞4] ）。开发团队一旦接受这些开发任务，就应该准时完成，不得修改交付标准。

步骤3. 执行迭代计划（任务板）

首先，你需要确定每次Sprint（开发冲刺）[张乐飞5] 的周期，短的周期可以更频繁的发布产品版本，因此可以从客户那里更迅速地收到反馈，修正错误。这个周期一般为1~4周，当然，你可以根据团队成熟程度或迭代任务确定一个合适的迭代周期，比如2周。这样可以让开发人员更投入地工作。

所谓Sprint，就是在一定时间内全身心投入开发。这个阶段通常用看板来管理需求，每个卡片[张乐飞6] 就是一个开发任务，工作完成后，可以将卡片移到下一个阶段，用看板管理需求，如图5-17所示：你也可以使用专门的软件来管理看板，例如国外的Jira、国内的明道。

图5-17 敏捷开发项目管理看板

在冲刺中，每一天都会举行项目状况会议，被称为“每日站会”。会议在固定地点和每天的同一时间举行，对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立，每个人都必须发言。会议的目标是讨论当前的任务的状态，一个推荐的汇报形式是：我昨天已经做了什么？我接下来准备做什么？现在遇到什么阻碍和问题？注意在会议中团队成员不必要针对每个问题进行探讨，只是作为一个重要信息的反馈通道，具体问题相关成员在会后私下当面沟通解决，这样更加高效，避免浪费问题无关成员的时间。

步骤4. 产品测试和演示

因为每次的Sprint目标就是交付一个可以用的产品特性，所以测试工作非常重要。有不少方法可以减少测试周期，比如，你可以减少需求数量，或者让开发参与测试。当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行演示会议，也称为评审会议。产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。

步骤5. 回顾会议和下一个Sprint计划

每一个冲刺完成后，都会举行一次冲刺回顾会议。回顾会议也称为总结会议，会议的时间限制在4小时，以轮流发言方式进行，每个人都要发言，哪里做得好、哪里不好都可以提出，总结并讨论改进的地方，放入下一轮Sprint计划。

㈢ 如何通过“敏捷开发”模式开发MVP产品

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行产品开发。在敏捷开发中，产品项目在构建初期被切分成多个子产品，各个子产品的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大产品分为多个相互联系，但也可独立运行的小产品模块或功能，并分别完成，在此过程中产品一直处于可使用状态。

在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件。这份文件基本上代表了不同敏捷方法论的共同点，我们称之为“敏捷宣传”，也叫做敏捷软件开发宣言，是指导以人为中心的迭代软件开发方法，具体四个核心价值内容如图5-14所示。

图5-14 敏捷开发宣传

1. 个体和互动高于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。虽然，过程和工具都是好东西，但是它们有时也会成为障碍。面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多。当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

2. 工作的软件高于详尽的文档

可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文件)为客户和也会[张乐飞1] 传递了高价值。一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的。但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的。敏捷通过寻求“刚好足够”的文档来避免这种情况。其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

3. 客户合作高于合同谈判

这个[张乐飞2] 价值观的核心是越接近你的客户越好。客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误。在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的。定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

4. 响应变化高于遵循计划

任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。即使底层的技术也在快速变化，新的途径和可能性在不断的被打开。对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。

当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。除了敏捷宣言之外，还有12条准则的支持文件，为敏捷宣言提供了更多的扩充细节。

l准则1：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值。

l准则2：欢迎对需求提出变更，即使在项目开发后期；要善于利用需求变更，帮助客户获得竞争优势。传统项目管理中地一个原则是设法去影响和控制会导致变化地因素。敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期。迅速应对和适应变化能给客户带来显着地竞争优势，从而应对新的机遇。

l准则3：要不断交付可用的软件，周期从几周到几个月不等，且越短越好。不同的敏捷方法论采用不同的迭代周期，但都是相对较短的。关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报。较短的迭代周期可以使团队持续关注客户的价值。[张乐飞3]

l准则4：在项目过程中，业务人员、产品经理与开发人员必须在一起。敏捷项目管理，让业务人员、产品经理和开发人员彼此靠近，并时常让他们在同一个地方一起工作，通过这样的方式让业务人员和开发人员之间没有隔阂。是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。

l准则5：要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式。敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么。提供相关资源，给予鼓励，相信团队能够完成任务。

l准则6：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍。其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率。面对面沟通是敏捷项目管理的精髓。这种沟通是公开的，任何团队成员都可以自由参与对话。

l准则7：可用的软件是衡量进度的主要指标。计划和文件可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值。传统项目往往极其纠结的是，项目的不断更新使得文件成为一种负担。真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。

l准则8：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工。理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。

l准则9：对技术的精益求精及对设计的不断完善将提升敏捷性。设计的越完善，维护起来就越简单，即使遇到变化。稳定和优质的项目会比劣质的项目更加允许团队快速应对变化。

l准则10：要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术，被所有的敏捷方法所拥护，尤其是精益方法。[张乐飞4] 关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动。保持简单不只是一种愿望，它使最基本的原则。

l准则11：最佳的架构、需求和设计出自自我组织的团队。自我组织是敏捷团队的核心元素之一。当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定。不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的。

l准则12：团队要定期反省如何能够做到更有效，并相应的调整团队的行为。敏捷项目中最可预见的事情就是变更。传统项目里当项目或阶段完成时开会总结是最常见的做法。而敏捷试着通过更频繁的回顾来完成这项工作。在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法。每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。

敏捷开发的业务目标是更早的交付价值，价值的交付不仅仅是早晚上线两天的问题，而是更早上线能够给自己和客户带来更大的价值越晚交付，价值越低。更快不是绝对速度的快，而是指时间上的早，即通过迭代交付实现分批和更早的交付。同时灵活地响应变化，当今世界跨界颠覆的案例数不胜数，一个企业的核心能力不再是已有的能力有多强，而是灵活响应变化，快速学习的能力有多好。