前言
可以说当你担当一次 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的人工，从上层项目开始估值，外包公司的外包项目也会有赚有赔，所以不要特别斤斤计较与估值准确度，需要用整个团队视角观察我们的产值；价值评估形成的绩效数据建议仅占少数绩效考核，避免因估值误差导致的绩效误差
浪费识别：无效沟通，过多的非必要会议，过多中间沟通环节（通过多个环节沟通），未被要求，非必要的功能；重复开发，错误开发，错误方案，过多返工，等待：等待各种确认、等待需求、等待前置任务、等待发布
