有人对如何管理 GUI 中的功能蔓延有任何实用建议吗？
我受到来自内部和外部来源的巨大压力，要求我添加、修改、调整等。当有人接近我说“如果……会不会很好？”时，我总是畏缩不前。我不能只是转身对他们大喊“不”，因为他们通常是我的上司或客户。
相反，我正在寻找建议来帮助解释为什么不断添加新功能是一个坏主意，并在此过程中管理他们对最终产品的期望。
TK
问问题
1543 次
28 回答
15
在正式流程中处理功能请求，通常通过项目经理和最初分析需求的人。将这些决定交给不是开发人员的人总是更好的做法，前提是无论谁来做这项工作实际上都有能力。
如果您是自由职业者，那么显然会对需求的更改收取费用，如果您是内部开发团队，那么您可以考虑跨部门计费，以确保人们考虑他们想要花钱的地方。
最后，预计需求会发生变化，特性会发生变化。如果您在编写代码时没有考虑可能会要求进行哪些更改，或者您的流程和/或截止日期如此不灵活，以至于您无法适应这一点，那么您会发现该项目将成为一场噩梦。
于 2008-09-17T13:10:06.977 回答
14
我所做的是将功能创意保留在索引卡上并将卡片张贴在可见的地方。当有人问，“它也可以做XXX吗？” 我写了一张新卡片。这是一个比尖叫“不！”更好的建立关系的举措。:-) 它还具有不会丢失潜在好主意的优点。OTOH，我当时没有强迫实施它。建议者知道他们已经被听取了，我知道我不会忘记，我可以重新开始工作，而且我们可以聚在一起，在比我的大脑在 CodeLand 时更好的时间做出优先级决定。
于 2008-09-17T14:05:39.310 回答
10
好吧，我将在这里成为敏捷的代言人。在该过程结束时无法解决问题，必须通过不同的项目管理来避免它。
除了特定的方法之外，诀窍是将这些决定交到客户手中。你有一份待办事项的清单。当他们想要更改该列表时，您询问他们列表中的哪个项目不会完成以容纳新项目。或者，他们会给你多少钱来处理它。
此外，您必须以小迭代（一周到一个月）的方式完成工作，以便他们有机会在其间重新调整。
我们使用 SCRUM，它很棒。经过几次迭代后，所有业务级别和流程级别的项目都得到了解决，您最终交付的正是他们想要的。
于 2008-09-17T13:24:54.400 回答
4
理想情况下，此类请求应由功能设计负责人处理。无论您喜欢与否，都会发生变化（从功能设计中的第一个字母到代码的最后一个字节等等），并且总会有对额外功能的要求。因此，请确保您的设计适合这样一个动态过程。
这可能听起来像是一个非常蹩脚的解决方案（我怀疑这是一个好的做法），但我过去一直在努力解决同样的问题。它发生在一家非常小的公司（管理层缺乏“层次”）的事实使情况变得更糟，因为我负责开发、功能设计、技术设计和管理我自己的项目。
对我有用的是将问题转移给提出问题的人（无论是上级还是客户）。交出功能设计、原型打印输出或任何描述当前情况的内容，并要求他们弄清楚应该“如何”和“在哪里”实现这个强大的新功能。
然后，上级和客户都“被迫”将其带回给自己的人，在会议上讨论等等。通常这意味着您没有第二次收到它的消息。在它确实出现的情况下，它实际上是一个有效的概念。
于 2008-09-17T13:12:50.077 回答
2
贵公司在开始项目之前似乎没有明确定义需求，这只会以泪水告终。
我的政策是提前清楚地细分所有要求，并让所有各方都知道违反这些要求的含义。
- 逐步延迟发布时间
- 增加的错误
- 不完整的功能
- 员工压力
- 员工辞职。
- 期望从最终产品中获得的额外费用比价格声明中商定的要多（这真的很糟糕）
如果他们不想坚持一个可持续且富有成效的系统，那么他们可能想要选择#5，或者以#5 威胁。
于 2008-09-17T13:13:30.637 回答
2
对于管理者：
- 产品越早投放市场（假设它是收缩包装），公司就能越早赚钱，现金流就越好。
- 不要完全排除新功能，而是要平衡它与你可以从做替代工作中获得的价值；解释机会成本。
为了所有人：
- 如果新功能在 UI 中呈现在您面前，请开始谈论视觉复杂性对整个产品的可用性以及吸引力的影响。但我相信你已经在这样做了。我会尝试挖掘一些参考资料...
于 2008-09-17T13:14:06.127 回答
2
恕我直言，最好的方法是明确概述实施新功能的成本。当用户开始看到此类添加的成本时，“如果”真的开始减少，那就太好了。
与客户对某项功能的不同意见通常会让你一事无成。如果你明目张胆地对他们说不，他们会感到疏远，与你和你的团队脱节。总体而言，该功能可能是一个好主意，因为您拥有世界上所有的时间和金钱，并且没有技术限制。在他们的世界里，在他们点击一个片段后能够在酒吧旁边看到一个fiz是一个好主意。当然，在我们的世界中，这意味着全表扫描、潜在的安全漏洞，以及确保它在下一个版本发布之前通宵达旦。
如果您为他们安排并解释为什么总体而言这不是一个好主意，他们通常会理解。不要忘记所有不同的因素（时间/金钱/增加项目复杂性的成本/推迟截止日期的风险）。一个通情达理的人会明白，如果你画得足够清楚，你至少可以对一个不通情达理的人说“我告诉过你”。
于 2008-09-17T13:16:27.680 回答
1
您不能只处理功能蠕变——您需要以适当的方式组织整个开发过程。
但是，根据您的描述，您似乎只是编写了其他人要求的代码，并且无法重新组织该过程。在这种情况下，您最好的方式是通过使用跟踪/票务系统来有效管理请求，该系统将允许您接收来自其他人的请求、对其进行优先级排序、估计它们、同意实施计划并跟踪您实际花在处理它们上的时间。
当您能够用现实世界的数据证明“这个小按钮”需要 2-3 天而不是 5 秒时，客户可能认为您应该处于更好的谈判位置。
如果您能够清楚地表明项目上线日期将由于新功能而延迟两周，您可能会看到这些请求完全消失。
但是，您必须记住，“功能蠕变”并不总是负面的。随着应用程序的成熟和增长，您的客户优先级也在发生变化。不承认这一点可能意味着您的成品将不是他们想要的。尝试检查他们是否会接受用尚未实现的原始规范中的旧功能交换新功能。
于 2008-09-17T13:16:49.927 回答
1
我保留了工作任务的优先列表，以及我对构建 X 中的内容的估计，以及我预计编写测试、实现代码和执行其他相关操作需要多长时间（粗略地说）。我总是听取他们的意见，讨论他们真正想要/需要的东西，并坚持让我们确定它在宏伟计划中的位置。我们谈论对日程安排和其他任务的影响。
它使沟通线路保持畅通无阻 - 没有任何意外，并且期望得到管理。最后，这不是我的程序——它是客户的（无论客户是谁），我想为他们建造他们想要（和需要）建造的东西。
于 2008-09-17T13:19:57.063 回答
1
关键似乎在问题中。
'管理特性蠕变'...您通过实施需要遵循的管理流程来做到这一点。你无法避免它（毕竟，经常是顾客要求它并且一直对他们大喊不，这往往会把这些可怜的生物赶走）......但这并不意味着它必须是无纪律的。有了一个程序，要求提出请求的人给出简单的事情，比如理由和对变更的初步调查/用例，你开始减少“这样做会不会很好”的数量。一旦你做到了这一点，你的特性蠕变就会得到管理，你可以开始确定优先级并提供更一致的反馈。
于 2008-09-17T14:30:41.480 回答
1
如果我们可以从 Internet 和 Web 2.0 之类的东西中吸取教训，那就是人们喜欢定制。这就是 iGoogle 和其他数百个网站的全部意义所在。如果您可以在 GUI 中进行自定义，那么您的客户很可能会因此而爱上您。
另外，看看其他项目如何成功地管理特性蠕变。例如，Google 允许用户提交功能请求，但也会显示已请求功能的列表。然后，用户也可以投票请求该功能。并不是说我很烂，而是看看stackoverflow.uservoice.com。他们有类似的政策。
听取用户的意见并获得他们的反馈至关重要。期待他们提出比你更好的新想法。期待他们提出你认为愚蠢的想法。如果有足够多的人想要它，而且看起来很合理，那就给他们想要的东西。
于 2008-09-17T14:49:41.777 回答
1
您的用户有很多没有得到照顾的需求。他们正在受苦。他们需要关注，他们需要你。我认为功能蠕变是在您尚未实现正确功能时发生的事情。
- 与您的用户建立密切的关系。让他们知道你总是对他们的意见感兴趣。定期给他们打电话，询问您的软件如何对待他们。
- 了解他们的工作习惯、标准做法、他们如何使用您的软件以及他们如何使用其他软件。当这些信息进来时，收集它。
- 当功能请求进来时，您的用户不会真正知道他们想要什么。但是，您知道他们想要什么，因为您拥有专业知识并且一直在倾听。因此，与他们一起澄清他们遇到的问题，然后使用您收集的知识尽可能概括问题。写一个解决这个问题的解决方案。
另一方面，“功能蔓延”通常是软件产品对不断发展的业务的反应。如果您的客户的业务正在增长，那么您很幸运，因为他们会在您的工作上花费更多的钱。所以放轻松，他们会付钱给你的！他们只需要明白，系统越大，更改就越困难，有时一个新的小功能需要进行大的重写，或者一个全新的用户界面，以保持一切顺利运行。
于 2008-09-17T15:22:09.640 回答
1
您必须小心平衡不愿避免功能蔓延与忽略功能请求和反馈的倾向。
每次用户向您提供反馈时，这都是改进您的产品和您的工作的机会。最终您可能会为用户和您的开发人员添加一些有趣的东西；工作实际上可能很有趣。是的，正如向您提出的那样，这可能是一个愚蠢的想法。但你的工作是接受反馈，从中提取任何积极的东西，并将其塑造成对你的用户、产品、公司和开发团队有价值的东西。
话虽如此，功能蠕变是一件非常难以管理的事情。而你管理它的程度取决于你的位置和“蠕变”是谁。如果您是中初级开发人员，并且 CEO 要求某个功能；好吧，您将添加该功能。你可以尝试让 CEO 相信这不是一个有价值的功能，或者它不起作用，或者有更重要的事情需要处理，或者它会对日程安排产生负面影响。但在请求该功能时，切勿这样做。你最终会得到的只是两个人捍卫自己的立场，而不是为了一个共同的目标而共同努力。
相反，立即接受反馈和功能请求（或功能需求）。走开，自己开诚布公地想一想。“这会很有价值吗？” “我在 CEO 要求的方式中遗漏了什么吗？” “有我说的那么难吗？” 问自己这些问题，并想出一些具体的答案。然后总是带着后续问题回到 CEO 那里。证明您已经考虑过请求的功能，并且实际上已经提出了一些想法、调整、增强或反对意见等。这将创建一个公开讨论。这是 CEO 没有预料到的，但他很可能不会反对，因为它最初并没有完全反对他的想法。
于 2008-09-17T17:49:23.123 回答
1
我们的一位财务支持者一直要求功能。有时他说我们可以让软件做'x'。如果可能的话，我们会告诉他是的，然后问他有什么时间表。如果他尽快回来 - 那么我们会告诉他其他一些功能将不得不放弃或延长我们的最后期限。值得庆幸的是，他通常会在未来的某个时间改变自己的观点。
我认为最重要的是实际记录想法或请求，即使该功能没有立即实施。
我们使用 Bugzilla 来跟踪错误 - 以及功能请求。我们有一个“功能”工作清单（或目标版本）...这样每个人都可以看到我们希望在未来开发哪些功能，并且随着人们对某个功能有更多想法，他们可以简单地在 bugzilla 中的项目中添加更多内容。
每次发布时，当我们坐下来制定版本的工作清单时，我们都会将脚趾伸入功能列表中，看看是否有任何可以引入的东西。我们确实会尝试在可能的情况下引入功能并向人们提供反馈 -这表明功能和想法并没有被置若罔闻。
这种反馈有助于人们知道我们正在承认他们的功能请求，并且我们确实可以实施它们，而不是仅仅坐在越来越大的列表上。
于 2008-10-21T14:08:12.183 回答
1
1) 增加发布前的时间。
2）成本增加。
3）指数维护成本
4）增加潜在的错误
为了管理功能请求，请他们提交变更单。定期审查变更单并就每个请求发回一份声明，“这将花费 X 长时间来完成，这意味着这 Y 额外费用。这可以接受吗？” 一旦请求者接受了额外的费用，那就没问题了。你的手已经洗过了。:)
于 2008-10-21T14:24:47.047 回答
1
你解释说“当然，这是可行的，你想估计它会推迟项目完成日期吗？另外，给你这个估计也会使项目结束时间增加大约一天。”
添加功能并没有错，只要利益相关者明白这样做是有成本的。
于 2008-10-21T14:28:33.093 回答
1
假设您构建的产品只有一个功能，并且所有 100 位客户都喜欢您的产品并发现它易于使用。现在假设您向产品添加了另外 10 个功能，只有 10 个客户会使用这些功能。现在您会发现 90% 的客户在使用您的产品时遇到了更多的麻烦，因为要做出的选择要多十倍，而您可以做的事情也多十倍，但对您无济于事。好东西已经在喧嚣中消失了。
这当然是一种简化，但现实情况是您的大多数用户只会使用您产品的一小部分功能。
阅读一些关于软件设计和 UI 设计的好书，并让你的经理也阅读它们。Joel Spolsky 的书籍是一个很好的起点 - www.joelonsoftware.com
于 2008-11-21T23:05:16.047 回答
0
创建定义需要解决的问题的工作任务。您的工作受限于只需要实施解决问题所必需的内容。
问题的任何进一步细化都将成为变更控制。
于 2008-09-17T13:08:29.010 回答
0
我们在我的办公室遵循线框。签核后的任何变更都必须通过变更控制程序。
于 2008-09-17T13:08:37.510 回答
0
在短时间内锁定功能集（Scrum/迭代/敏捷）。当用户开始看到东西在工作时，功能的必要性或缺乏性将变得更加明显。
此外，拥有一个能够带来所有变化的人是很有帮助的（在 Scrum 中，一个非常好的产品负责人）。
于 2008-09-17T13:14:13.380 回答
0
向他们展示简单的 GUI 是如何有效的。示例：Google Chrome，Apple 的软件。您可能还想展示臃肿软件的示例，如 Eclipse、Netbeans、Visual Studio……好吧，这些实际上都是软件 IDE，但它们都有杂乱的界面。
于 2008-09-17T13:14:54.517 回答
0
诀窍是将项目定义为一系列版本。您的初始设计是针对 2.0 版的，但预期的第一个版本是 1.0 版。欢迎所有新想法（功能），但由于时间安排，1.0 版被冻结，新想法必须进入 2.0 版。
当然，一旦 1.0 版发布，您就开始为 1.01 版的维护版本进行错误修复和编码等等……也许 2.0 版从未真正发布过，但它被用作难以捉摸的目标和功能的停车位很好，但还不足以延迟工作版本的发布。
于 2008-09-17T13:51:40.980 回答
0
要问的正确问题是“我怎样才能给开发人员一个稳定的环境，同时仍然只响应高收益的功能请求。” 类似 SCRUM 的方法是：
稳定的环境：
让开发人员在固定的小迭代间隔内处理一小部分固定的功能。
仅响应高收益功能请求：
一个人维护一个优先功能列表。总是可以添加新功能（减少很多政治）。然而，为下一次迭代选择的特征只是高优先级项目。
于 2008-09-17T13:58:26.470 回答
0
沟通是关键。在与客户的关系中，他们必须清楚，当创建具有一组功能的计划时，这就是一组功能。这只是那些与客户互动的人的错，他们要么误导了客户，要么以某种方式被客户吓倒了。
至于为特性蔓延做出贡献的开发人员，关键是在做出实施决策和直接添加新特性之间找到平衡。同样，定期与开发人员沟通可能会解决这里的问题。
于 2008-09-17T14:02:35.853 回答
0
可能无法避免所有功能请求。
但请尝试为每个功能请求分配成本。当下次计划会议或决定下一个版本的功能时，这将有助于清除不必要的功能。
于 2008-09-17T14:11:59.997 回答
0
如果您不是项目的经理或所有者，我会规定以下内容：
如果他们想要，就去做。确保他们在发薪日付钱给你。我了解到，有时为了让事情符合你的意愿而进行的战斗是不值得战斗的。享受生活，下班后并计划和编写以正确方式做事的个人项目。
于 2008-09-17T14:53:37.400 回答
0
您的问题的答案不仅仅是 GUI。当有人不注意合同规定的内容以及没有处理变更请求的正式流程时，总是会发生功能/范围蔓延。
如果您缺乏实施正式流程或影响其创建的能力，我建议您将所有功能更改请求记录在电子邮件中，并在电子邮件中通知您的管理层可能产生的后果。这不是为了得到任何人，而是为了保护自己免受最终失败的影响。
于 2008-09-17T15:02:46.863 回答
0
在某些时候，您必须运送一些东西。假设您正在经历某种正式的测试过程，只要产品继续变化，测试就永远无法在工作产品上签字。
它有助于提出一个时间表，描述将发布哪些功能以及何时发布。这样，推动新功能的人们就会知道他们的请求会得到处理。这并不意味着他们将立即得到处理，但它应该为他们提供一些保证，即下一个版本将解决他们的担忧。
于 2008-09-17T16:25:55.057 回答