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