【项目管理】需求变更，风险应对，质量管理，高效会议
一、需求变更
1、需求变更有流程
2、锦囊 1：达成最小共识，变更是有代价的
- 所有需求及所有变更必须建单，无单需求开发有权不接；
- 需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
- 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
找到合适的时机，树立对变更的最小共识。之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始。达成这个最小共识，是要让团队开始慢慢认识到，需求变更是有代价的.
我们追求的是达成项目目标，而不是零变更。
3、锦囊 2：源头治理，一次把事情做对（保证提需求方不会因为没想清楚而导致变更）
上线时间都是定死的，即便认真做了评审，发现了方案的很多问题，一改再改，最后压缩的还是开发时间。其实，要想真正把关需求的质量，还是得从源头开始治理。
从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。
我们在小黑屋搞起了“上墙文化”，产品和设计的 Deadline 排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都被搬上了墙。大老板站台，保证质量。
没过几天，这里居然成为了程序员午饭后驻足观赏的胜地。见到如此盛况，我们开始给他们准备各色小标签，让他们在游览的同时随时发表各种评论。大家的参与热情空前高涨，很多需求和设计的漏洞就在这里被提前发现、及时讨论并修改掉了，有效地保障了早期需求和设计的质量。
4、锦囊 3：快试错，不可抗力巧应对（不可抗因素大老板和大客户的变更）
不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。
我们不再一味地抗拒，不过也并没有放弃努力。相反，我们尽可能想办法降低试错成本。为了隔离老板的需求对整个团队进度的干扰，我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！
同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话。
当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了。很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。你可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老板要的是效果，那你就得用数据说话，更好地应对这些需求变更。
二、风险管理
项目风险是一种不确定的事件或条件，一旦发生，就会对至少一个项目目标造成影响，比如范围、进度、成本、质量等，项目风险也可能对组织或组织的目标造成影响，比如财务、声誉等。
项目从构思的那一刻起，就存在着风险。而应对风险的方式，并不总是规避。
如果风险给项目造成的威胁在可以承受的范围内，并且与可能得到的收获是相平衡的，那么这个风险就是可以接受的。要想在充满不确定性的大环境下取得成功，组织应该致力于在整个项目期间，积极而又持续地开展风险管理。
1、系统化风险识别
风险识别的主体，应该包含项目中的团队成员在内的各方干系人，而不只是项目经理。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。
识别风险过程的主要输出，就是初始的风险登记册，包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序。
【1】风险清单登记册
【2】如何描述风险
2、冰山下的风险
实际上，执行中最大的风险，不是那些显而易见的、冰山上的风险，那些冰山下看不见的风险，往往才是最要命的。通常，项目组中最坏的情况是，大家对项目里的风险避而不谈，避谈风险的原因可能是：
- 缺乏风险的沟通渠道
- 提出来也没有用
- 老板会认为自己没能力管好当前的项目
你需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功，仅此而已。
如果说，你还需要一个简单有效的办法，那你就先去观察一下，在吃饭的时候，你的团队分成了哪些群体。这些自然划分的群体，哪些是你经常交流的？哪些是你缺少交流的？
在工作之余，你要多关注和你缺少交流的群体，抽时间和他们多吃饭多沟通，让自己站在他们的视角想问题。这样一来，很快你就可以扩展自己对于冰山下项目风险的理解。记住，你识别出的风险越多，项目的风险就越低。
1、风险应对措施
- 对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案。一旦风险和危机来临，应急预案就可以有效地降低风险的损失和危机带来的灾难。
- 在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备。也许有些风险预案永远也用不上，但是这并不是说它们是多余的。在风险降临的危机关头，它们的价值就会凸显出来。
- 周期性的风险审查，来识别新的风险。在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状态同步会议上，对风险进行再评估
2、树立正确的风险观
【1】治未病，建立系统性保健机制
- 所谓的“治未病”，就是说要未病先防，事后不如事中控制，事中不如事前控制。
- 你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度。
- 匿名的问卷收集或访谈。你要坚持在多个版本中反复使用，积累数据。这样一来，你就可以通过各个版本的数据变化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风险提示和保健的作用就会逐渐发挥出来。上医治未病，如果你还不具备“望闻问切”的功力，那么匿名问卷，就是一个非常简单的措施，你一定可以做到。
【2】积极管理致命风险
项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化、监管风险等。
- 第 1 步：挖掘出这些致命风险，把它们变为可见的、可谈的。很多管理者非常关心执行中的风险，却对于这类致命风险讳莫如深，只留在自己脑子里，这样反而是最危险的。致命风险的挖掘，通常会让我们对项目背景的理解更加透彻，并对那些影响到项目生死存亡的关键要事，有更加清晰的认知和规划部署。
- 第 2 步：正视风险，不存侥幸心理。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。
- 第 3 步：在项目的核心团队中，周期性地梳理和同步风险状态。
三、质量管理
质量成本分为两类
- 一类是事前防止失败的一致性成本；
- 一类是事后处理失败的非一致性成本，包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本。
近些年来，越来越多的公司在严格控制测试人员的比例，鼓励开发人员通过各类技术手段从上游保障质量，就是因为越发地认识到：事后检查处理的代价其实是最高的。
实际上，质量是规划、设计、建造出来的，不是检查出来的。
预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。
1、质量规划，明确标准
规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。
各个阶段的质量保障手段的列表图
2、质量分析，追根溯源
质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。
- 每月坚持开线上 Bug 分析会。你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。
- 持续进行内部 Bug 分类。从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。
- 建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势，对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析。
3、质量控制，层层卡点
- 明确下来的质量规范和做法，真正落地到各个环节。我给你分享一张样例图，它展示的是从需求到发布的整个过程中的质量活动概览。
四、高效会议
会就是聚会、见面、集会，议就是讨论、商议，会议作为一种群体沟通方式，决定了正式信息在项目组内的传递路径。
“断舍离”，只开最有必要的会，会而有议，议而有决，决而有行。会议不在多，而在于精，每个会议都要真正开出效果来。
1、项目中的重要会议
2、启动会
启动会的目的是清晰目标，明确授权。要做到这一点，你需要分三步走，分别是 why、what 和 how。
- 第一步 why 是最难讲好的。但实际上，只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情。
- 第二步 what，描绘蓝图，设定清晰的愿景，包括项目的三年目标、五年规划，越清晰越好，为的是让团队看到未来的样子。
- 第三步是 how，也就是明确团队之间的责任分工以及合作公约。对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的协作模式。你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空前高涨。这时，启动会的效果就达成了。
启动会的核心要素
- 项目背景
- 项目目标
- 项目范围
- 里程碑计划
- 主要风险
- 组织架构
- 责任分工
- 流程机制
- 沟通方式
- 支持工具
3、每日站会
- 其实，开好站会的关键，是要还政于民。站会满足的是团队的自组织需要，而不是 leader 的监控需求。
- 其实，真正自我管理的站会，除了团队成员自己决定站会时间之外，连主持人都是成员轮流来当的。
为了让每个主持人都能把站会开好，有效把握会议节奏，经过长期的实践，我逐渐摸索出来一套“三张牌”式站会法。站会开始时，主持人将红、黄、绿三张牌分别发给所有的与会人员。在整个站会的过程中，任何人都可以随时举牌来行使自己的权利。
（1）举“红牌”：表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率；
（2）举“黄牌”：表示打断讨论，进行提问，向发言者了解协同及依赖的信息；
（3）举“绿牌”：这是一个 token 牌，代表每个人的发言权。每次只有 1 个人发言，按顺序来，将此牌归还给主持人表示同步完毕。
（4）当所有的“绿牌”都已归到主持人手中，而且没有更多疑问的时候，站会就可以结束了
4、项目周会
- 项目周会的目的，是解决整体计划层面、跨团队协同配合的问题，包括产品、运营、市场、研发等环节。由于项目周会是面向各个角色负责人，甚至面向全员的全局性会议，所以，项目周会就天然地成为了一个最能直接把控整体脉搏的地方。
- 项目周会的内容，除了常规的各角色进度和风险同步之外，你还需要根据项目组每个时期的整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么是当前最重要的。比如，业务初创期，我们每周会一起关注业务
5、保障会议品质的关键
【1】明确会议边界：每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界。
想要彻底改善，项目经理要做好两个确保：
- 确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及需要支持的地方；
- 确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停！
- 另外，参会的人，也应该是有边界的，并不是越多越好。相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的。发送会议邀请时，你要明确哪些是必须参与的人员，并抄送那些可以选择参加的人员。
【2】建立会议规则
- 会议不迟到，看手机，要参与。对于破坏会议内容，要进行触发。
- 建立会议守护大使，发现违反者，则接受惩罚,转换为会议守护大使。
【3】做好会后跟进
- 要想真正做到决而有行，最终靠的是有效的会后跟进，真正把决策落到实处。
- 会议主持人要及时汇总讨论的结果，并形成会议结论。对于无法当场确认的问题，一定也要进行记录，并明确跟进人和完成时间。
- 会后所有跟进事项，直接进任务系统，确保跟进到底。同时，要在会议纪要的邮件中明文呈现，下次会议统一回顾。
