Project management 您如何向客户传达发布日期？

作为一个开发团队，我们（内部）承受着很大的压力，需要向客户提供准确的发布日期。我们应该怎么做

我们所看到的问题在于准确定义每个版本所需的内容，以及不知道在发布过程中我们的优先级可能会如何变化。我们正在使用FogBugz，并认为我们可以利用基于证据的计划来帮助解决不确定性，但我们不希望我们的客户对信心范围感到非常满意

我看到Fog Creek有一项政策，即在实际发布之前不告诉客户何时发布。还有其他人采取这种方法吗

---

编辑：谢谢你的回答-很难选择一个被接受的答案，所以我投票选出了其中的一些给你带来业力。我选择了cowgod's作为与我希望处理我们自己开发的方式相匹配的产品。

我们采取的做法是，在完成之前不宣布发布日期。如果客户提前需要，我们会解释哪些部分已经完成，哪些部分还没有完成。有时候，他们只需要一个核心特性集就可以了，如果它是真正重要的特性，并且愿意等待其他特性。但根据我的经验，他们通常希望等到整个事情完成后再发布

---

我很幸运，我所处的文化环境没有那么大的压力让我们提前知道发布时间。

谷歌也这样做，没有公布发布日期

在一个项目中，关于发布，有三个因素可能会有所不同：

• 时间
• 资金/资源
• 功能数量

所有关于它们的常规yes/but/if（晚些时候添加额外资源自然对项目没有帮助）

---

如果你有一个固定的发布日期，时间是固定的。这样，只有改变另外两种方式，你才能正确地管理你的项目：花费更多，或者限制产品中的功能数量。

如果您在发布产品时面临着让客户知道的压力，您可以尝试一些XP技术，例如让客户决定他们首先需要哪些功能并进行TDD。

对于我目前正在进行的项目，我们每周都提供一次生产发布和一次质量保证（QA）发布。如果QA已经批准了前一周的部署，这将投入生产，我们最新的bug修复和功能请求将打包发布给QA。我们无限期地继续这一进程

---

我们有一个文档Wiki，它使用客户可以查看的最新发行说明进行更新。

我们不提供日期。我们只是问他们什么时候可以测试我们的版本。（这通常会给我们足够的时间来总结，因为没有人想测试，他们也都有自己的工作要做。）

只是为了给出一个不同的观点：

我们得到了发布日期

对于大型企业，您只能在周末发布内部产品，这意味着您可以很快了解到：

a/只有52个
b/保留其中一台存在大量竞争（物流团队是竞争对手之一，用于服务器和/或网络升级，并防止任何发布进入生产，因为服务器可以随时关闭）

所以我们没有发布日期的选择：我们一年只有其中的几个，它们不太可能改变

为了仍然交付一个有意义的发布，我们在发布日期前几周定义了一次“顶级内容”会议，以定义发布的实际部分（一些当前的开发将不在其中，因为它们被证明过于复杂，或者依赖于其他未准备好的部分，或者任何其他“优先级”更改）

然后，发布经理确保所有团队将所选开发合并到一个测试环境中，用于所有认证/UAT/预生产测试周期。（我在这里跳过了很多细节）

---

然后我们交付。准时（然后制作一些补丁；）

当我参与的项目准确地说明了发布日期时，我们将功能划分为“此版本的基本功能”和“可以滑到下一版本”，然后选择一个发布日期，这样我们就可以轻松地完成所有基本功能，并且认为至少有一些机会完成所有不重要的功能

当然，这提出了一个问题，为什么我们甚至在考虑不必要的功能，但在实际项目中，通常有几个东西可以朝一个方向或另一个方向移动，这取决于（a）客户是否了解建议的功能，如果是，他们是否喜欢，（b）接下来的版本预计多久发布，客户升级有多容易，（c）您的商业计划分别受到现在可销售的产品或明年令人惊叹的最终产品的影响

因此，实际发生的情况有三类，“基本的，而且预计仍然是基本的：如果不按时完成，我们将被迫推迟发布”，“目前视为基本的，但随着发布日期的临近，我们可能会改变主意”，以及“目前视为不适合发布，但如果时间允许，我们会将其向前推进”

不过，我参与的许多项目都运行了很长时间，临时版本基本上是当前工作版本的快照。说你“给出了一个准确的发布日期”感觉像是作弊，而实际发生的情况是，一个客户要求更新，你检查了该客户的活动bug列表，发现你有两个未解决的问题影响了他们，估计需要一周的时间来修复这两个问题并进行验证，然后告诉他们“我们会给出”