如何成为老板不可或缺的人？
这些内容的所有课程到这里就全部更新完了，感谢你看完了我的 16 次架构经历。
此时，我想很多人还存在这么一个疑问：如何成为一个优秀的架构师？在这个问题上，我觉得应该分为两种情况：第一种是成为面霸型架构师，第二种是成为老板眼中不可或缺的人。
如果你想成为一个面霸型架构师，我认为你只需做到以下 2 点就行：
把我的 16 次架构经历读透，并深入理解背后能解决哪些场景问题；
将 16 次架构经历背后涉及的技术原理搞清楚。
我相信等你把这两点搞清楚后，在面试过程中一定能成功秒杀面试官。接下来，我们主要讨论一下如何成为一个老板眼中不可或缺的人。
这里我之所以将这两种情况分开来讲，是因为面霸型的架构师真不一定是老板眼中不可或缺的人，我先分享几段个人真实的经历你就能明白了。
经历一
在工作第三年的时候，我认识了一个老板，他当时开了一家国外外包公司。因为觉得我技术不错，所以他一直希望我能去他们公司就职，不过我没答应，只是提议可以当兼职顾问。
某天周六，这个老板打电话跟我说：“我们的系统出现了一个问题，做了某个操作后，整个页面冻结住了，怎么点都没有用，目前技术人员还没有头绪，但是客户一直在催，想请你帮忙看看什么问题。”
我打开系统看了一下，整个界面的确是无法点击、输入了。后来，我重现了好几次这个问题，发现整个界面没法点击时颜色好像有点不一样，是不是将一个透明浮层置顶了？
最终答案也出来了，的确是由于一个 bug 导致浮层没退出。那为什么他们的技术人员都没有头绪呢？因为他们都是后端开发，JS 经验比较少。看了我的个人经历，你应该猜得出来我也是偏后端。此时我可以跟老板说：“我是后端，所以这个问题不属于我的领域范围吗？”
对于老板而言，他们并不在乎我们的职责是什么？老板最在乎的是我们是不是可以帮他解决技术问题。
经历二
这个经历是我在外企碰到的一个问题，我们先看看下面这段对话。
有一天，公司 SVP 跑过来问我：“XXX，你有没有觉得我们的开发速度慢？是不是我们的技术不行？”
“你能跟我详细说说哪些地方开发速度慢吗？”
“产品的人跟我说，他们现在提的需求经常需要好几个月才能上线，有时候一个简单改文字的需求都是如此。”
关于这个问题，一时半会儿我也解释不清楚，因为一开始沟通就不在一个维度上。因为开发者认为的开发速度慢指从开始开发到最终上线的时间久，而领导们认为的开发速度慢指一个需求从提出来到最终上线的时间久。
在这里我想问一下：你觉得开发速度慢算一个技术问题吗？要我说可算也可不算。
针对上面这个问题，最终我们坐一起讨论了下，并列出了所有影响开发效率的因素，如下表所示：
注意：表中我们只是列举了部分问题进行说明。
针对这些影响因素，最终我们决定能通过技术解决的就通过技术解决。因此，有时领导提的问题并不是一个单纯的技术问题，我们需要将其转化为具体的技术解决方案。
此时，你可能想说：开发效率低这种事情不是应该找架构师吗？这个不是管理的问题吗？下面我们接着看一段经历。
经历三
曾经，我们有一个新的项目，它的需求影响面比较大，功能点比较多。在架构设计时，如果还是基于原来的系统将会出现一系列问题，因为原来的系统做了 4年了，架构时间相对比较久。
此时，一个架构师趁机提议道：“我们能不能趁着这次需求将架构进行更新。”
之后，这位架构师就着这个问题与另一位负责这个项目的技术总监进行了讨论，并提交了相应的提案，提案中陈述了新架构的代价和好处。代价是需要多花 3 周时间进行研发，好处是系统会更稳定、问题会更少、迭代速度会更快。
因为 CTO 是产品出身，听这位架构师的陈述后不明觉厉，于是爽快地同意了，接下来项目直接进入如火如荼的开发阶段。
当然，在实际业务中，任何一个项目都会出现各种各样的变数，比如业务方说这个需求之前没考虑清楚，还有一部分流程遗漏，我们必须先把它解决了，不然系统用不了。于是，业务人员临时变更了需求。再比如更新新架构时，有些系统需要进行迁移，而有些系统不需要迁移，但是在实际做的过程中我们发现，原来决定不迁移的一个系统由于数据库耦合的问题，此时也必须迁移了。再比如，一些同学对新架构不熟悉，需要多花点儿时间上手。
面对这些突发事件，项目就很容易延期。于是，出现了下面这段对话。
某一个会上，CTO 说：“咱们的架构师不行啊，这次系统上线后，如果性能不稳定，就把他开了。”
我们诧异地问道：“为什么？还有其他原因吗？”
CTO 说：“你看我们这个项目，本来 1 个半月就可以完成，加了新架构的迁移后变成了 2 个多月完成，现在都快拖成 3 个月了，这明显是架构师的问题啊。早知道是这样的话，我们还不如不迁移新架构呢。”
我们就帮他开脱：“这其实也不全是架构师的问题，不是还有一些需求变更吗？”
CTO 说：“我知道啊，那些需求我看了，改动并不大，不至于拖上 1-2 个月。”
我们都沉默了，心里面 OS：“当初讨论迁移新架构，你也是同意了啊。”
CTO 离开后，我们两个总监私底下商量：“一定要保住这个架构师，不能让他一个人背锅。”
后来，有一次与 CTO 吃饭，他跟我们解释道：“我的压力也很大，本来跟老板说好了多久就可以上线，结果拖了两个月。当时我也跟老板解释了架构迁移的事，老板本来是同意的，可是第二个月就把架构迁移的事忘到九霄云外了，因为他压根儿对软件研发没概念。”
在整件事情中架构师有错吗？好像没错啊。
事后，我们也回顾了一下整件事情，之所以是架构师背锅，关键原因在于我们对架构师的期望不一致，比如我们期望开发效率高还是系统稳定性好？抑或是复杂问题的突破？因此，在真正解决问题之前，我们必须搞清楚领导对我们的期望值。
这里，我把关于如何成为老板不可或缺的架构师的要点总结为以下三点：
别在乎个人职责和边界是什么？我们需要在乎是否能够帮助老板解决实际技术问题；
有时候领导谈的问题并不是单纯的一个技术问题，我们需要把领导的问题转化成技术可以解决的问题；
我们需要搞清楚同事和领导的期望值，也是最重要的一点。
以上就是我的三段个人经历，它们并不能作为所有公司的评判标准。因为一名优秀的架构师的定义可以从很多维度上进行阐述。
不过，我也不期待一篇文章就能让你懂得如何成为老板不可或缺的人，我只希望这篇文章能给你一点启发。如果你能从中感同身受，那将是我莫大的荣幸了。
最后，感谢你花时间看完了我所有的课程，希望它对你有帮助。如果你觉得此专栏有价值，欢迎转发给更多的朋友。
好了，我们的《软件架构场景实战 22讲》今天已经全部更新完了，为了不断提升课程服务质量，这里有一份课程改进的问卷，请你抽出几分钟的时间填写一下。同时，我们会根据内容反馈，挑选 5 名用户各赠送专栏 1 个。