在需求管理活动中，进行某一项具体活动的时间点，就是需求时间。
（1）需求收集的开始时间和结束时间
关注需求收集的开始时间和结束时间，因为二者相减，约等于2周，或者说约等于2周的工作时间。因为每个公司的工作习惯不一样，可能会涉及到固定时间点的例会等，所以，需求开始时间和结束时间设置要灵活。
同时，需求收集的开始时间和结束时间，要有一定原则性。产品经理要尽量影响需求人，不要赶在紧邻结束时间提交需求。就好比，在现实生活中赶火车，总要提前一会儿到达车站，毕竟还要有检票进站等环节。同样，需求人在临近结束时间提交需求，负责人评审需求和产品经理评审需求的时间，都不能保证，会影响需求的质量，以及之后的排期站会的质量。
所以，为了规避这种情况，可以在需求收集结束前5天，发送排期站会的会议邀请，以此提醒大家马上就要排期需求了，赶紧提交需求。
（2）排期站会的时间
排期站会的具体内容和形式，后面的文章会提到。这里先提一下排期站会的时间。
排期站会的时间紧邻需求收集的结束时间。换句话说，需求收集一结束，立刻开始排期站会。
因为排期站会，需要需求人、负责人、产品经理、研发经理及研发工程师参加，所以要多方协调一个大家都有空的时间进行。
排期站会的时长控制在一个小时内。
4.4 结语
本章介绍了在需求收集阶段，应用急诊模式的流程步骤。
之后将介绍，在需求收集阶段的3个工具：
需求提交模板需求排期列表排期站会5. 收集需求的模板
本章介绍一套收集需求的模板。通过模板规范需求的内容，以及提升沟通的效率。
5.1 应用场景
模板应用在需求收集阶段，方便需求人提供和描述相应需求，便于负责人、产品经理、研发经理等角色评审需求。
利用此需求模板，可以快速提取需求信息，便于存档和查阅。
5.2 模板样式
此需求模板在填写上有如下说明：
（1）需求提交部门
填写需求人的所在部门。
（2）功能使用角色
比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
（3）使用频次
单位时间内预计使用功能的次数。比如，10次/月。方便判断此需求的优先级。
（4）提交时间
记录需求提交的时间，便于使用“先入先出”原则。
“先入先出”原则，来自于仓储的概念，指的是先进入仓库的商品先出库。比如，食品行业有保质期的要求，需要生产越早的食品，越早出库。
再形象一点，把处理需求的过程理解为一根管子，新进入管子的需求，就先从另一头流出。
因为需求对应的场景和业务可能会变化很快，如果积压时间太久的需求，就变贬值，跟不上现有业务的发展，所以要应用“先进先出”的原则。
（4）优先级和重要性
这两个概念下一章重点介绍。
简单地说，优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低，或者用简单的数据代替。
（5）需求涉及部门
一个系统需求，会牵一发而动全身。通过填写此需求可能涉及到的其他部门，来评估需求带来的可能影响。
也能驱动需求人在提需求时，增加跨部门思考的维度，提升需求的可行性。
不害人的需求，不是完整的需求。——《普拉姆原则》
（6）系统功能位置
对于系统功能优化类的需求，可以注明原有需求的位置，或者想要添加的功能页面。
（7）业务背景
或者叫需求背景。可以想象一下，如果需求是一部电影的话，是不是要介绍这个故事发生的时间、地点、人物等。以此类比，填写相关的需求背景。
（8）预期完成效果
描述需求实现后，预期实现的效果。
（9）需求说明
以任何形式来描述需求内容。
（10）需求文档
任何形式的需求文档，都不如流程图简单明了，便于沟通。
5.3 结语
此文档偏向于应用在后端产品或者系统需求。
如果是前端需求，可以根据业务需要选择填写。
6. 需求池的核心：优先级和重要性
本章重点介绍需求池中的核心：优先级和重要性。
6.1 什么是需求池？
需求池，顾名思义就是放需求的地方。需求像下饺子一样，储藏在需求池中。
在我看来，需求池是更像是一个游泳池，需求有不同的泳道。而泳道代表着需求的不同状态。
需求的状态一般包括：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。
每一种状态的需求，可以汇集成一起。比如，待排期状态的需求，可以汇总成列表样式，叫做待排期列表。
所以，需求池是多种状态的需求，以合适的形式展现的需求汇总。
结合，之前文章提到的内容，需求池列表可以是长成如下样子。
当然，需求池中不同状态的需求，可以用多种形式进行展现。比如，待排期的需求可以用列表的样式进行展示。待开发状态以后的需求，可以用看板的样式进行展现。
6.2 优先级——需求的分类和排序
需求的优先级是再熟悉不过的名称了。
优先级表现形式，一般是数字123、汉字高中低，或者字母ABC等。优先级可以用来给需求进行排序，优先级高的需求，优先开发。
同时，优先级也可以对需求进行分类。或者说，对不同的优先级给予一个不同的释义。
举一个例子：
需求优先级的定义，可以根据所在公司和组织、所经营的业务进行综合评估和划定。
但是，有一个问题，需求的数量一般会比需求优先级要多。所以，多个需求可能会同一个优先级，那么同一优先级的需求又该如何区分呢。
6.3 重要性——优先级的辅助
刚才说了优先级，具有对需求分类的作用。重要性是对优先级的辅助。
重要性是对需求进行打分，分数的范围是1-100分。每个需求会被赋予1个分数，每个需求的分数是唯一的。
例如，需求A、需求B、需求C，分别赋予了97分、85分、90分。那么，根据分数从大到小进行排序，那么优先做分数大的需求。
如下列表：
需要注意的是，重要性的分数只是用来做排序，不代表其他信息。比如，重要性是100分的需求不是50分需求的2倍。
另外，在做重要性评分的时候，建议每个需求之间不要打连续的分数。比如，需求A的重要性打95分，需求B的重要性最好打92分。分数中间的间隔，用来插入需求。毕竟在工作中，有很多突发的需求会插入进来，以调整研发计划。
6.4 统一的看优先级和重要性
从整体的角度看，优先级和重要性两者的关系。
优先级和重要性是需求池的核心！什么是核心？优先级和重要性一旦确定，将贯穿需求的整个生命周期，所有的资源将根据优先级和重要性来被安排。
换句话说，如果是高优先级和高重要性的需求时，不管在需求的哪一个状态，都会被优先分配资源。
优先级和重要性在处理跨部门需求的时候，尤为重要。原因在于，优先级可以用来比较不同部门之间的需求。因为优先级已经对需求进行了分类。
同时，重要性只用作一个部门内需求的比较，重要性的分数不能跨部门比较。比如，采购部门重要性100分的需求，与销售部门重要性是90分的需求，在分数上是没有可比性的。
（是不是有点晕了？先跳出来。）
优先级和重要性，只是处理需求的工具。更重要的是，如何给需求划分优先级和重要性。
我觉得这些方法有很多，但是可以借用项目管理的一个概念——项目组合管理。
项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化。
这个概念有点绕，只要关注一个词——“符合企业战略”。所以，划分需求的优先级和重要性，是紧密围绕着企业和组织的战略。
而如何划分优先级和重要性，可以看做是项目组合管理方法论的范畴。可以使用SWOT分析、KANO模型等等，这些都是得到优先级和重要性的工具。
所以，在符合企业或组织战略的核心目标下，通过项目组合管理的方法，先对收集到的所有需求标注好优先级，再对这些需求进行分组，形成需求组。分组的依据可以是部门，可以是项目。对这一组内的需求，赋予不同的重要性分数。因为需求组之间划分的标准不同，所以不同需求组的需求，重要性分数不具有可比性。
因此，从实现企业战略的角度，高优先级的需求在划分给不同需求组后，可能并不会赋予很高的重要性。
6.5 结语
优先级和重要性，只是处理需求的手段。它们背后的核心要义是企业和组织的战略目标。
7. 排期站会——需求收集的最后一站
上一章介绍了制定需求优先级和重要性。在此基础上，可以组织需求方和研发方在一起开排期站会。一是评定进入到需求设计阶段的需求，同时也是增进各方沟通信息的好时机。
7.1 为什么要站着开会
在敏捷开发中，站会是一个很有用的工具。在5-10分钟的时间中，快速交流信息，推进项目。
之初，排期会议也是安排在会议室之中，大家坐着沟通信息。实际上，人一旦没有紧迫感，就容易天马行空的沟通起需求的细节。值得注意的是，排期会不是需求评审会。
一般，排期会上要评定20-30个以上的需求，每个需求讨论3-4分钟，将是个极为漫长的过程。
所以，让大家站着开会，以一种不太舒服的方式，压缩自己的思路，快速沟通问题。
7.2 排期站会的一般流程
举行排期站会的一般流程如下：
（1）发送会议邀请
排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期，一般是2周举办一次。具体的开会时间，要与各方协调，特别是避开例会时间。
与会人一般包含：需求人、负责人、产品经理、研发经理、测试经理等。
（2）在规定时间开会，提前公布讨论需求组的顺序
站会中讨论的需求，会来自不同需求组（关于需求组的概念，请上一章:需求池的核心：优先级和重要性）。每个需求组对应着不同的人，为了避免浪费大家的时间，按照讨论组的顺序，让对应的人按顺序参加会议。
制定讨论顺序时，尽量要考虑每个需求组的数量，和需求组的重要性。因为，先行讨论的需求，就会有优先获得需求的优势。
（3）按顺序召集大家开会，首先介绍当前需求的开发情况
由会议主持人（一般是产品经理）介绍当前的开发状况，特别是沟通时间点。
（4）评审进入下一阶段的需求
主持人可以针对需求池的内容，沟通可以进入到下一阶段的需求。
但是，主持人要控制住节奏，防止大家陷入需求细节的讨论。对于一时没有定论的需求，要标注出来，邀请需求相关方在会后讨论。
7.3 排期站会的道具
（1）站会的场地
站会的场地可以选在工位旁，较大的过道或者走廊上。这样便于参会人快速到达和撤离开会现场。也可以让一些让其他同事，快速参加会议。
（2）展示会议内容：电视/白板/看板
一般大家要围绕着需求池来开会。而展示需求池的道具，可以一块儿屏幕或者投影。这样可以集中大家的焦点，和快速展示信息。
（3）倒计时器
在每一个讨论模块设置倒计时器，到时铃响。提醒大家关注时间。
7.4 结语
站会的首要目的是公布信息，增进沟通和了解。
大家在开会的过程中，了解微信和邮件中以外的信息，增加对需求的了解。需求相关方的信任和了解。
8. 登机模式与需求设计
之前的章节已经将需求收集和急诊模式讲完了。本章介绍需求设计和登机模式。
8.1 何为登机模式
做需求，犹如坐飞机，通过各种渠道买好了机票，但并不是意味着马上坐上飞机，而是进行check-in。
面对从各个部门提出来的大量需求，有时在需求收集阶段，不能简单快速的评估出全部细节。这个时候需要增加一个需求设计阶段，对已经定好排期的需求，进行check-in，将机票转化为登机牌，然后凭借登机牌，登上飞机。
这里的登机牌就是产品文档，登上飞机就是进入到需求开发阶段。
之前，在需求收集阶段，收集到的资料大部分是可以归为需求文档，也就是描述：我想要什么，实现什么样的效果。或者说，需求文档不涉及到具体界面功能流程、交互设计、UI设计。
实际上，需求文档也不应该涉及这些。原因是，提供需求文档的人（需求人和负责人）并不擅长用非业务语言描述，同时也会增加他们提交需求的工作量，从而影响需求质量。
专业的人做专业的事。
什么是产品化？将需求转化为可以投入资源的行动项。——《普拉姆原则》
这样的话，需求设计阶段，就需要讲需求文档转化为产品文档，真正将需求描述转化为产品解决方案，转化为让研发同学可执行的方案。
当然也有特例，如果需求是业务逻辑的修改，不涉及界面操作，这时的需求文档其实等价于产品文档。
8.2 产品文档要用共享文档
这里并不讨论在需求设计阶段怎么书写产品文档，因为书写产品文档是用于沟通的工具，格式并不是特别重要。
这里要提的是产品文档要采用共享文档的格式。在之前，本人将写好的产品文档是以邮件的形式发送给相关人。但是，随之而来的问题就是，更新和保存文档，就变成了问题。
以邮件的形式，总会是存在漏看文档，和不易查找文档的方式。
所以，产品文档要使用现在共享文档的方式。国内已经有很多类似的产品，比如墨刀之类。我使用的是文档。使用的原因是体验好，功能完备。
使用在线共享文档的最大优势是，可以随时保存，使用链接分享，随时保持文档的最新状态。同时，可以多人共同编辑文档，更新信息，减少沟通的成本。
同时，还能对文档进行积累和保存。
8.3 结语
在需求管理的需求设计阶段，对需求重新进行评估和设计，从而转化为产品文档，并使用在线共享文档的形式，进行协作，减少沟通成本。
9. 的使用技巧——看板模式与需求研发
经过多个章节，终于到了需求研发的阶段。这个时候，使用看板模式进行需求管理。普拉姆需求管理方法的介绍，也快接近尾声。
9.1 鸡肋的邮件
邮件已经成为公司最基本的沟通工具。但也是最鸡肋的工具——食之无味，弃之可惜。
所以，在需求管理的方法中，尽量让需求的形式或者载体，不仅仅依附于邮件，而应该采用多种形式。比如，在需求池中，需求就是以一行数据的形式存在。
在需求研发阶段，采用看板模式，以卡片的形式存在。
9.2 看板与需求卡片
（1）看板
看板的管理方法，是一个来自于制造业的专门知识。
看板管理，是指为了达到JIT准时生产方式而控制现场生产流程的工具。——百度百科
这里只是才用如下图进行示意，感兴趣的读者可以查阅相关资料，学习看板知识。
看板由不同的“泳道”组成，需求以卡片的形式，从最左端开始，运行至最右端结束。
一般“泳道”的划分，可以按照需求的状态划分。也就是说，需求卡片从左向右的流转，就是需求状态的流转。
（2）需求卡片
需求卡片是需求在看板中的载体。这里可以记载需求的所有信息。
但是包含如下信息：
在开发需求的过程中，各需求的相关人不用再去寻找邮件，或者翻看电脑保存的文档。
每个人都可以通过看板，看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如，测试工程师就可以通过看板，大概预知有多少卡片在待测试状态，从而预估自己的工作量。
当然，看板和卡片可以用采用多种形式展现。比如，用真实的板子和纸片进行管理。也可以采用电子虚拟的形式进行管理，比如使用。
9.3 的使用技巧
现在，有很多管理工具，在使用看板的方式。但是，综合感受还是做得太复杂。而的最大邮件就是简单，而且兼容很多插件，可以灵活应对多种场景。
当然，最大的优势是免费。
做为工具，本身极为容易上手，这里只是简单介绍一些使用技巧。
（1）卡片
的卡片功能非常强大。
这里要特别强调的是善于使用标签功能。
标签功能，像是办公文具中的条状彩色便利贴。对不同卡片进行分类。
因为有搜索和筛选功能，在实际的应用中，可以将不同的“部门”作为标签打在卡片上，这样就可以对卡片进行筛选。
这里提示的小技巧是，将同一类的信息的标签，赋予同一种颜色，以便于管理。比如，不同部门（如销售部门、运营部门等）的标签是红色，不同系统的标签是绿色。
另外，“附件”功能，可以添加在线共享的需求文档的链接，便于查看更详细的需求细节。
同时，可以利用“清单”功能，创建此需求的研发工作项目（WBS），使用@可以指定到具体的人。
（2）插件
使用建议使用浏览器，因为在的应用市场中，提供了很多的免费插件，增强的功能。
9.4 结语
本章介绍了需求研发的看板模式，从而引申出了的使用技巧。
只是工具，关键还是背后的需求管理方法。
10. 需求管理的证伪
这是普拉姆需求管理的最后一章。最后，再聊一些关于需求管理的感悟。
10.1 遭遇危机
之前文章提到的需求管理方法，包括三个阶段：
需求收集需求设计需求研发
其中，每个阶段分别对应了三个模式：
急诊模式登机模式看板模式
其中，让整个需求管理流程顺畅进行的是公交模型。也就是说，需求收集阶段、需求设计阶段、需求研发阶段，变换成2周为一个管理周期的公交车，让需求按照固定线路上车，完成需求的生命周期。
这样的流程设计，可以让需求得到充分的评估和讨论。但是，缺点是一个需求给人的感知是经历一个月以上的时间，才能完成。
同时，需求池区分了不同的状态进行展示，其实存在重要性和优先级信息在需求研发阶段逐渐模糊的情况，特别是在测试工程师面对需求时，对于需求的重要性和优先级就无法正确判断。在有临时需求插队时，情况会更加严重。
在收集需求人意见的情况，对普拉姆需求管理方法进行优化。
10.2 优化需求管理流程
根据公交模型，将之前的三辆公交车（即三个阶段：需求收集、需求设计、需求研发），去掉需求设计阶段，缩减为两量公交车（即需求收集、需求研发）。
这样修改之后，需求的生命周期就会从结构上，最快缩短到4周以内，即在2个需求管理周期内完成。
同时对需求站会的开会时间，进行修改。将时间改在需求收集阶段接近尾声的位置，即每2周的周四开站会。这样给人感觉就是开完会之后，排好的需求在下两周就可以进行开发。
10.3 优化需求池
需求的优先级和重要性在任何阶段都应该是不变的。比如，即使需求进入到了测试阶段，高优的需求应该优先获得资源。
所以，根据以上的思想，对需求池的信息进行精简，主要是去掉状态信息，让处在研发、测试或者设计状态的需求，全部放在一个列表中，根据优先级和重要性进行排序。
需求的状态展示，就依托看板模式。
其中，Title是填写需求名称，Link是此需求的卡片链接，可以快速将需求查看需求相关信息。是涉及此需求的需求人、负责人等。Label是指哪一个类别的需求，比如可以填写部门。
这样，只要没有完成的需求，就可以处在这个需求池中，根据重要性和优先级进行排序，所有资源根据这个需求池的顺序进行安排。
10.4 普拉姆理论的缺陷
用了将近10章的篇幅，将普拉姆需求管理方法的最佳实践阐述完。但是，还有几个问题，虽然有解决的理论，但是没有经过实践检验得出可行的方法。
问题一：如何评估工作量？
这是一个难题。在敏捷开发中，采用估点的方式，得到比较之后的相对工作量。但是，在实践中却是比较难实现。或者说，如何让需求人和负责人清晰明确的了解所提需求的工作量。
问题二：如何确定需求完成的？
由问题一引发出如何评估需求完成的。在实践中，需求人和负责人最想知道的是最终完成时间。但是，时间上进行会存在估不准的情况。毕竟，大家都不是先知。如何才能比较正确评估出完成时间呢？是不是要采用置信区间呢？
问题三：如何处理长期堆积在需求池中的需求？
资源永远是有限的。所以需求池中的需求，可能会积压很长时间。达到三个月的需求，应该是如何处理呢？如何说服需求人，去处理长期挤压的需求。也许出现需求积压的问题是需求缺少规划。
最后
我所写的都是屎，唯有一点要坚持。
我将实践之后的需求管理理论写出来，里面有肯定有很多纰漏和漏洞。
虽然胡扯的地方很多，但是有一个观点，我一定会坚持。那就是普拉姆方法的宗旨：积极主动，知识共享，相互尊重。
不管任何需求管理的技巧，都应该围绕这个宗旨展开，这是超越任何方法论的方法。
水平有限，希望对你有所帮助。
作者：，产品经理/PMP认证/工业设计硕士，微信公众号，专注PM职业技能成长。
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，永久会员只需109元，全站资源免费下载 点击查看详情
站 长 微 信： nanadh666
