我参与了几个项目，这些项目基本上涉及用“新”系统替换“旧”系统。一贯的模式是，构建“新”系统的团队中几乎没有人对“旧”系统有任何真正的了解。每当我对此提出质疑时，都会有人告诉我这是有目的的……通过不了解“旧”系统，团队能够以不同的方式思考，而不受那里的工作方式的限制。所以发生的情况是，团队中通常只有 1 或 2 个人对“旧”系统有所了解，每当出现有关“旧”系统如何做某事的问题时，都会向他们咨询。
但似乎总是发生的情况是，在“新”系统交付后，用户总是会提出“我们如何在新系统中执行 X（在旧系统中很容易）”形式的问题？对于开发人员来说，这往往是他们第一次听说 X。所以他们必须去研究 X 是什么，而他们给用户的答案往往是“你不能”或“你可以，但它是真的很尴尬”。
这对我来说似乎不对……在我看来，让“新”系统的每个开发人员都非常了解“旧”系统会收获很多，而且这不一定会扼杀他们的创造力，如果他们有不错的设计和开发技能。
关于哪种方法最好的任何想法？
您需要更好的业务分析师。他们应该审查旧系统，并准确（和完整地）定义新系统需要做什么。他们应该为您提供完整的要求列表，以便考虑所有需要发生的事情。
编写需求的人需要更彻底。如果这不可能，那么您可能需要参与并学习“旧系统”。
然而，总会有一些事情错过——这只是人性。您显然应该尝试使“新系统”尽可能灵活，以便在用户意识到他们已被遗忘时可以添加需要的功能。
我理解你的痛苦。
用新系统替换旧系统通常意味着功能相同（即至少能够完成旧系统能够完成的工作）
因此，虽然对旧系统的深入了解不是强制性的，但了解接口并构建一组功能测试套件对于有效地开发新系统很有用。
该套件将用于验证新开发的结果，请记住结果绝不能是 100%（否则，您将成功重现第一个系统的错误！）
另外，对于一个非常大的系统，您的新程序至少需要三个实现：
如果我们谈论的是一段很长的时间，那还涉及一个架构师能够管理旧系统的演变（它不能停滞不前，在新系统取代它之前等待几个月或几年），保持这些演变不变方向比你的新实现。
这听起来像是新系统的规范不完整，因为有人（项目经理、项目发起人）没有确保记录并检查旧系统的功能以查看客户实际使用的内容。
如果这样做了，那么没有人知道旧系统就无关紧要了，因为规范是您正在开发的东西。
如果您没有规范，除了您将遇到的所有其他问题之外，每个人都应该了解旧系统以避免这个问题。