【项目管理】项目管理方法学习
项目管理学习
项目经理五件事
把目标讲清楚；
把任务拆清楚；
把责任分清楚；
把风险看清楚；
把问题推闭环
项目经理成长阶段
一、执行者
此阶段项目经理依靠清晰的指令来用专业能力和执行力创造价值，个人产出是衡量贡献的主要标准，能够按时交付、可以解决所遇到的技术和流程问题、能让团队按照计划进行推进的是第一阶段的成功画像
只会执行是不够的
你需要开始看全局，知道项目真正要达成什么
你需要开始抓关键，知道哪些任务最值得投入精力
你需要开始推协同，知道如何让跨部门问题真正落地
你需要开始建机制，知道如何让项目不靠自己一个人硬撑
二、协调者
第二阶段所需要的是一种认知的转变，即价值不再仅仅来自个人直接产出，而是开始来自于推动别人产出，使多件事同时向前推进，协调各种人和资源的依赖关系
该阶段开始用项目管理工具来处理任务之间的依赖关系，开始与不同的职能人员接触，并且承担起计划、跟踪和沟通的职责，甘特图、里程碑、状态报告都是第二阶段所使用的工具
三、影响者
在没有正式权力的情况下，通过别人去推动重要事情的完成
第三阶段的价值创造，来源于理解各个干系人的利益结构，找到让他们愿意行动的原因，在冲突中找到各方都能接受的解决办法，在资源有限的时候做出各方都能接受的优先级判断
当项目出现问题的时候，最先反应的是由「我来处理」转变成了「谁是最适合处理这件事的人，怎样让他们行动起来」
第三阶段的核心能力是在对方还没有完全到位的时候，依然选择给予足够的空间和支持，而不是接管
四、系统设计者
设计一种能够让事情自己发生，并且在没有你的情况下，团队仍然能够正常运转的机制
第四阶段的项目经理在推动当前项目的同时，还在构建起能够为以后项目服务的能力基础设施，流程文档、方法论总结、检查清单、培训体系、复盘机制等。这些是第四阶段相对于第三阶段以外创造的价值
五、战略伙伴
在信息不全、目标不明、资源不定的情况下，仍然促成重要的事情发生，并使组织做出更好的决策
项目经理不再是单纯的项目交付管理者，而是成为了业务的战略伙伴，他们的价值不单体现在项目的成功交付上，更在于参与定义什么是值得做的项目、在众多优先级中做出取舍、在组织内建立起对项目价值更深层次的认识
第五个阶段需要一个根本性的认知转变：放弃对完全确定性的追求，在模糊、不完整的前提下做出判断并承担后果
- 当项目遇到困难的时候，你的第一反应是自己解决还是找合适的人去推动？如果是前者的话，你可能还处在第一或第二阶段。
- 你不在场时，项目还能顺利进行吗？如果不能，那你还在第三阶段，还没有建立第四阶段需要的系统。
- 当目标不明确的时候，你是等待清晰的指令还是主动澄清并推动共识形成？如果是前者，则进入第五阶段准备还不到位。
项目管理五字真言
拆、控、推、追、回
一、拆
拆目标，拆范围，拆任务，拆责任，拆节点，拆交付物
例如一个系统上线，首先应该拆解成：
需求确认、原型评审、开发排期、接口联调、测试验证、用户培训、上线准备、验收确认、问题闭环
谁确认需求，谁确认流程，谁确认数据，谁确认验收标准，谁最终拍板
二、控
控范围，控进度，控风险，控资源，控质量，控变更，提前判断项目有没有偏离轨道
让项目风险在变成事故前被看见、被处理、被关闭
需求没冻结，说问题不大；
关键人没到位，说再等等；
测试时间被压缩，说后面辛苦一下；
客户验收标准没确认，说到时候再沟通；
供应商反馈慢，说应该能赶上
每一次都不大，叠加起来就是大问题
三、推
推责任人，推关键节点，推资源到位，推问题升级，推决策落地
项目经理不是靠语气强硬推动项目，而是靠事实、影响、方案和截止时间推动项目
把每个模糊问题变成明确动作
把每个扯皮问题变成责任边界
把每个僵住的问题变成需要决策的选项
把问题推到具体人、具体时间、具体结果上
四、追
追责任人、追交付物、追截止时间、追确认结果、追问题关闭
任务不是有人做就行，要有交付物
问题不是有人处理就行，要有处理结果
问题不是有人处理就行，要有处理结果
会议不是开完就行，要有行动项
行动项不是分出去就行，要有人确认关闭
五、回
回看目标，回看过程，回看风险，回看问题，回看经验，回看机制
真正有用的复盘，要把项目重新拉一遍：
项目目标有没有达成、范围有没有失控、进度偏差主要发生在哪个阶段、成本有没有超、质量问题集中在哪里、客户满意度怎么样
复盘的目的，不是追责，而是让下一次项目更好做，把复盘结果变成模板、清单、流程、规则和预警项
项目开始时，先拆；把模糊的目标拆成清楚的任务
项目推进中，先控；把潜在的风险提前控住
遇到卡点时，主动推；把卡住的问题推到决策层
任务执行中，持续追；把执行过程追到闭环
项目结束后，必须回；把项目经验回收到机制里
项目经理大误区
一、只会传话，不会判断
项目经理不是传声筒，要做判断，把混乱的信息整理成事实，把事实变成方案，把方案推向决策
客户提出一个需求，要判断它是不是本期范围
领导临时加一个任务，要判断它会不会影响关键节点
团队反馈一个困难，要判断这是能力问题、资源问题，还是计划问题
项目出现延期，要判断是局部延误，还是会影响整体交付
哪些必须做？
哪些可以延后？
哪些要评估影响？
哪些需要重新确认范围？
哪些需要管理层拍板？
二、只会催进度，不会拆任务
任务拆清楚了，进度才有抓手
任务没拆清楚，所有催促都是噪音
三、遇到问题就甩锅，不敢扛责任
项目经理不是背锅侠，但项目经理必须是问题的第一推动人，不是所有问题都要你亲自解决，但你必须推动问题被解决
谁负责分析？
谁提供方案？
谁协调资源？
谁确认决策？
什么时候关闭？
如何验证结果？
项目经理敢于面对问题，团队才会敢于暴露问题
三、会议开了没结果
真正有效的项目会议，必须有三个结果
第一、有结论：这个问题怎么处理，方向是什么，是否需要调整计划
第二、有责任人：谁来做，谁配合，谁审批，谁负责最终结果
第三、有截止时间：什么时候完成，什么时候反馈，什么时候验证
会议只是手段，闭环才是目的
如果一个问题开了三次会还没有负责人、没有方案、没有时间点，那不是问题复杂，而是项目经理没有把会议管住
五、不建机制，全靠人盯
项目管理不能只靠个人记忆和个人责任感，而是至少要有：
任务机制：每个任务有负责人、截止时间、交付物和状态。
进度机制：项目关键节点能被持续跟踪，不是到最后才发现延期。
问题机制：所有问题进入台账，有责任人、有处理方案、有关闭状态。
风险机制：潜在风险提前识别，而不是爆雷后再汇报。
变更机制：需求变化要评估影响，不能随口一加就进入执行。
复盘机制：项目结束后沉淀经验，不要下个项目继续踩同样的坑
项目管理全流程
项目经理要做的，是判断优先级、推动关键决策、协调关键资源
不只是“什么时候完成”，而是：
这个项目为什么要做？做到什么程度算成功？谁负责什么？资源够不够？风险在哪里？过程中偏了怎么办？交付后怎么验证？下次怎么做得更好？
第一步、立项评估
一个项目值不值得做，至少要看四个维度：
第一，战略价值。
这个项目是不是和公司当前重点方向有关？能不能支撑增长、降本、提效、风控？
第二，业务收益。
项目完成后能带来什么结果？是收入提升、成本下降、效率提高，还是客户满意度改善？
第三，资源投入。
需要多少人、多少钱、多少时间？现有资源能不能撑住？
第四，实施难度。
技术难不难？跨部门多不多？外部依赖强不强？风险是否可控？
第二步、定目标
项目目标要从一句大话，拆成可衡量的结果
项目愿景：为什么做？
核心目标：要解决什么问题？
关键指标：用什么数据衡量？
验收标准：做到什么程度算完成？
目标一旦具体，项目才真正进入可管理状态
第三步、识别干系人
干系人管理要看两个维度：影响力高不高、关注度高不高。
- 影响力高、关注度高的人，要重点管理，定期同步
- 影响力高、关注度低的人，要提前争取支持。
- 影响力低、关注度高的人，要做好沟通解释。
- 影响力低、关注度低的人，保持基础告知即可
第四步、任务拆解，把大项目拆成可执行的小动作
WBS工作分解结构，本质上就是把项目拆到“可交付、可执行、可检查”的程度
一个好的任务拆解，要满足三个标准：
能看清产出物、能明确负责人、能判断完成状态
哪些是关键路径任务；哪些是高风险任务；哪些是常规任务；哪些可以授权；哪些必须自己盯到最后
第五步、排计划，看清关键路径
真正有用的计划，不是越复杂越好，而是能看清三件事：
- 哪些任务必须先做？
- 哪些节点不能延期？
- 哪些任务一旦延误，会影响整体交付？
项目计划里最重要的，不是每个小任务都写得多细，而是关键里程碑要清楚
每一个里程碑，都应该对应明确的时间、成果和责任人
关键路径，就是那些一旦延期就会拖垮整个项目的任务链，比如需求冻结、方案确认、核心模块开发、接口联调、测试验收、客户签字、上线切换
普通任务晚一天，可能只是局部影响；关键路径晚一天，整个项目就可能晚一周
第六步、分责任
RACI责任分工表
R：负责执行的人
A：最终负责的人
C：需要咨询的人
I：需要告知的人
一个任务可以有多个协作人，但最终负责人最好只有一个
第七步、管风险
项目风险不是出现问题之后才管理，而是在问题发生之前就要识别
- 高概率、高影响的风险，要重点预防
- 高概率、低影响的风险，要设标准动作
- 低概率、高影响的风险，要准备应急方案
- 低概率、低影响的风险，保持关注即可
风险管理三要素：
- 风险描述
- 应对措施
- 责任人和触发条件
第八步、盯执行
项目监控五要素：
- 进度：计划完成了多少，实际完成了多少？
- 质量：交付成果是否达标？
- 成本：预算消耗是否超出预期？
- 风险：哪些问题正在变大？
- 问题：当前卡点是什么，谁来解决？
项目例会围绕三个问题展开：上周完成了什么？本周要完成什么？当前卡点是什么？
每个卡点必须形成动作：谁负责；什么时候解决；需要谁支持；下次会议怎么验证
第九步、管变更，需求可以变，但不能随便变
变更不可怕，可怕的是没有机制
提出变更→评估影响→审批确认→调整计划→同步执行
每一次变更，都要说清楚：影响哪些范围？增加多少成本？延长多少时间？带来什么风险？是否影响最终目标？
项目经理不能简单说“不行”，也不能随口说“可以”
可以变，但要先评估；
可以加，但要看代价；
可以调整，但要同步目标、资源和时间
第十步、交付验收
项目交付必须有验收标准，验收标准最好在项目一开始就定义，而不是到最后再临时讨论
项目验收三要素：
- 成果物是否交付
比如系统、文档、流程、报表、培训材料、上线记录等。
- 质量是否达标
比如功能是否完整、数据是否准确、流程是否跑通、用户是否通过测试。
- 业务目标是否实现
比如效率是否提升、成本是否下降、问题是否减少、满意度是否改善
第十一步、复盘，把经验变成下一次的能力
真正有效的复盘，不是找人背锅，而是把经验沉淀成方法
复盘四要素：目标达成了吗？过程哪里偏了？原因到底是什么？下次怎么改？
复盘不能只停留在感受层面，要沉淀成可复用的东西：模板；清单；标准流程；风险库；问题案例；最佳实践
比如项目延期，不要只写“需求确认慢”，而要进一步追问：为什么需求确认慢？
- 是关键用户没参与？
- 是需求模板不清楚？
- 是审批链路太长？
- 是项目启动时没有锁定范围？
Refrence
项目管理实战派