每个产品都会有一个产品的愿景，每间公司都会对这个产品有一个投入产出比的要求。产品愿景vision + 投入产出比ROI 有了这两样东西之后，就会由PM产生出来一个大的产品需求列表。在敏捷当中，这个需求列表就是我们的user story用户故事。为什么叫用户故事呢？因为大多数在写需求的时候往往就是一句话需求，例如我需要一个能装水的杯子。这样的需求我们能准确的做出来吗？那么在敏捷中我们对需求的描述必然有一个固定的格式，例如:
作为一名白领(角色)，我需要一个能保温(功能)的水杯，以便我在日常工作时能够喝到热水(好处)。
一条 User Story只能有一个User角色。
User story关注业务场景和用户需求，偏向于用户能够理解或看懂的内容。重点把业务需求和场景说清楚即可，比较简单。User story通过一个简单的情境，具体的描述出软件在「使用人」的手上，是怎样被「操作」的。这样的描述可以让开发人员尽快能的贴近使用者的真实需求，而不是做错重点。
有了需求列表之后，PM就要对需求进行相应的优先级排序，在需求管理中如何确定需求的优先级？定义需求优先级的方法有多种，这里分享一下我的思路。在产品从0~1的过程中，我建议将所有的需求分为三大类：
1 基本因素（必须做的基本需求）
是产品主要业务流程中的主干线，例如手机产品，打电话、发短信是最基本的产品，满足这个需求用户也许并不会真正影响用户满意度。但没有的话这款产品是不被接受的。基本需求可以说是一款产品的存在的必要竞争力。
2 期望因素（可以做的期望需求）
满足期望需求是越多越好，一款产品具备更多的期望因素用户的满意度会越高，同样是手机产品，屏幕大的、性能好的、拍照强的速度快的当然更具备竞争力。满足的期望需求越多，竞争力就越大。
3 魅力因素（可有可无的兴奋需求）
这通常是用户意想不到惊喜，有的话满意度会大大增加，如果没有的话也没太大的影响。手机行业的smartisan是一个挺好的例子。
这三个要素是会变化的。随着产品竞争程度越来越激烈，用户受市场教育越来越成熟，魅力因素可能变为期望因素，期望因素也可能变为基本因素。
另一种定义需求优先级的方法，可以先画个坐标，横向坐标代表重要程度，纵坐标代表紧急程度，第一象限为重要且紧急，第二象限为紧急不重要，第三详细为重要不紧急，第四象限为不重要也不紧急。
image
优先级P1：重要且紧急，需要放下手中其他事立即处理的；
优先级P2：重要不紧急，按部就班即可不紧急意味着不改变计划；
优先级P3：紧急不重要，紧急意味着需要人做，不重要说明谁做都可以；
优先级P4：不重要也不紧急，没啥事了再来处理。
除了定义优先级之外，有些时候我们需要砍掉一些需求，因为在项目中，时间、成本、范围这三大要素互相制约，如果需求范围无限量的多，则会影响进度和项目质量，最终导致产品失败。当产品进入新一轮迭代时，PM需要从Product Backlog中筛选一定量的需求放到Sprint Backlog。
需求管理最终还是要根据产品、项目的实际情况出发，有时候我们也会遇到成本的制约，这时需要考虑需求的性价比了，也就是商业价值除以开发成本的比值。商业价值包括了用户价值和公司价值，而开发成本就是指技术可行性、难度、实现需要的时间。评判用户价值，我们可以用几个属性来建立数学模型例如：需求的必要程度占40%，解决了用户的痛点占35%，使用场景的频率占25%。
评判需求的公司价值，可以给公司带来现金流或数据增长潜力的需求可以优先考虑。
网友评论