你好，我是郭东白。今天这节课，我们就正式开始架构师生存法则的学习。
你肯定看到过这样的观点：架构设计就是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。
然而我要强调的是，在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则：所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
架构活动为什么需要目标？
你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多，我来分享其中一个。
我们公司目前大多使用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试一试？不论是业务产品还是技术尝试，除了耗费大家的心力，还会给原有系统注入新的复杂性，导致整个系统的无序。因此我们需要做架构治理，剔除无序的元素，让系统重新回到结构化的状态。
这也是为什么我一再强调，架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。
思考题
在每节课的思考题环节，我都会留三道题。建议你任选其中一道作答，目的不是做得全，而是思考得深，让你自己有所得。
- 由于业务压力，我们经常会面临各种各样的重点项目。那么，你是怎么判断一个项目的重要性呢？怎么决定自己思考力的分配呢？注意，这里指的不是你被上级领导分配的写代码的时间，而是你发自内心觉得某件事情很重要，你主动花大量功夫去思考的过程。也就是说，你自主决策的个人注意力分配的算法是什么？
- 你或者你周围人是否曾建造过一个非常精巧的轮子，但是随着时间的推移，变成了诸多要被清理的破轮子？当时发明者有没有意识到这个轮子会增加系统的复杂性呢？为什么？
- 在你参与过的架构活动中，最让你感到兴奋的一个目标是什么呢？为什么？
欢迎你把自己的思考分享在留言区，我会和你交流。
精选留言
2021-12-07 13:56:04
2.有直接证据能佐证降本增效(如项目上线后带来多大的收益 or 降低成本)的项目，占30%注意力
3.董事长项目、集团项目、BU 项目、必保项目等新名目（上层领导的项目），占20%注意力
备注：这类项目很多可能只是拍脑袋决定，但没办法，打工人还是要生存的（特别是董事长项目，老板让你干，你能说不？）。有时也可能因为个人局限性，做前不一定能领悟到这类项目的作用，后面的结果可能证明这类项目收益很大。
4.技术或业务前瞻性的项目（紧急但不重要），占10%注意力。
总结来说，我一般都是按风险、创收和创新三个维度来区分注意力。风险：创收：创新 = 4 ： 5 ： 1
2021-12-07 13:23:09
我们面对业务诉求或系统bug经常要出一些解决方案。这些方案由于要快速达到业务效果，或则快速止损。往往都要快。但实际一个健全方案的落地，需要多部门评估多部门排期，需要长时间的拉齐和沟通。如果我们的目标是助力业务价值提高，那就会出一个短期方案临时支撑。但是人员是会变动的，一旦变动一些短期方案很可能就成长期方案了。因为只有当事人有全局视角，各参与方与后续接手人都不敢轻易做变动，也不愿意去做。有这个口子后，业务价值反而成了肆意用短期方案的理由，历史问题也成了常用借口，项目在狗皮膏药和万用借口的助力下自然越走越糟，成本和风险不多加大。对于短期方案，隐患成本相对既得利益滞后很久，套在个人的职业生涯上（23年），最优解不言而喻，没有其他因素干预这个场景，是公司制度或则sop的问题。
2021-12-14 12:57:18
大致顺序为 系统紧急修复->高优先级业务需求->收益高的技改项目->普通优先级需求->普通系统维护升级
其中，系统紧急修复，例如最近的log4j事件，是无条件全投入的
在无系统紧急修复的情况下，对于高优先级的业务需求，根据投入、收益和分配到的资源决定具体的注意力分配，优先分配给投入少收益大的项目，其次是 投入大收益大分配资源多的项目，这种项目一般为团队中比较重要的项目，这一点主要以公司的整体战略和发展为先
收益高的技改项目排在第二位，注意是收益较高的技改项目，一般公司都会要求在需求之外有额外的贡献，这种技改项目不仅锻炼技术能力，很可能也是你的晋升关键；
普通需求排第四位，这个是本职工作，不出差错即可
最后的是普通的系统维护升级，保证系统的99.999可用，一般都不需要花费太多的注意力，每周固定抽一段时间集中分析处理即可
2021-12-23 09:46:57
业务的项目是无穷的，研发的资源是有限的，首先要明确一点是不可能用有限的资源完成无限的需求，必须针对这些项目进行排序优先级，然后再根据优先级来投入资源。
在投入资源的时候，还需要明确行业的趋势及技术趋势，与我们当前的技术能力，这中间是有Gap，需要正面这两者之间的gap，在整个的业务过程中要不断提升技术框架，达到行业水平。
面对业务的项目，我们要从两个角度来完成，分别是现有研发技术框架完成、提升技术框架完成。这两个角度就需要去做平衡，使用60%的研发资源来完成项目，再使用30%的研发资源来提升技术框架，还有10%的研发资源用于团队的技术能力提升。
那如何去判断哪些项目是60%，哪些项目是30%呢？我主要通过两个维度来衡量，分别是【业务价值】和【技术价值】，通过这两个维度去画四象限，把所有的项目划到这四个象限中，对于业务价值低&技术价值低的项目使用外包或者公共服务的方式进行，对于业务价值高&技术价值低的项目使用当前60%的，对于业务价值低&技术价值高的项目使用10%的研发资源，对于业务价值高&技术价值高的项目使用30%的研发资源
第二个问题
轮子的问题需要注意两点，分别是与业务挂钩、固定的迭代周期。技术轮子开始的时候都很好，往后更多的是一个是一个膨胀的系统，无法管理。这个时候需要想办法让整个技术轮子处于可控状态，通过与业务挂钩，能够保证整个技术轮子的资源投入，不会因为员工离职等各种理由中断。二是需要固定的迭代周期，保持技术轮子的活力，控制复杂度，让整个技术轮子形成稳定循环。
第三个问题
通过技术帮助业务成长，这个会让我觉得非常有价值。
回答完这三个问题后，我自己还想到了黄金圈原则，通过why-how-what的方式来思考业务。我们在活动过程中，经常会使用what指导我们做什么，使用how指导我们怎么样做，但是很少去问why的问题，为什么做？或者通过不断的why可以让我们更明确我们的目标到底是什么。
2021-12-07 09:17:43
二：🈶️肯定有，复杂性变高可能来自：人员离职、缺少文档、缺少测试、补丁太多、不能重构、代码入侵太强
三：目前正在做的设计，最主要是目标是降低项目实施成本，包括新项目实施周期、部署维护、降低对团队人员能力要求。对企业而言，无论公司大小，无论是否融资，无论模式有多先进，生存和赢利是底层逻辑（骗融资除外）。以前没认识到这一点，认为技术是技术，和企业经营没啥关系，就没有大目标，为了技术而技术，所以各种技术追新、重复造轮子挖坑、把公司搞烂再换一家
2021-12-08 01:00:52
以组织的战略目标为重：任何时候，团队的目标都应该与组织的战略目标一致，架构师应重点思考这种项目。
以团队的整体利益为重：架构师在一定程度上代表了团队的整体利益，架构师应该优先思考对团队利益大的事件。
以边际收益高者为重：架构师应优秀思考投入产出比高的方案。
以弱者为重：要对团队中的精锐力量充分赋能，让他们自由发挥能力，而架构师往往只需要侧面辅助和知道事情的结果。而团队中偏弱的力量往往会成为瓶颈，对于较弱者需要适当倾斜思考力，还需要发动精锐力量来帮助弱势力量。
以难度大者为重：架构师应优先思考项目中难度很大的问题，对于普通问题可以直接交给研发团队去思考，。研发团队和架构师是一个战壕里的战友，架构师要对研发团队充分信任和授权，这样的队伍才更有力量。
2022-04-12 12:06:31
我在以往的经历过的团队中，设计并实现过许多精巧的“轮子”，也许我的“轮子”并不是很关键，有些“轮子”直到我离开公司，一直在转，并且几乎没有过二次维护。我分别介绍一下失败的“轮子”和一直运行的“轮子。
1）失败的“轮子”：
当时在游戏团队，为了提高玩家体验，要做一个兑换码系统，需要批量生成和核销，在接到任务的时候，只有一个需求：一个兑换码只能使用一次。当时我技术老大跟我说，虽说现在需求只有一个，但是未来，我们可能用到一个兑换码可以使用多次，或者一个兑换码可以被不同的人使用多次的情况，你要好好考虑一下哦！于是我就放飞了自我，研究出8种核销兑换码的类型，并且最后上线了。上线之后，就发生了2次bug，出于责任的压力，我直接把另外7中情况在代码中“屏蔽”了，只保留了满足需求中的情况，上线后就再也没有发现过bug。直到我离开团队，另外7种情况也没用到～～
2）一直转的轮子：
当时团队需要一个日志报警系统，需要给制定的公众号推送报警通知。于是我接下了这个活儿。封装了腾讯SDK、报警策略、调用接口。。。等等，分别单独封装的模块做测试，然后再做整体的“黑盒”测试，最后就上线了。之后只要是接到优化日志报警系统的需求的时候，先考虑：这个需求到底是不是报警系统该做的，如果不该做的，宁愿单独写一套服务，也坚决不往这个系统里放；如果需求是报警系统里的任务，比如增加“短信”报警，或者增加报警策略，就单独增加、或者修改相应的模块，并做好单独的模块测试，再上线。
这些轮子带来的思考：1）千万不要做过度设计，2）模块划分、测试驱动 是很好的开发策略，3）目标单一，非常非常重要！！
2022-04-12 12:05:54
思考问题一：
情况1：不该我考虑的不考虑！
这个情况很符合我现在的工作环境，4、5个的项目（不同的框架，甚至不同的语言），一起堆过来，有时真让人抓狂！！遇到这样的问题，我会先那些提出需求的产品经理讨论项目的重要程度（安排优先级）！如果项目经理直接都说自己的项目重要，那么就把所有的项目预计的花费时间列出来，然后找到他们的领导或者我的领导叫到一起讨论优先级的问题（在我这个开发的视角中，是看不到哪个项目重要的，所以这事儿不该我考虑）。不论找不着上级领导确认，最后都要把最后的计划排期做成excel文档，邮件统一发出来，让所有人知道。
情况2:该我考虑的必须考虑！
我对项目优先级的判断先把项目需求现做下面的分类：
1）哪个项目既能高效完成，又能带来收益
2）能高效完成，不会产生拖拉的后果，带来的收益并不是很大
3）带来的收益很大，但是占用长期的开发时间
4）既没有收益，又占用开发时间
我的选择是 1 > 2 > 3 > 4。事事难料，难免全篇一律，所以优先级选择还可能根据所处的环境做不同的选择，单基本上不会变。
2021-12-08 15:34:54
如果是业务项目，可以从需求的出发点来看，这个是从帮助用户完成任务的角度出发的吗？那通过福格行为模型来看：这个项目是否提升用户的行为动机,或者降低了用户的能力成本？
技术升级项目的话，当前的技术痛点是什么？升级交付后是否可以扛住较长一段时间的增长压力？新服务是否有一定的抽象性，可以比较容易的进行扩展。
如果项目我觉得很重要，我会从技术的先进性，抽象程度，扩展性,易用性来思考架构方案。现在看,这其实不太好，最关注的应该是目标达成度，以及后续的行动成本是多少。付出改造成本后,对公司和组织的价值回报应该怎么计算?至少应该值回人力成本。
2.今年就造了一个轮子,通过抽象服务来解决运营层面配置的问题,目测效果不太好.可能要被清理了吧.现在复盘一下,首先是和leader的目标没有对齐.我们对这个事的目标和理解是有偏差的。同时组织架构上的不合理导致了项目的不合理，那在环境不理想的情况下，这个系统没有好办法推下去，只能在一小部分场景使用，和我的预期偏差太大。这也确实消耗了不少我的热情。
3.搞完以后可以在公司内推广有可以量化的指标,因为有机会晋升,可以加薪。
2021-12-23 18:59:56
1. 涉及公司关键营收的项目，或者说是现在生死存亡的项目，分配50%的精力
2. 对于支撑公司日常运行的项目，分配10%精力
3. 涉及开拓新市场的创新类项目，对其中有盈利能力有增长空间的，或者说公司未来的项目，分配15%的精力
4.涉及开拓新市场的创新类项目，对其中有盈利可能的，或者说可能是公司未来的项目，分配10%的精力
5.对于一些政治类项目，用尽量短平快的方式达到目的，分配7%的精力突击弄完
6.对于一些没有盈利可能的半死不活项目，分配1%精力定期check一下
7.对于一些应该早些下线的项目，分配7%精力早日送走
2021-12-16 09:48:53
2021-12-07 22:50:46
* 📖：为什么有些架构活动会没有正确的目标？
* 🤔：看到标题，愣住了。没有目标的架构，没有正确目标的架构，有区别。自然堆积的架构，经架构设计的架构，有区别。没特别明白这问句式标题。
* 📖：架构规划，必须有且只有一个正确的目标，而且必须与公司的战略意图相匹配，这是架构设计的起点。
* 🤔：听起来很正确的样子，可到底正确在哪里？有个正确的目标，有且只有一个正确的目标，何谓正确，为何只且只能有一个？
* 📖：目标缺失的两大根因：
* 技术上：目标缺少全局视角
* 🤔：为何会喜欢讨论新技术？我也会关注新技术，当我一个人的时候，我不会提起它，当很多人一起闲聊的时候，容易提起它。关注新技术可能是好奇心，或者是职业习惯，聊新技术只是个话题素材。
* 🤔：谁能具有全局视角，谁该具有全局视角？这个角色似乎，更坚定说，必须是部门的负责人。也就是说部门负责人要以全局视角，来给架构设计指明正确的方向。而且此负责人不仅对部门管理负责，更要对部门技术负责。
* 业务上：目标太多、不明确
* 🤔：业务没搞清楚，请技术先来A/B，出结果再说。其实，会这么做，即使出了结果，也没有辨别能力。至少得有个假设，或者多个假设，通过试验来验证假设，才合理些。
2021-12-14 16:20:54
按以往的工作经历，项目的重要性可能就是按照领导的喜好，或者是即将到来的最后期限。如果让我来决定，那么可以按照重要且紧急、重要不紧急、紧急不重要、不重要不紧急的优先级来排列。
如果让我自己来选，可能也比较喜欢“极简”设计，但是从某种程度上来看，所谓“极简”或者是“敏捷”的设计，有时候也是在思考上懒惰的结果。
在我参与的架构活动中，我比较喜欢和用户接触，去了解需求的过程，因为这样才能真正解决问题。
2021-12-14 18:49:54
2021-12-21 17:14:26
1.带给业务的正向价值
2.研发人效提升大小
3.架构合理化演进
其中1优先级最高，2和3稍微靠后。也要case by case的看。
在业务成长期或者瓶颈期，业务基于突破，需求偏多，倾向于快速支撑业务需求，赋能业务增长。
平稳期，业务需求相对偏少，重心倾斜到架构合理化演进及人效提升上，以期稳定、高效的支撑业务未来1-2两年的发展。不同公司的文化氛围不同，有些公司研发话语权强一些，可以顶着业务压力做一些技术侧的升级。更多的中小型公司面临生存压力，业务话语权大于研发，研发做纯技术的架构升级相对困难，可以在支撑好业务的前提下，适度的做一些技术侧的改造。
2021-12-08 16:59:26
2021-12-07 22:57:46
* 📖：如何思考一个项目的重要性？
* 【1】：这是一次性的项目，还是做完可以复制的项目
* 【2】：项目解决的业务场景与需要的关键技术，是否有机会做出护城河，也就是越往前做，业务越依赖项目，项目越会促进技术
* 【3】：项目的难度和挑战，是否我期待发展的方向，能否触发我的投入热情
2022-04-13 18:41:46
要是以前，我会看这个项目是否能让我感兴趣或者勾起我的好奇心，有可能是业务比较有趣或者可以运用新技术。
学完这一课，虽然我不知道公司的战略是什么，但是我会从用户的角度来看，这个项目是否有价值或者意义，再去考虑自己的因素
2022-02-09 15:55:01
在分布式环境下，任何一次系统调用都会增加复杂度。所以我相信，发明轮子的团队一定深刻考虑过引入新项目所带来的复杂度问题。一个好的轮子，一定会有多个应用场景，在全局的角度看，如果这个轮子能收拢同类功能，让大家一键接入，降本提效，整体效率一定是最优的。
思考过往，总结下自己经历过的好轮子变成废轮子的情况：
1、公司经营环境发生变化，团队职能发生调整。
比如一个中台团队，是为了更好满足于公司各业务线的基础需求而建立的。当因监管或其他因素导致公司业务大量萎缩，中台反而成为累赘，中台人力需要转变为业务人力。那这一大坨中台系统，在业务的视角来看，就会成为过度包装的轮子项目。
2、全局规划与局部紧迫性的不匹配。
轮子项目服务与众多业务线，一个轮子想要变得更好，需要沉淀足够的经验后不断演进。当某个别业务线因为自身的特殊性，总是急需一些定制化的功能又不能被满足时，业务团队不得不另谋出路。要么是fork一个分支，要么是重新做一个。从长期来看，必然是重复建设，但在短期内，在业务团队的视角来看，新的轮子各方面都优于老的轮子。
3、KPI导向。
公司从上到下，都不喜欢一件事情写5年。今年从0-1开发了新东西，反响热烈，第二年从1-10，新增了许多特性。第三年就没有了，取而代之的是另一个关注点有点不同的“一站式解决方案”。为了让绩效更好看，貌似大家都爱这么做。
对于控制不了的原因，只能默默接收。对于kpi以及技术先进性等原因，需要与郭老师一样，紧盯目标，甄别伪需求。目标感是学了2篇文章以来感受最深的一点。
2021-12-15 06:10:04