如何为增量产品开发制作业务案例

Question

我不为一家开发公司工作，但我们一直在与一家公司合作开发一个应用程序，以便在我们的业务内部使用。该应用程序有点“利基”，因此，虽然我们有能力扩大它和推出到我们的其他地点(我们是一家国际公司)，这是不可能的，我们将发布到全球市场(例如。卖给我们的竞争对手)。即使我们这样做了，应用程序将是一些利基和市场小。

为了获得项目的资金，我们需要准备一个业务案例。我们采用了敏捷开发方法，在开发“最小可行产品”的基础上构建了业务案例，并在此基础上获得了预算批准。我们非常幸运地与一家技术提供商合作，他们非常关注应用程序的最终用户/可用性，以及最低限度的技术功能，因此我们的“最低可行产品”实际上是非常完美的。

然而，在我们进行开发的过程中，我们发现了大量可能的增强，包括功能和用户体验(甚至是一些体系结构的增强)。考虑到我们有一个有限的预算和时间表，我们必须非常积极和有纪律的优先排序。其结果是，我们现在的应用程序是如何准备向最终用户推出的，但是在我们的待办事项中列出了大量的好机会，我们没有预算来推进这些机会。

我真的很想得到更多的资金，并进一步开发应用程序，但这是很难做生意的理由。从公司的角度来看，这不是我们的核心业务:它是帮助我们交付核心业务的工具，因此预算必须与其他活动竞争。由于我们已经交付了我们的"MVP"，我们已经交付了大部分价值(至少在预算持有者的眼里)。与MVP相比，这些附加功能的投资回报率大大降低.

人们通常是如何在敏捷项目中添加下一个特性集的？你如何让预算持有者和决策者相信用户体验、无形资产和抛光的价值；特别是在我们这样的利基应用程序中，你不需要持续发布和更新来保持竞争优势？

这个链接提供了一些想法。，但它并没有给我任何答案。有没有人有任何想法，如何架构额外的功能和递减的价值？

注意:最初的商业案例是关于采用手工过程并使其半自动(使用软件进行以前基于纸张的操作)。另外的特性是与其他系统更好的数据集成、UI增强、更改一些应用程序逻辑以使其更加灵活:即所有有价值的东西，但没有一个具有极高的“投资回报”。

Answer 1

单个特性或改进的ROI通常很难用数字表示。然而，很多组织都知道，当他们订购了一些为他们的特定业务制作的软件，这就为他们每年节省了一定的资金，因此，将一定比例的X再投资于软件的维护和演变是有意义的。这将更适用于当软件将返回一些许可证费用Y每年，然后百分比应该指"X+Y“。

然而，这个百分比应该有多大，这是一项战略决定，因为小幅度改进的许多效果只有在较长的时期后才能显示其价值。但是，最低限度是限制维护成本的百分比，以确保应用程序中的每月错误得到修复，并且软件能够适应环境变化(例如新的OS版本、与之交互的平台的新版本、安全修复、第三方库中的更改等等)。

因此，通常需要有人因为做维护而得到报酬。这是获得协同效应的良好基础--定期支付年费，不仅用于维护，而且还用于进化，这使得维护人员有可能在薪资中找到一个人，为产品的进一步开发保留实际知识。如果您的组织只愿意支付绝对最低的维护费用，也许只有在出现错误或出现新OS版本时才会按需支付，并且维护人员必须重建每年更改软件内容的知识，因为他们没有几个专门从事这项工作的人员，这对您的组织来说可能会比他们每年在固定预算的基础上定期投入一些资金进行维护和改进要贵得多。

举个例子，看看那些让自己为Windows或旧的Internet 6.0这样的平台开发个人软件失败的公司，而忘了签订合同来保持这款软件的最新--它们现在面临着在现代操作系统或浏览器上获得替换的巨大问题。这样的决定最终会让他们付出比他们之前做一些战略投资更多的钱。

因此，简单地说，我不会尝试为小的个别特性计算ROI。试着让你的组织领导人意识到更大的前景，希望他们对战略思维敞开心扉，并试图说服他们每年进行一定比例的"X+Y“再投资。

注意:我发现了一篇关于优先排序特征的非常有趣的相关文章，其中讨论了为什么"ROI“不是优先处理待办事项的一个很好的指标，并介绍了另一种模型(”延迟成本“)，也许它对您有用。