需求变更：

pmp里面涉及需求变更的很多，尤其是CCB 

对于CCB的需求变更，可能需要以下步骤：

1. 确定变更的原因和必要性：需要了解变更是因为业务需求的变化、技术方案的变更还是其他原因，以及变更是否是必要的。

2. 分析变更对项目的影响：需要评估变更对项目进度、成本、质量等方面的影响，并确定是否需要重新调整项目计划。

3. 确定变更的范围和优先级：需要确定变更的具体内容和影响范围，以及变更的优先级，以便在实施时可以有效地管理资源和风险。

4. 制定变更管理计划：需要制定一份清晰的变更管理计划，包括变更的审批流程、实施策略、测试计划等，以确保变更能够顺利地实施并达到预期目标。

5. 与相关方沟通和协商：需要与各相关方进行沟通和协商，包括业务方、技术团队、项目管理团队等，以确保变更的可行性和各方的理解与支持。

6. 实施变更并进行监控：需要按照变更管理计划进行变更实施，并对实施过程进行监控和控制，以及及时进行反馈和修正，确保项目能够顺利进行。

软件的ccb 变更委员会一般是由产品 leader、技术leader、测试 leader 及项目经理组成，如果是乙方肯定还有甲方的代表相关。

 需求变工的标准流程不难，关键是能否落地。

1 达成共识，变更是有代价的。

毕竟产品仍然在探索期，变更总是在所难免的，我们追求的是达成项目目标，而不是零变更。

2 源头治理，一次把事情做对

把产品设计先封闭，小黑屋+deadline是一种方式。

前置压缩，不是压缩后面开发的时间。

3 快速试错，巧妙应对

 有些老板或者大客户的需求不能直接顶回去，要分析背后真实需求。

老板的需求可以快速响应，快速尝试，灰度验证，用数据说话，降低试错成本。

风险控制：

项目管理中，风险管理是一项重要的任务，其目的是识别潜在风险、评估其可能对项目造成的影响，并采取相应的措施来降低或规避风险。以下是几个关键步骤：

1. 风险识别：通过调查和分析项目相关因素、历史数据、以及其他信息来确定可能出现的风险。

2. 风险评估：对识别到的风险进行评估，分析其潜在影响和概率，并确定加以关注的风险。

3. 风险规划：确定如何管理和应对风险，制定风险管理计划，并制定应急措施。

4. 风险监控：不断监控项目进度和风险，及时采取措施解决出现的风险和问题。

5. 风险控制：采取相应的应对策略和措施，控制和规避风险对项目造成的影响。

风险管理是一个循环的过程，通过不断反复的识别、评估、规划、监控和控制，可以为项目实施提供保障，确保项目成功地实现预期目标。

风险识别

系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。人员也是相关干系人，不只是项目经理。

识别风险过程的主要输出，就是初始的风险登记册，包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序。

 没人反馈风险，不代表没风险。PM需要跟所有项目干系人建立联系，你识别出的风险越多，项目的风险就越低。

风险应对措施

你需要为识别出的每个风险，制定相应的风险应对措施。对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案。

树立正确的风险意识

系统性反馈机制：常规风险

项目中的风险群众最有发言权的，经常 收集意见，匿名问卷跟访谈。

收集研发过程满意度：括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面）

对这个版本功能设计的满意度，即产品认可度。

知名风险管理

 如高层对项目态度，合作方关系，竞争对手的变化，监管政策等。

这种一旦发生就是致命性的，按照pmi的说法，提前结束或者失败的项目也要走项目流程。

我所经历的也不少，老板点名要做搞了2月不上线了，或者半路夭折的，都是一种警醒。

这种不可控的因素，除了与发起人积极沟通外，无它更好的办法。公司就是要收缩了，砍掉一些项目，敏感的人可能会更早察觉。常规风险反而来自需求环节，再早期。随着时间的推移，项目的正常推进，不确定性会降低的。早期风险大，变动代价低，晚期不确定性低，变动代价大。

质量管理

在项目管理中，质量管理是一个重要的组成部分。项目经理需要确保项目的产品或服务达到预期的质量标准，并在项目执行过程中实施必要的质量控制措施。因此，项目经理需要具备质量管理技能，以确保项目的成功和客户的满意度。

在pmi 里面，有很多传统的质量管理相关，比如6西格玛，戴明环，质量成本

戴明环提出了著名的“戴明环”，也称为“PDCA循环”，即“Plan（计划）-Do（执行）-Check（检查）-Act（改进）”四个阶段的循环。他认为通过这种循环，可以不断地改进和完善管理过程，提高产品和服务的质量，从而提高企业的竞争力。

质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本 。

实际上，质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。

  一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中，程序员是绝对的关键力量，而非测试人员。这也是前面强调提测前冒烟通过率的意义。

  质量规划，明确标准

  规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。在业务生命周期的不同阶段，质量标准应该是动态变化的。

工程上有很多行业的检查措施，软件上关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支规范，同时设计代码准入标准，确保代码 Review、单元测试、接口验证和 UI 验证等手段与项目质量要求相匹配。

质量分析，追根溯源

项目管理质量分析的主要步骤包括：

1. 确定项目的质量目标和标准。

2. 制定质量管理计划，包括确定质量管理的组织结构、质量相关的活动、质量检查点、质量控制措施等。

3. 实施质量管理计划，包括对项目过程执行的监督、质量检查、质量改进等。

4. 进行质量分析和评估，包括收集质量数据、分析数据、制定质量报告等。

5. 控制项目的质量，包括对质量管理计划的执行进行监控、对发现的问题进行改进、预防质量问题等。

通过项目管理质量分析，可以确保项目在质量方面达到预期目标，提高项目的成功率和客户满意度

软件上要开开发人员团队是否新建立，成熟度如何，开发测试配备是否合理，用户反馈的问题。是否需要缓一下新需求，着重查漏补缺。

坚持开线上 Bug 分析会（就是复盘啊），内部 Bug 分类：需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，看看之前的改进措施如何落地。

质量控制，层层卡点

质量控制在项目管理中非常重要，它确保了项目产品和服务的质量，维护了项目的声誉和利益，提高了客户和利益相关方的满意度。质量控制要求项目经理和项目团队在整个项目周期中拥有一系列的质量计划、标准、检查、纠正和评估的方法和工具，以确保项目产品和服务符合成本、进度和质量要求。

质量控制的主要任务包括下列几个方面：

1. 制定质量管理计划，明确项目的质量目标、质量标准、质量测量指标和质量评审标准。

2. 确保项目产品和服务的质量符合质量标准和相关规定要求。

3. 对项目产品和服务进行质量检查和质量测试，发现问题及时纠正并对缺陷进行跟踪和监控。

4. 建立项目质量文档和质量记录，包括技术规范、技术评估报告、缺陷跟踪报告等。

5. 进行质量评审和质量审核，识别存在的质量问题并采取措施进行纠正。

6. 对外部供应商和承包商进行质量评估和质量控制监督，确保项目的供应链体系和过程符合质量标准和要求。

对于软件来说，大厂会有自己持续集成交付平台，逐步为自己的应用定制合适的持续集成方案，指定代码准入的阈值，比如静态扫描、单元测试、覆盖率测试、冲突检测、Jar 包版本检测的通过条件等。

要想一次把事情做对，你首先得明确什么是对，然后要分析差距，找到相应的质量保障方法，并不断迭代。质量也有代价，有了技术债迟早要还，结合需求迭代着主动去还，不然暴雷了死得很惨。

高效会议

前面整理过复盘会，评审会。本节重点看启动会，每日站会、项目周会

启动会

启动会的目的是清晰目标，明确授权。要做到这一点，分别是 why、what 和 how。

第一步 why 是最难讲好的。但实际上，只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情。大团队通常邀请发起人老板来讲，小团队就是产品或者PM来讲。

接着是 what，描绘蓝图，设定清晰的愿景，

最后一步是 how，也就是明确团队之间的责任分工以及合作公约。

启动会准备：

1.项目背景

2.项目目标

3.项目范围

4.里程碑计划

5.主要风险

6.组织架构

7.责任分工

8.流程机制

9.沟通方式

10.支持工具（任务管理、文档管理、代码管理的工具）

新项目或者新阶段才需要启动会来进行公开澄清跟授权。

每日站会

每日站会是自组织的需要，而不是leader的监控需求。

团队每天会通过站会了解整体状态，并对暴露出的风险和问题做出集体决策。有的站会很短，早上一开始就开，有的长，可能加上决策，敏捷推荐的是短的，只说昨天做了啥，有没有遇到问题，今天计划做啥。针对问题再单独开会，减少失控。

  每日站会可以轮流主持，主持人发邮件同步信息。

周会

通常对于小团队，有每日站会可以不需要周会。

项目周会的目的，是解决整体计划层面、跨团队协同配合的问题，包含产品、运营、市场、研发等环节。项目周会的内容，除了常规的各角色进度和风险同步之外，你还需要根据项目组每个时期的整体阶段性重点，让大家感受到导向，就是什么是当前最重要的。

高效会议：

会议边界：

每个会议都有特定的主题和目的，并有明确的参会人员范围。相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的。

会议规则：团队公约

迟到，跑题，拖拉等行为达成一致。

会后跟进：

所有跟进事项，直接进任务系统，确保跟进到底。同时，要在会议纪要的邮件中明文呈现，下次会议统一回顾。

会议不是目的，借助会议去做好群体沟通，最好是短时间达成一致，会议品质是团队互动品质的体现，不是1个人的事。

周会容易变成流水账，那可以让每个人说说工作中的问题，以及需要协调的工作，缩短时间。

引入变化

三个因素：天时、地利、人和。首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通。创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效！

在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法。

   不论访谈、观察、同理心跟倾听。出发点也是团队需要，干系人的疼点。你是否能够站在对方的角度设身处地地思考问题，也是建立信任的基础。