问从头开始重写系统:你在提案中包含了什么？

EN

我已经成功地推销了几次这个项目，下面是我的总体策略。这是基于我们的公司文化，在技术使用方面比我们业务线上的其他公司更进步，但我相信这些策略几乎在任何地方都有效。

首先，也是最重要的，你需要让他们了解公司的需求和财务利益。如果没有，就不用麻烦了。如果你能想出具体的数字，那就这么做。如果不是，给出你最好的估计，并告诉他们这只是一个估计。如果号码是一个完全未知的号码，试着从可能知道的人那里找出号码。下面是我使用的一般音高格式。

首先，我描述了该程序的作用以及它如何为我们的公司带来好处。指出它是如何节省资金的，或者如何给你带来竞争优势。让他们看到这个系统对我们的成功至关重要。

第二，检查问题。描述问题如何影响业务，而不是如何影响您作为维护程序员。

请务必将任何最终用户的痛苦包括在内。(例如，他们需要等待系统修复，他们的生产力下降，否则我们可能会错过机会。或者他们需要手动计算数字，这既耗时又浪费人力。一些东西。)

如果你可以诚实地说重写需要多长时间，而不是让它继续下去，那么你需要证明你每个月/每周/周期/任何时间都要花费x个小时，而重写需要这么多时间。

如果重写的时间比您在故障排除上花费的时间更长，请确保将出现问题时所浪费的时间包括在内。

基本上，你需要考虑底线。底线不仅仅是钱的问题。这也是为了提供比竞争对手更好的机会(这就是为什么公司首先在IT上投入资金--以跟上或超越其他公司)。

编辑

此外，不要伪造可以通过升级进行的改进，以及它们如何给公司带来优势。

• 是谁在使用web应用程序？获得他们对重写的支持，否则你可能会在以后遇到麻烦，当一些事情不太好的时候(“你为什么要改变它?现在比以前更糟了！”)要做到这一点，一个好方法是询问他们想要修复什么。确保他们得到一些东西来弥补新system.
• Estimate的痛苦，修复当前系统的bug需要多长时间，并将其放在您重写它的估计值的旁边。老实说，
• 会检查你过去花了多少小时来解决问题。
• 确保你必须从头开始重写所有内容。通常，使用重构和大量单元测试
• 一点一点地迁移现有代码会更安全、更简单。如果你想避免在遇到麻烦的情况下孤身一人，请让你公司中的重要人物来支持这一点。寻找决策者，层次更高的人，声音有一定分量的人。

许多公司宁愿继续修补正在运行的东西，即使维护成本很高，也不愿继续进行高风险的重写。尤其是当该函数是业务关键型函数时。

您有机会添加主要功能，这可以作为不更改为重写的风险。

然而，在展示你所拥有的东西之前，你可能只需要得到一个“工作原型”实现。提供迁移计划和兼容性测试计划。

如果在接下来的一年中，重写总共需要6个月的时间，那么要确保节省的成本大于保留现有系统的成本。许多人不会关心是否只在三年或更长时间内实现节省。

我们重写了系统，但它们是对业务至关重要的系统，每年都会产生大量的许可成本。6个月的重写和2天/月的维护很容易销售，更不用说其他好处了，比如极大地提高系统的准确性(导致需要指导旧系统的人员裁员)。总而言之，节省的资金帮助公司在最近的低迷时期保持了更大的活力，并将使我们在未来的竞争中获得优势。