才聚

本文为学员投稿的原创作品，现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章，被采纳即可获得丰厚稿酬，欢迎大家关注公众号踊跃投稿。

 

如您有意向投稿，可点击查看投稿要求和方法，按文中方法将稿件投递给我们。

据权威机构统计，项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响项目的进度和成本，甚至直接决定项目的最终成败。需求管理过程中的常见问题有：

需求管理不仅仅是为了确保需求能够在系统中顺利传递，更重要的是确保整个团队对这些需求的理解和响应方式能够真正为组织创造价值。需求管理的过程不仅包括如何收集和处理需求本身，还涉及如何协调团队内部的沟通、资源分析以及需求的优先级设定。

需求管理的复杂性在于它既是技术性问题，也是管理性问题。需求管理不仅仅依赖于技术工具的支持，更需要团队之间的高度协作和组织内部的制度保障。如果需求只是停留在技术层面，而没有与组织的战略和管理实践结合，那很难真正发挥它的价值。因此在需求管理中，不仅需要考虑如何高效地处理需求，更要关注如何通过需求管理支持组织的长期战略目标。

项目需求管理本质上是一条从用户中来到用户中去的业务流。由于技术局限，需求方很难每次都能准确地把需求传达给产品经理，由于业务局限，研发也很准确获取用户真实的应用需求。需求信息的不对称、需求描述的错位，需求理解的偏差，容易引发功能设计的缺陷，最终导致项目风险甚至项目失败。可以说需求收集是需求管理第一步，也是关键一步，牵一发而动全身。

从群众中来，到群众中去。用户调研是需求收集的第一步。用户调研前需要明晰基础用户和核心用户都有哪些，如果“甲方爸爸”是谁都没搞清楚，收集到的需求可能就南辕北辙，到头来忙了个寂寞。用户调研我主要分两个方面：

（1）定性

根据基础用户-用户领导-核心用户这条主线进行闭环。首先从基础用户收集到需求锚点，接着跟基础用户领导进行需求目标方向和价值确认，最后对核心用户进行深度交流。通过face to face的访谈、焦点小组讨论，过程中运用开放性的问题引导和鼓励用户分享自己的观点，观测用户行为，深入了解用户的实际需求，使用习惯、问题痛点。

（2）定量

通过设计并发布在线问卷方式获取大量用户需求的普适性、集中度和变化趋势，来量化用户需求进而优化功能，主要应用于功能上线后的需求反馈；

通过用户调研收集的需求只是需求管理中的一部分，另一部分市场需求需要通过数据分析、竞品分析来获得。对竞品进行全面的功能拆解和比较，了解竞品在功能上的优劣，找出空白地带和优化空间，为自身产品增添独特价值。同时审视竞品的UI和交互设计，学习优化的设计理念并识别可能导致用户流失的体验短板，转化为具体的需求功能优化点。

需求分析是需求管理的核心，贯穿于整个项目的生命周期。需求分析的出发点在于，对需求进行进一步的提炼并指导需求的抽取，理清业务关系，挖掘需求背后的价值。

需求分析应该围绕业务价值进行分析。在实操中，业务价值的判断标准往往充满着主观性，不同利益相关方可能会基于各自的立场和经验做出不同的判断。

判断业务价值的标准应该是多维度的，包括市场潜力、用户需求、技术可行性、商业价值等多方面的考虑。这时建立一个标准化的评估体系就显得尤为重要了，但是大部分功能都依赖KANO模型或MoSCoW法则、SWOT、二八原则做一些粗颗粒度需求优先级分析。同时在需求分析时应该考虑需求的时效性和市场环境变化，如一些政策性的需求在特定的时间点是具有很高的价值和时效性的。

但随着市场和时间的变化，其价值也会相应变化，因此在处理需求分级和需求价值分析时，应该保持一定的灵活性，拥抱变更，响应变更，保证项目持续高效交付。

需求收集结束后我是先分类后分级进行需求分析的。

需求分类并非一项简单的项目活动，我就常囿于如何定义和执行需求分类的标准的问题。执行需求分类标准进行需求分类可以更清楚地了解需求的范围和复杂性，这有助于更好地进行资源分配和质量控制。在实操中，需求分类的标准应该能真实反映需求的本质，是团队建设过程中的一种组织资产，且应该动态调整以适用于团队对需求的评估和管理。

常见的需求分类包括功能性需求、非功能性需求、基本需求、期望需求、魅力需求等等。只要真实反映需求的初衷和用户期望，并有利于需求的传递，帮助团队更好地理解和管理需求，就能提高资源的利用率和产品的交付质量。

需求分级，简单理解就是根据需求确定优先级。需求分级过程中往往会引发部门间的博弈。需求方往往希望他们的需求能够被优先排期上线，可能会试图通过夸大需求的紧急性和重要性来争取更多的资源，但其缺乏或选择性忽略研发团队所能承接的版本容量认知；研发团队关注需求的实现难易程度，可能会基于技术复杂性和实现难度或版本容量推迟某些需求的排期交付。

一般来讲在互联网企业，业务普遍强势于研发，业务在需求排期不得到满足的情况下，问题往往就直接升级到双方领导，大概率迭代基线会被打破重建，即使研发团队处理“超负荷”也不一定能满足业务“这个需求很简单，明天上线”的诉求期望。

需求管理的潘多拉魔盒打开，需求的熵增由此演进。需求的优先级防线溃堤，需求优先级将失去公平性，技术权威也同样受损，将影响到需求管理过程的有效性和项目的按时按质交付。

为缓解这种博弈带来的负面影响，我组织业产研三方进行会议拉通，以项目制度形式固化下来指导需求管理。

首先，需求分类分级是一个透明的过程，各部门的决策标准和优先级应该公开讨论和协商，以减少潜在的冲突和误解。其次，引入第三方评估机制，邀请外部专家或顾问参与需求的分类分级、需求拆解、需求估算评估课程培训，增加方法论的科学理解和应用；第三，定期进行项目迭代复盘，总结经验，完善项目知识库管理，持续改进。

需求评审与确认是项目管理需求活动中不可裁剪的一项活动。简单的需求可以评审和确认一并完成，复杂的需求可能需要经过多轮的评审会进行PK才能最终确认，结论一般会以会议纪要或需求方案的形式送达参会人员，并上传wiki方便项目团队成员熟悉和复盘。

在项目开发过程，需求排期进入迭代后，需求管理工作是不是可以“中场休息”了？答案显然是NO。

产品经理/项目经理需要实时跟踪监督需求的开发进度和质量，以确保需求如期上线交付。一般地，每日stand up meeting上团队成员会反馈其所承担的任务进度和碰到的问题难点。

如果项目过程中出现问题，要及时识别风险和实施风险分析、风险应对，与需求方和团队成员沟通风险点和解决方案，以确保上线的产品和需求一致，符合其业务价值。

需求经过单元测试、冒烟测试等一系列测试后，终于可以与需求方见面了，但要等UAT通过才能进行上线。到此你是否已觉得需求交付了，是不是终于可以好好休息了？暂时放松一下是没问题的。但是，放松归放松，项目经理要明白，需求管理工作是以终为始的一个循环过程。对于迭代来说，版本上线后，上一个迭代的生命周期已然终止，用户使用产品后，在“蜜月期”对产品功能可能会有新的想法，新一轮的需求收集旅程又开始了。

需求管理虽然只是项目管理过程中的一个活动，但需求管理也是一个系统性的工程。VUCA时代下，需求的易变性和复杂性增加了需求管理的难度，不可避免地会与AI进行碰撞与结合，对需求管理提出了新的挑战。

总之，需求管理是一个方法论，也是一个管理框架，包罗万象，只要我们找到适合团队的管理方法，需求就会在科学的轨道上不断以终为始前进，指导我们按时按质地向用户交付满意的产品。