PMP如何管理多用户需求.pdfVIP

专注 PMP ，软考，ITLT ，P2 培训 / PMP 如何管理多用户需求 前提场景： 1、项目的需求同时来自于： 集团公司（总公司）、分公司，或者同一个公司的多个部门（岗位）责任人，或者同个部门的多个 最终用户。 2、项目组资源不足以完成短时间内爆发的大量需求； 3、需求提出人都希望自己提出的需求能优先完成。 4、此时PMP 该如何应对？ 工作挑战： 对个别用户响应及时未必得到表扬，但对大多数用户响应不及时，容易引起大面积投诉，此时PMP 和项目团队来说，成为被群起而攻之的对象。 例外情景： 1、“需求”使用习惯上的广义定义，与需要、愿望、愿景、问题、解决方案等之间的转换关系和区 别本文不讨论。 专注 PMP ，软考，ITLT ，P2 培训 / 2、本文关注遇到多个用户提出的需求时，某些困难、障碍时该如何排除，并提供临时性应对方法， 对团队能力的长远改进不讨论。 3、假设现有公认的工具不适用，如PMBOK 列出的工具项目团队不能掌握和有效应用，已熟练使用的 情况不讨论。 4、因项目无常态，未必适合所有项目团队，仅供交流。 应对思路： 1、 布置合理的排队模型 常见问题： 如果不加以管理，排队模型可能如下图所示： 需求接收口只有一个，而队列中的需求提出人相互直接不可见，在资源紧张时，用户感受会相当的 不好，常爆发类似抱怨： “为什么我很久之前提出的需求还得不到响应，甚至现在还没有开始做？”， 有可能引起大面积投诉。 应对方法： PMP 应该拆除需求队列间的隔离墙，将需求受理放在统一的平台，使所有的需求提出人能了解到： 1）项目组当前在处理什么需求？ 2）自己的需求可能与谁的需求产生资源竞争？ 3）预计自己的需求什么时候可以得到受理？ 了解到这些信息后，队列中的需求提出人可以消除或缓解黑盒排队的等待焦虑感。同时使需求提出 人自觉地不与上级部门、上级领导提出的需求“抢跑道”，减少投诉的发生。 专注 PMP ，软考，ITLT ，P2 培训 / 2、 对需求提出人进行反向考核 常见问题： 各需求提出人提出的需求如果因为表达能力不足或者对自身岗位职责不熟悉，需求描述不清，甚至 提出的“需求”实际上仅仅是大脑中的“灵光一闪”，会对需求受理方产生很大的干扰。在资源不足以 及时满足各需求提出人的时间要求时（如有响应速度的考核），用正常的需求搜集、管理方法，不能很 好的处理此类问题，需要反向对需求提出人有需求提出质量的考核，以约束提出人的行为，提升需求质 量。 应对方法： PMP 召开需求提出人都能参加的会议，或者在每周例行报告中公布需求受理清单，清单需要能够较好 的反映原始需求的后续变更情况。一般原始需求提得不清楚或欠考虑，后续变更会特别频繁。当有需求 成绩单公布时，任何人都不希望自己排名在倒数，因此会仔细考虑自己提出的需求是否说明清楚，细节 是否考虑周全，能否帮助需求受理人更好地理解。 当然可以采取其他方法，但无论如何，不应总是甲方对乙方单向进行考核，乙方对甲方的反向约束 力是PMP 不应当忽视的一个细节。 3、保障反向考核制度 常见问题： 强者制订规则，弱者服从规则。 当有成绩单对需求提出人进行考核时，某些强势部门就会努力使自己排除到考核范围之外。 如前些时候我完成的一个功能： 为了提高财务报销凭证审批效率，财务部提出对所有审批环节进行考核。如果在某个环节，事项超 过3 天仍未审批，则对审批责任人所在的部门进行扣分。例外：财务部作为需求提出人，特别说明公司 领导不在考核范围内。 此功能启用后，发现财务部被扣分最多，于是财务部提出财务部自身也不在考核范围内。 ^_^ 上述案例说明，强者不会轻易服从他人制订的规则，如果和弱者一起被考核，未免太掉身价。另外 一方面，如果不服从规则的部门很多，如综合部、市场部也纷纷提出不接受考核，那么乙方建立的考核 制度就会崩溃。 应对方法： PMP 与关键干系人（如需求提出部门、上级领导）讨论，对于关键关系人提出的需求，不仅要优先处 理，还要派专职的需求分析师仔细研究。同时提出：“为了加强需求的管理，使需求受理更加