让我们扮演魔鬼的拥护者:你会给管理层编写解决方案但购买昂贵包裹的原因是什么?
答案 0 :(得分:25)
虽然在一天结束时,一切都会以某种方式归结为第1点。
答案 1 :(得分:11)
简单;当您自己的总体拥有成本(TCO)大于包裹的总体拥有成本时,请购买。 (你如何可靠地计算出你自己的TCO是一个留给读者的练习;-))
不那么简单; DIY软件是您的核心业务,或者软件是一个独特的卖点。你不想把你的大脑或心脏外包出去。
答案 2 :(得分:2)
已经存在一个非常类似的程序。除非你是为了娱乐/学习目的而这样做的
答案 3 :(得分:2)
购买组件的优点: - 购买它可能比开发它更便宜 - (在某些情况下)团队没有开发该组件的专业知识。所以收集这种技术的时间是令人望而却步的 - 维护成本转移给供应商
缺点 - 无法控制组件的生命周期(包括何时发布新版本,应该执行哪些修复等) - 可能需要调整/整合工作。 - 由于集成问题,可能会引入性能损失。
答案 4 :(得分:2)
我已经看过很多这样的例子,我认为它分成了两半。首先,你的“商品”软件 - 消息传递中间件,数据库等 - 通常都会被买进。我永远不会坐下来编写我自己的异步消息系统,除非这对我的业务来说绝对是核心。其次,有增值部分,我认为这是相当不同的。
我在金融领域工作,有一些供应商系统(例如Murex,Summit和Sophis)为各种金融市场产品提供风险/预订/后台功能。我认为选择这些是危险的,原因有两个。
第一个原因是你在软件方面没有领先于你的竞争对手,你没有增加自己的价值,所以它只是在你可以收取的价格方面成为“竞争对手”,或者你可以冒多大的风险。
第二个原因,从软件开发人员的角度来看更重要,尽管供应商的系统现在可能适合您,但在两三年内可能不适合您。如果你已经在它之上建立了自己的业务,并且突然发生了变化 - 或者在你需要的时候没有改变 - 你就可以保持高度干燥。或者,如果公司破产或想要退出市场,您有两种选择 - 购买它,或者从头开始重新编写所有系统。
我已经失去了我所见过的那些正在拼命试图关闭增值供应商系统的公司数量(典型的例子是Murex,Sophis,Summit ......见上文:)并自己编写。< / p>
针对增值供应商系统的补充论点是顾问/承包商通常要贵得多。一位资深的c#顾问每天可以在这里花费x00英镑。拥有供应商系统经验的顾问将增加约20-25%。
答案 5 :(得分:2)
我会给他们真正的理由(假设我在一家我真正想要工作的公司,也就是说,而不是被PHB奴役)。通常这是“如果我有这个,我会更快地完成工作,而且我的时间对你来说很有价值”。
但更有帮助:如果问题是“什么时候出现你想要支付软件的情况?”,那么:
在哪种情况下
可替换地:
第一点意味着,游戏公司不应该编写自己的IDE,Web应用程序公司不应该编写自己的编译器,银行软件部门不应该编写办公应用程序等,除非你真的认为你最好不要写游戏,网络应用程序,交易软件,或任何你有实际截止日期的事情。显然有一些例外:如果你想要一个小小的脚本或webapp,那么编写它可能比找到你需要的东西更容易。
在第二点,“更好”对不同的组织意味着不同的东西。假设功能相同,如果您的部门充满了linux极客,那么免费选项可能比没有Linux极客的情况下有更多的加分,并且还需要在相关软件包上使用SLA。如果“软件包”将被编译到您的非免费产品中,而不仅仅是支持您的开发,那么显然GPL中的免费软件对您来说毫无用处,而麻省理工学院可能会免费精细。等等。
答案 6 :(得分:1)
大大简化,但选择最小的:
费用是执行task
uses
次的费用。 task_execution_time是执行任务所需的(人)时间,包括任何开销,tool_development_time是开发工具所需的时间。
我遗漏了很多变量来保持简单。添加更多以适应:)
答案 7 :(得分:0)
与购买解决方案所涉及的成本和时间相比,开发新解决方案所涉及的成本和时间很长。通常管理层对这两个因素非常敏感。
答案 8 :(得分:0)
它会更便宜,但前提是您准备修改您的业务实践以适应包的工作方式。在包装上执行大量自定义以适应您的业务实践几乎总是比从头开始创建自定义应用程序要花费更多,并且经常以泪流满面。
答案 9 :(得分:0)
购买软件有很多理由。在我看来,最重要的是:
外包的优势:
答案 10 :(得分:0)
如果你要从零开始制造自己的汽车,它可能会非常昂贵并且非常不可行,但是如果你要买一辆现成的汽车,它可能会便宜很多并且更加可靠。
软件也是如此(大部分时间),每一点定制代码不仅需要开发,还需要经过测试和支持。如果您可以将产品纳入客户的要求,通常可以是更具成本效益的解决方案。但是,我认为当一个产品被用于一系列要求不是为其设计的要求时会出现问题。
答案 11 :(得分:0)
一些原因
如果您的供应商相当稳定,这适用。如果它们很小或财务状况不佳,商业软件可能比内部开发更大赌博。
无论你走哪条路,你都会获得锁定效果。迁移远离实际使用的应用程序永远不会自由且很少便宜。
答案 12 :(得分:0)
一次性内部开发可以用来替换订阅软件,例如,如果您有可用的开发资源,则可以证明2X的一次性开发成本可以替换每年的X订阅。它还可能意味着最终解决方案完全针对业务需求,而第三方解决方案可能不完全匹配或需要额外的支持或解决方法。这适用于我在过去一两年中参与过的项目,其好处是新系统更准确,因此需要更少的支持人员。是的,好的软件会让人多余。
还应该为核心公司软件进行内部开发,该软件允许您作为一个实体存在,以便您下次在软件支持合同或订阅时出现时不会出现干扰,或者解决方案并不完全适合您的需求。
然而,不提供核心功能的基本软件的一次性成本很容易证明,无论是Oracle的大笔资金,还是最后需要的体面的CMS,CRM或客户票务系统。周。
答案 13 :(得分:0)
部分取决于管理层希望开发人员编写代码。
如果它是一家游戏开发公司并且他们正在推出自己的电子邮件解决方案,那将是一种浪费。有才华的游戏开发人员编写自己的SMTP客户端和服务器系统而不是进行更有趣的游戏开发(更不用说这可能会违背开发人员在雇用时可能想到的“任务声明”的任何外观)
如果相反它是编码一些小实用程序或其他它可能是值得的。如果有实习生,这可能是一个很好的项目,可以让他们开始,或者如果一些开发人员生病和厌倦了游戏物理,并想做一些更平淡的事情,他们可以工作一段时间。< / p>
答案 14 :(得分:0)
当我想自己编写代码并且我的老板认为我们应该买它时,他会说,“买最好的,剩下的就做。”
另一个经验法则:当它是您的业务核心产品之一时,请自行完成。如果不是,请考虑外包或从有核心产品的人那里购买。无论如何,他们会做得更好。
答案 15 :(得分:0)
我认为类比会适合。
假设您对最新的赛车引擎有所了解,它将立即让任何车速度提高20英里/小时。您之所以能够做到这一点是因为您非常了解并且在量子级别如何优化引擎以便它们更好地工作。但是,您在其他领域的工程技能,例如设计框架或车轮,只是平均水平。你是否会花时间试图提高这些技能并重新发明轮子(或框架原样?)?否。
相反,你将与制造最好轮胎的人和制造最佳车架的人合作,并将你的发动机与它们结合起来。这可以节省您的时间和金钱,因为您专注于您的产品,而不是提供支持基础设施。这也适用于软件。如果您需要的工具非常复杂,请从其他地方获取,因为您希望专注于制作最终产品,而不是让您制作产品的基础设施。