”为什么现在做项目越来越难？当前的项目经理为什么越来越难做？要求越来越高？“
之前的项目经理：保时保质保量完成项目即可，做项目的交付。
现在的项目经理：既要又要还要，既要求做完（交付项目），又要做成（即商业论证达到目标），还要做对（决策之前，达到收益），同时在做的过程中还面临诸多不确定性混杂起来。
初阶项目经理搞定事：站在自身岗位角度，做项目交付，需要项目管理
中阶项目经理搞定人和事：对上理解公司战略，向下会落实，做好分工、做好收益管理，需要运营能力
高阶项目经理搞定组织、人才、资源：站在组织发展层面，需要战略管理能力。
同学甲：现在人们的知识水平越来越高，不仅甲方内部内卷严重，我们本身公司内部的内卷也很严重。甲方跟项目内部的成员的要求越来越多，已然不仅仅是达到甲方、公司、项目目标、项目交付物等项目本身的要求，还包括团队成员的成长、相关方的满意度、公司战略的满足、交付产品的用户体验和高可用性等等，要考虑的因素多了 ，自然越来越不好做。
同学乙：项目无论怎么发展，反正都是项目经理的问题，公司流程制度人员都没问题。这是通病
同学丙：要求越来越高，人不好管理，沟通不好。人不好沟通，变动太大，不像之前一是一二是二
同学丁：项目类型和规模越来越复杂，技术发展快，需要不断学习和适应新的技术变化无常的环境竞争加剧
同学戊：项目经理和项目管理没有实权，项目经理-接盘侠-背锅侠——公司画的饼，同事给的瓜，自己摸的鱼，领导甩的锅
同学己：项目管理软件搭建和上线”这个项目不好做，需要反复打磨，过往项目信息录入软件也是脱掉一层皮，后期仍然需要大量的信息实时更新，过程很痛苦，最一开始系统的搭建逻辑如果有误可能前期即使投入了大量精力，也还是用不起来，别问我是怎么知道的。
现在基础的项目经理（或学过PMP的）都能把项目做完，今天主要告诉大家如何能把项目做成做好？
我们一起学习一个P2中很好用的工具——雷达图，来测一测你的项目现在如何，应该使用什么策略应对~
通过雷达图判断出主要难点后，根据难点情况匹配相关的方法。
项目5大难：
独特性高（事难）：每个项目都是独特的，一个组织也许实施过许多类似的项目，并建立了一个熟悉的、经过验证的项目活动模式，但是每个项目在某些方面都是独特的，比如，一个不同的团队、一个不同的客户、这些因素的组合形成了每个项目的独特性。
不确定性高（项目前难）：项目经常面临各类风险和不确定性。
临时性（时间难）：项目本质是临时性的，有明确的开始和结尾。
变革性（项目后难）：项目是引入变革的手段，项目管理的升级是变革、流程优化叫变革，变革的力度包括改变的广度和深度，也意味项目管理需要弹性和灵活程度。
跨职能性高（人难）：项目是否成功，很大因素取决于人，项目通常会涉及很多人，团队、跨部门，甚至跨组织，且各个参与方都有不同的视角和动机。
这五个维度分别从0、1、2、3、5、8打分，将这五个点连接到一起。
为什么是0、1、2、3、5、8？不是0、1、2、3、4、5这样的等差数列？
与之类似的，风险概率矩阵的风险值也不是等差数列，而是0.05、0.1、0.2、0.4、0.8这样指数上升。
这并不是一种量化的方式，而是一种定性的行为，用数值代表程度。
项目难度如何定义呢？
项目五大难的特点，项目都是独特唯一的，我们很难像运营一样那么确定的运转项目。我们需要主观的分析这个到底独不独特，不确定性究竟是大是小，而不能一味的用不大不小的中庸评判。
在项目前期团队为项目画像时，当团队成员对一个项目的评判有很大差距时，这里往往隐藏着风险。是有某些风险没有识别到？还是对项目本身的理解有遗漏？当我们最终达成统一时，往往此时，我们的理解才真正的走到一起。共识不是通过“大家还有没有问题？”来实现，而是通过这种方式直观的表达，在一定程度上让大家的理解达到一致。
直播课笔记
大纲1：
1、案例项目背景介绍、模块构成、痛点问题列举；
2、项目的五个特点；
3、项目复杂度分析工具——雷达图；
4、借助项目雷达图画像，洞察项目复杂度。
大纲2：
1、分级管控技术介绍
2、MoSCoW分级管理需求实践案例
3、MoSCoW分级管理变更实践案例
项目交付VS项目经理的区别
大家可以先思考一下，你是哪一种呢？同时我门再来分析几个场景哈。
场景1：领导给了我一个团队学习分享的项目，每周内分享两次，一次业务分享，一次认知分享，我要怎么做？
"红薯牌可乐：
详细了解项目的目的、目标，结合当前的业务节奏，优先规划业务分享的优先级，找干系人确定交付的时间排期，提前一周提醒交付节点，探讨打磨分享内容，分享当天进行分享主持，说明分享的价值和背后故事，最后预告下期分享内容和时间，结合分享内容进行团队打分，将高分的分享人，将内容做成微课，方便后续新人和组织使用"
------
@红薯牌可乐 思考维度可以，看来你是个项目管理者
🔎MoSCoW优先级排序法，是项目管理中用来定义项目范围（需求）、确定功能质量（验收标准）、变更管理（问题严重程度）中常用的工具法则，以便用户（User）、项目主管（PE）、项目经理（PM）、供应商（Supplier）对纳入项目中的每个需求交付的重要性和紧急性达成共识。M-o-S-C-o-W，是四个英文单词的首字母的缩写，再加上单词of的首字母O使之能够形成便于记忆的名称——MoSCoW，中文谐音一般称其：莫斯科。
📍Must have：必须有。如果不包含，则产品不可行。
📍Should have：应该有。这些功能很重要，但不是必需的。
📍Could have：可以有，现在能做的。这些要求是客户期望的，但不是必需的。
📍Won’t have for now：这次不会有，现在暂时可以不做。
■ 针对项目情景来讲，MoSCoW用的最多的场景应该属于捕获需求这部分内容，可以使用下图来表示：
■ 针对变更主题来讲，MoSCoW用的最多的场景是针对问题中变更请求这部分内容：
Must have：该变更对项目是必须的；
Should have：该变更是最重要的，缺失了它就削弱了商业论证；
Could have：该变更是有用的，但缺失了它不会削弱商业论证；
Won't have：该变更既非必须也不重要，可以等待；
■ 针对质量主题来讲，MoSCoW用的最多的场景是针对捕获客户质量期望后的验收标准进行优先级排序这部分内容，项目的验收标准形成了对关键利益相关方所接受的、可衡量的产品特性的优先排序清单。
Must have：对项目产品验收标准所必须具有的功能；
Should have：对项目产品验收标准所应该具有的功能；
所有规定为“必须有”和“应该有”的验收标准都应该是要达到的。
■ 针对MP流程中的小组工作包数量WIP来讲，适当运用MoSCoW排序法也会起到一定的作用。WIP来自于敏捷开发中的概念，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。如下图：
