在实施GJB5000B的组织中，RDM（需求开发与管理）实践域有一个关键要求：EPG需制定“需求提供者准则”。准则写得再漂亮，落地时的核心问题只有一个：到底谁才是项目的需求提供者？
选对了人，需求准确，项目顺畅；选错了人，需求偏差，返工不断。标准给了我们“需求提供者准则”这个框，但框里该装哪些人？怎么找？这就需要引入一套实操方法：根据目标识别关键干系人，根据风险识别其他关键干系人。
第一把尺子：根据目标找“主角”
首先收集客户的组织架构，然后对照项目的目标和愿景进行判断。部门负责人或资深副职负责人与目标直接相关，他们就是关键干系人，也是需求提供者的首选。
比如某军用软件项目，目标是“提升装备测试数据处理效率与准确性”。测试部门负责人和分管测试的副总就是关键干系人——他们最清楚现状痛点，也最有动力推动改进。选他们做需求提供者，方向不会偏。反之，如果只找一线操作员做需求提供者，可能得到的是“按钮太小”“界面不好看”等操作层需求，偏离了项目目标。
第二把尺子：根据风险找“隐形关键人”
光看目标不够，有些关键干系人不一定和核心目标直接相关，但如果遗漏了，项目就会“翻车”。以下三类风险场景，对应三类必须纳入需求提供者的角色：
风险一：对一大批基层有影响。 某管理软件上线后，要改变几十个基层岗位的工作方式。如果把受影响的基层用户排除在需求提供者之外，系统做出来可能“领导满意、员工骂娘”。应该把基层用户代表纳入，让他们参与需求确认。
风险二：具有一票否决权的评价者。 比如质量部门、合规部门负责人，他们有权在评审会上否决需求方案。如果不把他们纳入需求提供者，需求通过后照样被打回。提前纳入，让他们的关注点在需求阶段就体现出来，才是稳妥做法。
风险三：技术实施有风险。 开发和运维团队也是关键干系人。开发团队最清楚技术可行性，运维团队最清楚部署和维护的约束。需求提供者只考虑“要什么”不考虑“能不能做”，后期必然扯皮。
合二为一：让需求提供者准则长出“手脚”
“需求提供者准则”告诉你：谁是需求提供者。干系人分析方法告诉你：怎么找到他们。两者合二为一，准则就落地了：
根据目标识别核心需求提供者（部门负责人、资深副职），根据风险补充其他需求提供者（受影响基层代表、一票否决权评价者、开发运维团队）。把这几类角色写进组织的需求提供者准则，每次项目启动时对照检查，就不会漏掉关键角色。
某实施GJB5000B的组织就曾吃过亏。项目初期只把使用部门负责人列为需求提供者，遗漏了分管该部门的财务副总——他拥有一票否决权。需求评审到了财务副总那里，被指出预算核算方式不符要求，整个需求方案推倒重来。后来他们把干系人分析方法纳入需求提供者准则，类似问题再没发生过。
识别出关键用户才能确保项目成功，识别出正确的需求提供者才能获取正确的需求，从而成功地交付。
四句诗总结:
目标为尺找主角，风险为尺补盲区。
准则落地有人脉，需求精准不返工。
参考书目：有效需求分析 ，作者： 徐锋，出版社： 电子工业出版社
