需求收集

敏捷开发模式下照样有需求收集的过程，不然开发个什么劲呢，不管是产品经理自己的想法，还是用户的需求，总有一个收集验证的过程。那么如何进行需求收集呢？除了老三样的问卷调查、意见反馈、竞品分析外，还可以有数据分析、同事反馈、用户观察等。

意见反馈：现在做任何互联网的产品，一般都会在产品上预留一个给用户反馈使用意见的口子，这就是我们经常在各个产品中见到的“意见反馈”链接页面或者是按钮弹窗，用以收集用户在使用过程当中反馈过来的信息，进而把这些信息收拢起来做统一分析，以得出相应的分析结果，看是否可以转换为产品需求。具体的处理过程可以参见意见反馈—小功能大设计。

问卷调查其实也是用户反馈中的一种，用以对特定人群或者不限人群投放预先设计好的问卷调查内容，适当加以鼓励填写的措施，以收集到一定数量的用户填写信息。

竞品分析应该是最常用的一种方式，这种方式最为直观，可以直接找到相类似的产品进行使用，然后分析其功能点和特性，找出优缺点。这种方式最常见，所以也经常造成功能上先类似的产品之间长的都差不多，也就是大家都说的“天下文章一大抄”，加引号的哈，我们还是有创新的，呵呵。

数据分析的方式是比较适合敏捷开发的，原因在其分析的结果可以快速的反应在开发结果上，以观察实际更改后的效果，比如一个购物流程，发现用户老是停留在购物车页面，就是无法转换成有效订单，这个结论一出来，我们就可以去分析购物车页面是否哪里体验做的不够好，导致用户提交订单的比率下降，分析的结果可以马上进行开发改进。

用户观察是要坐到用户旁边去观察用户使用产品的操作过程，不做任何限定，让用户以自己的方式随意使用产品，观察整个使用过程，适当的还可以进行一些提问。这种方式成本比较高，比较适合观察公司内部用户，或者是在用户的电脑上安装录屏软件，以达到事后观察的效果。

同事反馈只能小范围使用，其实就是内部PK，三个臭皮匠顶个诸葛亮，一群产品经理的智慧是比较可怕的，自己设计的产品要勇于拿出去分享，在PD内部做头脑风暴，有时候会有意想不到的效果。

此外还有微博搜索、博客搜索等信息收集的渠道，不再一一阐述。

需求记录

把搜集回来的需求做一定的分析之后得出的结论就是我们要记录的需求条目，也就是可以排到敏捷开发计划里面去实现的需求列表。一般我们记录某个需求条目的时候都会考虑到用户场景，以一个故事的形式表述出来。

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1.角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。具体的使用我想大家都非常清楚，毕竟产品经理每天都在和各色的用户故事做斗争。

需要注意的是，这样的需求条目在安排到敏捷开发的计划当中时，这些用户故事必须满足以下条件：

用户故事的六个特性- INVEST（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable ）

一个好的用户故事应该遵循INVEST原则：

独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

需求优先级

如何判断需求优先级，这个根据不同的产品需求、业务场景会有不一样的考量，不过一般可以遵循如下两个原则：

1、  价值，包括对产品自身的价值和对用户的价值，价值越高的优先级越高；

2、  紧迫性，时间要求越高的优先级越高，特别是线上问题的解决这种；

其他的考量具体的场景都会不大一样，但是有一点，在评定需求优先级的时候最好数值化，就是给每个需求条目打分，评定一个优先级的值，这样最直观，单纯的只是说优先级高、中、低不够直观，直接给一个数字就直接多了。比如1~10中10代表最高，优先级高的有10，9，8三种，显然优先级同为高的里面，10的就比8的优先多了。

需求变更

不可避免，我们都需要面对这样的问题，幸好，敏捷开发最大的优势就是可以拥抱变化。但也不是说就可以想变就变，产品经理还是要尽量控制好这种变更的发生，只有当一些不可控的因素发生后才行，比如政策法规改了这种，其他的都要尽量避免，所以说在制定需求规划的时候一定要完善才行。

采用了敏捷模式，不代表产品经理只要和开发人员口头讲一下需求就可以了，还是要有一个完整的需求规划过程，口头的方式变数太大，还是会影响到产品的进展的。所谓以用户痛点为中心的设计，就很适合敏捷的模式，快速迭代更改的都是用户继续得到解决或者改善的功能，自然需求优先级也会比较高。需求规划会贯穿产品过程，这样才能保证在敏捷的过程中产品的一致性。

下一篇：敏捷开发模式中的需求实现

转自：http://www.itfarmer.com.cn/1793.html