管理GUI中的功能蠕变

Question

有没有人对如何在GUI中管理功能蠕变有任何实际建议？

我受到来自内部和外部来源的强大压力，无法添加，修改，调整等等。当有人接近我时，我总是畏缩，“如果......会不会很好？”。我不能只是转过身来对他们大喊“不”，因为他们往往是我的上级或客户。

相反，我正在寻找建议，以帮助解释为什么不断添加新功能是一个坏主意，并在此过程中，管理他们对最终产品的期望。

Answer 1

在正式流程中处理功能请求，通常是通过项目经理和最初分析需求的人员。将这些决定交给不是开发人员的人总是更好，假设任何打算做这项工作的人实际上都有能力。

如果您是自由职业者，那么显然需要更改要求，如果您是内部开发团队，那么您可以考虑部门间结算，以确保人们考虑他们想要花钱的内容。

最后，期望要求改变并发生蠕变。如果您在不考虑可能要求更改的情况下进行编码，或者您的流程和/或截止日期非常不灵活以至于无法适应这种情况，那么您会发现该项目将成为一场噩梦。

Answer 2

我所做的是将索引卡上的功能想法保留在可见的地方。当有人问：“它还可以做XXX吗？”我写了一张新卡。这是一个更好的关系，建立行动而不是尖叫“不！” :-)它还具有不丢失潜在好主意的优势。 OTOH，我当时没有强制执行它。建议者知道他们已经被倾听，我知道我不会忘记，我可以重新开始工作，而且我们可以聚在一起，在比我的大脑在CodeLand中更好的时候做出优先决定。

Answer 3

那么，我会在这里成为敏捷的声音。在该过程结束时无法解决问题，必须通过不同方式管理项目来避免这个问题。

除了特定的方法之外，诀窍是将这些决定交到客户手中。您有一系列要做的事情。当他们想要更改该列表时，您会询问他们列表中的哪个项目无法完成以容纳新项目。或者，他们会给你多少钱来处理它。

此外，你必须在小的迭代（一周到一个月）内完成这项工作，这样他们就有机会在两者之间重新调整。

我们使用SCRUM，它很棒。经过几次迭代后，所有业务级别和流程级别的项目都会得到解决，并且您最终会提供他们想要的内容。

Answer 4

理想情况下，此类请求应由功能设计负责人处理。无论你喜欢与否，都会发生变化（从功能设计的第一个字母到代码的最后一个字节以及更远），总会有额外功能的请求。因此，请确保您的设计适用于这样一个动态过程。

这可能听起来像是一个非常蹩脚的解决方案（我怀疑这是一个好习惯），但我过去一直在努力解决同样的问题。事实上，它发生在一个非常小的公司（管理层缺乏“层次”）使事情变得更糟，因为我负责开发，功能设计，技术设计和管理我自己的项目。

对我有用的是将问题转移回询问的人（无论是上级还是客户）。移交功能设计，原型打印输出或描述当前情况的任何内容，并要求他们弄清楚应该如何实现这个强大的新功能的“如何”和“在哪里”。

然后，上司和客户都被“强迫”将其带回自己的人，在会议中讨论等等。通常这意味着你第二次没有收到它。在它出现的情况下，它实际上是一个有效的概念。

Answer 5

在启动项目之前，您的公司似乎没有明确定义要求，而这只会以泪流满面。

我的政策是提前明确所有要求的细分，并让所有各方了解侵入这些要求的含义。

1. 逐步延迟发布时间
2. 增加错误
3. 功能不完整
4. 员工压力
5. 员工辞职。
6. 期望更多的最终产品的额外费用超过了在宣布价格时达成的协议（这真是太糟糕了）

如果他们不想坚持一个可持续和富有成效的系统，人们可能会选择＃5，或者威胁＃5。

Answer 6

对于经理：

• 产品越早上市（假设它是收缩包装），公司越早赚钱，现金流就越好。
• 不要完全排除新功能，但要将其与您从替代工作中获得的价值进行平衡;解释机会成本。

适合所有人：

• 如果新功能在用户界面中面对面，请开始讨论视觉复杂性对整个产品的可用性 - 以及从中，吸引力 - 的影响。但我相信你已经这样做了。我会尝试挖掘一些参考文献......

Answer 7

恕我直言的最佳方式是清楚地概述实施新功能的成本。 “当用户开始看到这种增加的成本时，真的开始减少会很好。

与客户就某项功能不同意通常无处可寻。如果你对他们说不，他们就会感到与你和你的团队疏远和失去联系。该功能可能总体上是一个好主意，因为您可以拥有世界上所有的时间和金钱，并且没有技术限制。在他们点击剪辑之后能够在栏旁边看到 fiz 的世界是一个好主意。当然，在我们的世界中，它意味着全表扫描，潜在的安全漏洞，以及在下一个版本发布时确保它进入的所有黑客。

如果你为他们安排并解释为什么这不是一个非常好的想法，他们通常会理解。不要忘记所有不同的因素（增加项目复杂性的时间/金钱/成本/滑倒期限的风险）。一个合理的人会理解你是否画得足够清楚，你至少可以对一个不讲理的人说“我告诉过你”。

Answer 8

假设您构建的产品只有一个功能，并且您的所有100位客户都喜欢您的产品，并且发现它易于使用。现在假设您为产品添加了十个功能，只有10个客户会使用这些功能。现在您会发现90％的客户在使用您的产品时遇到的问题要多得多，因为要做出的选择要多十倍，而您可以做的事情要十倍，这对您没有帮助。好的东西已经在噪音中丢失了。

这当然是一种简化，但实际情况是，大多数用户只会使用产品的一小部分功能。

阅读一些关于软件设计和UI设计的好书，让经理也阅读它们。 Joel Spolsky的书籍是一个很好的起点 - www.joelonsoftware.com

Answer 9

如果有一个教训，我们可以从互联网和Web 2.0的各种东西中学习，那就是人们喜欢定制。这就是iGoogle和其他数百个网站的全部内容。如果您可以在GUI中构建自定义，那么您的客户很可能会爱上它。

另外，看看其他项目如何成功管理功能蠕变。例如，Google允许用户提交功能请求，但也会显示已请求的功能列表。然后，用户也可以投票以请求该功能。不是说我是个傻瓜，而是看看stackoverflow.uservoice.com。他们有类似的政策。

倾听用户并获得他们的反馈至关重要。期待他们提出比你更好的新想法。期待他们提出你认为愚蠢的想法。如果有足够的人想要它，并且看起来合理，那就给他们想要的东西。

Answer 10

关键似乎是问题所在。

'管理功能蠕变'...您可以通过实施需要遵循的管理流程来实现这一目标。你无法避免它（毕竟，经常是客户要求它并且不断地对它们大喊大叫往往会驱使可怜的生物离开）......但这并不意味着它必须是无纪律的。有了一个程序，要求提出请求的人提供简单的事情，如理由和初步调查/用例的变化，你开始减少'不会很好'的数量。一旦实现了这一功能，您的功能蠕变就会得到管理，您可以开始确定优先级并提供更一致的反馈。

Answer 11

您的用户有很多不需要处理的需求。他们正在受苦。他们需要注意，他们需要你。我认为当你没有实现正确的功能时会发生功能蠕变。

• 与您的用户建立密切的关系。让他们知道你总是对他们的意见感兴趣。定期给他们打电话，询问你的软件是如何对待他们的。
• 了解他们的工作习惯，标准做法，他们如何使用您的软件以及他们如何使用其他软件。当信息进来时，请收集它。
• 当功能请求进入时，您的用户将无法真正知道他们想要什么。但是，你知道他们想要什么，因为你有专业知识并且你一直在倾听。因此，与他们合作澄清他们所遇到的问题，然后使用您收集的知识尽可能地概括问题。编写一个解决 问题的解决方案。

另一方面，“功能蠕变”通常是软件产品对不断发展的业务的响应。如果您的客户的业务正在增长，那么您很幸运，因为他们会在您的工作上花更多的钱。所以放松一下，他们会付你的！他们只需要了解这一点，系统越大，更改就越难，有时新的小功能需要大量重写或全新的用户界面，以保证一切顺利运行。

Answer 12

你必须小心平衡不愿意避免特征蠕变的倾向，以及忽略特征请求和反馈的倾向。

每当用户向您提供反馈时，您就有机会改进产品以及您正在开展的工作。最终您可能会向用户和开发人员添加一些有趣的内容;工作实际上可能很有趣。是的，这可能是一个愚蠢的想法，对你构成。但是你的工作就是接受反馈，从中提取任何积极的信息，并将其塑造成对用户，产品，公司和开发团队有价值的东西。

话虽如此，功能蠕变是一件非常难以管理的事情。你如何管理它取决于你的位置和“蠕变”是谁。如果你是一名中级到初级的开发人员，那么首席执行官就要求提供一项功能;好吧，你将要添加该功能。您可以尝试说服首席执行官，这不是一个有价值的功能，或者它不起作用，或者有更重要的事情需要处理，否则会对时间表产生负面影响。但是在请求功能时从不做任何这样的事情。你最终得到的只是两个人捍卫自己的位置，而不是共同努力实现共同目标。

相反，请立即接受面值的反馈和功能请求（或功能需求）。走开，自己一会儿公开考虑一下。 “这有价值吗？” “我是否错过了首席执行官要求的方式？” “它和我要成功一样难吗？”问自己这些问题，并提出一些具体的答案。然后始终回到首席执行官并提出后续问题。证明您已经考虑了所要求的功能，并且实际上已经提出了一些想法，调整，增强或异议等。这将创建一个公开的讨论。首席执行官没有预料到，但他很可能不会反对，因为它最初并非完全抵制他的想法。

Answer 13

我们的一位财务支持者一直要求提供功能。有时他说我们可以让软件做'x'。如果有可能我们告诉他是，然后问他有什么时间表。如果他尽快回来 - 那么我们告诉他其他一些功能必须给予或延长我们的截止日期。值得庆幸的是，他通常会在将来的某个时候改变他的意见。

我认为最重要的是实际记录这个想法或请求，即使该功能没有立即实施。

我们使用Bugzilla来跟踪错误 - 还有功能请求。我们有一个“功能”工作清单（或目标版本）......这样每个人都可以看到我们希望在未来开发哪些功能，并且随着人们对功能的更多想法，他们可以简单地在bugzilla中添加更多项目。

每当我们坐下来制定工作清单的版本时，我们都会将我们的脚趾放入功能列表中，看看是否有任何我们可以提取的内容。我们会尽力提供功能并提供反馈对人们而言 - 这表明特征和想法并没有被置若罔闻。

这种反馈有助于人们知道我们正在承认他们的功能请求，我们会全面实施它们，而不是只是坐在一个越来越大的列表上。

Answer 14

我保留了工作任务的优先级列表以及我对构建X中的内容的估计以及我希望它编写测试，实现代码以及执行其他相关操作所需的时间（粗略地说）。我总是接受他们的意见，讨论他们真正想要/需要的东西，并坚持我们确定它在宏观方案中的适用范围。我们谈论对计划和其他任务的影响。

它保持通信线路畅通无阻 - 没有任何意外，并且期望得到管理。最后，它不是我的程序 - 它是客户（无论客户是谁），我想建立他们想要（和需要）构建的。

Answer 15

您无法处理功能蠕变 - 您需要以适当的方式组织整个开发过程。

但是，根据您的描述，您似乎只是编码其他人要求的内容，并且无法重新组织该过程。在这种情况下，通过设计跟踪/票务系统来有效管理请求的最佳方式是允许您接收来自其他人的请求，确定优先级，估计它们，同意实施计划并跟踪您实际花费在其上的时间。

当你能够用现实世界的数据证明'这个小按钮'需要2-3天而不是5秒时，客户可能会相信它应该会更好地进行谈判。< / p>

如果您能够清楚地显示项目上线日期将因为新功能而延迟两周，您可能会看到这些请求消失。

你必须记住，'特征蠕变'并不总是负面的。随着应用程序的成熟和发展，您的客户优先级也在不断变化。没有承认这可能意味着您的成品将不是他们想要的。 尝试检查他们是否会接受原始规范的旧功能交易，但尚未实施。

Answer 16

1）释放前增加时间。

2）成本增加。

3）指数维护成本

4）增加了漏洞的可能性

要管理功能请求，请他们提交变更单。定期检查变更单并发回有关每个请求的声明，“这将需要X很长时间，这意味着这个Y额外成本。这可以接受吗？”一旦请求者接受了额外的费用，那就没问题了。你的手洗了。 ：）

Answer 17

你解释“确定，这是可行的，你想估计它将推动项目完成日期的数量吗？另外，给你这个估计也会增加项目结束的一天。”

添加功能没有任何问题，只要利益相关者明白这样做会产生成本。

Answer 18

在某些时候，你必须运送东西。假设您正在经历某种形式的测试过程，只要产品不断变化，测试就无法在工作产品上签字。

有助于提出一个时间表，描述将要发布的功能以及何时发布。这样，推动新功能的人们就会知道他们的请求将被处理。这并不意味着他们现在就会被处理，但它应该让他们有一些保证，下一个版本将解决他们的担忧。

Answer 19

沟通是关键。在与客户的关系中，他们必须清楚，当使用一组功能创建计划时，即一组功能。这只是与客户互动的人的错，他们要么误导客户，要么被客户以某种方式吓倒。

对于有助于功能蔓延的开发人员来说，关键是在实施决策和直接添加新功能之间找到平衡点。再次，定期与开发人员沟通可能会在这里引发一个问题。

Answer 20

您的问题的答案比GUI更广泛。当某人没有注意合同规定的内容以及没有正式的处理变更请求的过程时，特征/范围蔓延总是会发生。

如果您无法实施正式流程或影响其创建，我建议您获取电子邮件中记录的 所有 功能更改请求，并通知您的管理层电子邮件中可能产生的后果。这不是为了获取任何人，而是为了保护自己免受最终失败的影响。

Answer 21

如果您不是该项目的经理或所有者，我会开出以下规定：

如果他们想要，就去做吧。确保他们在发薪日付款。我已经了解到，有时候让事情符合你想要的东西的战斗，不值得战斗。享受生活，下班后和计划＆amp;编写你自己的个人项目，以正确的方式做事。

Answer 22

可能无法避免所有功能请求。

但请尝试为每个功能请求分配费用。当下一次计划会议或决定下一个版本的功能出现时，这将有助于清除不必要的那些。

Answer 23

创建定义需要解决的问题的工作任务。只需要实现解决问题所必需的工作就可以限制你的工作。

然后，问题的任何进一步细化都将成为变更控制。

Answer 24

要问的正确问题是“如何为开发人员提供稳定环境，同时仅响应高优势功能请求。”类似SCRUM的方法是：

稳定的环境：

让开发人员在一个小的固定迭代间隔期间处理一组固定小功能。

仅响应高效益功能请求：

一个人维护一个优先级功能列表。新功能可以始终添加（减少许多政治）。但是，仅为下一次迭代选择的功能是高优先级项目。

Answer 25

诀窍是将项目定义为一系列版本。您的初始设计适用于2.0版，但预期的第一个版本是1.0版。欢迎所有新的想法（功能），但由于时间安排，版本1.0被冻结，新的想法必须进入2.0版本。

当然，只要版本1.0发布，就会开始修复1.01版本的维护版本并进行编码等等......也许版本2.0实际上从未实际 获得释放，但被用作难以捉摸的目标和功能的停车位 这很好，但还不足以推迟发布工作版本。

Answer 26

显示他们简单的GUI如何有效。示例：Google Chrome，Apple的软件。您可能还想展示膨胀软件的示例，例如Eclipse，Netbeans，Visual Studio ......好吧，这些实际上都是所有软件IDE，但它们都有混乱的界面。

Answer 27

锁定功能设置为短时间帧（Scrum / iteration / agile）。当用户开始看到工作时，功能的必要性或缺乏将变得更加明显。

此外，让一个人通过所有变化来做是有帮助的（在Scrum中，一个非常好的产品负责人）。

Answer 28

我们在办公室里跟随线框。签收后的任何更改都必须通过变更控制程序。