我所相信软件架构师和技术领导者的成功三角

原文链接：What I believe is a triangle of success for Software Architects and Technical Leads

近年来，我一直在多家组织担任软件架构师，包括技术公司和高速增长的初创公司。既是个人贡献者又是架构团队的经理。我意识到有三个原则可以帮助我完成日常工作。我总是试图做出所有决定，尝试了解业务和成本影响，并花时间编码。还有一些令我惊讶的原则。它们是我个人成功的三角形（感谢 HBO 的名字灵感）。

如果您不相信需要架构师或技术主管，您可能需要先查看我的其他故事：软件架构师和自治团队。

让您的船员分享使命

我们很容易陷入这样一个陷阱：仅仅说服管理层做决定，或者作为架构师建立一个规则就足够了。现在，我们有独立的微服务团队，团队必须平衡相互冲突的优先级。抄近路很容易。如果你不能说服人们为什么某个决定是重要的，他们可能只是找不到足够的时间来遵循它。确保每个人都理解任务，并具有高度的动力。之后，通过实际贡献成为任务的一部分。

让贡献者参与决策

在将任何想法称为决定之前，将其呈现给直接在其上工作的人。首先，您会获得良好的反馈，然后您可以分享和理解该决策。在 @ebaytechberlin，我们发现架构决策记录作为一个 Pull Request 很好。您还应该采取其他措施。

首先在白板上讨论技术思路

我发现写得很好的提案很难改变。一旦任何人对某件事投入了巨大的努力，情感依恋就会起作用。在这种情况下，您可能会偏向于最初的建议。最好先把你的想法作为草稿，然后在白板上讨论其他人的想法。这样，就可以进行更多的讨论，并通过朝着正确的方向共同采取建议。仪器可能不需要白板，但需要拉请求。其想法是，最初的提议应该支持变更的灵活性。

确保记录缺点

我们都知道没有银弹。几乎任何技术决策都是一种权衡。通常，合乎逻辑的人不同意这些决定，因为他们不以同样的方式看待权衡。确保你解释了为什么某些优势超过了你当前项目的劣势。最好将权衡、结果和缺点包括到架构决策记录中，并记录为什么它们不如解决方案的优势重要。

向所有受影响的利益相关者展示决策

一旦做出决定，工作就不会结束。这只是旅程的开始。通过向其他利益相关者透彻地说明为什么团队会采取特定的技术方向，您就增加了以正确的方式平衡优先级以实现决策的机会。您还应该确保不仅工程师，产品经理和工程经理都了解技术远景。确保您的技术目标对非技术人员也具有有意义的名称和价值。“重构事件收集器” 是一个乏味的名称，任何产品经理都无法理解其中的价值。“删除不合理的事件跟踪代理以更快地添加对新事件的处理” 是一个冗长但已经有意义的名称。

理解现金流

每一个成功的工程组织都需要在财务上取得成功，才能继续其使命。这应该是技术负责人最关心的问题之一。

不同解决方案的成本是多少美元？

了解某些云或硬件服务的成本，以及您的组织平均工程小时成本。你自己学习这项技术的费用，将其与聘请一位经验丰富的顾问的费用相比有多大。良好的体系结构也是长期以最佳成本实现业务目标的体系结构。如果不把粗略的数字放在你的决定上，很难做出正确的决定。

参与产品要求的梳理

产品改进，是我作为架构师经常参加的唯一一次团队会议。作为一个技术远见者，你需要非常清楚地知道你未来的系统需要如何工作。当一个产品经理呈现出新的特性，并且捕捉到某些产品决策的细微差别时，我发现这非常有用。但请记住，如果你是一个架构师或其他类型的领导者，而不是团队的一部分，那么你应该更愿意在团队会议中倾听。这种出席的主要目的是学习业务需求。只有在必须做出重大决定，而且不朝着你认为最佳的方向发展时，才积极参与。

花点时间坐在客户席上

与运营部门或客户支持团队共度一周可能是个好主意。我不是说你应该停止工作一个星期，坐在电话旁接客户电话。但是，如果您不直接处理 UX 或前端，那么很容易对产品的使用和操作方式建立错误的假设。

了解指标

了解产品的另一个补充方法是从数据度量中学习。你的客户是谁，你有多少。人们在您的平台上使用最多的功能是什么？某个特性应该处理多少流量应该是数据驱动的决定。您可以从产品管理中获得许多想法，以了解这方面的最佳实践。

了解战略目标

了解企业的战略优先事项。没有人能预测未来，你不应该建造不需要的东西。但这有助于了解船的航行方向。你在市场上的竞争优势是什么？你需要保持哪些关键优势？这将让你知道在哪里投入更多的时间，以及什么对企业更重要。

从内部了解你的车

5 年前是 JavaScript 专家的人，今天不会自动成为专家。“我有几十年的经验” 不是当今技术领域的论据。事情确实改变了，你需要保持最新。此外，在实践中展示产品和代码库知识的人，在提出决策时会赢得更多的信任。

用编码保持平衡

关于你应该花多少实际操作这一点，没有一个理想的时间。这在很大程度上取决于你对项目的时间、你对产品的了解程度以及你对技术的了解程度。主要的想法是编码不再是技术负责人的主要职责。如果你编码太多，你就没有时间做你最重要的工作。

作为一名技术领导者，你可以通过正确的技术决策而不是通过你自己提供的代码来对组织产生更高的影响。

同时，您需要自己深入了解您的代码库和产品。您需要尽可能多地编写代码，以保持这些冲突的优先级之间的平衡。

找时间编码

作为一个技术领导者，你会发现你在会议上花费了太多时间，工作时间变得支离破碎，你不再能够集中足够的精力，代码贡献成为一个挑战。

小贴士 1：安排你的工作。根据经验，当我的时间窗口少于一小时时，我甚至不会尝试编码。尽管我试图将一个无需开会的日子完全用于实际工作，但在会议较少的日子里，我会查看请求、创建文档或与人交谈。

小贴士 2：在 “低” 架构季节做出更大贡献。每个项目开始时都有更多的设计决策。你将高度参与其中，并将有较少的实际操作机会。只要接受这一点，只要项目进展顺利，你就会有更多的时间做出更大和重要的贡献。

仔细选择编码任务

如果您不属于一个工程团队，那么如何准确地为生产代码作出贡献可能并不明显。

小贴士 1：作为一个有贡献的想法，在最具挑战性或最不愉快的工作中迈出第一步。你不应该只吃糖果。你得把你的手弄脏，以身作则。如果您正在努力进行痛苦的重构，那么您也应该是进行重构的人。

小贴士 2：您应该为生产代码做出贡献，而不仅仅是在原型上工作。只要来到团队说 “嗨，我能和你一起冲刺吗？” 就行了，但这不是一个最佳的主意。对于团队来说，可能会看到老大哥在看着他们。相反，最好找一个真正需要帮助的团队。这可能是一个有多个成员休假的团队，也可能只是一个新团队，他们还不知道当前的情况。

保持深度

恭喜你，现在你是技术负责人。你不会再整天编代码了，因为你有不同的职责。你至少应该在一些学科上保持深入。因为我不是一个软件工程师，而且不花一整天的时间编写代码，这已经快 5 年了。但我仍然可以向一些最有经验的同事暗示一些棘手的 Java 错误的解决方案。重要的是不要成为 “各行各业的杰克”，谁只有广泛的知识。我很难想象自己是一个优秀的架构师，如果不保持深入的技术性，他会提出最佳的解决方案。

作为技术负责人或架构师，有很多方法可以产生影响。不要害怕花时间学习你的产品、代码库和解释你的技术愿景。你需要做的最重要的工作是制定正确的决策并使它们具体化。实际上，99% 的工作只是通过学习和贡献来准备技术愿景。