如何向经理证明技术的投资回报率？
我在文档中找到的最接近的方法是：
http://www.agilejournal.com/pdf/Finding-ROI-in-Build-Automation.pdf
本文档中有一些公式，但我无法确定它们是否只是很多营销，或者它们是否是如何计算投资回报率的准确公式。
我并不是真的想在上面的论文中计算构建工具的ROI，我只是想计算像ANT这样的简单构建工具的ROI。
答案 0 :(得分：3)
他们没有切入问题：无形的好处 - 尽管他们至少试图通过一个例子。公式只是为了获得投资回报率很高的百分比 - 如果“使用构建工具”是一个股票，我将获得多少回报？
这已经表明问题本身存在缺陷：自动化构建主要是提高质量的工具;提高生产率通常是次要问题。
然而，当与坐在钱上的家伙交谈时，这无济于事 度量标准我用来分析构建工具的效果：
通常，自动构建工具只需消除瓶颈就可以收回成本：每个开发人员都可以发布软件，而不仅仅是John the Builder。
最后一点很重要（但是最难给出数字），因为错误的总成本没有正常分布，但是高度“帕累托”：一个bug可以给你一些讨厌的新闻，或者制作关键客户转向竞争。
维护自动构建的核心理由是发布错误主要是可避免的。
答案 1 :(得分：0)
我无法想象有任何明智的方法可以准确衡量开发人员工具和实践的投资回报率。我唯一可以想到的可能是工厂环境，在那里你可以衡量生产力和平均质量。
我建议做其他人做的事情，选择一些能够支持你想要的公式，然后调整它们直到投资回报率高到足以证明投资的合理性。
答案 2 :(得分：0)
以小时为单位估算： 估计您目前花费的时间以及花费的时间
将估算值放在客户投诉中： 估计您当前的错误数量。估计新系统会捕获多少个错误。找出用户报告的错误百分比，并记录用户可见的错误数量。
添加到小时： 弄清楚需要多长时间来修复可能被捕获的错误，并将其计入小时估算值。
添加不可量化的“可售性” 通过额外的时间，我们构建了额外的功能。随着更少的错误，销售人员在脚下射击的演示更少。如果我们这样做，我们可以销售多少额外的软件？
最后一点不会成功;主要是关注前两个指标;小时和客户可见的缺陷。
答案 3 :(得分：0)
我的建议是诋毁现在的东西然后提供替代方案。
您可以尝试将重点放在现在如何构建和部署的问题上，并首先赢得这场战斗。经理不想改变那些不会导致他们悲伤的事情，所以如果没有做任何事情，你需要证明这将是一个问题。
你应该考虑：糟糕的构建会损失多少时间和可信度;目前犯了多少错误;手动重复发生了多少等，并试图把这些事情的指标或例子。
如果您可以赢得开发人员的支持，那么您也可以根据论点的强度添加他们的批准。另一个要点是，优秀的开发人员喜欢使用优秀的工具，因此渐进式管理等于有动力的开发人员。
如果你赢得了开发者和你的经理人的心，这可能意味着不仅仅是一张纸上有一些数字。