五 项目启动
项目的启动，具有里程碑意义的节点，标志着企业开始正式向一个架构活动投入各种资源。
从项目管理角度来看，项目启动是获取项目干系人承诺。比较正式的是让所有参与方完成一次有约束效应的目标与任务确认。
不是个庆典仪式，项目启动环节的王道是以终为始，公开架构活动的明确目标，以清晰的语义阐述参与者的责任、权利和架构环境，保障参与者对目标的全力投入。
准备工作：（跟项目经理一起）
1.资源环境：确认并锁定运营资源、产品资源、技术资源和数据资源。
2架构环境：将之前搭建的架构环境，尤其是架构信条的细节，整理成完整的线上文档，并共享给其他参与者。
3.架构文档：完成整体的架构规划，初步完成不同领域的细节规划文档。
4.重大风险：梳理好整体和各个领域的风险，完成已知的重大风险预案。
与此同时，还会发现架构活动可能还面临着一系列的挑战：缺乏问题升级机制和冲突解决机制、缺失技术细节、架构方案冲突、隐藏的技术风险。
项目启动完整过程
1 架构方案的正确性验证：架构师亲自完成，不能交付别人 。相当于亲自验收，尤其是子域的架构规划与整体架构目标偏离。
2 技术交付内容的正式确认：从技术视角出发，自顶向下验收所有子域的方案。
3 重大风险的解除
4 预警和冲突解决机制建设
预警就是在架构活动启动之后，有一个畅通的沟通渠道，来确保重大问题能被决策者注意到。比如进度日报、周报，统计数据。
冲突解决机制就是在两个或多个合作方之间出现争议，并且无法化解冲突的时候，需要紧急启动的升级决策流程。
任何人都是在巨大的时间和交付压力下工作的，边界模糊是常态。尤其是交付出现困难 的时候，就是要确保所有参与者不会把技术问题“政治化”，重大问题不会被隐瞒，大家达成一个共识：技术问题和团队冲突不可避免，但我们有确定的沟通机制和处理流程来帮助大家解决问题。
5 项目启动完成：
采用大化商业价值和最小化成本做事方式，通过完整的架构目标描述、清晰的预警和冲突解决机制、宏观的架构方案和顶层用例、分模块的架构设计和交付方案、重大的集成时间点、设计文档 Wiki 链接等高质量的内容。为参与启动会的一线程序员提供全局视角和技术干货，这是架构师能为项目启动带来的核心价值。
六 阶段性交付
这个阶段耗费时间最长，大量研发人员投入到架构活动中去。架构师此时不要单纯把自己化身项目经理，推动项目执行方。而是对用户价值点的提纯。PM更侧重基于时间段划分，忽略了交付价值的差异。及时采用时间段方式交互，架构师的注意力也要放在高用户价值点的任务交付上。
郭老师借用 了mvp的概念，提出了最小价值单元（MVPU），这是一个交付单元。
1.独立性：从用户视角看，这个单元可以被单独识别。
2 结论的完整性：从阶段性交付的商业价值的角度看，我们从这个单元得出的结论是完整的。
3 可度量性：这个单元为目标用户创造的价值可以被数字化、被度量。
在价值单元交付的过程中，要在保障结论有效性的前提下，尽早把一个完整的功能发布给目标用户，同时向他们及时收集反馈。这个过程的王道是忠于架构目标，尊重市场反馈，以最大化企业 ROI 的原则，选择正确的交付路径。
进入阶段性交付前的准备工作
1阶段性 MVPU：从目标用户的视角看，最小可用的价值单元是什么？用户是如何感知到这个功能的价值的？
2阶段性目标：用什么量化指标来度量这个功能的价值？如何通过 A/B 测试来验证这部分的价值？
3 最短路径：在不破坏项目结构的前提下，交付 MVPU 的强依赖是什么？
郭老师提出了阶段性价值交付的概念，并强调了架构师要持续关注和创造商业价值。在阶段性价值交付这个节点上，还隐藏着一个职业成功者所必需的思考习惯：时刻做取舍。在架构活动中，最具用户价值和最具商业价值的部分，也是最小可用价值单元。
阶段性价值交付的完整过程
在交付的过程中，主要有三部分工作：目标分解、定义交付路径，以及项目交付跟踪和路径调整。
1目标 分解：
首先是商业价值的视角。这个项目能为企业带来哪些重要的商业价值呢？度量这个商业价值的核心指标是什么
其次是用户价值的视角。这个项目能为用户带来什么重要的价值呢？相应的指标是什么？
最后是技术价值的视角。这个项目能为企业带来哪些重要的技术价值？相应的指标是什么？
一上来就起一个全员都参与的大项目，成本高、压力大，失败的概率更大，反而不如ROI 最大化的路径。
2 交付路径设计
架构师的价值就在于保障整个架构活动的结构性，以及交付顺序的合理性。主要有如下三件事要做：
梳理强依赖关系；
控制联调的成本和节奏；
把握速度和结构性的平衡，先提升最终目标的成功概率为准。
3 交付跟踪与路径调整
任务进度的跟踪属于项目管理层面的问题，我们主要讨论MVPU 的目标达成情况。
多数时候你会发现目标没有达到预期，这是很正常的。我们的假设往往过于乐观，逻辑也不够严谨。这是个非常重要的决策点。因此我们必须寻找目标不满足预期的原因，看看问题出在哪里，是否有解。这种分阶段交付其实给了整个决策团队一个调整的机会，越早发现问题，就越有时间来调整，从而提升最终的成功概率。即使商业模式不成立需要大改或者需要放弃，代价也是相对低的，减少了浪费，给自己和团队赢得了宝贵的试错机会和调整方案的时间。
4 完成阶段性交付
七 复盘
通过复盘，不仅能确保参与者的 成长最大化，还可以通过复盘挖掘到更多的架构机会，为未来同类的架构活动沉淀更好的工具。
复盘个人理解比较狭隘，基本上跟事故反思挂钩了。失败了，严重delay了，pm会组织复盘。架构的复盘特指通过还原并深度思考架构活动的完整历程，来寻找可以提升未来架构活动成功概率的过程。
复盘的目的：寻找可以提升未来架构活动成功概率的机会。
复盘的对象：复盘的对象不仅包括失败案例，还包含成功案例。尤其是失败案例，遇到更为频繁。
复盘的视角：
对他人的审视，简单来说就是一句话：谁造成了我的失败？对自我的审视，简单来说也是一句话：我什么地方做得不完美？还可以其他维度进行分析，从不同的维度进行分析，比如决策逻辑层面、执行层面、组织和文化层面等。通常出现问题都是多因素叠加导致的。
复盘的三大误区
一 止于问责：惩罚责任人并不是复盘的目标，也不应该是复盘的终点。复盘会成了甩锅会，相关人不愿意讨论改进，掰持谁的责任大耗费时间长，有的人争论得不可开交，其他人都噤若寒蝉，生怕把自己牵扯进来。
对于一个公司来说，最重要的是从失败中获取能力的提升。
第二个止于意识提升：在复盘的过程中，肯定会涉及到自我剖析，让参与者寻找各自的提升点，这个受限于自我保护意识容易反思不够彻底。但是项目复盘，更重要的是整个公司的能力提升，个人能力的提升并没有固化到团队或公司中。
第三个是止于错误补救。就是在最大程度上挽回问题所造成的损失，但不能对于未来的架构活动形成任何助力。
复盘的王道就是通过对失败事件的深度剖析，从中寻找一些机会点，从而提升企业未来的架构活动的成功概率。
进入复盘前的准备工作
1.建设复盘氛围：为参与者提供一个安全且平衡的复盘环境。
2 梳理错失的机会点：从公司层面的宏观视角看，错失的最可惜的机会点是什么？
3 设定目标：引导参会者对复盘目标有个清晰的认知。如果不能拿到一个非常有洞察的、能真正提升未来成功概率的结论和行动点，那么复盘就不能结束。
氛围不好，复盘就是追责，效果往往不好。
组织复盘的完整过程
1.回顾架构活动；
回顾过程指的是以时间顺序对事实进行多维度的客观描述，包括主要决策的环境、最终的决策，以及由此推演而来的规划。把之前的文档提炼即可，除了架构师视角的回顾外，还需要从非 技术的视角出发进行回顾。包括PM，业务、运营等，不能清一色地邀请研发人员，因为研发人员往往只会从技术视角出发来做深度探讨。。
2.过程控制和整体规划；
在引导与控制的过程中，你要帮助其他参与者梳理思考维度，而不是梳理分支。
a.整体流程：从目标设定到架构环境搭建，再到最终的交付，有什么可以改进或提升的地方
b决策质量：公司在大型决策中的质量怎么样？如何进一步提升决策质量？
c 架构规划：我们到底有没有真正意义上的架构规划？这个架构规划有无重大缺陷？取舍是否正确？架构规划对实施起到指导作用了吗？
d.执行和实施：实施过程是否忠于最初的目标？最终是否能交付预期的价值？
e.质量控制：核心模块的最终质量是否达到了预期？
f.组织维度：团队是否胜任？组织是否给力？协同是否高效？
g 文化维度：公司文化对架构活动的成功有帮助吗？还是阻碍了架构活动过程中的探索和求真？
并不是每个参加架构活动的人都能贡献出深度思考。因此在选择会议的参加者、准备回顾内容、控制每个话题的时长、话题之间的流转上，要体现出架构师的认知。
3.梳理机会点；
这个过程是个多轮的共创过程，引导每个参与者共同思考一个问题：我们到底有没有真正意.在某个维度或者某个组合维度上，我们错失的最大机会点是什么？从而多轮讨论寻找全局最优解。
4.挖掘根因；
这里我们要用故障复盘里的五个“为什么”的方法，也就是“Five Whys”，不断挖掘问题根源，突破问题的表面现象，最终找到一类问题的底层根源。
很多复盘都止于故障发现。也就是大家最常用的故障防控三板斧：加监控报警、加响应及时性考核、加灰度发布能力。报警太多会淹没，也会让人麻木。
5.寻找新的模式与机制；
一定要把个例中的发现转变成一种模式和企业的机制。我们很多时候都只是在缺乏思考中忙碌，默认当前的做法就是正确的做法，举例：单点问题在未来的架构，既可以做单点加固。也可以问业务方和产品设计者：为什么这个服务必须是一个同步的强依赖服务？
6 产出跟进项；
最终建议整个公司做出改变的事项，通常不超过3项。
从单个案例中推导出的结论，必然有一定的局限性，因此只有集中精力认真分析少数几个跟进项，才能有效提升这些跟进项的存活率。
项目结束，项目管理提到了资源释放。这里也是郭老师所倡导的，不要结束了还继续扣人。
关于创造价值
架构师最大的增值来自我们在整个架构活动中对决策的持续引导上。架构师不是团队大脑角色，我们都要建设并倚仗去中心化的决策过程，鼓励参与者来贡献尽可能多的想法。
在具体的实施过程中，我们需要做到三点：
1.确保软件架构的合理性视角不被忽略；
2.引导参与者在信条之下做理性讨论；
3.确保讨论的收敛，防止讨论变成脑暴。
王道与霸道
大厂的压力大，博弈明显，郭老师认为从价值创造的角度出发，王道就是公平、理性且公开透明的环境，以及尊重事实的行为方法。
“实践里面出真知”，信息过剩的时代，只看看没有实践下去，没太多效果。模块二都是操作建议。
