如果允许每个客户更改代码，您如何支持产品开发？

Question

你怎么处理这事？

允许客户随时更改软件是正常的吗？我是在一个没有规格和不断要求改变的环境中工作的。

对于每一个新的客户，我们必须创建一个新的分支，并作出如此多的变化，当我完成时，我有一个完全不同的产品。正因为如此，我对编程几乎失去了兴趣。

所以，我说不应该让客户随意更换软件，这是否错误呢？

英语是我的第二语言，所以请原谅任何错误。

相关： 如何处理信息不全的客户选择

Answer 1

编辑：我最初忽略了您有许多客户的部分，并且正在为每个用户定制一个软件。我会留下我原来的答案供参考，但它并不真正适用于这种特殊情况。

在您的情况下，我建议您需要一个不同的策略来解决客户的关切。我所使用的一种技术是，任何更改都必须与使产品对所有客户更有用相一致。这意味着你可以对许多变化说“是”。例如，通过模板使UI可自定义。这将有利于所有的客户，但可能是由特定客户的愿望，以使其外观和感觉符合他们的标准。但这也意味着您需要对某些请求说“不”，或者以一种对所有人都有用的方式对它们进行修改。

您还可能希望让您的客户使用类似UserVoice的东西来发出特性(和bug)请求，并对它们进行投票。这允许您的客户对产品的方向有一些直接的输入，但是强制所有的请求都被过滤。同样，您不需要总是接受级别最高的请求，也可以接受一些级别较低的请求。指导原则应该是使你的产品对最广泛的客户有用。

我不认为为每个客户设立一个单独的定制分支是不现实的，除非你计划只有有限数量的高薪客户。最终，您的版本控制系统将成为您的瓶颈，不能让您的公司成长，甚至不能很好地为您当前的客户服务。

一旦你进入一个更可持续的特征选择模式，我最初的答案可能仍然适用。希望这能有所帮助。

原始

我要说的是，有些顾客根本不值得拥有。只有你才能知道什么时候是这样。

然而，通常情况下，我们的工作是发现客户实际需要什么并交付。我建议遵循敏捷开发方法来做到这一点。很少有顾客真正知道自己需要的是什么。更甚的是，开发人员在开始编写代码之前就不了解客户需要什么。敏捷方法接受这一现实，并遵循使更改对流程的破坏性更小的实践。

首先，敏捷方法使用轻量级的过程，并将决策延迟到最新的可能时刻。有一个“刚刚足够”的前期计划来规划一个基本的架构框架，但在大多数情况下，它是按你的方式设计的。这并不像敏捷方法中使用的技术(如TDD、对编程、重构等)听起来那么随意，而是鼓励良好的设计和设计改进的可靠技术。

第二，敏捷方法对文档很了解。虽然不是无文档的，但这些方法将文档维护保持在最低限度。更改最糟糕的方面之一是文档已过时，必须不断更新才能正确。敏捷方法识别那些真正有用的文档并维护这些文档，但是其他过时的文档可以被丢弃。它们在需要的时候就会被使用，但是你并没有被绑在它们身上。敏捷方法非常重视代码和测试，它们是自我记录的。

第三，敏捷方法鼓励基于相互信任的合作发展形式。这是双向的。客户必须相信你有他们的最大利益，而你必须相信客户知道，或者至少，当他看到他需要的东西时，他能意识到他需要什么。

最后，敏捷性的特点是提前发布，经常发布。尽早将产品掌握在客户手中是获得客户真正需要的反馈的最好方法(同样，提前)。一旦您有了一个具体的产品，您将开始获得有关真正重要的更改的信息。通过计划尽早和频繁地发布，并将其与其他敏捷实践结合起来，您还将构建一个框架，使更改更容易适应其中。

即使在遵循这些方法时，正如我前面说过的:有些客户不值得拥有。如果你的客户不信任你，在改变不好的时候听从你的建议，或者客户不知道，也不知道他真正想要的是什么，那么也许会有一个时候切断你与他们的联系。我建议和他们交谈，让他们知道你想让他们得到他们需要的东西，但他们需要知道那是什么。花点时间来讨论这个问题，这样你们都能更好地理解目标，并将敏捷的方法应用到应对变化的现实中。如果他们仍然是不合理的，那么也许这将不是一个很好的适合你。

Answer 2

我说不应该允许客户随意修改软件，我说错了吗？

软件是谁的？你还是他们？

如果我拥有一所房子，如果我愿意的话，我可以每周雇一个人把它涂成不同的颜色。如果画家抱怨，我可以找一个新的画家。如果我没钱了，也许是因为我是个白痴。但是画家在粉刷我的房子，得到我的钱，用它养活他的家人，并没有做错什么。

如果我拥有某个软件，我可以用它做任何我想做的事情。如果你不这么做，我会问别人的。

Answer 3

与实现相比，规范应用程序同样重要(甚至更重要)。给客户至少一个基线文档，UI模拟或类似的东西，我认为是至关重要的。

随着系统的发展和成熟，你必须接受改变的要求，否则系统会受到熵的影响，你付出的任何努力都将永远失去。如果它是一个更商业化的产品，试着限制所有客户想要的改变。那么每个人都得到了增值。

如果您有基线文档，那么您可以为定制收费。您希望进行的定制越少，您的收费就越高:P确保您记录并估计了所有更改请求。(我使用fogbugz实现这个功能，但是有很多其他工具)如果客户正在为更改付费，那么在tleat您将被重新计算更改系统的痛苦。