是否有人对如何管理GUI中的特征爬取有任何实用建议？

我受到来自内部和外部资源的巨大压力，要求它们进行添加，修改，调整等。当有人接近我时，"如果...会不会很好？"这句话总是让我感到畏缩。我不能只是转过头对他们大喊大叫，因为他们经常是我的上司或者顾客。

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

解决方案

回答

创建定义需要解决的问题的工作任务。工作仅需实施解决问题所需的约束。

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

回答

我们在我的办公室中使用线框。签核后的任何变更都必须经过变更控制程序。

回答

通常在项目经理和最初分析需求的人员之间，通过正式流程来处理功能请求。假设那些将要从事这项工作的人实际上有能力，最好将这些决策交给非开发人员。

如果我们是自由职业者，那么显然可以对需求的变更负责，并且如果我们是内部开发团队，则可以考虑跨部门计费，以确保人们考虑他们想要花多少钱。

最后，期望需求会发生变化并且功能会发生变化。如果我们在编写代码时没有考虑可能要进行的更改，或者流程和/或者截止日期过于灵活以至于无法对此进行调整，那么我们会发现该项目将成为噩梦。

回答

理想情况下，此类请求应由功能设计负责人处理。无论我们是否喜欢，都会发生更改(从功能设计的第一个字母到代码的最后一个字节，甚至更多)，并且总会要求提供其他功能。因此，请确保设计适合这种动态过程。

这可能听起来像是一个非常me脚的解决方案(我怀疑这是个好习惯)，但是过去我一直在努力解决相同的问题。由于我负责开发，功能设计，技术设计和管理自己的项目，因此它发生在一个很小的公司(管理层缺乏"层")的事实使情况变得更糟。

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

然后，上级和客户都被"迫不得已"将其带回自己的人民，在会议上讨论，什么都没有。通常，这意味着我们不会再收到它的消息。在确实出现这种情况的情况下，它实际上是一个有效的概念。

回答

在开始项目之前，公司似乎没有明确定义需求，而这只会以眼泪结束。

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

• 逐步延迟发布时间
• 错误增加
• 功能不完整
• 员工压力
• 员工辞职。
• 期望最终产品超出价格声明所商定的额外费用(这是真的很差)

如果他们不想坚持一个可持续和高产的系统，则可能要选择＃5或者威胁使用＃5.

回答

对于管理人员：

• 产品越早投放市场(假设它是收缩包装)，公司就能越早赚钱，现金流越好。
• 不要完全排除新功能，而应将其与我们从替代工作中获得的价值进行权衡；解释机会成本。

为了每一个：

• 如果新功能是用户界面中的现成功能，请开始讨论视觉复杂性对整个产品的可用性(以及由此带来的吸引力)的影响。但我确定我们已经在这样做了。我会尝试挖掘一些参考资料...

回答

在短时间内(Scrum /迭代/敏捷)设置了锁定功能。随着用户开始看到事物起作用，功能的必要性或者缺乏性将变得更加明显。

同样，让所有变更的人来帮助(在Scrum中，一个非常好的产品负责人)也很有帮助。

回答

向他们展示简单的GUI如何有效。例如：谷歌浏览器，苹果的软件。我们可能还想展示膨胀的软件示例，例如Eclipse，Netbeans，Visual Studio ...好的，这些实际上都是软件IDE，但是它们的界面都很混乱。

回答

恕我直言，最好的方法是明确概述实施新功能的成本。当用户开始看到这种添加的成本时，"如果真的开始减少"的话，那就太好了。

与客户就功能达成不同意见通常无济于事。如果我们对他们直言不讳，他们会感到疏远，并且与我们和团队失去联系。总的来说，此功能可能是个好主意，因为我们拥有全世界所有的时间和金钱，并且没有技术限制。在他们的世界中，单击片段后能够在酒吧旁边看到一个傻瓜是一个好主意。当然，在我们的世界中，这意味着要进行全表扫描，潜在的安全漏洞，以及通宵达旦的工作，以确保在下一个发行版发布之前都可以使用它。

如果我们为他们布置并解释为什么这不是一个真正好的主意，他们通常会理解。不要忘记所有不同的因素(时间/金钱/为项目增加复杂性的成本/延误期限的风险)。一个有理智的人会明白，如果你画得足够清楚，你至少可以对一个不合理的人说"我告诉过你"。

回答

我们无法仅以适当的方式来组织整个开发过程所需的特征爬取。

但是，从描述看来，我们只是在编码其他人的要求，而无法重新组织该过程。在这种情况下，通过导航/票务系统可以有效地管理请求，这是使我们能够接收来自其他人的请求，对其进行优先级排序，估算它们，同意实施时间表并跟踪实际花费在他们身上的时间的最佳方法。

当我们能够通过实际数字证明"这个小按钮"将需要2-3天而不是5秒的时间时，客户可能会认为应该可以更好地进行谈判。

如果我们能够清楚地表明由于新功能，该项目的上线日期将延迟两周，那么我们可能会发现这些请求完全消失了。

但是，我们必须记住，"特征蠕变"并不总是负面的。随着应用程序的成熟和增长，客户的优先级也在发生变化。不承认这一点可能意味着成品将不是他们想要的。
尝试检查他们是否会接受将尚未实现的原始功能的新功能换成原来的功能。

回答

我保留了一份优先的工作任务清单，并估算了构建X中的内容以及我期望它花多长时间(粗略地说)来编写测试，实现代码以及执行其他任何相关工作。我总是吸收他们的意见，讨论他们真正想要/需要的东西，并坚持要求我们确定它在总体规划中的位置。我们谈论对时间表和其他任务的影响。

它使通讯线路畅通无阻，没有任何意外，期望得到了管理。最后，这不是我的程序，而是客户(无论客户是谁)的程序，我想按他们想要的(和需要的)构建它们。

回答

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

除了特定的方法外，技巧还在于将这些决策交到客户手中。我们有要做的事情清单。当他们想要更改该列表时，我们问他们将无法完成列表中的哪个项目以容纳新项目。或者，他们会给我们多少钱来处理。

另外，我们必须进行小规模的迭代(一周到一个月)，以便他们有机会在两者之间进行调整。

我们使用SCRUM，它很棒。经过几次迭代，所有业务级别和流程级别的项目都得到了解决，最终我们将准确地交付他们想要的东西。

回答

诀窍是将项目定义为一系列版本。初始设计是针对版本2.0的，但是，预期的第一个发行版是版本1.0。所有新的想法(功能)都受到欢迎，但是由于调度的缘故，版本1.0被冻结，因此新想法必须进入版本2.0。

当然，在1.0版发布后，我们便开始为1.01版的维护版本进行错误修复和编码，以此类推...也许2.0版从未真正
被释放，但被用作难以捉摸的目标和功能的停车位
很好，但不足以延迟发布工作版本。

回答

正确的问题是："我如何才能给开发人员一个稳定的环境，同时仍然仅对高收益功能请求做出响应。"像SCRUM的方法是：

稳定的环境：

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

仅响应高收益功能请求：

一个人维护着优先功能列表。总是可以添加新功能(减少很多政治因素)。但是，为下一次迭代选择的功能仅是高优先级项。

回答

沟通是关键。在与客户的关系中，对他们必须清楚，当创建具有一组功能的计划时，即一组功能。与客户互动的人的过错只是误导客户或者被客户吓倒。

对于有助于功能爬升的开发人员，关键是要在实施决策和直接添加新功能之间找到平衡。同样，定期与开发人员进行交流很可能会在这里解决问题。

回答

我要做的是将功能性想法保留在索引卡上，然后将其张贴在可见的地方。当有人问："它也可以做XXX吗？"我写一张新卡。与尖叫"不！"相比，这是一种更好的建立人际关系的举措。 :-)它还具有不会丢失潜在好主意的优点。 OTOH，我现在不强制实施它。推荐人知道他们已经听过，我知道我不会忘记，我可以重新工作，而且我们所有人都可以在一起做出优先决策，这比我的大脑处于CodeLand时更好。

回答

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

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

回答

关键似乎在问题中。

"管理功能蔓延" ...我们通过实施需要遵循的管理流程来做到这一点。我们无法避免(毕竟，通常是客户要求它，并且一直对他们大喊大叫会把可怜的生物赶走)……但这并不意味着它必须不受纪律。有了一个程序，该程序要求请求者提出简单的要求，例如辩解和变更的初步调查/用例，那么我们开始减少"不愿意这样做"的次数。完成此步骤后，就可以管理功能爬取，并且可以开始确定优先级并提供更一致的反馈。

回答

如果有一个教训，我们可以从Internet和Web 2.0中学到东西，那就是人们喜欢定制。这就是iGoogle和其他数百个网站的目的。如果我们可以在GUI中内置自定义项，那么客户很可能会因此而爱上我们。

此外，请看一下其他项目如何成功管理要素蠕变。例如，Google允许用户提交功能请求，但还显示已请求的功能列表。然后，用户也可以投票要求该功能。并不是说我很烂，但是请看一下stackoverflow.uservoice.com。他们有类似的政策。

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

回答

如果我们不是该项目的经理或者所有者，我将规定以下内容：

如果他们想要它，那就去做。确保他们在发薪日向我们付款。我了解到，有时候使事情符合意愿的战斗是不值得的。下班后享受生活，规划和编码自己的个人项目，以正确的方式做事。

回答

问题的答案不仅限于GUI。当某人没有注意合同中规定的内容以及没有正式的流程来处理变更请求时，功能/范围就会不断发生。

如果我们缺乏实施正式流程或者影响其创建的能力，建议我们将所有功能更改请求记录在电子邮件中，并通过电子邮件将可能的后果通知管理层。这并不是要得到任何人，而是要保护自己免受最终失败的影响。

回答

用户有很多需要照顾的需求。他们正在受苦。他们需要关注，他们需要我们。我认为，如果我们尚未实现正确的功能，就会发生功能蠕变。

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

另一方面，"功能蠕变"通常是软件产品对不断发展的业务的响应。如果客户的业务在增长，那么我们很幸运，因为他们会在工作上花费更多的钱。放轻松，他们会付钱给我们！他们只需要了解，系统越大，更改的难度就越大，有时新的小功能需要进行大的重写，或者需要全新的用户界面，以使一切平稳运行。

回答

在某个时候，我们必须运送一些东西。假设我们正在经历某种形式的正式测试过程，只要产品继续更改，测试就永远无法在可用的产品上签字。

它有助于提出一个时间表，描述将发布哪些功能以及何时发布。这样，推动新功能的人们便有了一些想法，即他们的请求将得到处理。这并不意味着现在就可以解决它们，但是应该向他们保证，下一个版本可以解决他们的问题。

回答

我们必须谨慎地权衡不愿避免特征蠕变和忽略特征请求和反馈的趋势。

每当用户向我们提供反馈时，这都是改善产品和我们正在从事的工作的机会。可能最终我们为用户和开发人员都添加了一些有趣的东西。进行工作实际上可能很有趣。是的，这对我们来说可能是一个愚蠢的主意。但是，工作是接受反馈，从反馈中提取任何正面信息，并将其塑造成对用户，产品，公司和开发团队有价值的东西。

话虽这么说，特征蠕变是一件非常困难的事情。我们如何管理它取决于职位以及谁是"蠕变"的人。如果我们是中级开发人员，并且CEO要求提供功能；好，我们将要添加该功能。我们可以尝试说服首席执行官，这不是一项有价值的功能，或者它将无法正常工作，或者还有更多重要的工作要做，或者会对计划产生负面影响。但是在请求功能时绝对不要做任何事情。最后，我们将只有两个人捍卫自己的立场，而不是为实现共同的目标而共同努力。

取而代之的是，立即以票面价值接受反馈和功能请求(或者功能需求)。走开，独自一会儿公开考虑一下。 "这有价值吗？" "我是否想像CEO要求的方式吗？" "难道就像我说的那样难吗？"问问自己这些问题，并提出一些具体答案。然后，请务必向CEO提出后续问题。证明我们已经考虑了所需的功能，并且实际上提出了一些想法，调整，增强或者反对意见等。这将引起公开讨论。 CEO没想到，但是他很可能不会反对，因为最初并不是完全反对他的想法。

回答

我们的一位财务支持者一直在要求功能。有时他说我们可以让软件执行" x"操作。如果可能的话，我们告诉他是，然后问他考虑的时间表是什么。如果他尽快回来，那么我们告诉他，其他一些功能将不得不给予或者延长我们的截止日期。值得庆幸的是，他通常会将自己的观点改变为将来的某个时候。

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

我们使用Bugzilla来跟踪错误以及功能请求。我们有一个"功能"工作清单(或者目标版本)...这样，每个人都可以看到我们将来要开发的功能，并且随着人们对某个功能有更多的想法，他们可以简单地在bugzilla中添加更多功能。

每次发布时，当我们坐下来制定版本的工作清单时，我们都会将脚趾伸入功能列表中，以查看是否有可以引入的功能。我们会尽力提供功能，并将反馈反馈给人们。表明功能和思想并未落入耳聋。

该反馈有助于人们知道我们已经确认了他们的功能要求，并且我们确实会实施它们，而不是仅仅将它们放在越来越大的清单上。

回答

1)增加发布前的时间。

2)成本增加。

3)指数级维护成本

4)增加了潜在的错误

为了管理功能请求，请他们提交变更单。定期检查变更单，并发送回有关每个请求的声明，"这将花费X长时间，这意味着Y的额外费用。这可以接受吗？"一旦请求者接受了额外费用，就可以了。你的手被洗净了。 :)

回答

我们解释说："当然，这是可行的，我们是否希望对完成项目的日期进行估算？而且，给我们提供的估算结果也将使项目结束增加大约一天的时间。"

只要利益相关者了解到这样做会带来一定的成本，添加功能就没有错。

回答

假设我们构建的产品仅具有一项功能，并且所有100位客户都喜欢产品，并且发现它易于使用。现在假设我们向产品添加了另外十个功能，只有十个客户会使用。现在，我们会发现90％的客户在使用产品时遇到了更多麻烦，因为选择的余地增加了十倍，而我们能做的十倍无法解决的事情。好东西已经在噪音中流失了。

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

阅读一些有关软件设计和UI设计的好书，并让经理也阅读它们。 Joel Spolsky的书是开始www.joelonsoftware.com的好地方