如何做好项目管理中的需求管理？90%的项目经理回答不出来
2024-10-10本文为学员投稿的原创作品，现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章，被采纳即可获得丰厚稿酬，欢迎大家关注公众号踊跃投稿。
如您有意向投稿，可点击查看投稿要求和方法，按文中方法将稿件投递给我们。
本人任职于某科技公司项目经理，主要帮助客户梳理现有的业务流程，借助公司自主研发的低代码平台实现流程的线上化，业务的数字化转型。
由于项目性质特殊，在实施期间，对于总体项目需要采用传统的瀑布式开发规划整个项目进度与范围，但在落实到每个节点时，又需要采用敏捷开发的方法，通过不断的版本更新让流程满足用户需求。
在整个过程里面，流程设计的相关方众多，需求繁杂，给需求的管理带来很大挑战。在学习了PMP后，尝试把学到的需求管理的方法运用到实际工作中，也颇有成效。
对于需求的管理第一步，肯定是收集项目干系人的相关需求。在企业业务流程里，普通的端到端流程，如采购流程，往往会涉及企业里面的多个部门和众多参与人员，选择合适的需求收集方法才能保证听到各方的声音，而不让设计出来的流程顾此失彼。
在收集需求的时候，PMP中提及过很多方法，像访谈、焦点小组、问卷调查等等。在我们实际的操作中，对于流程优化项目来说，比较倾向于使用头脑风暴与访谈相结合的方法。
进行头脑风暴时，会邀请流程所涉及部门的一到两个资深人员参与其中。通常步骤如下：
（1）框定范围：即要优化流程的起止点
（2）处理现有流程与产出
（3）基于现有流程列出痛点
（4）对痛点的梳理与合并
在进行头脑风暴时，主要任务是对业务现状进行梳理并有大概的理解。同时关注到业务相关方所面临的痛点，并把部门与部门之间的信息进行共享，对于要解决的问题达成初步共识。
在对每个痛点进入深入的挖掘与调研时，一般来说就会转换成访谈的手段。在进行流程的开发与优化时，前端有业务人员的参与，背后也涉及后台相关数据、权限等的管理，两者之间常常会有矛盾存在，如业务人员总希望流程精简操作简单，而对于后台的技术人员而言却希望能够流程能够足够完善把所有数据点都记录下来。
在收集需求的时候，我们应该要明白流程是业务导向，要为业务服务，所以在访谈的时候，应该更多地关注业务上的细节，并在充分考虑业务需求的基础上再匹配系统需求。
在经历一系列与用户的沟通后，对流程的使用者面临的痛点已经有了一定的了解。这时需要针对每个痛点设计大概的解决方法，转化为业务需求。
表1：业务痛点-需求转化表
整理出需求清单后，林林总总的需求还需要进行进一步的处理：对需求进行优先级排序。首先会对需求进行评估，常见的模型有ICE方法或Kana模型等。而在流程优化项目里，通常考虑的是影响范围和对业务的重要性两个维度，因此会根据这两个维度对需求进行打分，并进行优先级排列：
-
影响范围大，对业务很重要：高优先级
-
影响范围大，对业务不太重要：中/高优先级
-
影响范围小，对业务很重要：中/高优先级
-
影响范围小，对业务不太重要：低优先级
需求收集并排序完毕后，在根据需求进行实施前还需要对需求进行确认。上文提及，在端到端流程里，涉及的业务相关方众多，如果每一次的需求确认都需要把所有相关方集中在一起，按照经验，往往又是一轮新的无休止的争吵。因此需求的确认要找对人。
这时候RACI矩阵能帮助到我们。在前期的各种调研时，就需要针对出现的参与人员给到角色定位，对于R和A的相关方，是有必要及时让他们知道整体项目的方向与需求。同时还有一个不太正式的技巧，这种流程改造的项目，基本就是哪个部门出钱，谁就有最终的话语权能够决定项目的方向，进行需求确认。
在整个项目最终的需求确认好以后，项目组同事会设计整体的方案并进行方案评估。方案通过后，项目经理需要把所收集的需求转化成可执行的任务，并落实到确定的人员手上。对于某些复杂的需求，需要拆分为多个任务才能实现，因此需求与任务间的关系要构建清楚，才能为以后的跟踪打好基础。
在需求的执行过程中，多采用敏捷开发的方法，对需求进行排序并确定好具体的开发时间，优先级越高的需求，转化为任务的描述和解析就要越细致。采用滚动解析的方法对需求进行管理，让团队把时间与精力都集中在当下要完成的需求上。
表2: 需求– 任务转化表
创建需求跟踪表，每个需求都会有不同的状态进行标记：新需求，已分配需求，已完成需求。
对于已分配的需求，在每周举行的周例会时，团队成员需要及时更新这些需求对应任务的执行状态，让项目经理和其他团队成员能及时了解整个项目的进度，同时对于可能出现的风险提前采取措施应对。
对于已完成的需求，项目经理会从及时性与质量两个维度对该需求的完成进行考核，并记录在需求跟踪表中。
对于新需求，项目经理需要定期审阅，保证这些已经存在的新需求是满足客户要求而且符合业务的发展。除此之外，因为采用滚动解析需求的方法，项目经理还需要根据项目的进展对需求进行详细解析，方便项目的推进。
需求是不断变化的，有可能是客户直接提出，也有可能是由于开发过程中内部因素导致。首先对于需求的变更会分为两个不同的场景来展开：
（1）新需求的变更
新需求因为还没执行，因此针对这类需求的变更实际操作会相对简单。在对变更进行评审后，如果评审通过，项目经理可直接更改需求池里的新需求，并且根据实际需求更改需求的优先级。
（2）已分配的需求变更
针对这类正在进行的需求，第一步也是需要经过相关方的评审，只有批准后的变更才能被执行。
批准后的变更，项目经理需要添加变更记录，并绑定到原需求中，同时告知到需求的执行人员。由于变更会导致需求的执行时间有所变化，因此在变更记录中需注明变更后对项目进度的影响。
在整个项目实施过程里面，利用低代码平台已经实现流程的线上化，因此相关的节点与文档都以项目为基础进行存档。项目和需求进行绑定，需求与任务进行绑定，同时变更也与需求相绑定并反应到任务上。过程文档架构清晰，无论是执行过程还是项目结束后，对需求的管理也能一目了然。
图1：项目需求和变更管理表
在项目结束后，其中一个重要的环节是对需求进行回顾。由于业务的特性，在流程优化项目中有些需求是有共性的。 例如针对流程的类型，如审批流，通常会对流程的进度监控有要求，以及审批过程往往会要求能够发起协同。或者即使是不同的企业，财务部门对数据的保密性要求更高。
因此对需求进行回顾并根据不同的特征形成“需求画像”，有利于我们积累经验，快速形成方案，以满足用户需求。
