上下文如下：开发的企业软件没有足够的直接客户参与。我们没有为特定客户开发此软件，而是填补了市场空白。我们只为主要客户提供核心要求，现在有更多客户加入。规定的截止日期，要求变更，设计时间短。欢乐时光！ ：）
我们获得了第一个版本。然后我们获得了第二次发布（幸运的是以更有条理的方式）
维护工程面临的两个版本所遇到的大多数问题都是他们所谓的“设计错误”，而不是旧的代码缺陷。 通常，这些“设计错误”使得功能的某个功能或部分行为符合设计，但该行为并非某些客户希望产品执行的操作。并不是所有客户都有这些问题 - 每个客户都是不同的，而对于一个客户来说，这个问题就足够了。
这让我对几件事情感到疑惑，而且我真的可以从你们所有人那里获得更多经验。
以下是一些深奥的问题：
您认为这是产品生命周期中的常见现象吗？
您认为上下文对此有多大贡献？
您的经历和背景是什么？
答案 0 :(得分：0)
没有开发的企业软件 足够的直接客户参与
您认为上下文有多少 有助于此吗？
你的经历是什么？ 上下文
类似的背景，直到项目开发期间的大约一半时间，在交付中间产品时，我发现许多客户的期望与我的想法完全不同。我想发送中间件进行审批是一个好主意，这样我修改的内容要少于发送不符合客户期望的最终产品，所以我建议你保留与客户的联系。时间，并让他批准功能，然后再转向新功能。这样，当最终产品准备就绪时，它将成为客户一直看到并逐步批准的产品。
答案 1 :(得分：0)
这取决于产品的使用寿命：使用寿命越长，可能和/或所需的进化就越多。
例如，我从1991年到2003年帮助维护了一个软件产品;最后，它几乎没有像开头那样：
它在这段时间内销售，每年发布几次;这是客户想要的，但客户（及其需求）随着时间的推移而发生变化，基础操作系统，竞争对手也是如此。
答案 2 :(得分：0)
这绝对是常见的，需求因客户而异，他们希望以不同的方向推动产品。
任何给定的更改有三种选择：
1）你没有这样做 - 他们已经购买了产品软件，他们必须使用产品。我希望Word做的事情与众不同，但我付了几百英镑，而不是从头开始构建一个定制的文字处理器，所以我必须忍受它。
2）你分支产品并有两个不同的版本 - 通常不是这是最糟糕的事情。作为一个软件公司，您的模型依赖于许多为共同代码库做出贡献的客户。拥有多个版本会显着增加成本（每个错误修复两次，两个手册等等）并打破您的业务模式。同样，如果他们想要完全按照他们的要求构建定制软件，那么他们需要为此付出代价 - 你不会以套餐价格购买定制软件。
3）自定义（可能作为选项/模块/可配置设置） - 这可以工作，但您真的需要考虑是否为您的产品做正确的事情。每个额外的选项都会大量增加代码交互的方式数量和必须执行的测试数量，因此会产生很大的成本。在企业领域，您必须接受客户将在此领域提出要求，但您需要准确评估后果和成本（在开发和持续支持期间一次性）并使销售和管理层了解它们。
但基本上它们都归结为同样的事情 - 产品软件，即使在企业级别，也比内部团队（或咨询公司）构建定制产品便宜得多。这种价格优势带来了不利因素 - 这是因为你没有得到你想要的东西，而且企业有时需要屈服于软件。
这通常不是客户或销售人员的热门信息，但您需要确定您所在的市场（产品或定制），并在做出决策时记住。
就问题的其他两个方面而言 - 我不相信上下文创造了它。它的根源是组织不同。除非你的所有客户都一样，否则在某些时候总是会出现问题。也许它比它可能更糟糕，但可能比你想象的要差。
我在这方面的经验：我一直在围栏的两边。我是一名开发和/或项目经理，负责调试企业（和非企业）第三方软件产品（门户网站，财务系统和旅行预订系统），我曾在两家软件公司工作，开发它们作为开发经理（目前我正在做的事情。）
答案 3 :(得分：0)
这就是你创建API的原因。我还看到了企业级应用程序，它们允许用户在表单和内部报表工具后面创建自己的vb / java脚本。是的，嵌入一个报告工具编写者，不要试图自己制作所有这些。
企业因其渴望在每个应用程序中拥有大量功能而臭名昭着。即使在同一家公司内，您也可以通过多种方式做同样的事情。我是他们的防守，时间就是金钱，所以当你点击1000个用户时，就可以加起来。另一方面，他们也有太多的时间在他们的手上思考他们可能在他们公司的整个生命周期中跟踪的所有可能的数据，并希望他们在您的应用程序中全部。他们有钱并且比他们的创业时间长得多。
答案 4 :(得分：-1)
当您交付客户不想要的东西时，您已经失败了需求工程。由于这是软件开发的第一个阶段，设计，编码和测试都是基于它的，因此需求中的错误是最难以修复的。