在规避风险的环境中，我如何倡导半严格的发布时间表？
最近，我越来越被描述为我在该行业中最令人沮丧和士气低落的经历之一困扰：必须坐在经过测试，重新测试，上演的发行版上，并且出于所有目的并且已经准备好装运/部署目的。 作为一个全方位解决方案的人，而不仅仅是一个顽固的编码人员，我确实理解甚至提倡适当的变更控制。但是最近，在覆盖我们的基地和按时运输之间的微妙平衡已经变得不平衡了，在恢复到理智的状态上，我几乎没有成功。 我正在寻找有说服力的论据来帮助说服规避风险的管理人员： 开发团队应该（或必须）能够设置自己的发布时间表-在一定的范围内（除了最大的财富500强公司，对于所有其他公司，1-3个月应该足够保守）； 软件版本是重要的里程碑，不应轻率地对待。换句话说，不必要的延误/停工是极具破坏性的，应仅将其作为解决某些关键业务问题的最后手段；和 希望（或要求）作为利益相关者参与的外部（非dev / non-IT）实体有责任与开发团队合作，以达到发布时间表，尤其是在计划船交付前的最后一周左右日期（即用户测试/分期）。 以上是根据经验对我而言正确的断言，但看来我现在必须证明这一点-因此，如果存在这样的问题，我想在这里提出一些建议。 谁必须向管理层“出售”固定（或半柔性）发布周期的想法，才能指出一些论点/策略有效或有说服力，哪些无效？除了明显的时间表争用和沉没成本之外，即使在“公司”环境下，是否有任何硬数据/证据可用于证明运输实际上很重要？ 另外，我也乐于听取建设性的争论，即为什么时间表灵活性（即使在数周/数月的时间内）比按期交付更重要；我现在很难相信，但也许他们知道我不知道的东西。 请注意，我们已经分阶段发布了产品，除了生产之外，它经历了每个阶段。使用商业错误跟踪器跟踪问题，并且分配给此版本的每个问题（其中100％）均已解决。我意识到这很难让人相信，这才是真正的重点-出于无法解释的原因，管理层会延迟100％，功能完善，经过全面测试并且获得了利益相关者的批准，这是没有道理的，但这就是事实，这就是正在发生的事情，这是要解决的问题。