数十万互联网从业者的共同关注！
作
者：wideplum，作者授权早读课转载。
公众号：wideplum
编辑：Verna
本文适合0-2岁产品经理阅读，产品大牛、敏捷管理大师请绕过。
通过这篇文章，总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是，用最轻量化的投入，与他人协作，并管理需求，推动需求上线。这套方法论组合了项目管理、敏捷开发的知识，希望能对大家有所帮助。
1.1 我们的工作是否像救火
总是做迫在眉睫的事情，会令人丧失目标。
——《普拉姆原则》
我在工作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精力，时间长久就会缺乏动力。
上面讲的是个人的角度，如果一个组织或者团队面对大量的需求，在处理需求的时候，没有节奏和规划，会产生消极的影响。从小的方面看会影响团队士气，往大的方面看，会影响组织实现既定的目标。
我的工作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为一个桥梁，保障业务运营团队从我这里输出高质量的需求，也要保障具有不同知识背景团队，能过通过需求，高效沟通，快速推进需求上线。
于是，我就通过工作实践，形成了自己的管理需求方法论——普拉姆方法。
存在即有标识。
——《普拉姆原则》
为了便于总结和归纳，我给这个方法论起了个名字。在需求管理中，需求的名称也是很重要的因素，之后会提到。
1.2 需求管理是什么？
我的定义是，
通过协作，管理需求内容和进程，实现成功发布。
便于理解这个概念，在这里讲一个海湾战争的故事。
在海湾战争中，美军在前期并没有派出大规模的地面部队进行战术打击。而是，派出一批批的特种部队渗透到敌人境内，侦查清楚敌人重要的军事目标，并将精准坐标和信息，传递给后方。顷刻之间，海洋上的战舰派出飞机和战斧导弹对其进行精准轰炸，并取得战术和战略上的胜利。
在这个例子中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。产品经理通过需求管理的方法论，用高效和轻量化的方式，去精准的做出需求，实现预期的效果。
1.3 宗旨是什么？
普拉姆方法的宗旨是积极主动，知识共享，相互尊重。
什么是宗旨？可以理解为这套方法论的价值观。这套方法论的每一个细节，都应该遵循这个宗旨来实践，并遵循这个宗旨发展和进化。
“积极主动，知识共享，相互尊重”的宗旨，是我借鉴了美国西南航空的价值观。美国西南航空是美国航空业受到911事件巨大打击的背景下，依然能够盈利的廉价航空。在航空业极为复杂的管理模式下，使用廉价航空的经营方式实现盈利，还是令人十分震撼的。所以，阅读了相关书籍之后，将美国西南航空的价值观的精华，吸纳为普拉姆方法的宗旨。
积极主动
积极主动是核心，具体指团体之间的成员积极主动的承担责任去做事情。
在《高效能人士的七个习惯》中，积极主动也被列为很重要的素质。在管理每个需求的过程中，每个人都要有担当或者忽略角色的做事情。这也是敏捷开发中推崇的。一个产品经理在不同的需求中，可能既是梳理需求、输出原型的角色，又可能是测试的角色。但是，团队中每个工作的角色在变，通过管理需求达成的目标不会变。
请明确讲清需求的目标！我会像战士，即使身陷重围，也会向胜利的方向战斗！
——《普拉姆原则》
知识共享
知识共享，是指分享不同团队的领域知识，减少沟通的未知区域，减少沟通中的误解。
有一个Johari窗格的沟通理论，专门提到沟通分为四个区域，即开放区、盲目区、隐秘区、未知区。通过扩大开放区，来提升沟通的效率和效果。
同时，
“公则生明”，即将信息公开透明，可以增加协作团队之间的信任。
比如，公开展示各需求的进度。
讲个题外的故事，俞永福对产品经理说过，产品经理要有树靶子的意识。自己的需求就是靶子。公司内部的任何人都可以打靶子。每个产品经理有责任，维护好自己的靶子，不被打漏。所以，产品经理自己要让自己的需求健壮，不被打漏。
从另外的角度看，
尽早的把问题暴露，可以最大的降低解决问题的成本，防止问题积累成一个“惊喜”
。
相互尊重
相互尊重，是指尊重每一个人的人格、劳动及输出成果。
在管理需求的过程中，要与不同岗位的人打交道。每个人站在不同的立场，必然会有看待问题的不同角度。所以，大家在合作的过程中，要相互尊重。内在的思想是人格上的尊重，外在的表现是尊重别人的劳动成果。不要站在自己的立场和知识背景，去简单评判别人的劳动。
对他人劳动的尊重，就是对他人的尊重。
1.4 结尾
这是文章的的开篇，湿货很多。可能都是大家知道的常识。不过，常识并不常用。把常识内化为行动之中，可以让事半功倍，至少不会犯错。
识别出需求的干系人，是需求管理中非常重要的起点。之后的需求管理活动要与干系人及角色，进行紧密的合作。
2.1 什么是干系人
干系人，是来自于项目管理中的概念。
项目干系人是能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。他们也可能对项目及其可交付成果施加影响。干系人可能来自组织内部的不同层级，具有不同级别的职权；也可能来自项目执行组织的外部。
——《项目管理知识体系指南(PMBOK指南)(第5版)》
总结的简单点，
干系人是与需求相关的人或者组织。
而且干系人在需求管理中起到很重要的作用。特别是在做跟业务流程密切结合的需求时，找到并找对干系人极为重要。在需求中的每个人，都会从自己的立场出发提需求，可能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的角度去思考需求，或者找到那个能从全局思考的干系人去帮助找到需求中的障碍。
有人就会有角色，每个角色必然有不同的关注点，被忽略的关注点都变成了坑。
——《普拉姆原则》
这里再扩展一点，就是需求可能存在二律背反的情况。也就是说，提一个优化改善的需求，可能会损害其他流程或角色的利益。有时，产品经理要找到需求的受害者，从而更全面的了解需求。
不害人的需求，不是完整的需求。
——《普拉姆原则》
所以，
找到和找对需求的干系人，对于需求管理非常重要。
2.2 需求管理中的角色
在《西游记》中，六小龄童扮演的角色多达16个，最知名的就是孙悟空，还有道士、和尚之类的角色。而唐僧的角色，就有三位演员扮演过。同理，在需求管理中，干系人是一个个的演员，而演员可以担任多个角色。
以下是我在从事后端系统的工作中遇到的角色。
需求人
顾名思义，真正提出需求并描述需求细节的角色。这个角色可以是任何干系人，毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起，有助于判断所提需求的立场。
负责
人
负责人也来自于业务部门。收集需求人的需求，从业务角度对需求进行梳理和判断，并转发给产品经理和研发同事。当业务团队远大于技术和产品团队时，负责人的角色就非常重要。如果业务团队的人数小于等于技术团队时，可以省去这个角色。
负责人，就像一个漏斗和筛子一样，初步筛选一遍需求。毕竟，评估需求也是要花费时间，特别是占用研发同事的时间。
产品经理
需求管理的组织者、推动者。以“积极主动”的态度，与需求管理的角色进行沟通。
研发经理
研发资源的管理者。在这里的研发经理，一般是带四、五个人小团队的级别。因为，他们能够了解每个研发工程师的工作和能力，协助评估业务需求。
研发工程师
实际参与研发需求的程序员。
测试工程师
参与需求测试的测试人员。可以根据公司的组织架构，增加测试经理的角色。测试经理的级别也是带四、五个人小团队。
在需求管理中，产品经理要当成一个桥梁，与不同的角色，进行沟通和协作。在后面，需求管理的流程和需求看板的管理方法，都会与这些角色紧密相关。
2.3 如何识别干系人和角色
了解所在公司的组织架构，以及团队组织架构，是识别干系人和对应角色的关键。
产品经理可以根据组织架构，明确了解到研发和测试的相关角色。
同时，产品经理可以跟业务团队进行沟通，了解业务团队的业务背景和知识，以及团队文化。
识别出潜在的需求人，才是真正的考验。
以上，就是需求管理中干系人的相关内容。
普拉姆方法的运行流程包含三个模式：急诊模式、登机模式、看板模式。本章将介绍这三个模式与公交模型的关系，提供一套应对”越快越好“类需求的方法。
3.1 破解“越快越好“的局面
在接到来自各部门的需求时，每个需求都会打上”越快越好“的标签。站在提需求者（需求人和负责人）的角度，研发资源是稀缺的，老板的要求是急迫的，如果不表达需求的急切性，需求就排不上。
这就像飞机迫降之后，每个人都会带着”越快越好“目的奔向出口，如果没有空乘人员的指挥，最后大家慌不择路的堵在出口，最终导致延误了逃生时间。
处理工作的模式：划散乱为规律，划应急为预测。
——《普拉姆原则》
所以，可以借鉴急诊室的场景 ，来规划”越快越好“的需求，让需求管理有序的运行起来。
3.2 急诊室的场景
产品经理面对的需求，就是来看急诊的病人。病人都会觉得自己应该马上得到最快的医疗救治。但是，医疗资源有限，只能让医生先救治最危重的病人，病情较轻的病人要先等待一下。这个时候，需要有一个预检分诊的流程，预先对病人进行判定和分诊，从而让急诊室高效的运转起来。
因此，借鉴急诊室的做法，我们对需求增加一个”预检分诊“的预处理模式。
从而对”越快越好“的需求，进行区分，在研发资源稀缺的情况下，让真正紧急的需求获得资源
。
3.3 让需求管理运转——公交模型
设想一下，病人去急诊楼就医的时候，我们安排了”预检分诊“（预处理）的流程。那么就需要安排一个房间，让病人们在那里等候，并安排医生进行诊断。然后，病人根据预检医生的诊断，再从这里出来，去对应的诊室去看病。
所以，
要让这个流程在需求管理中正常的运行，就需要采用公交模型。
公交模型，是我结合火车模型发布模式，起得一个通俗易懂的名字。
（火车模型发布模式是）以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法。
——《启示录——打造用户喜爱的产品》
公交模型，就像我要从到家到公司要换乘3趟公交车去上班，到公交站等车。每趟公交车之间都有发车间隔和到站时刻，并且周而复始的经过公交站。所以，我就按照规划好的路线，从公交站坐车，再到下一个换乘站乘车。
从公交模型中，可以提炼出几个概念：出行路线、发车间隔、到站时刻。
在公交模型中，出行路线称为”需求管理流程“，发车间隔称为”需求管理周期“。到站时刻，称为”需求时间“。
3.3.1 需求管理流程
需求管理流程，是指在需求管理中，按照顺序依次进行需求管理活动。
需求管理活动按先后顺序分为
三个阶段：需求收集、需求设计、需求研发。
再强调一遍，这三个阶段是依次进行的。先进行需求收集、在进行需求设计、最后进行需求研发。
每一阶段的需求管理活动对应一个指导原则。指导原则就是急诊模式、登机模式、看板模式。急诊模式指导需求收集，登机模式指导需求设计，看板模式指导需求研发。
在文章的开头，我用急诊室的场景，介绍了急诊模式。后续的章节中，我会介绍剩下的两种模式：登机模式和看板模式。
3.3.2 需求管理周期
需求管理周期，简称”周期“，是需求管理活动按顺序重复出现，并完成需求管理活动的时间叫做需求周期。
普拉姆方法的需求周期，是80小时，即2个星期。80小时原则，来自于项目管理中的工作分解结构。根据项目管理的一般经验，将一个项目中的工作，按照80小时的工作量进行拆分比较合理。所以，每一类需求管理活动按照2周的工作量进行。
换句话说，需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车，三辆公交车运行一趟的时间是2周。每个需求相当于是乘客，要根据路线（需求管理流程）在公交站等车。当然，每个需求的终点就是发布上线。
3.3.3 需求时间
在需求管理活动中，进行某一项具体活动的时间点，就是需求时间。
一般，需求时间意味着规则。比如，需求设计阶段的周二的下午2：00，需要开排期站会，这是一个约定好的时间，需求的相关方都必须要来。排期站会后面再介绍。
3.3.4 运转模式
如果一个需求从开始到发布上线的生命周期来看，公交模型是下面这个样子。
从需求管理周期的角度，无数需求按照公交模型去运转着。从参与到需求管理的角色来看，每一个周期中的需求收集、需求设计、需求研发阶段，参与者的工作是连续可预测的。每个角色各司其职，让需求管理顺畅的进行下去。
3.4 总结
这章通过介绍急诊室的故事，也就是急诊模式，来引出破局”越快越好“类需求的方法，以及后面要介绍的登机模式和看板模式。这三个模式用来分别指导需求收集、需求设计、需求研发三个阶段的需求管理活动。
同时介绍了推动需求运作的公交模型，让需求管理活动具有预测性和规划性。
本章之后，将依次介绍三个模式和三个阶段对应的方法和工具。
4.1 再谈需求人和负责人
在《需求管理的三个模式与公交模型》中谈到，需求就像来急诊室的病人，只有经过“预检分诊”的过程，判断出需求的轻重缓急，从而匹配出对应的资源。
那么，在实际的场景下应该如何应用急诊模式呢？
首先回忆一下《需求管理中的干系人和角色》中，提到了角色有需求人和负责人。
需求人
，这个角色来自于公司或者组织的任何方面，他们是提出需求的人。
负责人
，这个角色负责收集需求，特别是业务需求。当业务团队的人数，远远大于研发团队时，这个角色非常的重要。
需求人和负责人在应用急诊模式时，处在比较重要的位置。
4.2 急诊模式的应用流程
急诊模式的应用流程如下图：
其中，圆角方形代表操作步骤，直角方形代表输出物。
在这里复述一下整体的步骤。
-
需求人提交需求。提交需求的模板，之后的章节会介绍。
-
负责人收集需求文件，初步评审需求。在这里，如果需求存在不合理的状况，特别是业务流程不合理，负责人可以将需求打回需求人重新整理。
-
产品经理、研发经理初步评审，并放入待排期列表。产品经理拿到负责人评审通过的需求，与开发经理进行初步评估，判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板，之后的文章也会介绍。不合理的需求，也会打回。
-
根据待排期列表，需求人、负责人、产品经理、研发经理评定待排期列表中的需求，生成待开发列表。在这个过程，会应用一个工具——排期站会。这个工具，之后也会介绍。经过排期站会后，形成待开发列表。
在需求收集阶段，以上所有步骤是应用急诊模式的过程。
4.3 关于时间的把控
在《需求管理的三个模式与公交模型》中，公交模型下，会有三辆“公交车”，即需求收集、需求设计、需求研发。因为需求管理的时间周期可以是2周，所以每辆“公交车”的发车周期是2周。
换句话说，在需求收集阶段，执行急诊模式的操作步骤的时间是2周。
其中，需要关注几个需求时间。
在需求管理活动中，进行某一项具体活动的时间点，就是需求时间。
需求收集的开始时间和结束时间
关注需求收集的开始时间和结束时间，因为二者相减，约等于2周，或者说约等于2周的工作时间。因为每个公司的工作习惯不一样，可能会涉及到固定时间点的例会等，所以，需求开始时间和结束时间设置要灵活。
同时，需求收集的开始时间和结束时间，要有一定原则性。产品经理要尽量影响需求人，不要赶在紧邻结束时间提交需求。就好比，在现实生活中赶火车，总要提前一会儿到达车站，毕竟还要有检票进站等环节。同样，需求人在临近结束时间提交需求，负责人评审需求和产品经理评审需求的时间，都不能保证，会影响需求的质量，以及之后的排期站会的质量。
所以，为了规避这种情况，可以在需求收集结束前5天，发送排期站会的会议邀请，以此提醒大家马上就要排期需求了，赶紧提交需求。
排期站会的时间
排期站会的具体内容和形式，后面的文章会提到。这里先提一下排期站会的时间。
排期站会的时间紧邻需求收集的结束时间。换句话说，需求收集一结束，立刻开始排期站会。
因为排期站会，需要需求人、负责人、产品经理、研发经理及研发工程师参加，所以要多方协调一个大家都有空的时间进行。
排期站会的时长控制在一个小时内。
4.4 结语
本章介绍了在需求收集阶段，应用急诊模式的流程步骤。
之后将介绍，在需求收集阶段的3个工具：需求提交模板、需求排期列表、排期站会。
本章介绍一套收集需求的模板。通过模板规范需求的内容，以及提升沟通的效率。
5.1 应用场景
模板应用在需求收集阶段，方便需求人提供和描述相应需求，便于负责人、产品经理、研发经理等角色评审需求。
利用此需求模板，可以快速提取需求信息，便于存档和查阅。
5.2 模板样式
此需求模板在填写上有如下说明：
需求提交部门
填写需求人的所在部门。
功能使用角色
比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
使用频次
单位时间内预计使用功能的次数。比如，10次/月。方便判断此需求的优先级。
提交时间
记录需求提交的时间，便于使用“先入先出”原则。
“先入先出”原则，来自于仓储的概念，指的是先进入仓库的商品先出库。比如，食品行业有保质期的要求，需要生产越早的食品，越早出库。
再形象一点，把处理需求的过程理解为一根管子，新进入管子的需求，就先从另一头流出。
因为需求对应的场景和业务可能会变化很快，如果积压时间太久的需求，就变贬值，跟不上现有业务的发展，所以要应用“先进先出”的原则。
优先级和重要性
这两个概念下一章重点介绍。
