34 模块小结：架构师如何在架构活动中持续创造价值？
你好，我是郭东白。
这是我们第二个模块的最后一节课，我会先来展示整个架构活动的大图，然后总结一下模块中的核心知识点。
这个模块的内容非常多，所以通过这节课的总结与回顾，希望你能对整个架构活动建立起宏观的认识。同时，也可以再温习一下相对陌生的内容。此外，评论区的内容也很丰富，是不错的学习材料，可以为你提供不同的思考视角。
架构活动总览
首先看一下架构活动这张大图，它覆盖了整个模块的所有知识点：
图中描述了架构活动的四个核心角色，分别是决策者、赞助者、执行者和架构师。架构师的作用贯穿架构活动的整个过程，是架构活动的设计者、规划者和执行保障者。我用底部的绿色条，来表示架构师在架构活动中持续创造的价值。即：通过持续发掘和评估重大风险，来控制整体的交付风险；通过分析和解决差异点，促进尽可能多的参与者达成共识；通过不断分解问题，保障增量价值的交付；通过持续的文档沉淀，从而驱动科学的决策。
一般来说，架构活动有八个大节点，依次是环境搭建、目标确认、可行性探索、规划确认、项目启动、阶段交付、项目上线和总结复盘。我在图中用浅蓝色来表示。其中项目上线是个比较常规的重大节点，不过在我们的方法中，对于架构师来说并不是重点内容，所以就一笔带过了，没有单独拿出来讲解。
这些节点不一定要出现在我们主持的架构活动中。比如环境搭建，如果你所在的公司很小，或者你在同一拨人中主持过多次架构活动，就没必要重复搭建类似的架构环境了。
如图所示，这些节点基本上是按顺序进行的。但我们也经常遇到需要循环往复不断调整节点顺序的情况，尤其是目标确认和可行性探索这两个节点，可能需要反复迭代才能完成。
当然，从宏观层面看，架构活动又是连续不断的。一个架构活动结束之后，你和其他参与者又将进入到下一个架构活动中，从流程搭建重新开始。
不过更现实的情况是，任何时候，部分参与者会同时参加多个架构活动。这涉及多个架构活动互相干扰的情况，就共享资源而言，是一个多方博弈的过程。
到这里，你对架构活动应该建立起宏观的认识了。接下来，我就总结一下我们近二十节课中覆盖的重点思想。
一个大环境
架构活动是在一个大的架构环境之下进行的，也就是我们在节点一里搭建的架构环境，所以这张图还可以有另一种表现形式。节点一产生了能覆盖其余六个节点的大环境，也意味着节点一与其余六个节点形成了父子关系。
不过我们这张图主要是为了示范从架构师的视角看架构活动都有哪些行动点，所以这七个节点在图中就表现成了并列关系。
在图中，我用黑色直角线条连接了节点一与其他六个节点，来表示这种父子关系。整个大的架构环境，需要有一个所有参与者共同认可的决策信条和冲突解决机制，以及能保障活动成功的激励机制和工作环境。
我们在一些节点中反复提及这些信条和机制，比如重大风险梳理的过程、任务边界划分的过程等。这种基于理性思考、尊重事实的决策方式，是我们为整个架构活动建设的最重要的保障机制。
两个目标确认点
图中有两个圆环形图标代表了“目标确认点”，就是完成架构活动目标确认和验证的时间点。一个是在目标确认环节，一个是在项目上线环节。
我们在模块一的法则一就提到了，保障唯一且正确的目标是架构师的生存之根本，所以目标确认和可行性探索这两个节点（即节点二、三）就是在保障目标的正确性、合理性和可达性。经过反复确认后，一直到阶段性价值交付（即节点六），我们将始终以这个目标为决策和行动的指引，从而作出正确的判断。到了项目上线之后， 我们依然要以这个目标为标准来验收整个项目的产出。
当项目没有达到预期目标时，很多人非常担心被老板追问为什么目标没达成，然后试图逃避验收环节。但事实上，这个验收环节可以帮助你发现具体的问题点。而这些问题点，就是我们启动复盘环节的前置条件。那么复盘环节，最终就是要找到具体决策和流程中的缺陷，从而修复问题，避免同类问题的发生。
三个放弃点
图中还有两个深红色的三角图标，代表执行放弃的动作。每个放弃的动作都有三个入口，也就是三个放弃点：
- 入口一是风险决策的时候，指的是发现无法控制的重大风险。
- 入口二是架构规划确认的时候，指的是发现架构规划无法满足预期目标。
- 入口三是规划正式确认的时候，指的是发现执行计划存在重大风险，无法满足预期目标。
我们在前面的课程中已经多次强调了，放弃得越早，风险越小，成本也越低。放弃得越晚，团队承担的心理压力越大，对团队的士气打击也越大。
需要注意的是，随着我们架构师判断力的逐渐提升，发现重大风险和及早止血就变成我们的核心能力了。
四个主要角色
图中有四个主要角色，分别是决策者、赞助者、架构师和执行者。也就是标记在图中的四个人。
其实架构活动中还有很多重要的角色，比如项目经理。同时，需求侧的角色也对项目成败有着重要影响，比如产品经理、产品业务运营等。此外，在有多个复杂汇报关系长期参与的情况下，HR也是一个非常重要的角色。
这里需要注意的是视角的不同。我们整个模块是从架构师的视角出发，来描述我们在架构活动中的关键动作和行为。如果换个视角，比如把架构师换成决策者，那么他的关注点、行动点和思考方式又有所不同。
另外我想强调一下架构师与这些角色之间的互动。如图所示，在目标确认和可行性探索的过程中，我们主要跟决策者和赞助者互动，目的是辅助他们作出正确的决策，为架构活动设定正确、合理和可达的目标。
在规划确认、项目启动和阶段交付的过程中，架构活动的核心转移到了执行者，那么我们和执行者之间的大量互动，目的就是保障架构规划的完整性、合理性和结构性，控制执行风险，并持续关注执行过程中的核心增值点。可以说，在架构活动后期，执行者是主要角色。那么架构师的作用就是为执行者注入全局视角，提升决策质量。
多条反馈链路
这张图里还绘制了一些反馈链路，比如蓝色线条，始于节点六（阶段性价值交付），终于决策者，代表在阶段交付的过程中，架构师必须向决策者反馈交付进度和重大风险之类的信息。
这里要强调的是，架构活动成功的关键，就是为整个架构活动设置多个反馈链路，确保自上而下和自下而上的反馈链路都是通畅的。有了这些反馈链路，我们才能掌握架构活动的真实进展，在出现问题时能及时干预，避免问题失控。
全程持续地增值
最后我想特别强调一下“架构师是如何创造增值的”这个问题。有些人误以为增值就是撸起袖子加油干，也有些人误以为增值来自深度参与，还有些人认为增值来自明智的决策。这些想法的确有一定的道理，不过根据我的观察，这些都不是架构师最核心的增值。架构师最大的增值来自我们在整个架构活动中对决策的持续引导上。
自始至终，架构师都不是团队大脑的角色。无论是宏观节点上，还是节点内的重要步骤上，比如说任务分割，我们都要建设并倚仗去中心化的决策过程，鼓励参与者来贡献尽可能多的想法。
从这个角度看，架构师的重要性可能不是很高。但是事实上，对高质量决策的识别和引导能力，会让我们变得不可或缺。正是这种去中心化的决策过程，使得我们主导的架构活动比其他人主导的架构活动有着更高的成功概率。
在具体的实施过程中，我们需要做到三点：
- 确保软件架构的合理性视角不被忽略；
- 引导参与者在信条之下做理性讨论；
- 确保讨论的收敛，防止讨论变成脑暴。
这些内容，我们在课程里都有示范。最后我再强调一下粉红色的度假标识。个别公司存在一种非常病态的文化，把持续加班与员工价值贡献画等号。事实上二者完全不等价。从我个人的加班体会来看，在持续9117加班的过程中，我的总产出是低于996，甚至是995的。
在互联网几乎全体舍命狂奔的状态下，高强度的工作是个必然。我也见到过不少同事生重病的例子。在一个持续高强度的工作周期之后，必须要学会调整自己的心理和身体健康。我的经验是，没有充足的体力，思考质量也不会有多高。
关于王道和霸道
我们刚才提到了多个架构活动之间形成博弈的情形，关于这些内容的讨论深度，将会远远超过我们这门课程的范围。所以我仅就之前提到的王道和霸道的行为方式，来简单阐释一下。王道和霸道也是一个博弈的立场。
我们很难定义一个普遍的王道，不过一家公司内部的王道，我认为还是可以被定义的。从价值创造的角度出发，王道就是公平、理性且公开透明的环境，以及尊重事实的行为方式。具体而言，包括如下三个判断条件：
- 架构活动的资源分配以预期的价值创造为准。
- 架构活动的激励以实际可度量的用户和商业价值创造为准，不能偏离架构活动时设定的预期。
- 架构活动中的主要决策要尽量公开透明。
一般来说，王道就是顺应自然和民意的行为。在商业环境中，我理解的“顺应自然”就是尊重市场规律，以真实的价值创造来分配资源和激励。而“顺应民意”，则体现在真实的用户指标上的贡献值上，也就是大家常说的用脚投票的部分。
总的来说，架构师会面临很多挑战，应付这些挑战，有一些更符合长期的市场发展规律的办法，也更有利于提升企业长期的效率。比如用户体验提升和技术创新，我将这类解决办法称为王道。不过也有一些办法，通过相对简单粗暴的手段能达到短期目标，比如推广营销和强制997等，我称之为霸道。
有兴趣的话，你可以上网查一下关于王道和霸道的解释，这些内容会激发非常有趣的思考。我相信学习这些知识，会对你的架构师职业产生很多启发。
这里需要注意的是，如果是在一家行王道的环境里工作，行王道就相对容易一些。如果是在一家行霸道的环境里工作，行王道就相对难一些。你可能会问我，我的环境到底是行王道还是霸道啊？官方回答肯定是行王道。这个时候你只有听其言观其行，靠管理层的真实行为来判断了。如果说你观察到企业的行为不满足我前面提到的三个判断条件，那你就是在行霸道的环境工作。
但是无论是在哪种环境下工作，我都建议你尽量行王道。行王道的做法，会提升你作为一个架构师的普遍适用的能力。即使离开了这家企业，之后还可以继续创造价值。但是行霸道的做法就像是混黑社会，只能在同一条街上混，没办法搬家。
小结
我们这节课讲了架构活动的整体宏观视图，以及我们在其中的核心价值。我看到模块二里有不少同学说：“我要是早早读到这些文章就好了，可以避免一些错误。”从我自己的经验来看，还真不是这样。在我的认知里有这么一句朴素的话：“实践里面出真知”。
什么是真知呢？我认为就是那种你坚信且知道在什么时候去如何利用的知识。换句话说，没有实践过的理论，都不是真知。
我在开篇词就提到过。我们处在一个信息泛滥的年代，接收太多的理论了。如果你非常好学，今年你可能已经学了10门课了。但是如果不实践，那么知识不会对你的命运产生任何改变。
如果实践了，比如像一些同学，在学习这门课程之前就已经实践了。那么恭喜你，那些你深有同感、如获至宝的建议，就能成为你认同、并且能够利用的真知了。
模块二都是关于架构活动中的实操建议。因此，请你实践！
思考题
这节课只有一个作业：模块二至此就结束了。你觉得这个模块还缺少什么内容吗？你有什么好的改进建议吗？
欢迎把你的思考和想法分享在留言区，我们下节课再见！
- 术子米德 👍（4） 💬（1）
🤔☕️🤔☕️🤔 * 📖：行王道 vs 行霸道 * 🤔：王道，首先服我，至少是观念上认可我，然后听我。霸道，首先是怕我，无论心理和生理都先颤抖，然后听我。虽然当下都听我，差别在于我不在场的时候，或者我离开项目后，因服而听的行动力，跟因怕而听的行动力，向左和向右般天壤之别。 * 🤔：想咨询一下老师，在实际的架构中的目标，来自“遇到问题”居多，还是来自“方向选择”居多？ * 我看书上有所谓“Problem-focused”和“Solution-focused”的架构差别，前者所谓遇到问题，所以得靠架构去解决，后者所谓已有方案，找方向去开拓落地。 * 因此想听老师分享一下，自己实际的架构活动，目标是也有上述类型的差别？如果有的话，那这两种目标的架构活动，是否有差别？ * 🤔：想咨询一下老师，架构是否典型存在技术架构、业务架构、组织架构的差别？如果有的话，那你总结的架构活动图里，哪些方面跟技术架构关系强，哪些方面跟其它关系强，能否标注区分一下？尤其在目标确认、可行性探索、规划确认等过程里，是否存在架构领域性的不同比重？譬如规划确认，是否就跟组织架构强相关，可行性探索就跟业务架构强相关？
2022-05-22 - 罗均 👍（2） 💬（1）
在软件技术领域，如此清晰明确地总结出“王道之法”，东白老师或是第一人。古人称孔子“天不生仲尼，万古如长夜”！东白老师的课程，亦如很多工程师迷途中的明灯，为我们指引前行。 关于老师的架构活动总结，应该是无可挑剔的，看着老师的总架构活动图，一个想法冒出脑中，最后一个复盘环节，相当于一次阶段性战略胜利的总结，对应朱元璋攻下金陵后采纳的九字战略： 缓称王：氛围搭建 广积粮：机会点梳理 高筑墙：整理并提交专利？ 在【极客时间】里的一门关于如何写专利的新课里，其年轻的老师做了个非常有趣的比喻：每一项专利相当于一块砖，大批量的专利组合就是构建技术壁垒的长城。 由此学生联想到，复盘阶段，需要类似架构师的角色，同时具备产品、开发与运营的视角，将很多他们觉得“很简单”的“不会是专利”的方案，逐步包装成一个个专利，实现“高筑墙”。
2022-05-10 - spark 👍（1） 💬（1）
郭老师，take away~~~首先不跑题是关键。用批判性思维，拆解思考。a.结论和论题匹配，不跑题;b.反思信念和立场对思考的影响;c.反思情绪和欲望对思考的影响；d.反思格局和见识对思考的影响~~~ 从格局和见识维度，理解创作价值的架构活动。a.如果一个人只写过100万行CURD项目的代码，设计不了2000万代码产品的架构；b.如果技术积累小于4000小时，不可能成功，因为其他公司是积累1万小时的架构师在Lead；c.提出问题比解决问题更重要，思维方式不对，成功不了；d.算法和设计模式不通，成功不了，细节也是魔鬼；e.信息论、控制论、系统论、数学不及格，成功不了，因为基于数据和逻辑决策，需要博士才行~~~ GROW模型，Goal界定目标、Reality反映真相、Option改善心态、Will计划行动。认知到，沟通和达成共识之间的距离，就像追求“玛丽莲.梦露”一样，别人吐口水都看不起~~~
2022-05-10 - Andy 👍（0） 💬（1）
我就很喜欢有图片，这样理解起来简直轻松太多了，我一直认为，能够画图的人，才是真正的高手，不会画图，就意味着没有真正理解，郭老师的实力太强了，也感谢老师能够花时间和精力分享，让我能够真正感受到了，目前能够看到的顶级的CTO，水平是到什么程度
2023-04-27 - 微野 👍（0） 💬（2）
老师的架构活动图是用什么工具画的啊
2022-05-14 - Steven 👍（1） 💬（0）
实践里面出真知，没有实践空谈理论无意义。 同样的，有了一定的实践才能理解理论。
2022-05-14 - Geek_336706 👍（0） 💬（0）
“图中有两个圆环形图标代表了“目标确认点”，就是完成架构活动目标确认和验证的时间点。一个是在目标确认环节，一个是在项目上线环节。”这个圆环好像没看到图里在哪里？
2025-02-17 - Geek_798202 👍（0） 💬（0）
这个流程我是认同的，但是如果在一家行霸道的环境，如何解决人与人之前的冲突问题呢？比如我认为是对的，但是推行不下去，或者我认为是错误的，结果在强制推行
2024-05-22 - Noah 👍（0） 💬（0）
架构师和其他研发团队的配合模式上， 有什么好的建议吗？
2023-06-06 - 小昭 👍（0） 💬（0）
这个模块内容真的好多，不是架构师且没有类似经验，有些内容听着就云里雾里。 准备换工作了，会努力找一个行王道的公司，然后再慢慢努力实践老师讲的内容
2023-05-23 - blue blue blue🍬 👍（0） 💬（0）
项目经理听得津津有味
2022-09-17 - 杜秀清 👍（0） 💬（0）
架构师与PM合二为一，合体了
2022-05-18