要把风险变机会，把问题变答案，咱们先来聊聊这个事儿。在项目实施中，碰到些棘手的情况该咋办？比如群里有学员问了这么道判断题：有个案例是在项目期间，发起人让项目经理去查看并减轻新报告的风险，结果项目经理发现除了一项都是问题。你猜哪个选项被认定为风险？答案是 A 选项，新市场法规快批了，可能要改项目范围。PMBOK 里说得明明白白，风险是指一旦发生会影响目标的不确定事儿，问题则是已经存在有争议的事儿。简单说就是，风险还没发生是不确定的，问题是现在就有争议。 解析完这道题，有人就想啊：要是把题目里的 C 选项“SME 离职”换成另一种情况呢？假设之前没把这人离职当风险记下来，项目经理现在咋办？ 如果这个 SME 的离职早就被列在风险登记册里了，那直接按那个“剧本”办就行。照着登记册上的优先级、责任人、应对措施走，预案一键启动，有备选方案马上换。然后更新一下登记册，把这事儿关了就行。 但如果之前压根没把这事儿放进去当成风险呢？那就把它当成新问题来处理，得用系统化的方法。 问题解决流程大概分六步：先把问题记到日志上，接着定义清楚问题到底是啥，再找根本原因，然后想几个解决方案挑最好的那个出来，分人去干验证看看行不行最后关了它或者升级处理。有几个注意点：记录是起点防忘事；执行者必须是问题拥有者不能项目经理一个人扛；验证失败得回到定义问题那里从头再来。 咱们再看个例子来练练手：公司开发新产品测试时发现严重缺陷怎么办？答案是用因果图。测试阶段发现的缺陷属于质量控制结果的一部分。管理质量过程自带解决工具因果图能帮你把坏的原因拆成鱼骨图看得明明白白。 最后总结一下：问题解决流程在 PMP 考试里那是仅次于变更流程的第二大考点必须拿下！下次遇到类似情况直接套用：先看是不是风险还是问题；再按照流程走：记录→定义→挖因→出方案→分人→验证→关闭。 把这套流程记在本子里刻进肌肉记忆里项目再乱也能稳住阵脚！