软件需求管理知识及案例

软件需求管理知识及案例通过这篇文章，总结自己在工作实践中需求管理的方法论——普拉姆方法。

总结这个方法论的特点是，用最轻量化的投入，与他人协作，并管理需求，推动需求上线。

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

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）需求管理流程需求管理流程，是指在需求管理中，按照顺序依次进行需求管理活动。

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

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

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

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

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

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

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