如果允许每个客户更改代码,您如何维持产品开发?

时间:2009-05-25 12:18:30

标签: project-management specifications branch

你如何应对?

允许客户根据需要随时更改软件是否正常?我在一个没有规格和不断变化请求的环境中工作。

对于每个新客户,我们必须创建一个新的分支并进行如此多的更改,以便在我完成时,我有一个完全不同的产品。因此,我几乎失去了对编程的兴趣。

那么,我不应该说客户不应该随意改变软件吗?

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

  

相关:
  How to deal with poorly informed customer choices

5 个答案:

答案 0 :(得分:2)

  我是错的说客户   不应该被允许改变   软件在他的意志?

谁拥有该软件?你或他们?

如果我拥有一所房子,如果我愿意的话,我可以雇佣一个人每周用不同的颜色来画它。如果画家抱怨,我可以得到一个新的画家。如果我没钱了,也许是因为我是个白痴。但画家在画我的房子,拿钱和用它养活他的家人时并没有错。

如果我拥有某个软件,我可以随心所欲地做任何事情。如果你不这样做,我会问别人。

答案 1 :(得分:2)

编辑:我最初错过了您拥有众多客户并为每个客户定制单个软件的部分。我将留下原始答案供参考,但它并不适用于这种特殊情况。

在您的情况下,我建议您需要一个不同的方法来解决客户关注的问题。我所看到的一种技术是,任何变化都需要与使产品对所有客户更有用的一致。这意味着您可以对许多更改说“是”。例如,通过模板使UI可自定义。这将使所有客户受益,但可能受到特定客户希望将外观融入其标准的愿望的驱动。但这也意味着你需要对某些请求说“不”,或者以一般化对所有人有用的方式修改它们。

您可能还希望让您的客户使用类似UserVoice的内容来制作功能(和错误)请求并对其进行投票。这允许您的客户直接输入产品的方向,但强制要求通过所有这些请求进行过滤。同样,您无需始终接受评分最高的请求,您可以接受一些评级较低的请求。指导原则应该是让您的产品对最广泛的客户有用。

我不认为为每个客户建立一个单独的自定义分支是不切实际的,除非您计划只有有限数量的高薪客户。最终,您的版本控制系统将成为您的瓶颈,不允许您的公司发展壮大,甚至不能为您当前的客户提供良好的服务。

一旦您进入更具可持续性的功能选择模式,我的原始答案仍然适用。希望这会有所帮助。

<强>原始

我会事先说一些顾客不值得拥有。只有你可以知道这种情况。

通常情况下,我们的工作是发现客户实际需要并提供的服务。我建议遵循敏捷开发方法来执行此操作。很少有客户真正了解他的需求。开发人员在开始编写代码之前,更不了解客户需要什么。敏捷方法接受这一现实,并遵循使变更不会对流程造成损害的实践。

首先,敏捷方法采用轻量级流程,并在最新的可能时刻之前推迟做出决策。有足够的“前期”规划来规划基本的架构框架,但在大多数情况下,它是设计即用。这并不像听起来那样自由,因为敏捷方法中使用的技术,如TDD,结对编程,重构等,都是鼓励良好设计和设计改进的合理技术。

其次,敏捷方法对文档很轻松。虽然没有文档,但这些方法可以将文档维护保持在最低限度。变化最糟糕的方面之一是文档变得过时,必须不断更新才能正确。敏捷方法识别那些真正有用并保持这些文档的文档,但是可以丢弃其他过时的文档。它们根据需要在当下使用,但您并不依赖它们。敏捷方法非常重视代码和测试,是自我记录的。

第三,敏捷方法鼓励基于相互信任的合作形式的发展。这有两个方面。客户必须相信您最关心自己的利益,同时您必须相信客户知道,或者至少可以在他看到时识别他需要的东西。

最后,敏捷的标志是提前发布,经常发布。及早将产品送到客户手中是获得他真正需要的反馈(同样,及早)的最佳方式。一旦你有了具体的产品,你就会开始获得真正重要的变化信息。通过计划尽早发布并经常发布,并将其与其他敏捷实践相结合,您还将构建一个框架,使更改更容易适应。

即使遵循这些方法,正如我之前所说:有些客户不值得拥有。如果您的客户在变更不好或客户不知道并且无法识别他真正想要的东西时不足以信任您,那么可能会有时间切断与您的联系。我建议和他们交谈,让他们知道你想让他们得到他们需要的东西,但他们需要知道那是什么。花一些时间谈论它,这样你们都能更好地理解目标,并采用敏捷方法来应对变化的现实。如果它们仍然不合理,那么也许它不适合你。

答案 2 :(得分:1)

指出应用程序与实施一样重要(更均匀)。给客户至少一个基线文档,UI模拟或类似的东西我认为是至关重要的。

随着系统的发展和成熟,你必须接受变更请求,否则系统将受到熵的影响,你所投入的任何辛勤工作都将永远丢失。如果它是更商业化的产品,请尝试并限制所有客户想要的更改。然后每个人都获得了附加价值。

如果您有基线文档,则可以收取定制费用。您想要进行自定义的次数越多,您收取的费用越多:P确保您记录并估算所有变更请求。 (我使用fogbugz,但还有许多其他工具)如果客户正在为更改付费,那么在tleat,您将因为更改系统的痛苦而被重新计算。

答案 3 :(得分:0)

贵公司无可救药地陷入困境。

你应该立即去找工作。

答案 4 :(得分:0)

在我提出我的建议之前,我应该说我个人认为有生意可以赚钱。因此,如果客户愿意为他们想要的东西付费,请弄清楚如何容纳他们(而不是将其转走)。

现在, 解决方案:

我在一家公司,他们有一个软件包,然后出售给许多政府机构 - 每个都有自己特定的调整和功能。

我问总经理他们如何避免版本地狱 - 考虑到他们必须为每个客户维护一个特定的版本。他说“我们不,每个人都得到相同的版本”。他们只是为所有客户端维护一个版本,但关闭了特定于客户端的功能。

  • LM