项目管理
指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程
CPM:关键路径法
角色转变
- 亲力亲为 -> 影响他人把事情做好
- 追在屁股后面当监工 -> 明确目标,建立机制,形成一种良性的秩序
- 拿着锤子,看哪里都是钉子 -> 明确深层目标,工具是其次的
项目管理框架
项目管理内容
项目管理 = 管人(客户+成员)+管事
干系人管理
对项目干系人进行分析和归类,有针对性地规划管理其核心诉求和期望
- 高利益,高权力:了解这些人的真正诉求,项目真正要的是什么
- 低利益,高权力:满足其自身或团队的诉求
- 高利益,低权力:做到项目事项的随时告知,及时通报项目的进展和困难
- 低利益,低权力:不影响项目的前提下,花最小的力气对他们进行监督
范围管理:做什么
进度管理:花多长时间
需求变更:
- 明确变更是有成本的
- 在初期就把事情做对,避免后续再变更
- 优化能力,支持小步试错,降低变更成本
工具:
- 通过计划制定流程和计划跟进流程来跟进任务
- 工期估算不要太乐观,准备B计划和一定的缓冲时间
- 任务要有优先级
- 全局项目状态表,向全员同步项目进展
- 保证反馈渠道通畅
项目计划
- 任务分解:例如使用WBS,是把要做的事情,按照一个树形结构去组织,逐级分解,分割成小而具体的可交付结果,直到不能再拆分为止
- 估算时间:拆分的越细致,同时让负责任务的人估算,就能估算的越准
- 排路径:根据任务之间的关系,资源的占用情况,排出合适的顺序
- 里程碑:项目的推进过程中,根据里程碑完成的情况,可以很直观地知道项目的进展如何。如果发现不能如期完成里程碑,就需要进行适当的调整
- 跟踪与调整:收集信息,可以很容易的看出来执行的情况,发现偏差则需要进行调整
流程规范
- 明确要解决的问题
- 提出解决方法:方法更有针对性,可能只适用于特定场景或者特定人,而要将方法上升到流程规范,则需要有一定的普适性,能变成具体的步骤或者标准
- 达成共识,推广执行
- 持续优化,不断改进
成本管理:花多大代价
质量管理:达到什么要求
质量规划:
- 质量成本分为两类:一类是事前防止失败的一致性成本;一类是事后处理失败的非一致性成本
- 业务生命周期的不同阶段,质量标准应该是动态变化的
质量分析:找到质量差距的根本症结,制定相应的预防措施和解决方案
质量控制:通过引入必要的流程卡点来保证检测机制有效运行,提升质量
资源管理:有哪些资源可以用
沟通管理
风险管理:如何应对风险
风险观:事后不如事中控制,事中不如事前控制
应对:发生概率很高的严重风险,一定要提前准备风险应对方案和危机应急预案,需要培养风险意识,周期性的风险审查,来识别新的风险
致命风险:导致项目失败的风险,这种风险要挖掘出来,变为可见、可谈的,可度量的,不要心存侥幸,及时将信息同步给核心成员
针对风险,主要分成以下几个策略:
- 回避:对可能发生的风险,放弃或者修改导致风险的方案。这样就从根源上消除了风险,简单而彻底
- 转移:将风险责任转移给第三方,由第三方来保障
- 缓解:在风险发生前采取一定措施,降低风险发生的概率,或者减少风险可能造成的损失
- 接受:一些风险本身很难避免,或者去应对这个风险的成本超过风险发生后造成的损失
quadrantChart x-axis "可能性小" --> "可能性大" y-axis "损失小" --> "损失大" quadrant-1 "回避风险" quadrant-2 "转移风险" quadrant-3 "接受风险" quadrant-4 "缓解风险"
可行性分析
- 经济可行性:从成本和收益角度分析,看投入产出比。不仅要分析短期利益,还要分析长期利益,看是不是值得做
- 技术可行性:软件项目最终是需要人通过技术来实现的,所以要分析技术上是不是可行,如果有技术上解决不了的问题又能否规避
- 社会可行性:社会可行性涉及法律、道德、社会影响等社会因素。比如,触犯国家法律的事情肯定不能做;产品如若不符合道德标准,可能带来较大的社会负面影响,那么也要慎重考虑
采购管理:有多少还要买
集成管理:如何实现整体最优
过程
启动
- 正式宣告一个新项目愿景或新阶段的目标,干系人管理
规划
- 把愿景目标转化为可落地的行动方案和工作路线
计划:
- WBS 工作分解结构:把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分
- 关键路径:识别工作内容依赖并画出关键路径,持续关注,把关键路径上的风险作为最高优先级应对
- 定义完成标准:需要完成的事项列表,或者是应该达到的某项指标(特定水平的 Bug 数量 / 性能指标等)
- 达成共识:计划做完后,要广而告之与全员同步信息
- 即时:计划发生变更,要触达相关人员
执行
- 整合资源,推进项目落地
构建系统能力,在产品研发的整个过程中,建立起真正闭环反馈的产品验证机制
- 方案评审(OARP)
Bug 大扫除,划出一个专门的时间段,在这期间,所有参与项目的人员,集中全部精力一起来给项目找 Bug,目的是从各个维度衡量和体验产品
冒烟用例评审:冒烟测试是一个基础合约,定义了完成标准
监控
- 定期对项目的进展、范围、质量等进行跟踪和监控,识别目前的进度与计划之间的偏差,从而快速准确地采取法进行纠正和调整
紧急汇报:突发事件,或者提示重要风险状态变化时的实时报告,包括事件描述、影响后果、跟进分析、响应措施、所需支持
常规汇报:项目状态评估、风险列表、项目概况及计划变更情况
数据汇报:能够用图表和数据的,不用文字,可以直观地进行过程预测和风险预警
收尾
- 交付项目成果,组织团队的回顾复盘,归档所有文档等组织过程资产,正式结束一个项目或阶段
复盘会、奏章法...
复盘不需要固定的节点,每次的复盘,提出的问题,挑选一个最重要的改进就可了
会议
- 边界:每个会议都要有特定的主题和目的,并有明确的参会人员范围
- 跟进:会后所有跟进事项,直接进任务系统,确保跟进到底
- 必要:只开最有必要的会,开真正高效且产生决议的会
工具和技术
- RAM 责任分配矩阵 工作职责
- 甘特图 工作时间
结构化分解