下载APP
关闭
渠道合作
推荐作者
02｜法则一：为什么有些架构活动会没有正确的目标？
2021-12-07 郭东白
《郭东白的架构课》
课程介绍
讲述：郭东白
时长14:59大小13.72M
你好，我是郭东白。今天这节课，我们就正式开始架构师生存法则的学习。
你肯定看到过这样的观点：架构设计就是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。
然而我要强调的是，在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则：所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
架构活动为什么需要目标？
你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多，我来分享其中一个。
我们公司目前大多使用 Kafka 来做架构，但有一位架构师认为开源社区里正流行的 Pulsar 的设计理念与云原生趋势十分契合，值得在全公司推广。于是他经过多方调研，搭建了一套系统预研，并针对一些小场景做了测试。测试结果很让人满意，他便整理了一套 PPT 来找我做汇报。
他的 PPT 写得非常好，无论是 Pulsar 的设计亮点还是对我们公司的迁移场景，思考得都很全面，我从中也收获不少。但当我问他：“你这么做的目标是什么？”，他显然没有料到我会问这样一个问题，所以在沉默了一阵子之后才说：“技术先进性？”
事实上，在一个企业里，技术先进性很少会是一个架构活动的正确目标，所以很多人做架构升级都只是为了做而做。
从我过去二十多年的架构经验来看，一半以上的架构活动在发起之前都没有明确的目标。这种架构活动执行到最后，多个协同模块之间必然是一个散乱的结构，如下图所示。
如果在初期就有一个明确的目标，那么做到最后，子模块和初期目标就会是大致对齐的，同时也会最大化对目标的贡献。
目标缺失是由多种原因造成的，刚才我们讲的情形只是其中一种表现。接下来，我就来讲讲目标缺失具体有哪些根因。下节课，再来提供你作为一个架构师的具体应对思路。
目标缺失的两大根因
关于目标缺失的根因，我们可以从技术和业务两个维度来寻找。
技术上：目标缺少全局视角
由于技术原因导致的目标缺失往往有个非常积极正面的出发点：那就是技术同学对于先进技术的强烈好奇心。
很多同学会经常在社区内互相讨论新技术新趋势。当好奇心转变成行动，也就意味着我们已经从一个深受技术理念影响的评价者转变成了追随者。正是这种内在的驱动力，在推动着公司、行业乃至整个社会的技术发展。
探索新技术是一种积极正面的力量，我非常鼓励团队中的同学这么去做。
不过就像我前面提到的案例，从探索新技术变成漫无目的的架构尝试，中间缺失的就是全局思维：架构师没有从全局视角去思考架构活动的回报，以及它对企业整体复杂性的影响。
技术尝试跟业务和产品尝试一样，每一次尝试都是在耗费企业的机会成本。如果是一个正处于创新期和成长期的企业，那么每次尝试还会耗费相关同学的心力。心力是一个极其有限且宝贵的资源，一旦尝试失败，耗尽心力的同学很有可能会选择离开，加剧整个企业心力的损失。
除此之外，每次尝试都会给原有系统注入新的复杂性，从而导致整个系统的复杂和无序，这就是墒增的过程。
看到这儿你可能要问我了，如果我新起一个项目，是不是就可以引入新技术了呢？一个公司当然要引入新技术，不过还是那句话，关键在于要有一个明确的目标，而不是以一种漫无目的、浅尝辄止的态度去做技术尝试。
我曾在一个不到 700 人的研发团队里，看到过 8 个自动化 BI 报表工具、5 套 UI 组件、十多套工作流引擎。对于日常运维、软件升级、安全、合规和审计而言，这简直就是灾难。我相信在这些技术设计之初，从开发同学的视角来看，或多或少都有一些技术先进性的理由。但同时我也可以断定，引入这些技术时很少有人思考过全局复杂性。这就导致整个企业的软件从一个同构的系统迅速衰变成一个混乱无章的大杂烩。
值得注意的是，在这些令人吃惊的数字后面，其实还有一个不太光彩的原因，那就是开发者的个人利益。举个极端的例子，这个团队曾经有个做大数据的负责人，匆忙引入了开源领域的一个新框架，并在会议上作了个演讲。但是讲完之后没多久就提了离职，留下个做了一半的烂尾项目。
也就是说，开发者的个人喜好、技术能力，甚至与其他开发者的关系，也会影响到自己是否会引入一个新系统。
在技术层面上，还有另外一个常见的原因，就是信息沟通不畅。因为层级低的技术同学很少做跨团队跨部门沟通，一些小范围的架构改造也找不到一个官方版本可以借用，而且从头开始的时候，总觉得别人的设计太复杂，有过度设计的嫌疑，所以都是自己去新写一个版本。而一旦业务逐渐增长，小工具长成了大工具，就变成了一个新的变种。
这里我给你分享一个案例。当年微软内部有不少人骂微软的浏览器内核性能差，说某某开源方案很好使。团队后来就请这些持反对声音的人一起去做一个内部项目，请他们在开源的基础上做起，但是要求必须支持所有的测试场景，包括向后兼容的部分。
开始的时候，开源的版本性能是好，但是等杂七杂八的需求全部堆积上去之后，性能反而变差了，没过多久项目就叫停了。
这个案例告诉我们，一方面，做业务和做产品的同学要有正确的取舍，不能见什么功能就要什么功能。
另一方面，我们做技术的同学也不要动不动就认为别人的东西过度设计了，认为我的场景简单，就应该定制自己的技术。往往你的场景简单，仅仅是因为你的业务还没做起来。等业务做大之后，会发现业务根本不是你想象得那么简单。我见到过太多所谓的“极简设计”了, 事实证明，大多数的极简设计，要么早早夭折，要么越做越复杂。到头来还是得用专业版设计进行替换。
总结来说，从技术维度去思考目标缺失的根因，就在于缺少全局视角，主要有三方面的表现：技术同学对于先进技术的强烈好奇心，开发者的个人利益，以及信息沟通不畅。
业务上：目标太多、不明确
比技术原因更常见的是业务原因，主要表现在：目标太多、目标不明确或者是目标摇摆不定。
比如业务 leader 有一个极具创意的方案，但业务压力大，市场调研的准确度也很难判断，所以多数时间需要靠 A/B 测试来决定这个方案是否要推广。可以看到，业务同学连需求之间的一致性和相容性都没搞清楚，就把需求一个接一个地转给技术同学。在这种大量 A/B 测试的背景下，业务逻辑层层累积，系统变得越来越臃肿，老代码谁都不敢删。
还有一种情形在大公司里比较常见。有的 CEO 喜欢高举高打，上任之后先大搞运动。我曾经见过一个 CEO，他在一个季度里同时启动 10 个项目，目标五花八门。几乎是把整个部门分成了十个子公司，让他们各自为战。在巨大的交付压力之下，团队根本来不及做统一规划，每个项目各自为战，整个季度几乎全员 997。
结果呢？3 个月后项目完工，业务仍然在原地踏步，CEO 挑出个别数据指标上有亮点的项目做了个表彰大会，就万事大吉了。运动虽然失败了。但漫无目的的、随机大撒 CEO 项目的玩法，却被完美保留下来发扬光大，然后演变成董事长项目、集团项目、BU 项目、必保项目等新名目。
这种混乱对技术架构伤害很大，不过倒也不致命，是有技术解的，下节课中我会专门来讲。只是这种行为对团队技术文化的伤害非常大，一般来说，那些追求极客精神和科学决策的同学，往往非常反感这种随机探索的管理方式，所以大都会选择离开。
还有一种情形不太常见，但却极端致命，值得我们重视。那就是一个公司有两个明确的目标，这有点像华山派的剑宗和气宗之争。
举个例子，在一个做电商的公司中，剑宗会认为做业务要像自营一样对整个供应链做强管控，这样会有更好的用户体验，以获取更多的市场份额；气宗则认为道法自然，做业务就要走开放的平台模式，最大化平台的丰富度，由用户选择来淘汰落后的商家。
两派自然是互不服气。如果剑宗上位，公司就大兴剑宗玩法，一切设计都走供应链路线。如果剑宗连续折戟，那么气宗上位，之前的一切设计都推倒重来，全走平台模式。当然，任何时候气宗里都会有喜欢练剑法的，剑宗里面也有运气自如的。但公司内部不论是练气还是练剑，目标从来都不统一，那么在商业竞争中，结果只能是比剑输剑，比气输气。
事实上这种情形根本没有技术解。如果一个公司在战略上不断摇摆，就表明这家公司干脆没有战略意图，那么我更建议你另谋高就。
至此，我们已经把目标缺失的两大根因介绍完了。那么我们该如何应对呢？这正是我们下节课要讨论的内容。
小结
这节课我们讲了架构师的第一条生存法则，那就是每个架构规划启动之前，都应该有且仅有一个正确的目标。而你作为一个架构师，必须要搞清楚架构设计的目标到底是什么。只有找到了这个问题的答案，才能在多个方案中作出正确的取舍。
不幸的是，我们多数的研发需求和架构规划在发起前都没有明确的目标，最常见的就是竞争对手这么做了，要不我们也照搬一下做个 A/B 试一试？不论是业务产品还是技术尝试，除了耗费大家的心力，还会给原有系统注入新的复杂性，导致整个系统的无序。因此我们需要做架构治理，剔除无序的元素，让系统重新回到结构化的状态。
这也是为什么我一再强调，架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。
思考题
在每节课的思考题环节，我都会留三道题。建议你任选其中一道作答，目的不是做得全，而是思考得深，让你自己有所得。
由于业务压力，我们经常会面临各种各样的重点项目。那么，你是怎么判断一个项目的重要性呢？怎么决定自己思考力的分配呢？注意，这里指的不是你被上级领导分配的写代码的时间，而是你发自内心觉得某件事情很重要，你主动花大量功夫去思考的过程。也就是说，你自主决策的个人注意力分配的算法是什么？
你或者你周围人是否曾建造过一个非常精巧的轮子，但是随着时间的推移，变成了诸多要被清理的破轮子？当时发明者有没有意识到这个轮子会增加系统的复杂性呢？为什么？
在你参与过的架构活动中，最让你感到兴奋的一个目标是什么呢？为什么？
欢迎你把自己的思考分享在留言区，我会和你交流。
分享给需要的人，Ta订阅后你可得20元现金奖励
生成海报并分享赞 8
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01｜模块导学：是什么在影响架构活动的成败？
精选留言(26)
- 猿人谷2021-12-071.项目是用来规避系统风险的（按风险等级，逐步提高注意力），技术人保证系统的安全、稳定和高可用是第一要务，这类项目占40%注意力
2.有直接证据能佐证降本增效(如项目上线后带来多大的收益 or 降低成本)的项目，占30%注意力
3.董事长项目、集团项目、BU 项目、必保项目等新名目（上层领导的项目），占20%注意力
备注：这类项目很多可能只是拍脑袋决定，但没办法，打工人还是要生存的（特别是董事长项目，老板让你干，你能说不？）。有时也可能因为个人局限性，做前不一定能领悟到这类项目的作用，后面的结果可能证明这类项目收益很大。
4.技术或业务前瞻性的项目（紧急但不重要），占10%注意力。
总结来说，我一般都是按风险、创收和创新三个维度来区分注意力。风险：创收：创新 = 4 ： 5 ： 1展开7 - 陈吉米2021-12-07一：我觉得分配算法最主要的变量是项目重要程度和紧急程度，我的压力往往来自紧急但不重要的事情，而和战略目标一致的大致上是不紧急且重要的事情，分配过程中后者无论如何都不能被“暂停”，且要想办法变成重要且紧急的事情。
二：🈶️肯定有，复杂性变高可能来自：人员离职、缺少文档、缺少测试、补丁太多、不能重构、代码入侵太强
三：目前正在做的设计，最主要是目标是降低项目实施成本，包括新项目实施周期、部署维护、降低对团队人员能力要求。对企业而言，无论公司大小，无论是否融资，无论模式有多先进，生存和赢利是底层逻辑（骗融资除外）。以前没认识到这一点，认为技术是技术，和企业经营没啥关系，就没有大目标，为了技术而技术，所以各种技术追新、重复造轮子挖坑、把公司搞烂再换一家展开共 1 条评论5 
甘轲2021-12-081. 一个项目可以从几个方面来看,这是技改项目还是业务项目,项目的目标是增长性质还是补漏性质？
如果是业务项目，可以从需求的出发点来看，这个是从帮助用户完成任务的角度出发的吗？那通过福格行为模型来看：这个项目是否提升用户的行为动机,或者降低了用户的能力成本？
技术升级项目的话，当前的技术痛点是什么？升级交付后是否可以扛住较长一段时间的增长压力？新服务是否有一定的抽象性，可以比较容易的进行扩展。
如果项目我觉得很重要，我会从技术的先进性，抽象程度，扩展性,易用性来思考架构方案。现在看,这其实不太好，最关注的应该是目标达成度，以及后续的行动成本是多少。付出改造成本后,对公司和组织的价值回报应该怎么计算?至少应该值回人力成本。
2.今年就造了一个轮子,通过抽象服务来解决运营层面配置的问题,目测效果不太好.可能要被清理了吧.现在复盘一下,首先是和leader的目标没有对齐.我们对这个事的目标和理解是有偏差的。同时组织架构上的不合理导致了项目的不合理，那在环境不理想的情况下，这个系统没有好办法推下去，只能在一小部分场景使用，和我的预期偏差太大。这也确实消耗了不少我的热情。
3.搞完以后可以在公司内推广有可以量化的指标,因为有机会晋升,可以加薪。展开共 1 条评论2
vivieast2021-12-08问题1：
按照项目在公司的重要程度来分配。重点项目获得的资源更多，参与其中的收获更多，投入的精力会多一些。2- InfoQ_5bac5e222cf92021-12-08架构师要如何分配注意力？我觉得要分成五个角度：
以组织的战略目标为重：任何时候，团队的目标都应该与组织的战略目标一致，架构师应重点思考这种项目。
以团队的整体利益为重：架构师在一定程度上代表了团队的整体利益，架构师应该优先思考对团队利益大的事件。
以边际收益高者为重：架构师应优秀思考投入产出比高的方案。
以弱者为重：要对团队中的精锐力量充分赋能，让他们自由发挥能力，而架构师往往只需要侧面辅助和知道事情的结果。而团队中偏弱的力量往往会成为瓶颈，对于较弱者需要适当倾斜思考力，还需要发动精锐力量来帮助弱势力量。
以难度大者为重：架构师应优先思考项目中难度很大的问题，对于普通问题可以直接交给研发团队去思考，。研发团队和架构师是一个战壕里的战友，架构师要对研发团队充分信任和授权，这样的队伍才更有力量。展开共 1 条评论2 
术子米德
2021-12-07🤔☕️🤔☕️🤔
* 📖：如何思考一个项目的重要性？
* 【1】：这是一次性的项目，还是做完可以复制的项目
* 【2】：项目解决的业务场景与需要的关键技术，是否有机会做出护城河，也就是越往前做，业务越依赖项目，项目越会促进技术
* 【3】：项目的难度和挑战，是否我期待发展的方向，能否触发我的投入热情展开共 1 条评论2- 术子米德2021-12-07🤔☕️🤔☕️🤔
* 📖：为什么有些架构活动会没有正确的目标？
* 🤔：看到标题，愣住了。没有目标的架构，没有正确目标的架构，有区别。自然堆积的架构，经架构设计的架构，有区别。没特别明白这问句式标题。
* 📖：架构规划，必须有且只有一个正确的目标，而且必须与公司的战略意图相匹配，这是架构设计的起点。
* 🤔：听起来很正确的样子，可到底正确在哪里？有个正确的目标，有且只有一个正确的目标，何谓正确，为何只且只能有一个？
* 📖：目标缺失的两大根因：
* 技术上：目标缺少全局视角
* 🤔：为何会喜欢讨论新技术？我也会关注新技术，当我一个人的时候，我不会提起它，当很多人一起闲聊的时候，容易提起它。关注新技术可能是好奇心，或者是职业习惯，聊新技术只是个话题素材。
* 🤔：谁能具有全局视角，谁该具有全局视角？这个角色似乎，更坚定说，必须是部门的负责人。也就是说部门负责人要以全局视角，来给架构设计指明正确的方向。而且此负责人不仅对部门管理负责，更要对部门技术负责。
* 业务上：目标太多、不明确
* 🤔：业务没搞清楚，请技术先来A/B，出结果再说。其实，会这么做，即使出了结果，也没有辨别能力。至少得有个假设，或者多个假设，通过试验来验证假设，才合理些。展开共 1 条评论2 
Jxin2021-12-07结合今天的课程。有个问题请教下。该不该上短期方案，或则该怎么上短期方案？
我们面对业务诉求或系统bug经常要出一些解决方案。这些方案由于要快速达到业务效果，或则快速止损。往往都要快。但实际一个健全方案的落地，需要多部门评估多部门排期，需要长时间的拉齐和沟通。如果我们的目标是助力业务价值提高，那就会出一个短期方案临时支撑。但是人员是会变动的，一旦变动一些短期方案很可能就成长期方案了。因为只有当事人有全局视角，各参与方与后续接手人都不敢轻易做变动，也不愿意去做。有这个口子后，业务价值反而成了肆意用短期方案的理由，历史问题也成了常用借口，项目在狗皮膏药和万用借口的助力下自然越走越糟，成本和风险不多加大。对于短期方案，隐患成本相对既得利益滞后很久，套在个人的职业生涯上（23年），最优解不言而喻，没有其他因素干预这个场景，是公司制度或则sop的问题。展开共 3 条评论3
李2021-12-07如何判断项目重要性： 是否有商业价值，是否与公司战略方向一致。 有些项目，可能能带来短期价值，但是与整体目标不一致，这种反而是一种消耗。
思考力分配： 1.根据公司现阶段状况，如何发力。 比如小公司，就会想着如何提升效率，如何快速推动0-1探索。
如果是1-100的公司，就会思考如何提升规模化，如何确保安全、稳定。
如果是100+公司，会想如何保持持续稳定增长、安全，并会想如何继续探索新产品，用技术帮助业务开拓新领域。
坚持做正确的事。我的思考力，都是想着如何做正确的事，如何高效做事。
可惜我年轻时不懂，跟错了老板，跟错了公司。一个毫无战略，毫无战略定力，只顾眼前利益的公司。不懂尊重技术，不懂尊重人性的老板。本应该3年前就离开，可惜家里一系列变故，只能继续呆这里。
或许这都是在磨炼我，我相信未来一定有一个地方等着我。现在思考的事，解决公司任务的同时，如何努力的提升自己，准备好自己，并等待机会到来。展开共 3 条评论2
GAC·DU2021-12-07一类，能够自助造血项目，有正向的市场反馈，持续迭代，分配50%思考力。
二类，需要长期孵化项目，前景可观，分配20%思考力。
三类，外市场分析项目，拓展周边，分配20%。
四类，花边项目，专为投资人打造，分配10%思考力。展开共 3 条评论2
咏晨桃2021-12-08半年内从一个创业部门下的团队B（商户后台）转到了C（导购和交易）和；C团队有明确的OKR，有明确的业务指标，所以精力都在做项目上；由于部门预算被砍，商户后台B几乎没有需求了，开始做架构升级； 然后，因为平时有工作交集，所以B组TL会经常吐槽为啥后台哪哪哪不好用，到现在还没改；现在看来是没有站在全局视角看，影响团队生死存亡的到底是什么，是运营用户体验还是C端下单转化率？现在预算砍半，有一半的人需要转岗，我属于被转岗的，B组几乎全留下来了，3个TL也只留了B组TL；难道明年H1还是以架构升级为主？展开共 1 条评论1
JianXu2021-12-08郭老师，你文中Pulsar 的那个案例，提到针对小场景做了测试效果满意，你能具体说说是什么小场景，怎么定义满意吗？
接着说到迁移场景，你是指从当前技术栈迁移到Pulsar吗？展开共 2 条评论1
超大杯冰美式2021-12-08问题一：
首先考虑问题本身带给自己的价值是多少，既我有什么好处，个人技术能力提升，或者项目奖，升职加薪等，这类心理潜意识不断去思考它。占据大部分思考力，其次根据自身能力进行判断，比如A和B两件事举例，A事情做好可以带来很好的业务收益和个人成长，但是有挑战，未知领域问题或者一大堆复杂难题待解决，耗时长，一时半会解决不了的，以自己的能力不一定能做好，最多说是尝试做好，B事情就是业务紧急度高，但是没什么技术含量，打份工就是一定要做和处理的事，我会优先处理B事情，留下时间，慢慢思考A类事情，哪怕做不好起码是发掘问题点再解决方案上思考了很久了
最后感谢作者举例的场景，和思考方向，和我身处环境极为相似，受益匪浅！展开共 2 条评论1
9F2021-12-07听讲太累，还是看文本比较快，不过开车路上可以听展开共 1 条评论1- 咖啡咖语2021-12-07如何分配注意力？ 在努力践行ROI衡量标准，roi越高理论上投入的注意力越高； 只是在实际操作中，也会有断断续续的取舍，毕竟不是每件事都可以直观量化roi的共 1 条评论1
BIZ_UI_32021-12-07做架构越久，越来越发现决定架构形态的非技术因素占很大比重。现在一般都从ROI（投入产出比）的角度出发来看待项目。假设一个项目迭代短期的成本是50，未来可预期的收益是100；而另一个项目短期成本是10，但收益也只有10，我会选择前者。展开共 1 条评论1- Helios2021-12-07你是怎么判断一个项目的重要性呢？
我是根据老板的紧急程度判断项目的重要性的。
怎么决定自己思考力的分配呢？
我现在更倾向于执行者，主要集中大部分的一小块上。我的思考力分为两部分：全局视角和现有问题。全局视角能让我看到更多的问题（可能会用很简单的想法节省很多资源）和机会（对事情有了解一是让别人放心，二是做自己喜欢的事情能主动向上push），现有问题能够让我去学习看书解决工作上的问题，如果能解决会给自己带来很大的快感，当然自己有时候的过度设计也会对别人造成困扰。
我感觉我有一点做的很不好，我是一个容易焦虑的人，如果事情不着急或者不是重点项目，我就会懒惰下来，去学自己的事情（可能暂时和工作没啥大联系），因为看不到大方向大目标。而且还会焦虑这样做对不对（应不应该这么懒惰、被同事觉得不饱和、应该从工作中学习等等）。展开1 
Johar2021-12-071.我之前做的是B业务，所以判断一个项目的重要标准就是项目价值，一方面是就是实实在在的项目金额，决定了当下的业绩;另外一个方面是新业务试点项目，决定了未来方向。
2.重复造轮子的原因:1.公司内部消息不顺畅;2.公司各个部门有业绩考核，存在内部竞争;3.个人价值体现而重新造轮子。展开共 1 条评论1
禾急2021-12-07第一个学完，收获满满展开共 1 条评论1
Pytrick
2021-12-07微软的那个浏览器 是Edge吗， edge就是在chromium基础上做的？共 1 条评论1
