Project management 维持产品的早期发布

背景如下：企业软件开发没有足够的直接客户参与。我们不是为特定客户开发此软件，而是为了填补市场空白。我们只与主要客户一起满足核心需求，现在有更多的客户加入。强制的截止日期、不断变化的需求、很少的设计时间。快乐时光！：）

我们得到了第一次释放。然后我们获得了第二次发布（幸运的是，以一种更有组织的方式）

对于这两个版本，维护工程所面临的大多数问题都是他们所谓的“设计缺陷”，而不是好的旧代码缺陷。 一般来说，这些“设计缺陷”是指某个功能或某个功能的一部分的行为与设计相同，但这种行为并不是某些客户希望产品做的。并不是所有的客户都有这些问题——每个客户都不同，对一个客户来说足够的东西对另一个客户来说不够

这让我想知道一些事情，我真的可以利用你们的洞察力和更多的经验

以下是一些深奥的问题：

• 您认为这在产品生命周期中有多普遍

• 你认为上下文对此有多大影响

• 你的经历和背景是什么

---

当您交付客户不想要的东西时，您的需求工程失败了。由于这是软件开发的第一阶段，并且设计、编码和测试都基于此，因此需求中的bug是最难修复且成本最高的

企业软件开发没有 足够的直接客户参与

• 在这种情况下，这将是产品寿命中的常见现象。如果客户没有参与进来，而你不知道他想要什么以及如何想要东西，那么当你交付产品并了解他的反应时，你会感到相当失望

你认为上下文对你有多大影响 对此有贡献吗

• 我认为这是主要原因

你的经历和经验是什么 背景

---

类似的情况下，直到项目开发期的一半，在交付中间产品时，我发现客户的许多期望与我的想法大不相同。我想发送一些中间产品以供批准是一个好主意，这样我就没有那么多修改的余地了，因为如果我发送的最终产品不能满足客户的期望，那么我建议您不时与客户保持联系，并让他在您开始新功能之前批准功能。这样，当最终产品准备就绪时，它将是客户一直看到并逐步认可的产品。

这取决于产品的寿命：寿命越长，可能和/或需要的进化就越多

例如，从1991年到2003年，我帮助维持了一个软件产品；而在最后，它几乎与开始时完全不同：

• 它最初是DOS的汇编TSR，为小型（如律师）PC局域网实现调制解调器共享
• 它最终成为NT的分布式服务，为多家电信公司实现了成本最低的传真路由

---

这段时间它一直在销售，每年发行几次；这是客户想要的，但客户（及其需求）随着时间的推移而变化，底层的O/S、竞争对手等也发生了变化。

这是非常常见的，客户之间的需求不同，他们希望向不同的方向推动产品

对于任何给定的更改，有三个选项：

1） 你不能这么做——他们已经购买了产品软件，他们必须接受产品。我希望Word能做些不同的事情，但我花了几百英镑买了它，而不是从头开始定制文字处理器，所以我不得不接受它

2） 你可以将产品分成两个不同的版本——通常情况下，这是最糟糕的事情。作为一个软件公司，您的模型依赖于许多为公共代码库做出贡献的客户机。拥有多个版本会显著增加成本（每个bug修复两次、两个手册等），并破坏您的业务模式。再说一次，如果他们想要定制的软件完全按照他们的要求构建，那么他们需要为此付费——你不能以包价获得定制软件

3） 定制（可能作为选项/模块/可配置设置）-这可以工作，但您确实需要考虑这是否适合您的产品。每一个额外的选项都会大大增加代码交互方式的数量和必须执行的测试的数量，因此会带来巨大的成本。在企业领域，您必须接受客户会在这一领域提出要求，但您需要准确评估后果和成本（在开发和持续支持期间一次性评估），并让销售和管理层了解这些后果和成本

但本质上，它们都归结为同一件事——产品软件，即使是在企业层面上，也远比内部团队（或咨询公司）定制产品便宜得多。这种价格优势也带来了一个负面影响，那就是你不能得到你想要的东西，而且企业有时需要适应软件

在客户或销售中，这通常不是一个流行的信息，但你需要确定你在哪个市场（产品或定制），并在做出决策时记住这一点

至于问题的另外两个方面，我根本不相信是环境造成的。其根源在于组织是不同的。除非你所有的客户都是一样的，否则总有一天会成为一个问题。也许情况比以前更糟，但可能比你想象的要少