优先考虑买别人的而不是自己开发，除非自己开发能为你的企业带来真正的可持续的优势
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：软件蚕食一切。但是有些组织喜欢什么都自己开发。也许这么做有很好的理由，但不这么做也有很好的理由。耐克首席工程师JakeRottersman认为，除非自己开发的东西能够为企业带来真正可持续的优势，否则的话，能买的就不要自己做，因为这样能减少运营负担，让开发保持敏捷，让企业降低成本。原文发表在其个人博客上，标题是：BuyDon'tBuild:AvoidingOpsForFunandProfit
划重点：
服务的运营并非易事
自己开发也会遇到供应商锁定问题
工程师的时间是很宝贵的，要注意机会成本
要避免因此失去重点
工程师普遍都想管理个服务或开发定制服务。不过这往往是重大错误，最终会花费你大量的时间和金钱。要做一切的定制版的愿望似乎来自以下几个方面：
指望自己开发要比买便宜。
认为自己的公司很特殊，所以行业标准之类会不起作用。
认为自己需要对服务所做的事情有完全的控制。
避免被供应商锁定
但其实所有这四点都不像你想像的那么正确，那么重要。如果一个东西是你们业务的核心，或者能带来重大的竞争优势时，就自行开发是值得的。否则的话，也许用云提供商提供的服务或其他的saas更划算。跑自己的东西会带来巨大的运营负担以及产生巨大的机会成本。如果说从本文你只能吸取一条经验教训的话，那就是：自己开发当然有趣，但凌晨两点因为系统的一个小题大作的设计出问题而被叫醒可就没那么有趣了。
服务运营并不容易让系统保持正常生产需要时间和精力。开发反倒不是最耗资源的部分。相反，运行和维护复杂系统才是。大多数企业系统都需要工程团队来维持运行。而聘用工程师并不便宜，而且为了让大量团队协调一致，还引入了额外的复杂性。所有这些都会导致决策速度变慢。
因为需要更多的团队来维护更多的服务，所以决策速度开始变慢。然后，这些团队需要一起协作和协调。突然之间，要想进行更改，你有一百万个团队需要通知和管理交接。因为现在团队更多了，组织结构更复杂了，所以可能会导致经理之间的明争暗斗，带来更多的公司政治。
如果你遵循的是DevOps模式的话，那么开发服务的团队最终也要负责维护。团队需要维护的活动件越多，留给开发新功能的时间就越少。这很令人痛苦，尤其是对于产品正在迅速发展的年轻公司来说。用延长找到产品市场匹配的时间来换取自己动手实现东西，这可不是一个好交易。
你还得考虑所在组织的运营管理水平。说实话，如果是Amazon和你相比，你会更信任谁的正常运行水平?对于那些是你自己的身家性命所在的服务来说，你可能更相信自己。但这样的话其他的系统你就未必能够腾出更多的时间和精力去管理了，因为维持其运行所需要付出的代价的合理性变得更加难以证明了。
供应商锁定关于这个问题，你可能会想：“我可不想被供应商的特殊系统卡脖子”。我对此持反对观点，因为内部系统也存在锁定问题。这个问题最常见的版本是电子表格管理者(TheKeeperofTheSpreadsheet)。如果你要问“什么样的电子表格?”好吧，你问得合情合理。但某些重要的内部流程的电子表格已经变成了电子表格管理者的工作。大多数的大公司至少都有一个这样的电子表格。如果你在大公司工作的话，你大概会意识到这个数量已经是轻描淡写——可能还有很多。
那份电子表格的管理者会捍卫自己的流程，不希望对它进行更改，并愿为此不惜一切代价，因为他们会担心，一旦这个流程被自动化或者不再需要之后，自己就会被解雇。工程团队也会有这种情况，那些数据库或工单系统的管理者。突然之间，你得到了一个糟糕透顶的系统，但没有人愿意为干掉它而发声，因为他们的同事坚信，一旦系统被干掉，自己也会被干掉。而那些对此不敏感的人试着去修复相关流程时，往往会被设置政治陷阱。
成为工单系统的管理者往往也不是那么的有趣。如果你想沉迷无聊的工作，这倒是好方法。这还意味着你最终得到的是一个对企业来说不是最重要的系统，但却不让外部公司来接手这件事。本来那家外部公司的专长就是解决这个问题的，并因此形成了更加深厚的专业知识。当然，除非你内心有点邪恶，就是想找点糟糕的项目恶心一下被放逐的人。
所有这些都使得供应商锁定这个问题的严重性比大多数人想象的要低。不管你做什么都有被锁定的可能。你需要避免的是给任何供应商提供批发定价权。通过确保企业的关键差异化因素保留在内部，就可以避免这种情况。
工程时间是很宝贵的聘请软件和系统工程师并不便宜。作为整体，我们往往会低估自己的时间。你就想想看吧，是不是经常听到“哦，这个我一星期就可以开发出来”或者“这个很容易嘛”的说法。幸运的是，这只是Reddit或Hacknews上面的评论，但是如果在工作中听到的话，这往往会变成一句空洞的口号。
我们一般会用总拥有成本(TCO)
