当我们问人们在他们的软件项目上做了多少返工时，答案在5％到25％之间始终是变化的。我发现这很有趣，因为行业统计数据显示平均返工率要高得多（Forrester：30％； voke：40％）。人们为什么经常报告较低的返工率？以下是基于这些对话的一些原因：
词汇
在许多项目中，返工只是用不同的名称来表示。在许多情况下，它在预算流程中表现为其他订单项中的意外费用或填充费用。在另一些情况下，则需要进行大量的返工以进行维护，在极端情况下，甚至可能会定位一个新项目。
意识
我们进行了无数次对话，人们只是根本没有意识到返工的发生。一个原因与上述词汇有关，其中返工可以掩盖和分散在不同的预算项目下，从而掩盖了此支出作为返工的真实性质。
范围
似乎大多数人只考虑在项目开发方面进行的返工。返工的总成本取决于许多因素，包括您的开发过程以及您可能在开发周期中所处的位置，但也应包括所有受影响的领域，例如：规划&估计所有形式的测试（单元测试，集成测试，回归测试等）；产品文档；用户支持；服务和培训；等所有这些因素考虑进去后，返工的真实程度就变得更加清晰了。
否认
返工意味着做错了什么，需要重复工作。没有人喜欢与之相关联，对于许多人而言，很难接受平均软件项目上实际发生的返工量。虽然最初的讨论可能始于返工最少的要求，但经过一番询问后，返工率趋于上升。我记得有一次特别是在我们的谈话之后，最初7％的返工率最终达到了35％。
以上的组合
以上各项的各种组合可能会起作用，每种组合都会导致人们报告的返工率较低，并且可能会定期相信。
如果有更多原因，我也不会感到惊讶，也很想听听您所知道的任何信息。随着人们意识到软件项目上真正的返工规模，它很快成为改进计划的主要目标。
不要忘记在下面留下您的评论。
托尼·希金斯 是Blueprint产品营销副总裁，Blueprint是业务分析师的需求定义解决方案的领先提供商。 Blueprint被领先的分析公司Gartner任命为应用程序开发的“凉爽供应商”，并且获得了设计和建模卓越卓越的设计大奖，它通过提供专门针对业务分析师设计的业界领先的需求套件来使业务和IT团队保持一致。
