软件需求管理知识及案例

软件需求管理知识及案例
软件需求管理知识及案例
通过这篇⽂章，总结⾃⼰在⼯作实践中需求管理的⽅法论——普拉姆⽅法。

总结这个⽅法论的特点是，⽤最轻量化的投⼊，与他⼈协作，并管理需求，推动需求上线。

这套⽅
法论组合了项⽬管理、敏捷开发的知识，希望能对⼤家有所帮助。

1. 为什么要做需求管理？
1.1 我们的⼯作是否像救⽕
总是做迫在眉睫的事情，会令⼈丧失⽬标。

——《普拉姆原则》
我在⼯作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精⼒，时间长久就会缺乏动⼒。

上⾯讲的是个⼈的⾓度，如果⼀个组织或者团队⾯对⼤量的需求，在处理需求的时候，没有节奏和规划，会产⽣消极的影响。

从⼩的⽅⾯看会影响团队⼠⽓，往⼤的⽅⾯看，会
影响组织实现既定的⽬标。

我的⼯作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为⼀
个桥梁，保障业务运营团队从我这⾥输出⾼质量的需求，也要保障具有不同知识背景团队，能过通过需求，⾼效沟通，快速推进需求上线。

于是，我就通过⼯作实践，形成了⾃⼰的管理需求⽅法论——普拉姆⽅法。

存在即有标识。

——《普拉姆原则》
为了便于总结和归纳，我给这个⽅法论起了个名字。

在需求管理中，需求的名称也是
很重要的因素，之后会提到。

1.2 需求管理是什么？
我的定义是，通过协作，管理需求内容和进程，实现成功发布。

便于理解这个概念，在这⾥讲⼀个海湾战争的故事。

在海湾战争中，美军在前期并没有派出⼤规模的地⾯部队进⾏战术打击。

⽽是，派出
⼀批批的特种部队渗透到敌⼈境内，侦查清楚敌⼈重要的军事⽬标，并将精准坐标和信息，传递给后⽅。

顷刻之间，海洋上的战舰派出飞机和战斧导弹对其进⾏精准轰炸，并取得战
术和战略上的胜利。

在这个例⼦中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。

产品经理通
过需求管理的⽅法论，⽤⾼效和轻量化的⽅式，去精准的做出需求，实现预期的效果。

1.3 宗旨是什么？
普拉姆⽅法的宗旨是积极主动，知识共享，相互尊重。

什么是宗旨？可以理解为这套⽅法论的价值观。

这套⽅法论的每⼀个细节，都应该遵
循这个宗旨来实践，并遵循这个宗旨发展和进化。

“积极主动，知识共享，相互尊重”的宗旨，是我借鉴了美国西南航空的价值观。

美
国西南航空是美国航空业受到911事件巨⼤打击的背景下，依然能够盈利的廉价航空。

在航空业极为复杂的管理模式下，使⽤廉价航空的经营⽅式实现盈利，还是令⼈⼗分震撼的。

所以，阅读了相关书籍之后，将美国西南航空的价值观的精华，吸纳为普拉姆⽅法的宗旨。

（1）积极主动
积极主动是核⼼，具体指团体之间的成员积极主动的承担责任去做事情。

在《⾼效能⼈⼠的七个习惯》中，积极主动也被列为很重要的素质。

在管理每个需求
的过程中，每个⼈都要有担当或者忽略⾓⾊的做事情。

这也是敏捷开发中推崇的。

⼀个产
品经理在不同的需求中，可能既是梳理需求、输出原型的⾓⾊，⼜可能是测试的⾓⾊。

但是，团队中每个⼯作的⾓⾊在变，通过管理需求达成的⽬标不会变。

请明确讲清需求的⽬标！我会像战⼠，即使⾝陷重围，也会向胜利的⽅向战⽃！——《普拉姆原则》
（2）知识共享
知识共享，是指分享不同团队的领域知识，减少沟通的未知区域，减少沟通中的误解。

有⼀个Johari窗格的沟通理论，专门提到沟通分为四个区域，即开放区、盲⽬区、隐秘区、未知区。

通过扩⼤开放区，来提升沟通的效率和效果。

同时，“公则⽣明”，即将信息公开透明，可以增加协作团队之间的信任。

⽐如，公
开展⽰各需求的进度。

讲个题外的故事，俞永福对产品经理说过，产品经理要有树靶⼦的意识。

⾃⼰的需求
就是靶⼦。

公司内部的任何⼈都可以打靶⼦。

每个产品经理有责任，维护好⾃⼰的靶⼦，
不被打漏。

所以，产品经理⾃⼰要让⾃⼰的需求健壮，不被打漏。

从另外的⾓度看，尽早的把问题暴露，可以最⼤的降低解决问题的成本，防⽌问题积
累成⼀个“惊喜”。

（3）相互尊重
相互尊重，是指尊重每⼀个⼈的⼈格、劳动及输出成果。

在管理需求的过程中，要与不同岗位的⼈打交道。

每个⼈站在不同的⽴场，必然会有
看待问题的不同⾓度。

所以，⼤家在合作的过程中，要相互尊重。

内在的思想是⼈格上的
尊重，外在的表现是尊重别⼈的劳动成果。

不要站在⾃⼰的⽴场和知识背景，去简单评判
别⼈的劳动。

对他⼈劳动的尊重，就是对他⼈的尊重。

1.4 结尾
这是⽂章的的开篇，湿货很多。

可能都是⼤家知道的常识。

不过，常识并不常⽤。

把
常识内化为⾏动之中，可以让事半功倍，⾄少不会犯错。

2. 需求管理中的⼲系⼈和⾓⾊
识别出需求的⼲系⼈，是需求管理中⾮常重要的起点。

之后的需求管理活动要与⼲系
⼈及⾓⾊，进⾏紧密的合作。

2.1 什么是⼲系⼈
⼲系⼈，是来⾃于项⽬管理中的概念。

项⽬⼲系⼈是能影响项⽬决策、活动或结果的个⼈、群体或组织，以及会受或⾃认为
会受项⽬决策、活动或结果影响的个⼈、群体或组织。

他们也可能对项⽬及其可交付成果
施加影响。

⼲系⼈可能来⾃组织内部的不同层级，具有不同级别的职权；也可能来⾃项⽬
执⾏组织的外部。

——《项⽬管理知识体系指南(PMBOK指南)(第5版)》
总结的简单点，⼲系⼈是与需求相关的⼈或者组织。

⽽且⼲系⼈在需求管理中起到很重要的作⽤。

特别是在做跟业务流程密切结合的需求时，找到并找对⼲系⼈极为重要。

在需求中的每个⼈，都会从⾃⼰的⽴场出发提需求，可
能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的⾓度去思考
需求，或者找到那个能从全局思考的⼲系⼈去帮助找到需求中的障碍。

有⼈就会有⾓⾊，每个⾓⾊必然有不同的关注点，被忽略的关注点都变成了坑。

——《普拉姆原则》
这⾥再扩展⼀点，就是需求可能存在⼆律背反的情况。

也就是说，提⼀个优化改善的
需求，可能会损害其他流程或⾓⾊的利益。

有时，产品经理要找到需求的受害者，从⽽更
全⾯的了解需求。

不害⼈的需求，不是完整的需求。

——《普拉姆原则》
所以，找到和找对需求的⼲系⼈，对于需求管理⾮常重要。

2.2 需求管理中的⾓⾊
在《西游记》中，六⼩龄童扮演的⾓⾊多达16个，最知名的就是孙悟空，还有道⼠、和尚之类的⾓⾊。

⽽唐僧的⾓⾊，就有三位演员扮演过。

同理，在需求管理中，⼲系⼈是
⼀个个的演员，⽽演员可以担任多个⾓⾊。

以下是我在从事后端系统的⼯作中遇到的⾓⾊：
（1）需求⼈
顾名思义，真正提出需求并描述需求细节的⾓⾊。

这个⾓⾊可以是任何⼲系⼈，毕竟
产品经理是⼀个负责从四⾯⼋⽅收集需求的⼈。

需求⼈⼀般要与其所在的部门联系在⼀起，有助于判断所提需求的⽴场。

（2）负责⼈
负责⼈也来⾃于业务部门。

收集需求⼈的需求，从业务⾓度对需求进⾏梳理和判断，
并转发给产品经理和研发同事。

当业务团队远⼤于技术和产品团队时，负责⼈的⾓⾊就⾮
常重要。

如果业务团队的⼈数⼩于等于技术团队时，可以省去这个⾓⾊。

负责⼈，就像⼀个漏⽃和筛⼦⼀样，初步筛选⼀遍需求。

毕竟，评估需求也是要花费
时间，特别是占⽤研发同事的时间。

（3）产品经理
需求管理的组织者、推动者。

以“积极主动”的态度，与需求管理的⾓⾊进⾏沟通。

（4）研发经理
研发资源的管理者。

在这⾥的研发经理，⼀般是带四、五个⼈⼩团队的级别。

因为，
他们能够了解每个研发⼯程师的⼯作和能⼒，协助评估业务需求。

（5）研发⼯程师
实际参与研发需求的程序员。

（6）测试⼯程师
参与需求测试的测试⼈员。

可以根据公司的组织架构，增加测试经理的⾓⾊。

测试经
理的级别也是带四、五个⼈⼩团队。

在需求管理中，产品经理要当成⼀个桥梁，与不同的⾓⾊，进⾏沟通和协作。

在后⾯，需求管理的流程和需求看板的管理⽅法，都会与这些⾓⾊紧密相关。

2.3 如何识别⼲系⼈和⾓⾊
了解所在公司的组织架构，以及团队组织架构，是识别⼲系⼈和对应⾓⾊的关键。

产品经理可以根据组织架构，明确了解到研发和测试的相关⾓⾊。

同时，产品经理可以跟业务团队进⾏沟通，了解业务团队的业务背景和知识，以及团
队⽂化。

识别出潜在的需求⼈，才是真正的考验。

以上，就是需求管理中⼲系⼈的相关内容。

3. 需求管理的三个模式与公交模型
普拉姆⽅法的运⾏流程包含三个模式：急诊模式、登机模式、看板模式。

本章将介绍
这三个模式与公交模型的关系，提供⼀套应对”越快越好“类需求的⽅法。

3.1 破解“越快越好“的局⾯
在接到来⾃各部门的需求时，每个需求都会打上”越快越好“的标签。

站在提需求者（需求⼈和负责⼈）的⾓度，研发资源是稀缺的，⽼板的要求是急迫的，如果不表达需求
的急切性，需求就排不上。

这就像飞机迫降之后，每个⼈都会带着”越快越好“⽬的奔向出⼝，如果没有空乘⼈
员的指挥，最后⼤家慌不择路的堵在出⼝，最终导致延误了逃⽣时间。

处理⼯作的模式：划散乱为规律，划应急委预测。

——《普拉姆原则》
所以，可以借鉴急诊室的场景，来规划”越快越好“的需求，让需求管理有序的运⾏起来。

3.2 急诊室的场景
产品经理⾯对的需求，就是来看急诊的病⼈。

病⼈都会觉得⾃⼰应该马上得到最快的
医疗救治。

但是，医疗资源有限，只能让医⽣先救治最危重的病⼈，病情较轻的病⼈要先
等待⼀下。

这个时候，需要有⼀个预检分诊的流程，预先对病⼈进⾏判定和分诊，从⽽让
急诊室⾼效的运转起来。

因此，借鉴急诊室的做法，我们对需求增加⼀个”预检分诊“的预处理模式。

从⽽对”越快越好“的需求，进⾏区分，在研发资源稀缺的情况下，让真正紧急的需求获得资源。

3.3 让需求管理运转——公交模型
设想⼀下，病⼈去急诊楼就医的时候，我们安排了”预检分诊“（预处理）的流程。

那么就需要安排⼀个房间，让病⼈们在那⾥等候，并安排医⽣进⾏诊断。

然后，病⼈根据
预检医⽣的诊断，再从这⾥出来，去对应的诊室去看病。

所以，要让这个流程在需求管理中正常的运⾏，就需要采⽤公交模型。

公交模型，是我结合⽕车模型发布模式，起得⼀个通俗易懂的名字。

（⽕车模型发布模式是）以固定的周期持续发布产品，如果某项既定功能未完成，就
挪到下个周期发布的开发⽅法——《启⽰录——打造⽤户喜爱的产品》
公交模型，就像我要从到家到公司要换乘3趟公交车去上班，到公交站等车。

每趟公交车之间都有发车间隔和到站时刻，并且周⽽复始的经过公交站。

所以，我就按照规划好
的路线，从公交站坐车，再到下⼀个换乘站乘车。

从公交模型中，可以提炼出⼏个概念：出⾏路线、发车间隔、到站时刻。

在公交模型中，出⾏路线称为”需求管理流程“，发车间隔称为”需求管理周期“。

到站时刻，称为”需求时间“。

（1）需求管理流程
需求管理流程，是指在需求管理中，按照顺序依次进⾏需求管理活动。

需求管理活动按先后顺序分为三个阶段：
需求收集
需求设计
需求研发
再强调⼀遍，这三个阶段是依次进⾏的。

先进⾏需求收集、在进⾏需求设计、最后进⾏需求研发。

每⼀阶段的需求管理活动对应⼀个指导原则。

指导原则就是急诊模式、登机模式、看板模式。

急诊模式指导需求收集，登机模式指导需求设计，看板模式指导需求研发。

在⽂章的开头，我⽤急诊室的场景，介绍了急诊模式。

后续的章节中，我会介绍剩下的两种模式：登机模式和看板模式。

（2）需求管理周期
需求管理周期，简称”周期“，是需求管理活动按顺序重复出现，并完成需求管理活动的时间叫做需求周期。

普拉姆⽅法的需求周期，是80⼩时，即2个星期。

80⼩时原则，来⾃于项⽬管理中的⼯作分解结构。

根据项⽬管理的⼀般经验，将⼀个项⽬中的⼯作，按照80⼩时的⼯作量进⾏拆分⽐较合理。

所以，每⼀类需求管理活动按照2周的⼯作量进⾏。

换句话说，需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车，三辆公交车运⾏⼀趟的时间是2周。

每个需求相当于是乘客，要根据路线（需求管理流程）在公交站等车。

当然，每个需求的终点就是发布上线。

（3）需求时间
在需求管理活动中，进⾏某⼀项具体活动的时间点，就是需求时间。

⼀般，需求时间意味着规则。

⽐如，需求设计阶段的周⼆的下午2：00，需要开排期站会，这是⼀个约定好的时间，需求的相关⽅都必须要来。

排期站会后⾯再介绍。

（4）运转模式
如果⼀个需求从开始到发布上线的⽣命周期来看，公交模型是下⾯这个样⼦。

从需求管理周期的⾓度，⽆数需求按照公交模型去运转着。

从参与到需求管理的⾓⾊来看，每⼀个周期中的需求收集、需求设计、需求研发阶段，参与者的⼯作是连续可预测的。

每个⾓⾊各司其职，让需求管理顺畅的进⾏下去。

3.4 总结
这章通过介绍急诊室的故事，也就是急诊模式，来引出破局”越快越好“类需求的⽅法，以及后⾯要介绍的登机模式和看板模式。

这三个模式⽤来分别指导需求收集、需求设计、需求研发三个阶段的需求管理活动。

同时介绍了推动需求运作的公交模型，让需求管理活动具有预测性和规划性。

4. 急诊模式在需求收集中的应⽤
4.1 再谈需求⼈和负责⼈
在《需求管理的三个模式与公交模型》中谈到，需求就像来急诊室的病⼈，只有经过“预检分诊”的过程，判断出需求的轻重缓急，从⽽匹配出对应的资源。

那么，在实际的场景下应该如何应⽤急诊模式呢？
⾸先回忆⼀下《需求管理中的⼲系⼈和⾓⾊》中，提到了⾓⾊有需求⼈和负责⼈。

需求⼈，这个⾓⾊来⾃于公司或者组织的任何⽅⾯，他们是提出需求的⼈。

负责⼈，这个⾓⾊负责收集需求，特别是业务需求。

当业务团队的⼈数，远远⼤于研发团队时，这个⾓⾊⾮常的重要。

需求⼈和负责⼈在应⽤急诊模式时，处在⽐较重要的位置。

4.2 急诊模式的应⽤流程
急诊模式的应⽤流程如下图：
其中，圆⾓⽅形代表操作步骤，直⾓⽅形代表输出物。

在这⾥复述⼀下整体的步骤。

需求⼈提交需求。

提交需求的模板，之后的章节会介绍。

负责⼈收集需求⽂件，初步评审需求。

在这⾥，如果需求存在不合理的状况，特别是
业务流程不合理，负责⼈可以将需求打回需求⼈重新整理。

产品经理、研发经理初步评审，并放⼊待排期列表。

产品经理拿到负责⼈评审通过的
需求，与开发经理进⾏初步评估，判断需求是否可⾏。

可⾏的需求放⼊待排期列表。

待排
期列表的模板，之后的⽂章也会介绍。

不合理的需求，也会打回。

根据待排期列表，需求⼈、负责⼈、产品经理、研发经理评定待排期列表中的需求，
⽣成待开发列表。

在这个过程，会应⽤⼀个⼯具——排期站会。

这个⼯具，之后也会介绍。

经过排期站会后，形成待开发列表。

在需求收集阶段，以上所有步骤是应⽤急诊模式的过程。

4.3 关于时间的把控
在《需求管理的三个模式与公交模型》中，公交模型下，会有三辆“公交车”，即需
求收集、需求设计、需求研发。

因为需求管理的时间周期可以是2周，所以每辆“公交车”的发车周期是2周。

换句话说，在需求收集阶段，执⾏急诊模式的操作步骤的时间是2周。

其中，需要关注⼏个需求时间。

在需求管理活动中，进⾏某⼀项具体活动的时间点，就是需求时间。

（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）需求⽂档
任何形式的需求⽂档，都不如流程图简单明了，便于沟通。