Ant 证明技术的投资回报率？

如何向经理证明技术的投资回报率

我找到的最接近如何做到这一点的文档是：

本文档中有一些公式，但我真的不知道它们是否只是大量的营销，或者它们是否是关于如何计算投资回报率的准确公式

---

在上面的文章中，我并不是真的试图计算构建工具的ROI，我只是试图计算一个简单构建工具（如ANT）的ROI。

我无法想象有任何明智的方法来准确测量开发人员工具和实践的ROI。我能想到的唯一可能的事情是在工厂环境中，在那里你可以测量生产率和平均质量

---

我建议大家都这么做，那就是选择一些公式来支持你想要的东西，然后调整它们，直到投资回报率足够高，足以证明投资的合理性。

他们没有切中要害：无形的好处——尽管他们至少试着举个例子。这些公式只是为了得到一个不错的投资回报率——如果“使用构建工具”是一种股票，我的投资会得到多少回报

这已经表明问题本身是有缺陷的：自动化构建主要是提高质量的工具；提高生产率通常是次要的问题

然而，当与坐在钱上的人交谈时，这并没有帮助。
我将使用这些指标来分析构建工具的效果：

• 从签入到最终媒体的周转时间
• 构建数量（用于测试、用于发布等）
• 请求的生成数（使用更快的生成，您可以预期需求会增加）
• 手动生成期间引入的错误数（假设您跟踪这些错误）
• 能够发布版本的开发人员数量
• 用于实施和维护的估计资源（时间、许可证、构建服务器等）
• 低概率、高风险情景分析

通常，自动化构建工具只需消除一个瓶颈就可以为自己买单：每个开发人员都可以发布软件，而不仅仅是构建者约翰

最后一点很重要（但最难给出数字），因为bug的总成本不是正态分布，而是高度“帕累托”：一个bug可能会给你带来一些负面影响，或者让关键客户转向竞争

---

维护自动化构建的核心论点是，发布错误基本上是可以避免的

以小时为单位进行估算： 估计你目前花了多少时间，以及你会花多少时间

将估算值计入客户投诉： 估计您当前的bug数量。估计新系统会捕获多少这些bug。找出用户报告的bug的百分比，并记录用户可以看到的bug减少了多少

加上小时数： 计算出修复将捕获的bug需要多长时间，并将其添加到每小时的估算中

添加不可量化的“可销售性”。
利用额外的时间，我们构建了额外的特性。有了更少的bug，销售人员就可以更少地展示自己的脚了。如果我们这样做，我们可以额外销售多少份软件

---

最后一点不会成功；这主要是为了将注意力集中在前两个指标上；小时数和客户可见的缺陷。

我的建议是怀疑现在存在的问题，然后提供替代方案

您可以尝试将重点放在如何立即构建和部署的问题上，并首先赢得这场战斗。经理不想改变一些不会给他们带来悲伤的事情，所以你需要证明如果什么都不做的话，这将是一个问题

您应该考虑：糟糕的构建会损失多少时间和可信度；目前犯了多少错误；有多少手动重复发生等，并试图把这些事情的指标或例子

如果你能赢得开发者的支持，那么你也可以在你的论点中加入他们的支持。另一点需要指出的是，好的开发人员喜欢使用好的工具，因此渐进式管理等于积极的开发人员

---

如果你赢得了开发者和经理的心，这可能不仅仅意味着一张纸上有一些数字。

你所说的“从签入到最终媒体的周转时间”是什么意思？周转的意义不仅仅是“从单击“构建”到弹出最终CD的时间”，而是“从单击构建到单击构建”，也就是说，包括重新开始流程之前的时间。这可能需要更长的时间，因为在CD可用后，可能需要进行归档和清理。“自动化构建的核心论点是，发布错误基本上是可以避免的。”-peterchen现在这听起来像是我可以利用的东西！你的老板有尖头发吗？如果是这样，你就完了！“对不起，失信”在回顾时有点苛刻，但是的，为什么需要改变的事实以及所有相关人员的认同在这里非常重要。快乐的开发人员和无bug的代码是一种投资回报。祝你好运