概述
这篇随笔主要介绍一下项目管理中的需求变更，风险管理，质量管理，高效会议的学习笔记。
需求变更：化解程序员的“头号噩梦”
需求变更一直都是一个热门话题，特别是在奉行唯快不破的互联网公司，需求变更可以说是程序员的头号噩梦，也是“996”的直接元凶。阿里有句非常有名的口号，叫作拥抱变化。既然需求变更无法被消灭，那么我们就要通过学习，掌握更好地应对需求变更的方法。我们先来看看常见的需求变更流程。
首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果。其实，流程本身很简单，关键在于能否被有效地执行。在这一讲，我会给你介绍几种亲测有用的方式，你可以把它们作为自己的“防身锦囊”。
锦囊 1：达成最小共识，变更是有代价的
我刚到 A 团队的时候，交互妹子就可怜兮兮地拉着我说：“2 个月过去了，我们的第一个版本还在打磨，80% 的交互稿都已经改得大不一样了，越是临近上线越是不断地改。如果去跟策划们争辩，对方就甩过来一句‘老大要加的’，你说怎么办呢？”这个“老大”也就是 A 业务的负责人。他是产品经理出身，又是完美主义加说一不二的性格。于是，产品策划在团队中就有着绝对的话语权。在耐心地观察了一番之后，我终于等到了时机。在版本结束的复盘会之前，我跟负责人建议说：“你看，我们项目组是全新的团队，成立两个多月了，这么长时间运行下来，还是有不少问题的。我们需要一次深度复盘，这次复盘非常重要，你一定要来参加！”复盘会的当天，大家匿名写纸条，分别列出各个环节做得好与不好的地方，贴到白板上。看着满墙花花绿绿的便签，写满了各个角色对需求变更的各种吐槽，这位负责人沉默了好久。
在复盘会接近尾声的时候，业务负责人当场发话：“从今天开始，团队里的需求变更要严格控制，从我自己做起！”在这之后，产品策划的随意变更行为显然收敛了很多。我也趁势在下一次的全员会上，跟所有团队成员约法三章，把复盘会上的共识，细化成了具体流程：
所有需求及所有变更必须建单，无单需求开发有权不接；
需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
你看，这么一来，大家对于需求变更这件事，就从上到下达成了一个基本共识，需求变更的压力也瞬间得到了缓解。所以，要想改变现状，首先就是找到合适的时机，树立对变更的最小共识。之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始。达成这个最小共识，是要让团队开始慢慢认识到，需求变更是有代价的。不过，毕竟产品仍然在探索期，变更总是在所难免的。怎么办呢？策划们开始想各种办法，好让技术能够顺利地接受变更。实验下来最有用的一招，莫过于请程序员们吃炸鸡了。当时坊间流传着一个段子：“没有一桶炸鸡解决不了的变更，如果不行，那就两桶！”在整体项目时间有要求的情况下，请程序员吃炸鸡，也确实成了项目快速推进的有效选择。作为项目管理，你要谨记，我们追求的是达成项目目标，而不是零变更。上面讲的这些，其实是变更发生之后的应对方法。那么，回到变更的源头，我们可以做些什么呢？首先，就是把关需求的质量，避免需求问题流到下游。 Bug Bash，就是一个好方法，建议你在一些大版本的需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，让各个角色早期深度地参与到项目中，这对防治需求变更非常有效。
锦囊 2：源头治理，一次把事情做对
有同学给我留言说，上线时间都是定死的，即便认真做了评审，发现了方案的很多问题，一改再改，最后压缩的还是开发时间。其实，要想真正把关需求的质量，还是得从源头开始治理。接下来，我来跟你分享一个几年前，我在某事业群启动中台建设项目的真实案例。这个事业群当时已经有三四年的历史了，伴随着多条业务线的高速发展，公共平台的架构频频遭遇掣肘。这个事业群的老大几经思索，下定决心花大力气快速进行整治。情急之下，他找到我，让我来负责这个超级复杂的项目。在四个月内，我们重整了这个平台积累了四年的整个业务和技术架构。当时时间非常紧张，，四五条业务线的产品和设计人员都会参与其中。作为新的中台架构，如果在后续执行中发生变更，往往会产生灾难性的影响。怎么办呢？我急中生智：“小黑屋集中开发呀！”不同的是，这次被关进小黑屋的，不再是苦哈哈的程序员，而是产品和设计人员。他们以前哪经历过这个啊？纷纷念叨着：“What？项目还没怎么着，先把产品和设计的 deadline 定了？！”于是，我找来那位老大站台，召集全员，开了次隆重的启动会。会议的第二天，十几位产品和设计人员就搬进来了。为了减少后期的变更，尽可能一次把事情做对，我们在小黑屋搞起了“上墙文化”，产品和设计的 Deadline 排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都被搬上了墙。没过几天，这里居然成为了程序员午饭后驻足观赏的胜地。见到如此盛况，我们开始给他们准备各色小标签，让他们在游览的同时随时发表各种评论。大家的参与热情空前高涨，很多需求和设计的漏洞就在这里被提前发现、及时讨论并修改掉了，有效地保障了早期需求和设计的质量。其实，这个项目中每条业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再加上不同业务线的策划之间、策划和设计之间、设计和开发之间的沟通成本，不知道什么时候才能真正确认，也不知道会埋下多少变更的“坑”。不得不说，这个锦囊是个大招，使用起来有一定难度。但从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。小黑屋 + Deadline 的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下！
锦囊 3：快试错，不可抗力巧应对
学会了前面两个锦囊妙计，来自产品经理的变更就不在话下了。不过，现实情况是，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢？我的建议是，不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。你可能会说，说起来容易，那如果老板或客户还是一定要改怎么办呢？我的一个团队在被大老板的各种任性变更摧残了半年以后，终于痛定思痛：“我们一直想着法儿地对抗变更，大家都身心俱疲。反过来想想，其实老板也是人，老板也很痛苦，我们要给老板试错的机会，不是吗？”后来，我们不再一味地抗拒，不过也并没有放弃努力。相反，我们尽可能想办法降低试错成本。为了隔离老板的需求对整个团队进度的干扰，我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话。当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了。很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。你可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老板要的是效果，那你就得用数据说话，更好地应对这些需求变更。
小知识：
需求变更在一个项目里是不可或缺的一部分，也是项目趋于完善的自我矫正器，正确看待需求变更应该是项目经理必备的职业素能。一般会遇到两种需求变更，一种是项目进行中自我发现需求变更会更好的完善产品；另一种是外界压力下做出的需求变更。
第一种可能更好的被接受，抵触情绪也会少很多。第二种来自甲方的压力或者老板的压力，要知道甲方、老板和项目经理看待问题的角度是不一样的，甲方更看重的是贴合自身利益，他不会考虑产品后续的扩展性，老板也许会考虑产品方面的诉求，但更多考虑的是公司战略层面的规划，因此，如何衡量这两者与产品之间的平衡性，其实非常难把握。
堵不如疏，如果一直抵触无论对项目团队还是自身发展都是利大于弊的，一般情况下，如果需求变更不大，或者代价很小，可以快速试错，就算恢复相对也会容易很多；而如果变更比较大则需要深度挖掘内在需求，要知道除了产品经理和项目经理，外部其他人很难站在全局看待，也许我们可以提供更好的实现方案，尽可能将产品各方面考虑进去。
另外，项目经理忌讳直接应需求的变更，再大的需求变更下，我们需要与团队更深入的沟通，这样才会将大家抵触情绪降到最低。
风险管理：如何系统化应对风险？
其实，项目风险是一种不确定的事件或条件，一旦发生，就会对至少一个项目目标造成影响，比如范围、进度、成本、质量等，项目风险也可能对组织或组织的目标造成影响，比如财务、声誉等。项目从构思的那一刻起，就存在着风险。而应对风险的方式，并不总是规避。如果风险给项目造成的威胁在可以承受的范围内，并且与可能得到的收获是相平衡的，那么这个风险就是可以接受的。要想在充满不确定性的大环境下取得成功，组织应该致力于在整个项目期间，积极而又持续地开展风险管理。
系统化风险识别
风险识别的主体，应该包含项目中的团队成员在内的各方干系人，而不只是项目经理。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。
识别风险过程的主要输出，就是初始的风险登记册，包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序。其中，风险概率是指每个具体风险发生的可能性，风险影响则是风险对于项目目标（进度、成本、范围、质量）的潜在影响。
上图是《项目管理知识体系指南》中给出的，风险对项目目标影响程度的评估量表。其中，造成成本增加大于 40%、进度拖延大于 20% 的风险，就属于最高影响程度级别的风险。你可以通过访谈或会议的形式来进行风险概率和影响的评估，参与人员包括熟悉相应风险类别的人员，以及项目外部的经验丰富人员。以下是一个风险登记册的示例：
冰山下的风险
实际上，执行中最大的风险，不是那些显而易见的、冰山上的风险，那些冰山下看不见的风险，往往才是最要命的。通常，项目组中最坏的情况是，大家对项目里的风险避而不谈，避谈风险的原因可能是：缺乏风险的沟通渠道提出来也没有用老板会认为自己没能力管好当前的项目试想一下，你的项目中鼓励坦诚沟通风险吗？你的项目中有恰当的程序和渠道，可以让你跟干系人沟通项目风险吗？
没有人反馈风险，不代表没有风险。我曾经见过一个项目组，在某个时间段，他们的业务迅猛扩张，临时招了一大批实习生，从事内容基础建设工作。日常工作时，管理者只是把任务交待下去，跟这些实习生缺乏深度沟通。由于业务繁忙，很少有人带这些实习生，于是，他们逐渐形成了一个与外界隔绝的小集体。直到一次重要里程碑交付前，大量实习生离职，影响到了部门重要 KPI 的达成，这个群体才引起了部门管理层的关注。如果一个项目经理只能依靠正常的渠道识别项目风险，这类问题就不可避免。那么，如何识别冰山下的风险呢？其实，当寻常的渠道不管用的时候，就要看项目经理的信息网络了。项目经理一定不能脱离团队。如果没有群众基础，只是坐等着别人给你上报风险，那你的工作就远远没有做到位。一个优秀的项目经理，必须是一个优秀的“情报人员”，上至最高的项目发起人及组织的各层决策者，下至项目最边缘的人群，比如外包、实习生、短期借调支持人员等，你都要跟他们建立广泛且深入的联系。你可能会问：“我不擅长人际交往，是不是就没办法做到这些呢？”当然不是。有很多内向型的项目经理，也做得非常好。其实，你需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功，仅此而已。如果说，你还需要一个简单有效的办法，那你就先去观察一下，在吃饭的时候，你的团队分成了哪些群体。这些自然划分的群体，哪些是你经常交流的？哪些是你缺少交流的？在工作之余，你要多关注和你缺少交流的群体，抽时间和他们多吃饭多沟通，让自己站在他们的视角想问题。这样一来，很快你就可以扩展自己对于冰山下项目风险的理解。记住，你识别出的风险越多，项目的风险就越低。
风险应对措施
接下来，你需要为识别出的每个风险，制定相应的风险应对措施。对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案。一旦风险和危机来临，应急预案就可以有效地降低风险的损失和危机带来的灾难。比如“双十一”之前的故障演练应急预案，你就需要针对每一种可能发生的线上突发状况，提前确定好处理步骤、责任人、预计时长，甚至是每一步的指令或脚本，以免在出现突发问题时，手忙脚乱导致出错。同时，在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备。也许有些风险预案永远也用不上，但是这并不是说它们是多余的。在风险降临的危机关头，它们的价值就会凸显出来。在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状态同步会议上，对风险进行再评估，并通过周期性的风险审查，来识别新的风险。
树立正确的风险观
1，治未病，建立系统性保健机制
举世瞩目的“阿波罗”登月计划，让项目管理开始风靡全球。当时的肯尼迪航天中心，流传着两个很有意思的“黑话”：沙包、打伞。“沙包”指的是把任务的延期藏起来，不到最后一刻不做汇报；“打伞”是说虽然你延期了，但还有更倒霉的家伙也延期了，而且率先被暴露了出来。你看，即便在“阿波罗”计划里，瞒报延迟、寄希望于他人“打伞”也是无法杜绝的事情。可是，为什么会有那么多的瞒报呢？因为在当时，及时汇报延期往往只会招来一顿责骂。实际上，越是严格控制的系统，越是有问题都窝着藏着，很可能一出问题就是大问题。事物的发展，总是从量变开始的。为了防止风险演变成问题，就要在项目早期，建立系统性的保健机制。所谓的“治未病”，就是说要未病先防，事后不如事中控制，事中不如事前控制。“春江水暖鸭先知”，关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康的，一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于，你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度。经常做匿名的问卷收集或访谈，定期做一场坦诚布公的复盘会，都是系统性保健的好方法。做调查问卷，是项目经理了解团队的重要方式之一。在每个重要版本结束时，你都可以用调查问卷的形式，收集大家的意见，其中有两个典型的问题：
对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度；
对这个版本功能设计的满意度，即产品认可度。
你要坚持在多个版本中反复使用，积累数据。这样一来，你就可以通过各个版本的数据变化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风险提示和保健的作用就会逐渐发挥出来。上医治未病，如果你还不具备“望闻问切”的功力，那么匿名问卷，就是一个非常简单的措施，你一定可以做到。
2，积极管理致命风险
其实，项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化、监管风险等。我作为项目经理的第一个项目，开工半年多就被紧急叫停，这让我对项目的致命风险有了深刻的体感。要管理好这些致命风险，确实不是仅凭项目经理一人之力就可以做到的。但是，如果我们只是一直做容易的事，做会做的事，对这些致命风险视而不见，就会把项目置于危险的境地。一旦致命风险真的发生，很可能会回天乏力。有经验的项目经理，可以从过往经历的失败中，敏锐地嗅到危险的味道。那么，项目经理可以做些什么呢？
第 1 步：挖掘出这些致命风险，把它们变为可见的、可谈的。很多管理者非常关心执行中的风险，却对于这类致命风险讳莫如深，只留在自己脑子里，这样反而是最危险的。致命风险的挖掘，通常会让我们对项目背景的理解更加透彻，并对那些影响到项目生死存亡的关键要事，有更加清晰的认知和规划部署。
第 2 步：正视风险，不存侥幸心理。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。
第 3 步：在项目的核心团队中，周期性地梳理和同步风险状态。
其实，在互联网领域，成功突围者大多都是一路坎坷，从各种致命风险中爬出来的，堪称九死一生。致命风险的存在，本身就是一种警醒。加速构建核心能力，不断拓宽“护城河”，才是最根本的应对之道。
实际上，风险是一种不确定的事件或条件，用辩证的眼光看，风险的另外一面就是“机”。互联网领域的产品创新，大多是一场跳进未知的冒险，这给传统的风险观带来了极大的冲击。在项目管理的过程中，步步为营的风险管理之外，积极把握不确定性带来的机会，提升系统的反脆弱能力，达到最优的效果，是项目经理需要持续修炼的功课。
质量管理：一次把事情做对！
我见过的大部分程序员，对自己的代码质量要求还是很高的。但是，一旦遇到赶工压力，尤其是在 deadline 之前，就很可能会把完成度很低的代码交出去，心想“反正有人给我检查，到时候再说吧”。但是，这些代码就好比是一台“行走的 Bug 制造机”，后患无穷。我曾经在一个技术债特别严重的部门中，面向各级程序员做过一轮抽样的访谈调研。调研的结果是，程序员们只有 27.2% 的时间在做真正产生价值的编码工作。但是，他们有 20.7% 的时间，是在做需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作。质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本，包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本。近些年来，越来越多的公司在严格控制测试人员的比例，鼓励开发人员通过各类技术手段从上游保障质量，就是因为越发地认识到：事后检查处理的代价其实是最高的。实际上，质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。我们都知道，一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中，程序员是绝对的关键力量，而非测试人员。那么，作为项目管理人员，你该如何更好地规划质量管理活动呢？总体来说，你可以从三个方面入手。
质量规划，明确标准
规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。需要注意的是，在业务生命周期的不同阶段，质量标准应该是动态变化的。比如，业务初创期追求的是最小化 MVP 模型的快速迭代，在这个阶段，质量往往不会是最关键的因素。但是，当规模扩张到一定程度之后，对于质量的要求就非常高了。不同的项目对质量的要求也相差甚远，无法一概而论。因此，只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义。你可以参考一下下面这张图片，它展示的是，一个已经进入规模增长期的稳定业务对客户端质量标准的定义。
定义好了质量标准，你要思考的是，在整个项目的进程中，需要规划好哪些质量保障活动，以很好地达到这个标准。我给你分享一张各个阶段的质量保障手段的列表图。
其中，你需要特别关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支规范，同时设计代码准入标准，确保代码 Review、单元测试、接口验证和 UI 验证等手段与你的项目质量要求相匹配。项目经理的视角始终聚焦在项目的整体目标上。在项目经理看来，质量作为目标的一部分，达到要求是最重要的，不需要追求质量的无止境提升。因为，质量终究也是有代价的，是否够用则取决于项目目标和要求。
质量分析，追根溯源
质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。我曾经给一个底层核心模块的技术团队做项目管理，但我经常听到上层模块抱怨它的质量，有时候甚至在关键流程上都有问题，团队内外都对其质量失去了信心。从数据上看，这个模块的线上 Bug 量占项目总 Bug 量的 17%，给上层其他模块和运维都带来了不少麻烦。随着越来越多的外部应用陆续接入，如果这个问题得不到有效解决，内部矛盾很可能就会升级为外部矛盾，不容忽视。经过深入分析，我对频发的质量问题有了以下认识：
团队扩张得很快，在相当长的时间内，测试人员的配比都非常低，8 个开发对应 0.5 个测试。测试基本上只是给开发打工，只能保证最最基本的功能，其他更深度的测试类型根本无所涉猎；
团队没有从用户的视角来检验产品，上层模块的应用场景、运维的应用场景与测试的视角相差较大，测试效果很难保障；
约有五分之一的线上 Bug，是来自社区，用户侧出现问题以后才去社区找，再把这个补丁合进来，没有主动应对。
同时，我也做了用户调研，最终的结果显示，用户对底层核心模块的期望更多的是稳定，至于新功能，用户普遍表示暂时没有需要。因此，盲目增加复杂功能其实并不明智，保持产品简单可靠才是王道。定位完问题，我们就可以采取相应的措施进行改进或预防了。
新功能适当放慢：在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变动。回顾总结：将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措施，并跟进实施到位。查漏补缺：对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体 review，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是一项长期工作，要确保将其分解到各个迭代中，分批实施。走到前面：紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要的补丁。以终为始：新功能需求确定后，测试用例同步设计并进行 review，然后开放冒烟测试标准，让开发人员在明确“什么是完成”的前提下，进行开发。
在坚持了两个月之后，整体的质量状况好了很多。总体来说，质量分析最重要的是要追根溯源，找到问题症结。我给你推荐几种简单实用的方法。每月坚持开线上 Bug 分析会。你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。持续进行内部 Bug 分类。从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势，对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析。
质量控制，层层卡点
如果说质量分析的要点重在追根溯源，那么质量控制，就是将一些明确下来的质量规范和做法，真正落地到各个环节。我给你分享一张样例图，它展示的是从需求到发布的整个过程中的质量活动概览。
需要注意的是，质量控制及卡点行为，是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口。即便是在同个项目的不同应用中，也会因为线上要求的不同，而对质量卡点有不同的侧重。通过质量卡点的在线工具化，才能做到真正有效的质量保障。比如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值，提交测试申请时，如果系统检测到缺陷值有升高，就不能够成功提交。
高效会议：项目中要开好哪些会？
从事项目管理工作之后，你会发现自己一下子多了很多大大小小的会。项目全局涉及到的整个过程，你都要去了解。很多人说，项目经理有 80% 的时间都用在了沟通上，不是在开会，就是在开会的路上，其实所言不虚。会就是聚会、见面、集会，议就是讨论、商议，会议作为一种群体沟通方式，决定了正式信息在项目组内的传递路径。实际上，我们的会议，就像现代人的营养一样，过剩了。我们知道，营养过剩就会吸收不进去，那么会议过剩了，会怎样呢？如果我们把项目组看成一个有机体，这个有机体承载不了那么多的信息，后果就是会而不议。会上说了一堆，却没有决议，没有动作，那么这个有机体是没有办法正常运作的。怎么办呢？答案就是“断舍离”，只开最有必要的会，会而有议，议而有决，决而有行。会议不在多，而在于精，每个会议都要真正开出效果来。
项目中的重要会议
其实，“断舍离”是一种思维习惯，也就是说，你要有意识地选择，最适合项目现阶段状况的会议。
项目过程中有大大小小的会，我把这些会议汇总在了下面的这张图片中，你可以看一下。实际上，这些会分别服务于不同的目的。之前我讲过复盘会、评审会，我们今天重点来看启动会、每日站会和项目周会。实际上，只要掌握了这些类型的会议要点，其它类型的会议也就不在话下了。
启动会
启动会好比是誓师大会，用来快速地聚拢兵力，集中力量干大事！我曾经经历过一个项目，因为战略调整和重组，这个团队的规模，迅速地从十多个人扩张到了一百多人。这个临时拼凑的百人军团，大多是自上而下从各个部门紧急征集来的。看起来人很多，但因为角色身份混乱，工作习惯不同，团队内部存在着各种冲突和困惑。在这样的情况下，一场启动会就是非常有必要的。那么，怎么做启动会呢？启动会的目的是清晰目标，明确授权。要做到这一点，你需要分三步走，分别是 why、what 和 how。
其中，第一步 why 是最难讲好的。但实际上，只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情。那个项目的启动会，我们特意邀请到大老板亲自上阵跟大家讲述项目背景。他从公司战略赛道的选择性聚焦，讲到自己对这个事业的追求，话语中所传达出的重视、关注和热爱，是让这个 why 真正打动人的核心要素。接着是 what，描绘蓝图，设定清晰的愿景，包括项目的三年目标、五年规划，越清晰越好，为的是让团队看到未来的样子。你可以使用直接讲解的方式，也可以采用更加互动的做法。比如，我们曾经组织大家基于项目的背景信息一起共创，分组画画，共同畅想未来的愿景。这种画面感，会形成一种深刻的体感记忆，让大家在开始做事之前，就先有了沉浸式体验，效果非常好。最后一步是 how，也就是明确团队之间的责任分工以及合作公约。对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的协作模式。你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空前高涨。这时，启动会的效果就达成了。
关于启动会的内容，你可以从以下十个方面着手准备：项目背景，项目目标，项目范围，里程碑计划，主要风险，组织架构，责任分工，流程机制，沟通方式，支持工具，其中，沟通方式指的是，会议的时间安排、频率及参与人员；支持工具一般是指项目组统一使用的任务管理、文档管理、代码管理的工具。需要注意的是，只有在新项目或新阶段准备启动，涉及到方向、目标、人员、职责的调整的时候，才需要开启动会来进行公开的澄清和授权。
每日站会
随着敏捷的普及，每日站会的概念也是深入人心。然而，很多站会被当作是例行公事的汇报会，枯燥无味，还有一些站会开得冗长且低效。其实，开好站会的关键，是要还政于民。站会满足的是团队的自组织需要，而不是 leader 的监控需求。那些把站会开得很持久的团队，往往已经形成了自我管理的氛围，团队每天会通过站会了解整体状态，并对暴露出的风险和问题做出集体决策。作为项目管理人员，你要引导团队不断建立和完善自己的规则，并在运行顺畅之后，把站会还给大家，让大家自己决定站会要怎么开。早期我带过一个团队，经过反复尝试，大家决定把站会的时间放在午饭前的 11:30 开始。这样一来，团队成员可以有相对完整、不被打扰的整个上午的工作时间。另外，吃饭的动力也会让大家集体加速，从而保障站会的高效。如果有一些争议性的话题没有解决，午饭时也可以继续讨论。
其实，真正自我管理的站会，除了团队成员自己决定站会时间之外，连主持人都是成员轮流来当的。为了让每个主持人都能把站会开好，有效把握会议节奏，经过长期的实践，我逐渐摸索出来一套“三张牌”式站会法。站会开始时，主持人将红、黄、绿三张牌分别发给所有的与会人员。在整个站会的过程中，任何人都可以随时举牌来行使自己的权利。
举“红牌”：表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率；
举“黄牌”：表示打断讨论，进行提问，向发言者了解协同及依赖的信息；
举“绿牌”：这是一个 token 牌，代表每个人的发言权。每次只有 1 个人发言，按顺序来，将此牌归还给主持人表示同步完毕。
当所有的“绿牌”都已归到主持人手中，而且没有更多疑问的时候，站会就可以结束了。这样简单的游戏规则，既可以帮助主持人有效地把握节奏，同时还把会议控制的权力和责任交给了与会的每一个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同时又能保持“高效”。
项目周会
通常情况下，对于 10 人以内的小团队来说，如果已经有了每日站会，就不太需要再另外设置周会了。但是，当项目组的规模继续扩大，分成了若干的工作小组之后，你就需要利用项目周会，周期性地对项目的各个角色、各条线的进展和风险做全面的检查了。项目周会的目的，是解决整体计划层面、跨团队协同配合的问题，包括产品、运营、市场、研发等环节。由于项目周会是面向各个角色负责人，甚至面向全员的全局性会议，所以，项目周会就天然地成为了一个最能直接把控整体脉搏的地方。项目周会的内容，除了常规的各角色进度和风险同步之外，你还需要根据项目组每个时期的整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么是当前最重要的。比如，业务初创期，我们每周会一起关注业务数据的实时变化，针对有问题的部分，各个角色及时联动调整策略；对于一些技术保障类的业务，则会每周重点关注客户反馈的工单数据和服务保障 SLA 的变化；对于 ToB 类业务，会重点关注付费率、续费和丢单情况的最新变化，从而及时找到问题，快速联动解决。
保障会议品质的关键
实际上，会议的品质，很大程度上可以看出一个项目团队的互动品质。把会开好，看上去很简单，但其实并不容易。我的经验是，不要盯着会议的数量，而是要追求会议的品质，这里有三个基本要素。
1. 明确会议边界
每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界。你可以写下目前参加的每一个会，问问自己：“为什么要开这个会？会议的边界是什么？哪些议题适合在会上讨论？”对于那些与主题不相干的议题，你要坚决舍弃。我见过过很多会议，要么是流水账式的汇报状态，一大半人在那儿玩手机、看电脑，要么就是进入了技术细节讨论状态，过分纠结于细节，争执不下，早就偏离了会议主题。这些都是会议边界定义不清的问题。想要彻底改善，项目经理要做好两个确保：确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及需要支持的地方；确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停！另外，参会的人，也应该是有边界的，并不是越多越好。相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的。发送会议邀请时，你要明确哪些是必须参与的人员，并抄送那些可以选择参加的人员。
2. 建立会议规则
我们曾经做过一个“会议小恶魔”的游戏，就是让每个人想尽办法地破坏会议，借此去体会开好一个会，需要哪些要素。结果我们发现，像迟到、拖堂、开小会、看手机等行为，问题虽然不大，但是频繁发生的话，就会大大地影响会议品质。特别是对于一些周期性的常规会议，约定好会议规则是非常有必要的。主持人要引导大家建立会议规则，对于迟到、请假、拖堂、跑题等行为建立公约，并成为规则的守护者。我身边有些做得好的项目周会，光是会议规则就已经迭代过五六个版本，从迟到红包、拖堂红包开始，到轮流担任“规则守护大使”的角色，最后发展成由主持人判定违反会议规则者，即自动成为下次会议的主持人……不得不说，这一招真的很管用。规则上的推陈出新，在活跃了氛围的同时，还共同构建出了高效的会议品质，最终是对每个人的时间负责。
3. 做好会后跟进
要想真正做到决而有行，最终靠的是有效的会后跟进，真正把决策落到实处。会议主持人要及时汇总讨论的结果，并形成会议结论。对于无法当场确认的问题，一定也要进行记录，并明确跟进人和完成时间。会后所有跟进事项，直接进任务系统，确保跟进到底。同时，要在会议纪要的邮件中明文呈现，下次会议统一回顾。
总结一下，开会团队都觉得流于形式，组织者也觉得索然无味。其实，这并不是敏捷方法的问题，流水不腐，户枢不蠹。没有什么东西是一成不变的，会议设计和流程，也需要根据项目各阶段的情况做相应的调整。既然项目的状态和团队的状态一直在变化，那就要根据这种变化去动态调整，想清楚我们到底要开哪些会？不开哪些会？怎么把会开好？只要你坚持只开最有必要的会，开真正高效且产生决议的会，大家不但不会排斥，还会积极参与，会后还会有“这么短时间就达成一致”的满足感！所以你看，会议不是目的，借助会议去做好群体沟通，让大家看到有效的进展，才是最重要的。
总结
以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。