前言

可以说当你担当一次 PM 之后，对项目来说自己不在一方面的资源，对项目、对产品的 owner 意识才能亲身体会。当项目上线那一刻，就好比上学时一道难到全班的“数学题”被我给解出来了，成就感油然而生。下面我根据自身的工作体会，已经在公司内部关于技术 PM 培训总结了本文，用于各个 PM 参考，同时为哪些想提高管理技能(协同技能)的同学做一些参考。本次分享结合众多大佬的心得和自己的实操，相对简单粗暴，需要深入学习的同学需要查阅相关书籍。本人实操经验有限，难免有功力不到之处，欢迎指正

关于项目管理的一些看法

项目管理是人人具有的能力

有一本书叫《人人都是产品经理》，也有一本书叫《人人都是项目经理》，项目管理并不只出现在工作当中，可以拓开眼界，宽泛的说，有目标有价值的事情都可以当成一个个项目，比如生活中的如上学读书、买房、结婚、旅游等等都可以看成一个个项目；所以所谓的项目管理，就是在既定的时间内如何设定目标，确认优先级，制定实施计划，最后能够达成管控的过程。

随着软件及互联网的发展，开发工作已经告别了孤胆英雄的时代，在今天即重视技术大牛的能力，也更重视团队协作能力，而随着管理思潮的发展，企业也越来越注重培养自组织、高效敏捷型团队，像我们日常工作中也会随时拉一个人出来作为某个项目的owner，这种趋势也需要团队的人在专业能力外具有更强的管理协作能力，当你不具备这种能力时，你可能会逐渐落伍于这个时代，所以项目管理并不只是项目经理的专业能力，是需要每个人学习并具有的能力。

如何学习

首先推荐学习一些敏捷的思想和方法论，因为敏捷的思想更有助于我推动日常工作，方法论叫较多易于实践。之后可以了解一些精益开发的思想，精益思想注重价值与优化，用于敏捷实践的优化参考。在更多深入管理中可以学习借鉴经典项目管理理论，诸如计划、时间、风险、资源、成本等，经典项目管理有更具体的方案。

PM职责

不同的工作需求，PM 职责不同。下面我结合目前工作的需要描述一下。

沟通管理

在团队素质较高的今天，PM 第一职责就是保证有效沟通，核心是为了信息更快更好传递给需要的人。

项目干系人管理
- 列出所有关系人：PM、PD、TC、前端、后端、其他负责人以及开发人员
- 项目动态及时通知相关责任人
- 建立项目管理群，相关文档材料以及开发进度列入群公告中
透明化
- 项目价值、产品方案、技术方案、项目计划、各个结论等全员共享
- 项目状态、风险、动态等即需要告知相关责任人，也需要同步效率平台让关注的人查阅
- 信息传达要及时，相关知识要共享。
沟通机制
- 建立沟通机制，沟通群、邮件组
- 项目协同工具：效率平台、jira、gitlab
- 沟通频率、沟通反馈与同步
  - 需要给各个角色提供什么信息，何时提供
  - 明确在过程中需要沟通的环节以及各个环节需要确认的问题与输出
  - 何时开会、会议主题、会议议程、计划时长
有效沟通

项目范围

需求分解、变更必须和整个过程管理配合。

明确项目的核心价值，避免项目过度复杂或过度简化，这是评估合适项目范围的参考标准
需求管理：协助需求分解
变更管理

时间管理

组织任务分解，关键节点设定，计划排期，跟踪并应急

工期估算
排期计划
计划跟踪与修正

项目成本

跟踪实际投入与产出，作为效率监控

主要为资源投入、评估工作量，跟踪相关工作量进展，为效率管理提供依据

项目质量管理

产品方案评审
技术方案评审
验收标准管理
code review 的组织
测试计划、测试范围、测试用例评审等协调
测试报告

风险管理

风险识别
风险分析
风险应对
风险监控

共享知识库管理

需求、需求变更记录及相关知识文档（aone），讨论记录
UI
技术方案，设计思路等
会议纪要(建议除邮件外,要有干系人共享的wiki版本)
排期计划
发布计划(部署方案)
测试计划、测试用例、测试报告

过程管理(参考 scrum)

需求阶段

需求收集、审批确认 —— 会议记录、审批流程记入相关项目知识库
建立项目知识库，建立需求讨论组
复杂的需要要制定需要计划
- 需求收集
- 需求分析
- 评审记录
- UI 设计
- 业务确认
输出产品方案(PRD、原型、UI)等

研发阶段

需求评估 —— 简易需求直接与需求评审会议合并，复杂的单独组会评估
- 组织需求宣讲
- 项目主要资源(产品\架构\研发\测试\UED)对于项目进行整体评估
  - 技术方案以及技术方案确认
  - 工作量评估（粗略保守估算）
  - 资源评估
  - 风险评估（需求是否稳定，资源是否充足、时间是否存在风险，其他风险）
  - 可启动开发条件是否充足
- 需求分解
  - 用户故事或者功能分解到适合一个迭代可完成的大小（粗略评估）
  - 无法更细颗粒度分割不要强求分割，迭代时可按照任务分割
- 输出项目排期计划，整体迭代节奏，邮件通知相关责任人
迭代管理
- 组织迭代计划会议，评估迭代内完成的用户故事\功能点\测试\UI,分解任务,制定具体到天的迭代计划,并输出(邮件)给负责人，记录到知识库
- 组织每日立会(或隔日)
  - 需要明确每个人最新进展、当天计划、遇到的问题，时间建议 15分钟以内，不讨论具体时间，具体问题单组组会讨论
  - 小团队项目，最新进度通过聊天同步即可(记录到 doc 上)
  - 需要跨组协作的项目，需要及时跨组进行同步
- 组织迭代演示及复盘
  - 在项目上线前一两天进行
  - 在本阶段完成的做一个简单回顾
  - 能演示的东西，向产品、测试或业务进行展示；可及时发现问题，增加大家对项目的了解，而不是等到开发完成才展示成果，有效提升项目信心、降低项目风险。
  - 迭代报告
- 测试计划制定
  - 尽早组织测试计划制定，建议项目启动测试即介入，尤其时研发兼PM时注意计划、例会、演示等不要遗漏了测试同学
  - 协调测试与产品沟通验收条件（重点针对与需求场景而非功能点），含测试范围（测试边界），验收标准，质量标准，性能标准
  - 协调测试输出测试用例，进行用例评审
  - 测试切入的时间计划与资源安排
- 发布管理
  - 制定发布计划
  - 多个项目的部署顺序，是否依赖
  - 部署步骤，各环节负责人，各环节部署时间
  - 回滚计划，或发布失败的应急方案
  - 通知所有项目负责人，重要的负责人必须确认
- 复盘（小项目直接通过迭代复盘）
  - 回顾目标
  - 评估项目效果
  - 总结做的好的地方，与不好的地方，并讨论优化思路
  - 根据总结，形成行动计划

效率管理

没有量化就没有管理，量化是我们评估项目投入，进度、效率的基础；作为 PM 得理解，在软件项目管理中，每一种量化都有大量失败案例，选一种适度量化方案，不要过度量化。推荐量化管理方案：

需求和任务要有工作量评估
以工作量评估作为基线，实际发生工作量做对比，评估进展，团队效率
量化方式一（可阅读Scrum相关资料）
- 尽量细化任务及需求,需求分解到一个迭代（两周），做用户故事点数或工作量评估（可细化到任务）
- 通过需求完成趋势图、需求燃尽图作为效率衡量，在基准线之上的项目要标记为风险
量化方式二（可阅读挣值管理相关资料）
- 根据项目评估项目价值（计划值PV）
- 细化分解各个任务价值，作为任务估值
- 根据实际完成（EV）/计划估值（PV），衡量项目进度偏差
- 根据实际完成（EV）-实际发生成本（AC），衡量成本偏差——计划投入与实际投入偏差
- 统一的估值管理模型可以衡量整个团队的效率问题
通过价值流图识别浪费，然后优化，聚焦于价值最大化，而不仅仅优化成本

风险管理

在项目整个过程中， PM 要维护风险列表。每个风险识别后，PM 要协调尽快明确应对方案以及风险负责人，跟踪风险解决进展；要及时暴露风险给能处理或能决策的人。

风险识别以及基本应对：

需求以及产品风险：聚焦需求价值，以完成需求核心价值未衡量标准。管控产品方案复杂度，复杂需求要分阶段、分块评估，方案要围绕需要核心价值。产品方案要经过技术评估、业务评估，必要时要经过审批以尽量降低需求及产品风险；PM 要确认需求以及产品方案经过评估以及审核。PM 要管控项目变更，通知相关责任人（尤其是需求方），影响排期要进行风险管理，必要时升级主要决策人决定，要避免在相关负责人不知道的情况下私自更改方案。
资源风险：资源冲突，与其他项目PM或高级leader进行沟通，根据优先级先协调排期，如冲突无法解决，升级到可决策的人做决定；单个资源在多个项目中或需要支持现有系统运行，与对应的资源沟通，明确项目可项目可占用的时间，作为风险解决记录，如风险太高，建议更换资源或增加辅助资源，必要时升级此风险到对应决策人；缺少特定资源，申请 PMO 支持或升级到相关决策人进行协调，如短期无法解决，标记风险高，每日跟进；资源不足，PM申请PMO或相关决策人支持，在内部无法协调解决时，申请并推动招聘与外包流程；资源突发情况管理，如突然请假等，建议重要项目PM在项目启动时明确要求团队成员提前申请请假等事项，如遇到突发请假的情况，及时通报风险给相关决策人，并做资源调整或计划调整并告知干系人
时间风险：根据项目难度（复杂度），资源情况，deadline，排期等评估时间风险（极高，高，中，低）；时间风险高的要明确告知需求方（相关决策人），并确认；时间风险高的申请更高优先级，优先占用相关资源；时间风险高的根据情况适当申请加班（非必要避免过度加班，合适的研发节奏比加班更有效率）；减少非必要时间消耗，如不必要的会议等；降低沟通成本，集中项目成员统一区域办公，异地人员可申请出差，必要时要求封闭开发减少外部打扰
技术风险：标记项目技术复杂度，或技术复杂模块，对于任何不熟悉的技术使用都不要盲目乐观；从需求评估阶段引入技术方案评估，如加入架构评估及技术管理委员会审核的环节；研发阶段要对相关技术方案不断核对，及时调整或请架构、技术管理委员会评估，必要时申请外部资源支持；高风险的技术问题，要逐日更新解决进度

一些思考

《思考，快与慢》讲到人类的思考其实有两个系统，一个系统根据直觉做快速反应，另一个系统需要更长的思考并做出反应。系统一反应快，但复杂问题容易出错，系统二反应慢，但应对出错概率低。这是人类长期进化的结果。

那么映射到项目管理中，在技术与思想日新月异的今天，针对项目管理没有银弹，我们不能用一套方案应对所有场景，需要区分快速响应的和需要持续投入的项目，我们需要不同的应对策略。针对快速响应的项目，需要简化上文提到的环节，并允许犯错。

一些理念

信息与知识共享：信息管理是项目管理的潜在核心，包括需求、背景知识、相关责任人、产品方案、时间计划、复盘等等信息；就像程序一样，信息必须流转到真正处理的人才会价值最大化，要确保信息沟通；信息的更广泛传播更有助于收集反馈信息，PM要确保信息尽量广泛传达（需保密的除外）；PM不要形成信息瓶颈，即所有信息都由PM中转，发挥每个成员的沟通能力，并确保信息同步给相关干系人

计划：坏的计划比没有计划强；敏捷不是甩开膀子埋头干，敏捷没有计划时一种误解；计划要详细，但不要求过度准确；计划要在执行过程中不断调整修正；迭代尽量稳定，但允许接收紧急变化，变化要告知相关干系人并经过决策人的确认

需求：聚焦业务价值与场景,什么角色为达到什么目标（价值）需要一个什么功能（或系统能力；聚焦业务描述，可以标注业务预期；EPIC是一个大的用户故事，一般我们用于与用户提出的需求对应，可以相对模糊，甚至是一句话

用户故事与PRD：两者不是对立的，一定程度上是同样的事情；用户故事更侧重于价值与场景体现，但滥用时容易产生一句话需求，这是一个误解；PRD可以由场景及价值描述，但PRD的形式更容易陷入功能实现描述而引发需求风险；明确价值与应用场景是我们的核心诉求，因为方案可以很多套，功能可增减，但没有实现业务的核心诉求会导致项目南辕北辙

发布：尽量构建并使用CI(持续集成)与CD(持续部署)的流程

度量：没有量化就没有管理,度量在管理中非常重要；过度度量(过度量化)，或工时记录有很多失败案例，会加大团队成本；时间管理没有必要小于天（或者0.5天),微观时间管理应该交给个人；价值评估：不要等同于工作量评估，比如我们评估本项目价值100W，但不同于我们要化100W的人工，从上层项目开始估值，外包公司的外包项目也会有赚有赔，所以不要特别斤斤计较与估值准确度，需要用整个团队视角观察我们的产值；价值评估形成的绩效数据建议仅占少数绩效考核，避免因估值误差导致的绩效误差

浪费识别：无效沟通，过多的非必要会议，过多中间沟通环节（通过多个环节沟通），未被要求，非必要的功能；重复开发，错误开发，错误方案，过多返工，等待：等待各种确认、等待需求、等待前置任务、等待发布