需求人，即真正提出需求并描述需求细节的角色。这个角色可以是任何干系人，毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起，有助于判断所提需求的立场。
负责人，负责人就像一个漏斗和筛子一样，初步筛选一遍需求。毕竟，评估需求也是要花费时间，特别是占用研发同事的时间。
产品经理，即我们自己，需求管理的组织者、推动者。以“积极主动”的态度，与需求管理的角色进行沟通。
研发leader，研发资源的管理者。在这里的研发经理，一般是带四、五个人小团队的级别。因为，他们能够了解每个研发工程师的工作和能力，协助评估需求优先级。
研发工程师，即实际参与研发需求的程序员。
测试工程师，即参与需求测试的测试人员。可以根据公司的组织架构，增加测试经理的角色。测试经理的级别也是带四、五个人小团队。
在需求管理中，产品经理要当成一个桥梁，与不同的角色，进行沟通和协作。在后面，需求管理的流程和需求看板的管理方法，都会与这些角色紧密相关。
需求管理周期
在比较成熟的互联网公司中，一般会采用类似笔者所在部门实践的火车模型发布模式。火车模型发布模式是以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法。
版本迭代的周期，一般是80小时，即2个星期。80小时原则，来自于项目管理中的工作分解结构。根据项目管理的一般经验，将一个项目中的工作，按照80小时的工作量进行拆分比较合理。所以，每一类需求管理活动按照2周的工作量进行。
严格遵守需求管理活动的三个阶段：需求收集、需求设计、需求研发。固定的周期，可以按版本号来区分，赶不上已经封板的版本功能的需求，则往下一个版本进行排期。
具体流程可以参照以下的流程图
其中，圆角方形代表操作步骤，直角方形代表输出物。
在这里复述一下整体的步骤。
1、需求人提交需求。提交需求的模板，之后的章节会介绍。
2、负责人收集需求文件，初步评审需求。在这里，如果需求存在不合理的状况，特别是业务流程不合理，负责人可以将需求打回需求人重新整理。
3、产品经理、研发leader初步评审，并放入待排期列表。产品经理拿到负责人评审通过的需求，与开发经理进行初步评估，判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板，之后的文章也会介绍。不合理的需求，也会打回。
4、根据待排期列表，需求人、负责人、产品经理、研发leader评定待排期列表中的需求，生成待开发列表。在这个过程，会应用一个工具——排期站会。这个工具，之后也会介绍。经过排期站会后，形成待开发列表。
收集需求的模板
模板应用在需求收集阶段，方便需求人提供和描述相应需求，便于负责人、产品经理、研发经理等角色评审需求。
利用此需求模板，可以快速提取需求信息，便于存档和查阅。
模板中各字段大致需要这么填：
需求提交部门，填写需求人的所在部门。
功能使用角色，比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
使用频次，即单位时间内预计使用功能的次数。比如，10次/月。方便判断此需求的优先级。
提交时间，记录需求提交的时间，便于使用“先入先出”原则。
“先入先出”原则，来自于仓储的概念，指的是先进入仓库的商品先出库。比如，食品行业有保质期的要求，需要生产越早的食品，越早出库。
优先级和重要性，这是需求管理和需求池中的核心，下面会有具体介绍。
简单的说，优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低，或者用简单的数据代替。优先级是部门与部门之间的需求比较。
重要性是对需求打分，对优先级的补充，是部门内部需求的比较。
系统功能位置，对于系统功能优化类的需求，可以注明原有需求的位置，或者想要添加的功能页面。
业务背景，或者叫需求背景。可以想象一下，如果需求是一部小说的话，是不是要在开头介绍下这个小说发生的时间、地点、人物等。
预期完成效果，描述需求实现后，预期实现的效果。
需求说明，以任何形式来描述需求内容。
需求池的核心：优先级和重要性
需求池，就是放多个需求的地方。需求池是更像是一个游泳池，需求有不同的泳道。而泳道代表着需求的不同状态。
需求的状态一般包括：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。
每一种状态的需求，可以汇集成一起。比如，待排期状态的需求，可以汇总成列表样式，叫做待排期列表。
所以，需求池是多种状态的需求，以合适的形式展现的需求汇总。
需求池列表模板可以包含这些字段：
待开发状态以后的需求，可以用看板的样式进行展现。
优先级——需求的分类和排序
需求的优先级是再熟悉不过的名称了。
优先级表现形式，一般是数字123、汉字高中低，或者字母ABC等。优先级可以用来给需求进行排序，优先级高的需求，优先开发。
同时，优先级也可以对需求进行分类。或者说，对不同的优先级给予一个不同的释义。
举一个例子：
优先级等级
5：涉及公司战略和规划相关的需求
4：业务发展/收入增长类相关的需求
3：降低成本类相关的需求
2：提升工作效率相关的需求
1：提升系统用户体验类相关的需求
需求优先级的定义，可以根据所在公司和组织、所经营的业务进行综合评估和划定。
需求的数量一般会比需求优先级要多。所以，多个需求可能会同一个优先级，同一个优先级的需求这时候就需要用重要性来排序。
重要性——优先级的辅助
重要性是对需求进行打分，分数的范围是1-100分。每个需求会被赋予1个分数，每个需求的分数是唯一的。
例如，需求A、需求B、需求C，分别赋予了97分、85分、90分。那么，根据分数从大到小进行排序，那么优先做分数大的需求。
另外，在做重要性评分的时候，建议每个需求之间不要打连续的分数。比如，需求A的重要性打95分，需求B的重要性最好打92分。分数中间的间隔，用来插入需求。毕竟在工作中，有很多突发的需求会插入进来，以调整研发计划。
排期站会
在敏捷开发中，站会是一个很有用的工具。在5-10分钟的时间中，快速交流信息，推进项目。
之初，排期会议也是安排在会议室之中，大家坐着沟通信息。实际上，人一旦没有紧迫感，就容易天马行空的沟通起需求的细节。值得注意的是，排期会不是需求评审会。
一般，排期会上要评定20-30个以上的需求，每个需求讨论3-4分钟，将是个极为漫长的过程。
所以，让大家站着开会，以一种不太舒服的方式，压缩自己的思路，快速沟通问题。
举行排期站会的一般流程如下：
1.发送会议邀请
排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期，一般是2周举办一次。具体的开会时间，要与各方协调，特别是避开例会时间。
与会人一般包含：需求人、负责人、产品经理、研发经理、测试经理等。
2.在规定时间开会，提前公布讨论需求组的顺序
站会中讨论的需求，会来自不同需求组（关于需求组的概念，请上一章:需求池的核心：优先级和重要性）。每个需求组对应着不同的人，为了避免浪费大家的时间，按照讨论组的顺序，让对应的人按顺序参加会议。
3.按顺序召集大家开会
首先介绍当前需求的开发情况，由会议主持人（一般是产品经理）介绍当前的开发状况，特别是沟通时间点。
4.评审进入下一阶段的需求
主持人可以针对需求池的内容，沟通可以进入到下一阶段的需求。
但是，主持人要控制住节奏，防止大家陷入需求细节的讨论。对于一时没有定论的需求，要标注出来，邀请需求相关方在会后讨论。
需求开发看板
最后给大家找个看板的样例，看板模式简直可以说是程序员开发的利器，划重点，开发巴巴喜欢！
在开发需求的过程中，各需求的相关人不用再去寻找邮件，或者翻看电脑保存的文档。
每个人都可以通过看板，看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如，测试工程师就可以通过看板，大概预知有多少卡片在待测试状态，从而预估自己的工作量。
当然，看板和卡片可以用采用多种形式展现。
