又一个交付故事：技术决策的迷局

发布时间：2025-11-04 00:06:38 来源：云智核 作者：IT科技类资讯

上一个故事是交付技术决策局关于自治团队解放生产力的，除了生产力之外，故事交付的交付技术决策局另一个关键因素是软件架构，架构是故事在软件开发过程中并不那么容易改变的东西。然而与过去时代所不同的交付技术决策局是，今天的故事软件架构并不是所谓的架构师高高在上做出的一些决策后就不再改变了，在这个技术快速变化的交付技术决策局时代，今天的故事架构更像是在时间线上一系列的轻量技术决策积累的一个结果。

而这个故事，交付技术决策局就是故事关于技术决策的。

明线：所有权?交付技术决策局经营权?决策权?监督权?

与A记不同的是，我们的故事客户C记并没有自己的云服务器提供商IT团队，也没有一个明显的交付技术决策局IT部门。与C记的故事合作时间就更长了，这么长久的交付技术决策局合作过程，却是从一段“黑历史”开始的。

在2009年到2010年的时候，C记项目上一个技术决策的过程基本上是这个样子的：客户说，“我们只能用SQL Server”。我们听到这个消息之后，一方面在心里暗想，“为啥要选SQL Server，为啥喜欢微软”，另一方面，我们发现，客户并没有提究竟用什么 ORM 框架，于是便“我们自己搞一个吧”。接下来发生的事情是，我们自己搞出来了一个NoSQL的文档数据库嫁接在SQL Server之上。从这个项目上线的***天起，b2b供应网就开始被打脸：性能问题，维护成本，数据迁移的难度，我们花了非常大的代价，才让这套东西基本上能够工作。

在那段时间里，这并不是唯一一个“鲁莽的“技术决策，而这一切到底是如何发生的?实际上，存储框架的决策比起采用什么样的数据库来说，要重要的多，然而这样重要的决策却没有被拿到桌面上正儿八经的和客户一起讨论。我们并不是糟糕的工程师，然而我们却把自己的才智与精力放在了错误的地方。

没有业务的引导，技术决策就更“技术导向”而不是“业务导向”。

我不得不给客户写一封邮件来解释为什么我们要花很大的高防服务器代价，从一个 homemade 的存储框架，切换到更加成熟的方案，而我直到现在依然可以很清楚的记得当时的尴尬。

客户当然非常不高兴，***的回复是，“至少我们开始讨论这些事情了”。于是这正是我们开始做的，我们开始在作出重要技术决策的时候邀请客户参与。设置一个技术治理小组，每个月对技术方向进行讨论，用技术债雷达来可视化和积极的应对技术债，这些都是在客户的参与下发生的。

一方面，这是为了把更多的信息透明给客户，然而更为关键的另一方面是，为了作出慎重的技术决策，我们需要知道客户所面临的约束，我们需要能够从中验证自己的假设，从而更好的尊重这些约束。

Tech Lead 的倾向从追逐”正确“的决策，变成了开始作出”合适“的技术决策。

于是事情开始向好的方向发展，从2011到2014年期间，homemade 的存储框架的搭桥手术成功，能够让我们逐渐迁移到成熟的方案;我们开始构建了更多的产品，微服务的技术架构也逐渐成型;随着新系统的上线和老系统的退休，整个平台迁移到了RackSpace上，加上自动化部署流水线，发布变得越来越频繁。

Happy ending?可惜并不是，2014年，客户方的技术负责人被调动到了另一个部门，另一个人接手了他的工作。与前任不同的是，他对于技术决策的参与度非常高。甚至有时候会为团队做决策，然后让团队承担决策的后果。

这导致了另一个问题，当团队所得到的只是一个决策结果，没有一个重新思考和衡量约束的过程，团队无法在不断变化的技术环境中持续的验证以前的假设。一方面，我们丧失了很多采纳新技术的机会，更重要的是，团队需要能够自己做出决策，承受自己决策的后果，并从中自己的决策中学习和成长。

于是我们建议客户能够更多的分享上下文，而不是做决策，决策由团队来出，但是客户保留否决的权力。如果客户不认可决策，在分享了原因之后，团队可以更好的提出别的方案。

去年C记的团队成功交付了一个新的产品，替换掉了好几个花了三年多时间开发的老产品。由于大多数的功能都已经服务化，所以新产品的开发只花了半年多时间就上线了。用客户的话说，我们“able to leap tall buildings in a single bound”。这是正确的技术决策压过了错误技术决策之后的结果。

聆听、理解和尊重客户约束，在技术决策上谨慎的前行，同时，随着技术的发展不断去反思和检查这些约束假设是否依然成立，从而持续的保持技术架构演进的方向与业务能力的对齐。

这是C记的故事的明线。

暗线：寻找时间之矢

有意思的是，如果倒过来读C记的故事，会发现如果加以打磨，依然可是一个好故事：刚开始的时候，客户强控制技术决策，我们很suffer，然后，慢慢信任，逐渐放弃控制，***，我们赢得了客户的信任，开始独立做决策，happy ending。虽然并不真实，然而却是一个更好的故事。

这就如同物理学定律中，时间是对称的一样，决策机制在这个故事中，也是时间对称的，那么决策机制就并不是进化的关键因素。然而在物理学中，熵增却是时间之矢的指向，那么这里的时间之矢到底是什么?

从郭晓的演讲中，我找到了想要的答案。

就如同交易成本的不断降低，打破了壁垒，促进了无数的人投身创业一样，技术成本的不断降低，技术壁垒的不断降低，也会带来更大范围的结构性变化。

比如说自动化测试技术干掉了传统的测试部门，数据库的自动化技术干掉了DBA，部署、运营的自动化干掉了运营，云化、安全内嵌也许将要干掉采购和安全。当这些东西，因为技术的进步而标准化后，当全面的数字化平台in place之后，那么剩下的就仅仅是业务解决方案、技术栈与实现代码了，在这个画面里，不写代码的传统IT部门的麻瓜们是掺和不进来的，于是把决策权交给开发团队是一个自然而然的选择……

于是随着开发团队的权力越来越大，意味着更大的责任，在这种新形势下进行技术决策保障也需要转变思路。建立共同愿景，让团队找到自己为了什么来工作的理由，找到自己的 purpose，把自己与日俱增的 power 用到合适的地方，这才是作为技术***应该做的工作。

那么我们C记的故事的暗线也就浮出了水面，故事中所建立起的决策机制本质上是在营造安全感，我们的传统企业客户多多少少都有类似的决策机制(所谓的架构组)，说白了是用增强控制来应对新形势下的心态失控。

然而，能控制得了的东西却越来越少，技术之矢使控制本身越来越没有价值，反而成了阻碍和包袱。在IT部门灭亡之前，也许就如同我们与C记故事的后半段一样，在事情变好之前，会先变坏，但熵增的车轮，是不会停下的。

也正是这种反抗之力如此顽强，每每当传统企业想要甩掉包袱往前快跑的时候，重重的阻碍却并不来自于领导层。透过传统企业繁冗的流程和层级，背后是一个个“企业架构师”、“系统架构师”，一个个在这样一种新的形势下即将“被干掉”从而失去自己职业发展的人。

那么，你现在的职位是什么呢……

【本文是专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】

戳这里，看该作者更多好文

相关文章