在规避风险的环境中，我如何倡导半严格的发布时间表？

最近，我越来越被描述为我在该行业中最令人沮丧和士气低落的经历之一困扰：必须坐在经过测试，重新测试，上演的发行版上，并且出于所有目的并且已经准备好装运/部署目的。

作为一个全方位解决方案的人，而不仅仅是一个顽固的编码人员，我确实理解甚至提倡适当的变更控制。但是最近，在覆盖我们的基地和按时运输之间的微妙平衡已经变得不平衡了，在恢复到理智的状态上，我几乎没有成功。

我正在寻找有说服力的论据来帮助说服规避风险的管理人员：

1. 开发团队应该（或必须）能够设置自己的发布时间表-在一定的范围内（除了最大的财富500强公司，对于所有其他公司，1-3个月应该足够保守）；

2. 软件版本是重要的里程碑，不应轻率地对待。换句话说，不必要的延误/停工是极具破坏性的，应仅将其作为解决某些关键业务问题的最后手段；和

3. 希望（或要求）作为利益相关者参与的外部（非dev / non-IT）实体有责任与开发团队合作，以达到发布时间表，尤其是在计划船交付前的最后一周左右日期（即用户测试/分期）。

以上是根据经验对我而言正确的断言，但看来我现在必须证明这一点-因此，如果存在这样的问题，我想在这里提出一些建议。

谁必须向管理层“出售”固定（或半柔性）发布周期的想法，才能指出一些论点/策略有效或有说服力，哪些无效？除了明显的时间表争用和沉没成本之外，即使在“公司”环境下，是否有任何硬数据/证据可用于证明运输实际上很重要？

另外，我也乐于听取建设性的争论，即为什么时间表灵活性（即使在数周/数月的时间内）比按期交付更重要；我现在很难相信，但也许他们知道我不知道的东西。

_{请注意，我们已经分阶段发布了产品，除了生产之外，它经历了每个阶段。使用商业错误跟踪器跟踪问题，并且分配给此版本的每个问题（其中100％）均已解决。我意识到这很难让人相信，这才是真正的重点-出于无法解释的原因，管理层会延迟100％，功能完善，经过全面测试并且获得了利益相关者的批准，这是没有道理的，但这就是事实，这就是正在发生的事情，这是要解决的问题。}

乔尔·斯波尔斯基（Joel Spolsky）表示，软件开发团队是将资本（金钱）转换为可用软件的计划。老实说，从您的问题来看，听起来您的团队很擅长：您正在以合理的投资额获得不错的软件。

现在，当然，下一步就是将软件投入使用。除非您的公司选择这样做，否则他们将无法获得资本投资回报。坐在架子上准备部署的软件有点像仓库中的库存：成本沉没了，公司的资本金已经花掉了。还有机会成本：您的团队选择执行此项目，而不是其他事情。

更重要的是，搁置在架子上的新开发软件的价值就像坐在餐厅冰箱中的一箱干酪的价值：它慢慢腐烂。它的价值下降是因为您的竞争对手赶上了。它也拒绝了，因为随着开发人员转向其他事情，将新软件投入服务变得更加困难和风险。搁置几年后，它实际上可能一文不值。在这种情况下，您的公司选择放弃他们投资于开发它的资本。公司的所有者-股东-对此可能会不满意。

作为开发人员，您必须注意一件事。您的软件真的，确实可以在提议的发行周期结束时进行部署吗？它准备好了吗，还是在您的公司投入生产后还有大量工作要做和花费多少钱？您的公司是否拥有推广软件所需的服务器和软件许可证？您的工作产品是否包括部署计划？最终用户是否接受过培训？生产数据是否已转换？如果您的新软件涉及公司业务方式的变更，公司是否准备好进行更改？您是否制定了一种并行运行方案的方案，以确保新事物和旧事物都能正常工作？

所有这些部署成本都可以轻易地使仅开发软件的成本相形见war。明智的项目管理团队会尽力计划，预算和安排所有这些工作。你完成了那项工作吗？您向管理层说明了吗？如果不是这样，那么明智的做法是在您的展示上放慢速度。

现代敏捷软件的发布时间表可能与公司其他部门期望的变更步伐不同步。您的最终用户（您的利益相关者）可能根本无法以团队产生变化的速度吸收变化。

您的管理团队也可能运作不正常。您的团队是否开发了公司其余部分不想要的东西？您的新产品会威胁销售或生产团队吗？如果是这样的话，某位高管可能会说推出该工具太冒险而将其付诸东流。除非您是首席执行官，否则您无能为力。

您要求提供有说服力的论据，以便及时推出软件。真正令人信服的说法是：投资回报。该公司选择对该软件进行投资，现在他们选择浪费您的投资，因为您的软件在货架上缓慢腐烂。

及时部署的第二个论点是团队的士气。赶紧等待不是激励创意开发人员做好工作的好方法。如果他们不满意自己的工作投入使用，则可能会失去您的团队。

首先，观看此视频：

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

执行摘要：

您按时和按预算运送的方式是这样的：当您用光了时间或金钱用光时，您就可以运送。 而已。

大多数项目无法按时交付的原因是，在您准备好交付之前，在开发周期中，当您的资源被占用时，有人附带了“仅一个新功能或修复”就可以插入到发行版中。最稀缺的东西，现在您必须争夺。这被称为颠簸，它的发生是因为只要您不发货，就不必担心有人会告诉您您的产品很烂。

解决th动的方法是通过迫使人们在产品开发周期的开始而不是在结束时进行。

出于明显的原因，在发布日期之前的几周内进行产品更改非常具有破坏性。无论更改是一项新功能，对软件开发流程的更改，还是试图修复不在开发计划中的长期存在的错误的尝试，都是如此。

当有人在开发周期的后期来找我修复或更改时，我总是问他们：“您希望我不干什么，以便我可以完成您的事情？”

如果您需要金钱的动力，那就是这样：研究证明，您在软件生命周期中等待的时间越晚，实现功能或修复的成本就越高。 指数级。 证明这一点并不难。

您已经清楚地描述了您所面临的问题，但是我不清楚经理们为什么要采用这种方式。你能澄清一下吗？例如，您认为它已经准备好部署，有人反对吗？如果是，谁和为什么？他们是前政府大佬吗

这听起来很像一个能力与欲望的一致性问题，您有释放的欲望，但没有能力（权威），拥有权威的人没有欲望。

您需要找出为什么他们缺乏欲望-这是营销原因（在我们对旧版本进行挤奶的同时再保留一年），恐惧/信心（如果存在错误，将使我们看起来很糟糕） ，我们花了钱....，资源匮乏（无法负担运输/包装/公关材料的成本），它是商业性的，您的一些晦涩的下沉到不良的超额利润中，而他们又不想您赚钱（不像听起来那么傻）。

我还怀疑有关各方之间存在小分歧，因此没有进行合理的成人讨论。

抱歉-不是您要求的具体答案，希望有几件事需要考虑。

首先要考虑的是确保发布不是高风险。

理想情况下，您的变更请求应包含名为“ 风险缓解 ”之类的部分，其中包含有关在出现问题时如何回滚到先前版本的说明。从风险角度来看，没有任何数量的先前测试可以替代简单的选项来回滚更改。

• ^{在规避风险的环境下，我无法想象的方式进行不可逆的变化无痛。
  如果您的许多/大多数发行版都属于此类别，则可能需要重新考虑您的体系结构。}

如果您要认真对待开发团队的日程安排，则会暴露出未发布的风险。

如果您的发行版提供了针对生产/支持问题和停机的修复程序，则只需列出它们并指出除非升级，否则生产有重复这些操作的风险，这很容易做到。

对于开发团队来说，这是一种有效的措施，可以有效地防止发布失误，从而确保不发布的风险随着时间的推移而增加。这可以通过按固定时间表运行内部发行来实现，以提供生产问题解决方案的“累积”列表。

• 简而言之，阻止您发布的人不仅XX需要意识到他们会面临N无法解决各种生产问题的风险，而且还需要知道一周（或一个月）之后，他们将XX+1在批准队列中发布，阻止他们导致N+M各种生产问题的风险仍未解决- XX+2开发团队将提供这种情况以及进一步的“内部”发布。

上述方法实质上在应用程序更新和生产问题之间建立了更紧密和更明确的联系。

因此，您可能期望更多地参与生产问题升级。您可以利用这些机会来提升您对更严格的计划更新的愿景。您甚至可以自己触发一些升级，以加快采用所需方法的过程。

• ^{“ ......建议考虑将应用程序升级到较新版本（XX或更高版本）。当前已部署到您的环境（XX-2）的版本已严重过时-当前代码库背后的两个主要版本。因此，此类简单故障的详细信息如下：应用程序向客户端报告了深深隐藏在日志中且无法识别的垃圾，而不是清晰的故障描述-导致用户和支持人员浪费时间来研究非常简单的问题。“
   
  以上是我不久前在票证支持问题跟踪器中添加的评论与特定的生产事件有关。此后不久，“利益相关者”联系​​开发团队，询问如何跟踪我们的发行版以及他们如何帮助部署到其环境中。哦，他们也很快从XX-2版本。:)}

当生产升级时，您最好准备好快速清晰地展示自己的愿景。

您会发现有用的一件事是选择并跟踪谁负责特定的发行滑行。基本上，您需要能够快速清楚地回答“谁对计划内的发布没有发生这一事实负有责任？”之类的问题。如果您还没有准备好，他们可能会选择阻力最小的路径，并将责任归咎于您。正如对另一个答案的评论所指出的那样：“您可能会陷入困境，而管理层正试图保护您免受其害。”

最后的但并非最不重要的，

需要时间

（您可能已经知道这一点，但看起来值得明确说明）

您所寻找的东西可以描述为态度转变，从“有释放危险”到“有不释放危险”。态度改变很少在一夜之间发生，可能需要耐心才能完成转变。

您的问题上有一个很大的问号，这就是为什么您的公司不希望发布该软件。这并不总是一个简单的规避风险的案例。通常，还有其他一些潜在原因，这些原因通常不会从崇高的管理高度传承下来。因此，我对您的问题是：“您是否与老板坐下来，问他为什么阻止产品发布？”。

在管理风险与规避风险之间存在很大差异。出于法律或市场原因，可能会延迟产品发布。可能是管理层与开发团队之间的信任问题。该产品可能无法满足客户的需求，即使这恰好是几个月前客户所要求的。甚至可能出现这样的情况：管理人员认真掩盖了资产，同时试图将责任拖延到其他地方，或者甚至是第三方延迟，而后者要求您在完成产品交付之前完成某些工作。我可以提出许多方案。开发人员经常会承担风险规避，而又不了解方程式的另一端（尚未明确）。另一方面，这可能仅仅是自满，公司内部个人之间的冲突，

在所有情况下，重要的是要获得有关产品发布延迟原因的更多信息，并使用该信息来建立尽快发布产品的理由。是的，这可能非常令人沮丧，但是还有其他方法可以应对这些情况，而又不会冒与老板对抗或倦怠的风险。在类似的情况下，我本人也收集了信息，记录了我所取得的任何进展，然后，如果情况变得更糟，只需将项目搁置并转移到其他项目上。我之所以能够使项目回到正常的发布状态，通常是基于根据我收到的信息（对于所提出的问题的反馈）制定了合理的业务案例的结果。如果我无法说服管理层应该发货，我已经记录了不愿意将其作为项目完成的案例，并等待管理层批准发布的情况。然后，我确保我的经理签署了我的文件，表示文件已被管理层接受并理解，这样，如果他们以后再责备我不予批准，便可以掩盖我自己的屁股。

您始终需要点我的I号和T型叉，以免日后将运输延误归咎于您（无论多么不公平），而且重要的是避免在情感上对此类问题产生束缚，除非您喜欢赚钱的溃疡的想法。通过与某个专业团队合作来查看自己的处境，您可能会发现一个解决方案本身就可以解决，因为您已经有效地将自己置于距离问题更大的“距离”。如果您无法提出理由，则可能需要让它滑动一会儿，但是首先要提出您的理由，您需要显得专业超脱，并根据与之密切相关的信息进行论证您的公司及其内部运作方式。

我刚刚想过的另一件事可能对您有帮助，那就是阅读精益软件开发，看看其中是否有任何有价值的东西可能与贵公司的状况有关，尤其是在前几章中。我认为正是第4章讨论了尽快交付问题，并且涉及到延迟成本。

我想说，销售发行版最简单/最有效的方法是在准备就绪时关闭工具一段时间。做其他事情，开始一个新项目，处理现有项目的错误。直到它发出门后，再对它进行其他操作-毕竟，如果准备就绪后还没去，那为什么还要费心去做。

但是在现实世界中，实际发行版是别人的问题，您应该将其交付给他们，然后将其视为发行版。一旦离开您的门，它就会被运送出去。如果他们只是坐在上面，那不是您的问题（事实上，它很棒，没有bug报告！w00t！全方位无错误发行的奖金;））

因此，无论如何，您都需要一个变更控制系统和一个发布管理器。这样就很容易了（除非您确实需要管理变更控制，所以非常有必要进行源代码控制和部署构建。这需要组织，但如果组织起来，则很容易）。

我无法想象以您描述的方式让开发团队负责业务是“一件好事”，这可能掩盖了真正的问题，但是除非开发团队处于合适的位置来权衡来自销售，市场营销的投入等），您可能会因错误（且可能是错误的）原因而有释放风险。

如果我了解您的问题-您已经完成了该项目并且有可交付成果，那么您将无法向公司以外的任何人展示。（我希望本文对此进行了总结，我读了整个主题，但在手指上碰到麻烦）

你有没有尝试过：

1. 要求管理层让客户或一组客户在开发过程中充当涉众？通常，您可以找到一位客户进行中间发布并提供反馈。在发布的时候，他们可以成为伟大的倡导者。甚至向一个客户“限量发行”也足以帮助管理
2. 制定包括计划发布的发布计划。也就是说，您可以今天发布3.4，因为3.4.1版本计划在今天+ 1个月内发布。这与您已经提到的一个好主意，即发布节奏可以帮助此消息。
3. 获得支持，销售或市场支持。内建可解决前三大支持请求的修复程序，您可以从另一个部门获得盟友。如果您无法像第1条那样获得客户利益相关者，请尝试一些销售人员。提供可用于销售会议并带来产品。当您在旅途中时，向销售人员展示您对产品的状态（无论产品处于何种状态），请他们为您服务。

回答关于“为什么管理人员会发布？”的其他问题。公司在非西南地区一直在这样做，我认为这并非史无前例。例如，您已经准备好一个新版本，所有版本都已测试完毕。但是旧版本尚未被竞争所取代。一旦竞赛发布了您的旧版本的竞争产品，管理层就会发布等待上架的版本并扰乱市场，挫败竞争并保持销售和作为市场领导者的声誉。太早发布会向竞争者们伸出援手，他们可能会对您的路线图有更好的了解，并试图将您击败。

话虽如此...汉隆的剃刀可能是正确的答案:-)

离开那家公司，他们不了解软件。但是说真的，软件是使系统正常运行的原因，想象一下，如果您在制造汽车，汽车制造厂的速度是否会变慢？他们在等汽车发布吗？他们是渐进的和官僚的吗？不，他们试图以最快，最干净的方式来做事情。您有管理上的问题，应将其作为管理上的冲突加以解决，并尝试将其说成术语。询问风险对他们而言意味着什么，然后尝试将其最小化。开发人员的感受也很重要，因为它们必须适应您的干预将做出的决策。他们愿意整夜整夜准时出货吗？奖品/罚金是多少？等等。现在，我将为您提供解决此问题的实用方法，虽然有点极端，但需要进行审核。