你好，我是郭东白。从这节课开始，我们就进入到架构活动的第五个环节——项目启动。
完成架构规划之后，恭喜你，接下来可以着手准备项目的启动了。这是架构活动中极具里程碑意义的一个节点。项目的启动，标志着企业开始正式向一个架构活动投入各种资源。
项目启动时，你跟所有参与者就像组建了一个大家庭，开始朝着目标努力奋斗。不过实际情况是，这个环节往往会变成一个庆典：领导致辞、参与者喊口号，一切似乎都很完美。
我们知道，架构活动多数是高风险的。如果把架构活动比作多数以离婚和对撕收场的明星的婚姻，那么这种高风险婚姻，重要的不是婚礼，而是婚前协议。想想看，如果婚前有个互不对撕的条款，能挽救多少明星的职业生涯啊！
好，接下来我们就来聊聊这个话题，看看架构师需要在项目启动环节做好哪些工作，才能最大化架构活动的成功率。
项目启动前的准备工作
项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认。
这个过程与签约合同的过程十分类似。在进入项目启动之前，你跟各个参与方仅仅达成了合作备忘录。这是在口头上达成的约定，没有较强的约束性，因而我们还需要与各方正式“签约”，生成最终版“交付合同”。也就是说，通过项目启动会把合同的内容广而告之，参与者也都会公开支持合同，并认领交付项目。在此之后，签约正式生效，所有参与者都要对这个虚拟合同中的任务条款负责（Commitment）。
不过“签约”之后，不是说自此之后再也不能更改这个合同中的条款了。而是指有了承诺，任何参与者都不能单方面更改条款，需要通过一个确定的流程才能更改。
在互联网时代，项目启动环节的王道是以终为始，公开架构活动的明确目标，以清晰的语义阐述参与者的责任、权利和架构环境，保障参与者对目标的全力投入。那么架构师，就需要设立保障机制，来保障这个合同是真实有效的，从而最大程度地提升架构活动的成功概率。
在项目启动之前，我们架构师需要跟项目经理一同来做一些准备工作，主要有如下四个方面。
- 资源环境：确认并锁定运营资源、产品资源、技术资源和数据资源。
- 架构环境：将之前搭建的架构环境，尤其是架构信条的细节，整理成完整的线上文档，并共享给其他参与者。
- 架构文档：完成整体的架构规划，初步完成不同领域的细节规划文档。
- 重大风险：梳理好整体和各个领域的风险，完成已知的重大风险预案。
在准备的过程中，你会发现架构活动可能还面临着一系列的挑战，主要有如下六个方面。
- 缺乏问题升级机制和冲突解决机制：在互联网这种舍命狂奔的状态之下，缺乏这种机制的架构项目，注定会在众目睽睽之下以崩塌收场。
- 缺失技术细节：多数沟通停留在口头，设计文档不存在或者不完整；核心领域和强依赖中有大量仍处在争议状态的设计评审结论。
- 架构方案互相冲突：整体的架构方案，跟一个或者多个细分领域的架构方案有冲突。
- 隐藏的技术风险：多数互联网公司不怎么区分大项目和日常需求，导致对大项目的技术风险评估过于简单和乐观。而这些大的项目，可能会因为系统复杂度高而导致失败。
- 资源不确定：某几个领域的资源无法保障 100% 的投入，只表示“尽力而为”。
- 边界模糊：部分执行团队之间的任务边界模糊，这也是第 26 讲提到的任务边界划分尚未完成的情况。
作为架构师，我们可以从技术视角解决前四个挑战。而后两个挑战，则要依靠项目经理来推动完成。
根据这四个挑战，架构师需要完成的任务项依次是：架构方案的正确性验证，技术交付内容的正式确认，重大风险解除，以及预警机制建设。
架构方案的正确性验证
你可能会疑惑：我在架构规划这个节点不是才完成了架构方案的确认吗？为什么还要再验收一次？
因为这一次是玩真的！两次的架构方案确认，有点像你在大学操场上被问到“我们永远在一起吧，好吗？”或者在西餐馆里被问到“明天我们领证去吧，好吗？”
试着代入一下，回答这两句话的压力完全不能相提并论。
这一次是玩真的，所有执行者要在承诺书上签字画押。而你这次得到的答案，可能跟一周前甚至一天前大不相同了。
除了刚才讲的压力原因外，也有其他方面的原因。一种比较常见的情形是，项目启动之前会有大量细分领域的架构规划和评审，有时候也会做专门的外部评审。如果你在验收中发现了大量冲突的结论，这个时候就必须重新审视之前的整体架构规划，以及重大风险的相关梳理和结论。因为你之前的某些假设很可能是错误的。
还有一种比较常见的情形。在验收子域的架构规划时，可能会发现细分领域的取舍偏离了某些决策信条。比如实施团队做了某种取舍，但这些取舍偏离了整个架构活动的目标。
一般来说，我们做取舍的原则是以保障用户价值和商业价值为前提，且尽量满足架构活动的技术目标。但执行方往往会以保障自己领域的交付时间为第一优先级。很明显，两者是互相冲突的。
我从来没见过哪位决策者强制一个团队必须优先保障交付时间。哪怕是双十一大促这样的大项目，也要先确保商业效果，而不是交付时间。一旦碰到资源冲突，最终肯定是先砍掉低优先级的需求，而不是商业效果。
在这个验收环节，你可能会发现某个子域的架构规划还没完成。仅仅有口头上的需求沟通，文档内容要么缺失，要么还有大量待解决的结论。这些都是重大风险。
架构的正确性验证，本来就是一个自顶向下分解，随着项目进展和环境的变化而逐步细化的过程。项目启动呢，又是一个重大的状态变化的过程，意味着架构规划的确认将从非正式变成正式。那么之前没有暴露的细节问题，这个时候很可能会一下子大规模地涌现出来。
需要注意的是，这个验收环节必须由我们架构师亲自完成，不能移交给他人。打个比方，验收环节相当于飞行员在飞机起飞前的检查。也就是说，地勤人员检查过飞机后，飞行员还要从自己的视角出发再检查确认，才能让飞机起飞。甚至，乘客也要从自己的视角出发再进行检测，看看安全带是否好使、座位下是否有救生衣。
技术交付内容的正式确认
如果你参加过项目启动会，肯定见到过这种仪式。某位领导把一个具有象征意义的物品，通常是旗帜，交给某个领域的负责人。在转交的过程中，两个人会握一下手。很不幸的是，大多数项目的启动仅仅停留在了握手这个仪式上。
在项目启动环节，我们真正想达到的是深度握手。各个参与方对所达成的架构目标、架构方案、架构环境、任务边界、交付节奏，以及资源投入，完成一次有约束效应的正式握手（Acknowledgment）。
作为架构师，我们不能像领导一样去握手，而要将握手这个环节做成一个真正的技术协议，就像 TCP 协议中的三次握手协议一样。我们的目的，就是获取一个能提升交付确定性与交付质量的、毫无歧义的技术 ACK。无论是用 Jira、Wiki，还是用 PPT，都可以。
除了要确认我们在统一语义环节中达成的架构目标与架构方案外，还要从技术层面对每个子域的技术交付内容做正式的确认。
可能你会说，之前已经有 API 定义了。这还远远不够！你需要告诉每个执行者，请他们在某年某月的某一天之前，确认：
- 将要交付的子域的架构图、设计文档和评审结论；
- 人员保障；
- 质量目标。
架构师需要做的，就是从技术视角出发，自顶向下验收所有子域的方案。
如果这个深度握手的环节做得足够细致，你很可能还会发现新的重大风险，或者个别执行者不愿意对技术交付内容做出承诺，开始闪躲。甚至还会发现某些 Jira 文档链接指向的是空的 Wiki，等等。
这些可能出现的情况，都意味着架构活动中还有很多未曾发现的重大风险。那么接下来，我们就要开始解除重大风险了。
重大风险的解除
解除重大风险的具体做法，跟我们之前在可行性探索环节中的风险决策方法相同。这里就不重复了。
我想另外强调的是，在项目启动这个节点，放弃可能是最好的选项。你可能觉得，在项目启动之前退出就好比悔婚一样，多丢人现眼啊！但是，对比离婚大战和离后互撕，在领证前悔婚相对来说是个更负责任的行为，可以避免造成更大的损失。
为什么呢？在架构启动之前，其实公司投入的成本很低，很少能到百万人民币的级别。就像我在法则二中的举例，大规模的项目启动之后，一旦有损失，少则百万美金，多则百亿美金。
不过你要是对这些项目仔细研究的话，会发现它们都缺乏高质量的逻辑论证。要知道，一个有过专业训练的架构师至少是可以发现这些重大风险的。
也就是说，这样的损失是可以避免的。但是就像生活中的许多行动一样，放弃需要勇气。今天的放弃是为了避免明天更大的损失。
预警和冲突解决机制建设
如果没有什么重大风险，或者向上沟通了重大风险之后，决策者依然决定做一次有准备的冒险。这个时候我们是不是可以启动项目了呢？
还要再耐心等一下！为了保障架构活动的成功，你还要为架构活动引入问题预警机制和冲突解决机制。
作为架构师，你肯定不能想象线上服务没有任何报警机制和故障处理流程。架构活动也是一样的。其中不仅有复杂的团队关系，还有巨大的交付压力。在这么短的规划时间的架构活动中，怎么能没有任何报警流程呢？又一个不幸的现实是，大多数高风险的架构活动中，都缺乏问题预警机制和冲突解决机制。
什么是问题预警机制呢？就是在架构活动启动之后，有一个畅通的沟通渠道，来确保重大问题能被决策者注意到。
比如项目经理通过项目日报或者周报对风险逐层上报，就是一个很好的方式。从技术角度来说，统计数据、需求完成进度、Blocking Bug 的数量、集成测试的进度，都是很好的预警指标。
预警的价值就在于机制本身的客观性。如果能在项目启动之前公布一个预警机制，确保这个机制是基于某些客观数据制定而成的。比如 Jira 用户故事的完成比例、每天提测的代码量、缺陷率等，并把数据统计和汇总做得尽量客观。这样的话，每天发布状态和提出预警就不是针对任何人的，而是在公布一个客观事实，避免得罪人。
互联网时代，大多数公司都处在舍命狂奔的状态，导致项目失败成了常态。因此对于重大问题，必须要有发现、沟通、响应和止血的流程。我见过最离奇的缺少预警的情况，就是为四个 BU 建设中台的融合项目，最终竟然交付了一个有四套代码分支的“中台”。
什么是冲突解决机制呢？就是在两个或多个合作方之间出现争议，并且无法化解冲突的时候，需要紧急启动的升级决策流程。一般情形下，升级后形成的决策，参与各方无论如何都必须遵守并坚决执行，不能反复申诉和辩论。
虽然这种决策方式可能会导致重大失误，但在互联网时代，时间是最稀缺的资源，这种决策方式的时间成本是最低的。一般的做法是几个人小范围讨论，如果不能达成一致，就需要升级到更高层级再次讨论。如果依然达不成一致，就需要升级到决策者，形成一个最终的结论。一旦最终结论形成，各方须立即执行。
预警和冲突解决机制的意义是什么呢？任何人都是在巨大的时间和交付压力下工作的，边界模糊是常态。在一个高风险项目的后期，尤其是整体交付出现重大困难的时候，团队之间的冲突就会频繁发生。
那么搭建的预警和冲突解决机制，就是要确保所有参与者不会把技术问题“政治化”，确保重大问题不会被隐瞒，冲突不会被长期拖延。在这个过程中，你要向所有参与者传递一个态度：技术问题和团队冲突不可避免，但我们有确定的沟通机制和处理流程来帮助大家解决问题。
更理想的情况下，这些机制应该在架构环境搭建这个节点中，就被充分讨论并完成。在项目启动环节，你这个架构师只需要向全员宣布即可。一般来说，这种机制在企业内部的重大项目中可以被多次复用。
至此，你才真正帮助领导们签好了“婚前协议”。等他的公司上市或者项目上线之后，也没有人在那儿等着吃瓜了。
项目启动完成
如果你完成了以上这些准备工作，那就可以召开启动会了。
有的架构师喜欢开大会，无论项目大小，恨不得把整个公司的管理层都邀请过来。在这个内卷的时代，尤其是在大公司，开一个高调的项目启动会的确是提升项目成功概率的有效手段。
如果留心的话，会发现我在模块一的思考题里曾问过你这么一个问题：“怎么判断做事情的优先级？”有不少同学的答案里提到了项目的重要性。可以看出来，大公司中启动会的明星阵容，的确能彰显出一个项目的重要性。
不过项目中的大小会议都会占用参与者的时间资源，我还是期望你能坚持我们在法则五里提到的“最大化商业价值和最小化成本”的做事方式。
你应该通过完整的架构目标描述、清晰的预警和冲突解决机制、宏观的架构方案和顶层用例、分模块的架构设计和交付方案、重大的集成时间点、设计文档 Wiki 链接等高质量的内容，取代单纯地喊口号和作秀。只有这样，才能为参与启动会的一线程序员提供全局视角和技术干货，这才是你这个架构师能为项目启动带来的核心价值。
不过既然请来了明星阵容，那么明星们也要为你的启动会创造价值才行。我建议你可以邀请高层决策者和赞助者来分享项目背后的思考和动机：那个真正的 Why 是什么？他们从这个项目里看到的前景和未来是什么？
小结
项目启动不是一个庆典，而是一个类似合同正式签约的过程。这种正式的“签约”前肯定会暴露很多潜在的问题，你要做的就是从架构师的视角上审视这些问题：
- 哪些问题会导致系统性的风险，让整个架构活动失败？
- 哪些冒险值得选择？
同时，在整个过程中，你要从技术视角来审视这个虚拟的合同的有效性，也就是我们提到的深度握手这个步骤。最后，你也要为接下来的实施环节提供问题预警和冲突解决机制，确保执行过程中发生的问题能够被及时上报和解决，团队之间的冲突能够被迅速化解。
有了这些准备，你就可以用全局的视角和高质量的技术干货，来充实项目启动会了。
思考题
三个思考题，建议选择最有感触的一个来做：
- 你经历过印象最深刻的项目启动会是什么？为什么？
- 在一个项目启动会中，你最关注的内容是什么？你从中得到的最大收获是什么？这些内容能帮助到你吗？
- 我们在这节课提到了问题预警机制。你参与过的架构活动有预警机制吗？这些预警机制有效吗？为什么？