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