软件蚕食一切，但是有些组织喜欢什么都自己开发。也许这么做有很好的理由，但不这么做也有很好的理由。

耐克首席工程师Jake Rottersman认为，除非自己开发的东西能够为企业带来真正可持续的优势，否则的话，能买的就不要自己做，因为这样能减少运营负担，让开发保持敏捷，让企业降低成本。

工程师普遍都想管理个产品或开发定制产品。不过这往往可能是重大错误，并且会花费你大量的时间和金钱。那些一切的都想定制的愿望可能都来自以下几个方面：

• 指望自己开发要比买便宜。
• 认为自己的公司很特殊，所以行业标准之类会不起作用。
• 认为自己需要对产品所能满足的事情有完全的控制。
• 避免被供应商锁定

但其实所有这四点都不像你想像的那么正确，那么重要。如果一个东西是你们业务的核心，或者能带来重大的竞争优势时，自行开发是值得的。否则的话，也许用云提供商提供的服务或其他的Saas更划算 。因为自己开发运营通常都会带来巨大的运营负担以及产生巨大的机会成本。

产品的维护运营并不容易

开发反倒不是最耗资源的部分，相反，运营和维护系统才是。我们可以从身边大多数企业找到这样的案例，无论系统复杂或简单都需要产研团队来维持运行，而招聘一名工程师并不便宜。

或许可能这种内部系统的开发运营人员多是兼职，但同样需要耗费不少资源，并且这样开发维护的结果是：系统的可用性和稳定性是极差的，相信这样的内部系统大家都曾有体验。

并且，为了让大量团队协调一致，还引入了额外的复杂性。比如，你想要想对产品提一些改进的需求，就需要与更多的团队进行沟通、管理、交接。自研所带来的，往往会让这些变得更复杂，甚至可能会导致经理之间的明争暗斗，带来更多的公司政治。所有这些都会导致团队的决策速度变慢。

如果你遵循的是DevOps模式，那么开发产品的团队最终也要负责对产品进行维护。团队需要维护的活动件越多，留给开发新功能的时间就越少，这对于产品正在迅速发展的年轻公司来说，带来的影响可能是巨大的。因为用延长找到产品市场匹配的时间来换取自己动手实现的东西，这并不是一个明智的选择。

除此之外，你还得考虑自己团队的运营管理水平。比如对于那些是你自己的身家性命所在的业务或者产品服务来说，你可能更相信企业的能力。但对于那些不那么重要的系统产品，你就未必能够腾出更多的时间和精力去管理了，因为要维持其运行所需要付出的代价同样是巨大的，而它所产出的价值却不是长期明显。

我们也见过不少自己开发，或者是使用开源工具计划二开的企业，最后产出的基本都是自己常年吐槽的产品。

供应商锁定

关于这个问题，你可能会想：“我可不想被供应商的特殊系统卡脖子”。我对此持反对观点，因为内部系统也存在锁定问题。

比如：电子表格管理者（可以理解为管理层的数据需求），因为某些重要的内部流程的电子表格已经变成了电子表格管理者的工作。大多数的大公司至少都有一个这样的电子表格。那电子表格的管理者会捍卫自己的流程，不希望对它进行更改，并愿为此不惜一切代价，因为他们会担心，一旦这个流程被自动化或者不再需要之后，自己就会被解雇。

开发团队也会有这种情况，那些数据库或工单系统的管理者。比如你一直用的是一个糟糕透顶的系统，但没有人愿意为干掉它而发声，因为一旦系统被干掉，开发运营人员可能觉得自己也会被干掉。而那些对此不敏感的人试着去修复相关流程时，往往会被设置政治陷阱。

这也就意味着企业将要一直用这个难用的系统。

相对于以打造这种产品为生存根本的企业来说，他们更擅长来解决这些问题，并因此形成了更加深厚的专业知识。所以，供应商锁定这个问题的严重性其实比大多数人想象的要低，因为不管你怎么选择都有被锁定的可能。

独特流程

定制开发的另一个理由是因为公司的独特流程，觉得自己公司的需求外部工具的自定义也依旧无法满足；或者自定义同样要花费比较大的时间精力，还不如自己开发。

虽然这些都是自行开发的合理理由，但发生这种情况的概率其实比你想像的要小，而且你还有很多中方式来解决这些问题，而不仅仅是自己动手，比如让这类工具的厂商来定制开发；或者是找自定义能力强的产品，并且这些产品厂商一般都配有辅助配置团队来帮助企业节省自定义所造成的时间成本。

如果你依旧觉得还是需要自己定制开发，那么你将要面临的问题是：随着时间和团队规模的增长，流程会逐渐变得臃肿，原本跟业务流程相匹配的定制功能也会变得不能满足需求，于是又得投入更多的团队开发维护，因为这种情况下系统会变得越来越复杂，需要投入维护的人员也会越来越多，直到最后超出你的承受极限。

这里我不妨举一个很荒谬的例子，就发生在跟我合作的一家公司里面：

1.我们的文章推荐过程很复杂，需要对大量模糊数据进行联接。

2.我们可以开发自己的数据库系统来专门处理这个问题。

3.几个月的紧张开发时间过去了。

4.事实证明，这个工具很难用，我们既不知道为什么有的查询会导致系统崩溃，又不知道为什么我们的客户会对推荐表示抱怨。

你肯定不希望这种情况出现在自己身上，并且开发和维护一个甚至都不能正确工作的系统并没有多大价值。

失去重点

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

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

还有一点会导致这个问题雪上加霜，那就是不产生收入的东西经常会被忽视。CI / CD（持续集成/交付）系统绝对是很关键，但高管意识不到也不会那么想，因为它是非核心，也不能产生直接的收入。慢慢地企业就会有一堆被遗忘的内部工具，但如果你付钱让某人去干同一件事，那就变成了他们的生意，对方就会不断努力做好这件事。

机会成本

我们都知道聘请工程师并不便宜。除此之外自己开发定制带来的损失还有工程师本来可以开发企业核心产品而导致的机会成本。

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

除了调整自己的东西或者开发新的内部系统以外，你还可以做什么？

答案往往是要投入更多的时间来想出正确的架构，或者开发真正面向客户的功能，这才是你该关注的问题。

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

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

总结

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

考虑一下凌晨2点被人叫醒是否值得。就算你不怕被叫醒，也得考虑一下是不是别人做这项维护工作做得比你好。

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

如果你也正在找敏捷团队管理工具，PingCode是值得尝试的选择，并且我们还针对25人以下团队提供免费版本。

智能化研发管理工具PingCode官网

文/Jake Rottersman，内容转自36Kr,有删改