耐克首席工程师：敏捷开发，能外包的就别自己做

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：软件蚕食一切。但是有些组织喜欢什么都自己开发。也许这么做有很好的理由，但不这么做也有很好的理由。耐克首席工程师Jake Rottersman认为，除非自己开发的东西能够为企业带来真正可持续的优势，否则的话，能买的就不要自己做，因为这样能减少运营负担，让开发保持敏捷，让企业降低成本。原文发表在其个人博客上，标题是：Buy Don't Build: Avoiding Ops For Fun and Profit

划重点：

服务的运营并非易事

自己开发也会遇到供应商锁定问题

工程师的时间是很宝贵的，要注意机会成本

要避免因此失去重点

工程师普遍都想管理个服务或开发定制服务。不过这往往是重大错误，最终会花费你大量的时间和金钱。要做一切的定制版的愿望似乎来自以下几个方面：

1. 指望自己开发要比买便宜。

2. 认为自己的公司很特殊，所以行业标准之类会不起作用。

3. 认为自己需要对服务所做的事情有完全的控制。

4. 避免被供应商锁定

但其实所有这四点都不像你想像的那么正确，那么重要。如果一个东西是你们业务的核心，或者能带来重大的竞争优势时，就自行开发是值得的。否则的话，也许用云提供商提供的服务或其他的saas更划算 。跑自己的东西会带来巨大的运营负担以及产生巨大的机会成本。如果说从本文你只能吸取一条经验教训的话，那就是：自己开发当然有趣，但凌晨两点因为系统的一个小题大作的设计出问题而被叫醒可就没那么有趣了。

服务运营并不容易

让系统保持正常生产需要时间和精力。开发反倒不是最耗资源的部分。相反，运行和维护复杂系统才是。大多数企业系统都需要工程团队来维持运行。而聘用工程师并不便宜，而且为了让大量团队协调一致，还引入了额外的复杂性。所有这些都会导致决策速度变慢。

因为需要更多的团队来维护更多的服务，所以决策速度开始变慢。然后，这些团队需要一起协作和协调。突然之间，要想进行更改，你有一百万个团队需要通知和管理交接。因为现在团队更多了，组织结构更复杂了，所以可能会导致经理之间的明争暗斗，带来更多的公司政治。

如果你遵循的是DevOps模式的话，那么开发服务的团队最终也要负责维护。团队需要维护的活动件越多，留给开发新功能的时间就越少。这很令人痛苦，尤其是对于产品正在迅速发展的年轻公司来说。用延长找到产品市场匹配的时间来换取自己动手实现东西，这可不是一个好交易。

你还得考虑所在组织的运营管理水平。说实话，如果是Amazon和你相比，你会更信任谁的正常运行水平？对于那些是你自己的身家性命所在的服务来说，你可能更相信自己。但这样的话其他的系统你就未必能够腾出更多的时间和精力去管理了，因为维持其运行所需要付出的代价的合理性变得更加难以证明了。

供应商锁定

关于这个问题，你可能会想：“我可不想被供应商的特殊系统卡脖子”。我对此持反对观点，因为内部系统也存在锁定问题。这个问题最常见的版本是电子表格管理者（The Keeper of The Spreadsheet）。如果你要问“什么样的电子表格？”好吧，你问得合情合理。但某些重要的内部流程的电子表格已经变成了电子表格管理者的工作。大多数的大公司至少都有一个这样的电子表格。如果你在大公司工作的话，你大概会意识到这个数量已经是轻描淡写——可能还有很多。

那份电子表格的管理者会捍卫自己的流程，不希望对它进行更改，并愿为此不惜一切代价，因为他们会担心，一旦这个流程被自动化或者不再需要之后，自己就会被解雇。工程团队也会有这种情况，那些数据库或工单系统的管理者。突然之间，你得到了一个糟糕透顶的系统，但没有人愿意为干掉它而发声，因为他们的同事坚信，一旦系统被干掉，自己也会被干掉。而那些对此不敏感的人试着去修复相关流程时，往往会被设置政治陷阱。

成为工单系统的管理者往往也不是那么的有趣。如果你想沉迷无聊的工作，这倒是好方法。这还意味着你最终得到的是一个对企业来说不是最重要的系统，但却不让外部公司来接手这件事。本来那家外部公司的专长就是解决这个问题的，并因此形成了更加深厚的专业知识。当然，除非你内心有点邪恶，就是想找点糟糕的项目恶心一下被放逐的人。

所有这些都使得供应商锁定这个问题的严重性比大多数人想象的要低。不管你做什么都有被锁定的可能。你需要避免的是给任何供应商提供批发定价权。通过确保企业的关键差异化因素保留在内部，就可以避免这种情况。

工程时间是很宝贵的

聘请软件和系统工程师并不便宜。作为整体，我们往往会低估自己的时间。你就想想看吧，是不是经常听到“哦，这个我一星期就可以开发出来”或者“这个很容易嘛”的说法。幸运的是，这只是Reddit或Hacknews上面的评论，但是如果在工作中听到的话，这往往会变成一句空洞的口号。

我们一般会用总拥有成本（TCO）来表示拥有或维护服务的成本。因为计入TCO的很多东西都没有跟踪，所以TCO往往是很难真正计算出来的。你会遇到的主要问题是，这不仅是工程师的成本。我们关心的指标是工程师本来可以开发其他产品而导致的机会成本。

定制开发的另一个理由是因为公司的独特流程。一般的想法是没法通过自定义来让软件如愿工作，或者自定义的成本还不如自己开发。虽说这些都是自行开发的合理理由，但发生这种情况的概率其实比你想像的要小。很多企业都有着一样的流程。而且，随着时间的流逝，流程会逐渐变得臃肿。跟业务流程相匹配所需的大量定制工作根本没法完成。这里我不妨举一个很荒谬的例子，就发生在跟我合作的一家公司里面：1.我们的文章推荐过程很复杂，需要对大量模糊数据进行联接。2.我们可以开发自己的数据库系统来专门处理这个问题。3.几个月的紧张开发时间过去了。4.事实证明，这个工具很难用，我们既不知道为什么有的查询会导致系统崩溃，又不知道为什么我们的客户会对推荐表示抱怨。

你肯定不希望这种情况出现在自己身上。开发和维护一个甚至都不能正确工作的东西实在是令人沮丧。如果事情变得太过复杂以至于现有工具没法解决时，你应该停下来问一下所有这些复杂性对所在领域是不是真的很重要，或者自己采用的模型是否存在缺陷。

失去重点

跑您自己的服务版本还会带来一个重要问题，那就是工程师又多了一个需要关注的东西。重要的东西是有数量限制的。所以所有那些非核心的服务往往就会被疏忽关照，只能维持勉强能用的状态。

随之而来的问题是，折腾这些服务的所有人往往都想摆脱这个烂摊子。毕竟，没人愿意去做老板不关心的事情。所以，到头来团队的人事调动很频繁，这反过来又会导致拖延。

还有一点会导致这个问题雪上加霜，那就是不产生收入的东西经常会被忽视。是，你那CI / CD（持续集成/交付）系统绝对是很关键，但高管可不会那么想。这会导致陷入故障模式，慢慢地你就会有一堆被遗忘的内部工具。而只要你付钱让某人去干同一件事，那就变成了他们的生意，对方就会不断努力做好这件事。

机会成本

从很多方面来说，开发服务最大的问题在于机会成本。不是因为要付工资，而是说本来可以做其他的事。这基本上跟公司为了搞定一笔单子开发一次性功能属于同一个问题。最大的区别在于是工程是为了自己而做的，因此可能会对因此造成的损害视而不见。

工程师喜欢开发东西，很多人喜欢自己可以控制所有的按钮和旋钮那种感觉。在很多时候，这是件好事。毕竟，任何超级酷的东西其实就是这么开发的。当你有这种冲动，但对所做出的决策的业务效果不敏感时，就会出现问题。

你应该要问的问题是，除了调整自己的东西或者开发新的内部系统以外，你还可以做什么？答案往往是要投入更多的时间来想出正确的架构，或者开发真正面向客户的功能，而不是到处当灭火队员。

运营占据太多的位置往往会导致速度下降，每个工程师能做出的变更更少。不妨想想大公司和初创企业之间的速度差异。这不是因为初创企业招到了更聪明的人，而在于跟大公司的任何变更相关的那一大堆东西。

在这方面，工程不能光考虑要开发的软件。相反，你还得考虑整个产品的健康状况。这关乎的是开发对客户有用的东西，把非关键的放弃。高度聚焦在核心项目的东西上，这样开发才会更快。而且这样一来产品的维护工作也会变少。

总结

上述能买的就别自己开发的理由也许都不适合你的情况。自行开发有很多很好的理由。但是，如果你从来没有考虑过是不是可以靠买回来解决问题，而不是自己解决问题的话，那你应该考虑一下。

考虑一下凌晨2点被人叫醒是否值得。就算你不怕被叫醒，也得考虑一下是不是别人做这项维护工作做得比你好。你对自己的业务和产品细节的了解比我深。不过，提出这个问题还是值得的，不要置之不理。

我建议你优先考虑买别人的而不是自己开发，除非自己开发能为你的企业带来真正的可持续的优势。减少长期的运营负担，是让开发人员保持速度维持幸福感，并逐渐降低组织成本最简单的办法之一。

译者：boxi。