在长达20000个项目日的大型开发项目中，如何减少工作量、降低项目风险并在适当的时间集中使用资源？如何防止开发过程中忽略明确的警报信号？下面我先给大家展示一些在大型项目中反复出现的现象。然后我会给你一些建议，告诉你如何更好地处理这些问题。
大型IT开发项目的框架条件
金融机构复杂的前台和中台系统通常已运行 15 年，需要在应用和技术方面进行大规模变革——最近由法律要求引发。
举个例子：您的客户的期望是：
承诺并假定通过潜在的流程改进可以节省数百万美元的成本。
有关报告、客户联系、业务交易和报价透明度的法律要求。
上线后下一个折旧期的计划预算节省。
承诺通过使用敏捷项目管理和双模式 IT 实施来节省成本。
为了为您的项目提供资金，我们将首先寻找其他内部客户，他们将在构思期间为应用程序定义进一步的目标。
在这种情况下，十几个或更多不同的部门提出了大量新的要求 脊医电子邮件地址 和改进请求，旨在使处理过程和数据提供更容易。
所选示例的进一步环境条件是二到三位数的预算、实施中必须共同工作的多个供应商（承包商）以及外包测试区域。尽管专家和 IT 团队正在积极致力于这一概念，但必须考虑到如此多的变更请求，导致概念的批准面临相当大的时间压力。
当然，你有一个“项目章程”和一切“最先进的”。您可以概览所有需求、项目中的组织负责单位或相应的子项目人员。您还遵守报告渠道。您已经设置了用于项目规划的工具集，并且可以向决策委员会提供相应的报告（包括会议）。您将把这些交给项目委员会进行评估和决策。
您的项目显然组织得非常完美 - 子项目中有负责的子项目经理、专家和律师，他们反过来创建了足够数量和指定质量的专业概念。
大型IT开发项目的挑战
假设您的项目持续时间为三到五年。尽管组织良好，但事情进展并不完全顺利，因为存在不一致、支出现象、构思、案件处理延迟以及项目计划变更等情况。怎么可能呢？我告诉你：
处理子项目的计划顺序被证明是错误的，因为本应更易于管理的子项目首先启动。
复杂的子项目配备的专家和通才太少。
创建技术要求时需要多次迭代。
在实施 IT 相关概念时，技术概念中的重大错误就会变得明显。这些通常会导致开发人员提出问题，从而导致对 IT 概念以及专业概念的进一步调整。
各部门经常坚持他们的概念规范。
在项目中期，很明显，子项目的处理只能在有限的程度上并行：“积压”中提到的主题数量增加，所谓的“变更请求”数量增加。
专注于少数专家会导致项目出现瓶颈。
从需求和概念到开发的专业知识转移比预期更耗时。
对测试用例的描述和测试期望的误解会导致项目中系统集成测试 (SIT) 的重要测试阶段的延迟。持续发生的错误太晚才构建到相关的子流程中，并且没有得到一致的处理。相反，您只处理明显最大的问题案例，希望随着项目的进展，编程期间出现的错误能够得到纠正。
这种情况的一个负面影响是，各部门接受所提供的解决方案和吞下“隐藏”蟾蜍的意愿下降。
关于“抵消”的注释
你怎样才能及时把轮子拿到这里呢？警报信号是三到四位数的许多缺陷，其细节水平整体上变得难以理解，从而导致大量的“模糊”。
因此，我建议您简单地“扔掉”您发现的三分之一的错误并忘记它们。不仅有三分之一的错误被丢弃，而且只有那些被归类为次要的错误被丢弃。这是在这些错误与系统开发无关的假设下完成的。这些小错误包括，例如，测试数据现象、导致误解的操作错误、数据字段的不正确分配（例如“必须”而不是“可以”条目，反之亦然）、不正确的测试数据以及缺乏稳定的测试存货。
通过及时对相应子流程中发现的错误进行聚类，开发人员、测试人员和技术专家一致、及时、空间的“组队”，以及忘记小错误的勇气，您的重大项目可以在压力较小的情况下顺利进行。最初泰勒式的任务划分，每个参与的人都可以“及时”掌握并转移到生产中。
这篇文章也出现在银行博客上。