This is absolutely common that needs differ from client to client and that they want to drive the product in different directions.
There are three options for any given change:
1) You don't do it - they've bought product software, they have to live with the product. I wish Word did somethings different but I paid a couple of hundred pounds for it rather than having a bespoke word processor built from scratch so I have to live with it.
2) You branch the product and have two different versions - as often as not this is the worst thing to do. As a software house your model is dependent on many clients contributing to a common code base. Having multiple versions significantly increases costs (every bug fixed twice, two manuals, etc. etc.) and breaks your business model. Again, if they want bespoke software built exactly to their requirements then they need to pay for that - you don't get bespoke software at package prices.
3) Customisation (potentially as an option / module / configurable setting) - this can work but you really need to think about whether it's the right thing to do for your product. Each extra options massively increases the number of ways in which the code can interact and the number of tests which have to be carried out so there is a significant cost attached. In the enterprise space you will have to accept that clients will make demands in this area but you need to accurately assess the consequences and costs (one off during development and on-going for support) and make sales and management aware of them.
But essentially they all come down to the same thing - product software, even on the enterprise level, is far far cheaper than having an in-house team (or consultancy) build something bespoke. That price advantage comes with a downside - it's that you don't get exactly what you want and that the business needs to flex to the software sometimes.
It's not usually a popular message with clients or with sales but you need to work out which market you're in (product or bespoke) and remember that when making decisions.
In terms of the other two bits of the question - I don't believe the context created it at all. The root of it is that organisations are different. Unless you have all your clients the same, it was always going to be a problem at some point. Maybe it's a bit worse than it might have been but probably less than you think.
My experience in this area: I've been on both sides of the fence. I've been a development and / or project manager commissioning enterprise (and non-enterprise) third party software products (portals, finance systems and travel booking systems) and I've worked for two software houses developing them as a development manager (which is currently what I do).
Enterprise software developed without enough direct customer involvement
in such cases, this will be a common phenomenon in product lifetime. If the customer is not involved and you don't know what and how he wants things, you'll be up for quite a bit of disappointment when you deliver the product and you find out his reaction.
How much do you think did the context contribute to this?
I think it's the main cause.
What is/was your experience and context?
Similar context, up until about half-way across a project's development period, when delivering an intermediary product, I found out that many of the customer's expectations were quite different than what I had in mind. I guess it was a good idea to send something intermediary for approval, this way I had much less to modify than if I were to send a final product that would not meet customer expectations, so I suggest you keep a connection with the customer from time to time, and get him to approve features before you move on to new ones. This way, when the final product is ready, it'll be what the customer has seen and approved step by step all along.
It depends how long-lived the product is: the longer the life-time, the more evolution is possible and/or required.
For example I helped to sustain one software product from 1991 to 2003; and at the end, it was hardly anything like at the beginning:
It started as an assembly TSR for DOS, implementing modem-sharing for small (e.g. lawyers') PC-LANs.
It ended as a distributed service for NT, implementing least-cost fax routing for several telcos.
It was sold throughout this time, several releases per year; it was what customer wanted, but the customers (and their needs) changed over time, as did the underlying O/S, the competition, etc.
This is why you create API's. I've also seen enterprise level applications that allow users to create their own vb/java scripts behind forms and inside reporting tools. Yes, embed a reporting tool writer and don't try to make all of them yourself.
Enterprises are notorious for their desire to have massive amounts of features in every app. Even within the same company, you can get multiple ways of doing the same thing. I their defense, time is money, so when you save a 1000 users a click, it can add up. On the other hand, they also have people with too much time on their hands to think of every possible piece of data they may ever have to track in the entire lifetime of their company and will want them all in your app. They have the money and are set in their ways a lot longer than say a startup.
When you deliver something the customer did not want, you have failed with requirements engineering. Since this is the first stage of software development, and design, coding and testing are based upon it, bugs in the requirements are the most difficult and costly to fix.
发布评论
评论（5）
这是绝对常见的，不同客户的需求不同，并且他们希望将产品推向不同的方向。
对于任何给定的更改，有三种选择：
1) 你不这样做 - 他们已经购买了产品软件，他们必须忍受该产品。我希望 Word 能做一些不同的事情，但我花了几百英镑买它，而不是从头开始构建一个定制的文字处理器，所以我不得不忍受它。
2）你对产品进行分支并拥有两个不同的版本——这通常是最糟糕的事情。作为软件公司，您的模型依赖于许多为通用代码库做出贡献的客户。拥有多个版本会显着增加成本（每个错误修复两次，两本手册等）并破坏您的商业模式。再说一次，如果他们想要完全按照他们的要求构建的定制软件，那么他们需要为此付费——你不能以套餐价格获得定制软件。
3）定制（可能作为选项/模块/可配置设置）-这可以工作，但您确实需要考虑这是否适合您的产品。每个额外的选项都会大大增加代码交互的方式数量以及必须执行的测试数量，因此会产生巨大的成本。在企业领域，您必须接受客户会在这一领域提出要求，但您需要准确评估后果和成本（开发过程中的一次和持续的支持），并使销售和管理层意识到它们。
但本质上它们都归结为同一件事 - 产品软件，即使在企业级别，也比让内部团队（或咨询公司）构建定制软件便宜得多。这种价格优势也有一个缺点——你无法得到你想要的东西，而且企业有时需要对软件进行灵活调整。
这通常不是受客户或销售人员欢迎的信息，但您需要弄清楚您所在的市场（产品或定制），并在做出决定时记住这一点。
就问题的其他两点而言 - 我根本不相信上下文创造了它。其根源在于组织不同。除非你所有的客户都是一样的，否则在某些时候这总是会成为一个问题。也许情况比你想象的要糟糕一些，但可能比你想象的要少。
我在这方面的经验：我一直在栅栏的两边。我曾担任委托企业（和非企业）第三方软件产品（门户、财务系统和旅行预订系统）的开发和/或项目经理，并且我曾作为开发经理在两家软件公司开发这些产品（其中这就是我目前所做的）。
This is absolutely common that needs differ from client to client and that they want to drive the product in different directions.
There are three options for any given change:
1) You don't do it - they've bought product software, they have to live with the product. I wish Word did somethings different but I paid a couple of hundred pounds for it rather than having a bespoke word processor built from scratch so I have to live with it.
2) You branch the product and have two different versions - as often as not this is the worst thing to do. As a software house your model is dependent on many clients contributing to a common code base. Having multiple versions significantly increases costs (every bug fixed twice, two manuals, etc. etc.) and breaks your business model. Again, if they want bespoke software built exactly to their requirements then they need to pay for that - you don't get bespoke software at package prices.
3) Customisation (potentially as an option / module / configurable setting) - this can work but you really need to think about whether it's the right thing to do for your product. Each extra options massively increases the number of ways in which the code can interact and the number of tests which have to be carried out so there is a significant cost attached. In the enterprise space you will have to accept that clients will make demands in this area but you need to accurately assess the consequences and costs (one off during development and on-going for support) and make sales and management aware of them.
But essentially they all come down to the same thing - product software, even on the enterprise level, is far far cheaper than having an in-house team (or consultancy) build something bespoke. That price advantage comes with a downside - it's that you don't get exactly what you want and that the business needs to flex to the software sometimes.
It's not usually a popular message with clients or with sales but you need to work out which market you're in (product or bespoke) and remember that when making decisions.
In terms of the other two bits of the question - I don't believe the context created it at all. The root of it is that organisations are different. Unless you have all your clients the same, it was always going to be a problem at some point. Maybe it's a bit worse than it might have been but probably less than you think.
My experience in this area: I've been on both sides of the fence. I've been a development and / or project manager commissioning enterprise (and non-enterprise) third party software products (portals, finance systems and travel booking systems) and I've worked for two software houses developing them as a development manager (which is currently what I do).
类似的情况，直到项目开发周期过半时，在交付中间产品时，我发现许多客户的期望与我的想法有很大不同。我想发送一些中间件进行批准是一个好主意，这样我的修改量比发送不符合客户期望的最终产品要少得多，所以我建议您不时与客户保持联系及时进行，并在您继续使用新功能之前让他批准功能。这样，当最终产品准备好时，它将是客户一直看到并认可的产品。
Similar context, up until about half-way across a project's development period, when delivering an intermediary product, I found out that many of the customer's expectations were quite different than what I had in mind. I guess it was a good idea to send something intermediary for approval, this way I had much less to modify than if I were to send a final product that would not meet customer expectations, so I suggest you keep a connection with the customer from time to time, and get him to approve features before you move on to new ones. This way, when the final product is ready, it'll be what the customer has seen and approved step by step all along.
这取决于产品的寿命：寿命越长，可能和/或需要的进化就越多。
例如，从 1991 年到 2003 年，我帮助维护了一款软件产品；最后，它与开始时几乎没有什么不同：
在此期间，它一直在销售，每年都会发行几次。这是客户想要的，但客户（及其需求）随着时间的推移而变化，底层操作系统、竞争等也发生了变化。
It depends how long-lived the product is: the longer the life-time, the more evolution is possible and/or required.
For example I helped to sustain one software product from 1991 to 2003; and at the end, it was hardly anything like at the beginning:
It was sold throughout this time, several releases per year; it was what customer wanted, but the customers (and their needs) changed over time, as did the underlying O/S, the competition, etc.
这就是您创建 API 的原因。我还看到企业级应用程序允许用户在表单和内部报告工具后面创建自己的 vb/java 脚本。是的，嵌入一个报告工具编写器，不要尝试自己制作所有这些工具。
企业因希望每个应用程序都拥有大量功能而臭名昭著。即使在同一家公司内，您也可以采用多种方法来完成同一件事。我为他们辩解，时间就是金钱，所以当你节省 1000 个用户的一次点击时，它就可以加起来。另一方面，他们也有太多的时间来考虑他们在公司的整个生命周期中可能需要跟踪的每一个可能的数据，并希望它们全部出现在您的应用程序中。他们有钱，而且比初创公司坚持自己的方式的时间要长得多。
This is why you create API's. I've also seen enterprise level applications that allow users to create their own vb/java scripts behind forms and inside reporting tools. Yes, embed a reporting tool writer and don't try to make all of them yourself.
Enterprises are notorious for their desire to have massive amounts of features in every app. Even within the same company, you can get multiple ways of doing the same thing. I their defense, time is money, so when you save a 1000 users a click, it can add up. On the other hand, they also have people with too much time on their hands to think of every possible piece of data they may ever have to track in the entire lifetime of their company and will want them all in your app. They have the money and are set in their ways a lot longer than say a startup.
当您交付客户不想要的东西时，您的需求工程就失败了。由于这是软件开发的第一阶段，设计、编码和测试均以此为基础，因此需求中的错误是最难修复且成本最高的。
When you deliver something the customer did not want, you have failed with requirements engineering. Since this is the first stage of software development, and design, coding and testing are based upon it, bugs in the requirements are the most difficult and costly to fix.