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