我们计划在 2010 年完成一些功能性交付,但我们也有技术议程(架构重构、整合、升级平台)。有关将这些内容包含在路线图中的最佳方式的任何建议,以帮助企业了解它们为何重要。
一个选择就是说相信我们,因为这是保持一切健康的正确做法,但如果可能的话,我希望有更好的可视化
我们计划在 2010 年完成一些功能性交付,但我们也有技术议程(架构重构、整合、升级平台)。有关将这些内容包含在路线图中的最佳方式的任何建议,以帮助企业了解它们为何重要。
一个选择就是说相信我们,因为这是保持一切健康的正确做法,但如果可能的话,我希望有更好的可视化
对此有点愤世嫉俗,我会用金钱来形容每件事。如果你不能根据赚到的钱或省下的钱来重写你的技术议程,那你为什么要这么做呢?
此外,还有一篇关于“财务技术债务”的文章,我发现它非常有用:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
对我来说,更有趣的一点是“技术债务的一个重要含义是它必须得到偿还,即一旦你产生债务就会产生利息费用。”
有一个简短的跟进
http://forums.construx.com/blogs/stevemcc/archive/2007/12/12/technical-debt-decision-making.aspx
显示如果您不进行更改,支持时间、故障间隔时间、问题数量应该如何增加。每种技术都有其时间限制、制造支持的结束和正常的生命周期。
示例 - 如果您使用 MFC - 您可以证明在 MFC 中编写简单任务比在 winforms 中慢 3 倍。所以 x 个月后,不升级的好处将失去。
使用设备就更容易了,随着设备越旧,故障越多,而且很容易显示(通常在 3 年后 covarage 一切都开始崩溃,我认为它是这样计划的。它没有以前不是,但现在确实如此)。
使用基础设施 - 再次 - 如果您有 oracle 7.6 - 显示您在管理上花费了多少时间(金钱)以及在 11g 中花费的时间减少了多少。
等等。等等。等等。
最终经理希望看到投资回报率......总拥有成本...... BLA BLA BLA 所以你需要给他们那个。