如何处理对软件中荒谬功能的请求?[关闭]

一个好的软件设计师会抑制调用一个功能请求的滑稽。你必须相信你的直觉,但这只是一个很好的迹象,表明你想仔细考虑这个问题。

我建议一个简单的模型:

1. 试着理解实际问题是什么,而不是用户要求的解决方案。黄金设计规则” Don't discuss solution with the client, discuss requirements “。

2. 能够解释您认为所建议功能的问题所在。保罗·格雷厄姆有一个很好的作品叫做“ How to Disagree “。

这两个简单的步骤将帮助您和用户加深对实际问题的理解。没有用户,软件是没有意义的,我们大多数人依赖于用户为它付费。与用户一起工作,而不是以一种看似侮辱的态度疏远他们。

有些“荒谬”的特性请求根源于非常有趣和难以解决的问题。

总是把任何要求与金钱联系起来。提出这些要求的人通常更关心金钱,因此确保他们意识到这会使他们付出更多的代价,因为:

• 要花更长的时间
• 它可能会引入更多的bug
• 可能会减慢维护速度
• 它将减慢与之相关的新功能的开发

我发现“我们在第二阶段做这个好吗?”工作奇迹,可能有“我想我们可以管理没有它开始-让我们先得到一些东西出门”。

你选择的武器应该是 估计 . 荒谬的功能,通常带有荒谬的估计。什么时候? 必须具有功能X 得到一个3人一年的估计,它神奇地变成, 很高兴有功能X .

如果它是一个客户,并且在技术上是可以做到的,那么你就可以做到这一点,得到一份工作说明书——并且做到这一点。

如果这是你的工作,你做的和其他工作一样。你说,“是的,先生(或女士),我很乐意这样做。我也不介意这么做。我只是想让你知道这会对我们的其他系统或预算产生怎样的影响。不是说你错了,只是说也许我们应该考虑一下。这样可以吗?”

如果他们说不,那么,他们签了名,你就做了。如果你真的很担心,把你的谈话记录在没有听取建议的地方。 记住,如果你不把它记录下来,它就不会发生。 如果他们听了,你就赢得了一个朋友。

这对任何工作都是一样的-电脑,建筑工人,不管什么。

编辑:

我从下面的评论中获得了这一点:

没有人再看《星际迷航》了吗?记住,第一个会让皮卡德上尉知道任何错误,有时让-卢克会同意,有时他不会。我就是这么说的。

如果有多个请求,我会花时间礼貌地倾听,请他们优先考虑,并以书面形式提出请求,比如“已签署”或任何程序。然后告诉您的经理/客户,您将审查这些请求,并将评估结果和它对您的日程安排的影响反馈给他们。解释一下,为了生成这些数据,您需要花费x个小时(或天),因此您的其他工作将被延迟…

然后再回来估计-如果请求是荒谬的,那么您的估计很可能反映出这一点:—)

如果你的经理/客户想继续工作,浪费大量的时间和金钱,那么至少你已经提前把事情弄清楚了,而且你已经尽了你所能帮助他们。

如果可能的话,你应该要求他们把这些请求推迟到下一个阶段,建议你在下一个版本中考虑一下(我认为其他一些回复已经提到了这个想法)。

这些都是很好的答案。你需要硬数据(如果可能的话),“难以置信的荒谬”的估计,最重要的是尊重。

约翰尼的回答在本质上是正确的,如果不是在确切的话(我会评论,如果我建立了足够的代表)。不过,在某些情况下,使用这些确切的词语可能会造成足够的不一致,从而让请求者再次查看您的反对意见的内容。是的,这适用于 任何 基于项目的努力:软件,广告设计,甚至(喘息!)建设。不是说运送灰浆的咕噜声会有理由或影响反对有缺陷的设计,但施工负责人有义务告诉建筑师他的计划是否不可建造。

如果所有其他都失败了,请记录讨论并建立讨论。这不再是你的责任。

荒谬的功能请求在我回应时分为两个阵营。

1. 功能将导致应用程序按预期停止运行,即中断应用程序,使其速度过慢,使其无法工作。
2. 不会导致应用程序按预期停止运行的功能,但我不明白您为什么想要这样的功能

对于类型1,我将分析请求并以硬事实或专业意见作出响应。如果分析表明可能需要对现有代码进行额外的工作,那么估计并估计高!

对于类型2,首先我会要求请求者更详细地解释这个特性,毕竟它们可能在我对原始应用程序规范的问题空间之外没有清晰理解的业务领域中工作。如果我仍然没有理解它,并且我真的看不到这个特性的用途,那么我估计会很高,以阻止M

如果他们接受或者我接受,最后,得到它,然后我做。

一天结束的时候,他们是顾客,如果顾客走进裁缝店,要四条腿的裤子,裁缝可能会争论一段时间,但最后,这是一个定制的工作,而且要贵得多。所以,如果他们在这个特性中看到足够的价值,他们愿意付出,愿意接受他们的钱;仅仅因为你看不到这个价值并不意味着他们错了。

我认为您唯一能做的就是非常简洁地描述变更请求将带给相关人员的主要问题。在我工作的地方,我们和你有同样的问题。

一些更改请求迫使开发人员跳过这些循环,只是为了完成它,最后,它导致了一个功能的可维护性较低的代码,上楼的人认为这是一个好功能。

根据我的经验,你真的无能为力,最终管理层会开始抱怨开发需要多长时间等等。这是一个可怕的糟糕的周期,要么会在站点重建中结束,要么你的团队会在代码地狱中度过一段时间。

祝你好运。

我发现,大多数时候,要求不可能的人不知道为什么他们要求的是这样一个问题。

一般来说,我只是要求越来越多的澄清要求和越来越多的细节,直到:

• 一个灯泡亮在我的头上,我意识到他们想要的是什么,我可以说“啊,你真正想要的是x,而不是y”。在这一点上,他们通常会说“是的,这就是我一直在说的”。

• 他们意识到自己是多么不切实际,他们撤回了请求。

• 你们共同意识到这将是非常好的,但这是不可能的。通常,根据我的经验,这种情况的发生是因为你需要对一个大型的封闭源代码应用程序进行更改——在这种情况下,你只需要向供应商提出一个功能请求,这对于非技术人员来说比技术人员更令人满意;微软不会对Excel进行更改,因为一家小公司要求他们这样做!

客户创建的需求可能是这个问题的主要原因。问题是,客户有时会试图完成软件开发人员的工作。

他们有一个问题,然后找出他们将解决该问题的功能。不幸的是,这些可怜的灵魂中的一些人(大多数)并不擅长软件设计,因此在软件设计的最后你会得到一个非常奇怪的特性。

移除这些延迟特性的方法只是通过recursive.why()函数。一直问为什么,直到你发现他们的问题,然后自己设计这个特性。在许多场景中,您可以以简单、廉价和满足所有各方的方式重新设计它。

有时,似乎是一个荒谬的功能请求实际上是一个很好的请求。 有些时候,软件开发人员(我在过去也发现自己这样做了)会拒绝一个相当复杂但非常有用的特性 将 让公司赚大钱。所以当你遇到一个“荒谬”的特性时,一定要先计算出它对企业的潜在价值,然后立即将其抛弃。

有各种各样的“荒谬”。

• 太贵了 :我认为顾客需要的一定是值得花的钱
• 只是不必要的东西 :我试着解释客户不能使用它。如果他们仍然想要它,他们可以拥有它。
• 它与现有的概念相反 :这实际上是“太贵”的那种“买不起”。他们不会明白的。

我想讨论一下需求:—)

编辑:

典型的讨论

• 营销人员:在这张表的旁边,我们需要一个按钮来为选择提供函数x。
• 开发人员:但是我们需要函数x的附加参数p
• M:参数P很明显,很多情况下
• D:但是我们得报道 全部的 病例。我们需要提示P
• M:不!用户不喜欢被提示输入明显的值!他们只想“点击然后走”。
• D:在这种情况下是不可能的。我们需要提示。
• M:(随和)难道你猜不到吗?只有在真的需要的时候才提示吗?
• D:很难可靠地猜测。实际上需要几周甚至几个月的时间来实施,这是一个很高的风险。如果我们猜错了怎么办?为此我们需要人工智能。
• M:但这很简单:总是以防万一,布拉赫,我们知道P。
• D:是的,当然,但我们不知道用户知道什么。
• M:嗯,开发人员总是很复杂。
• D:…
• M:那么,你能不能做?
• D:没有。
• 为什么?
• D:(生气)我刚解释过。毕竟,如果用户真的想决定,你认为他喜欢系统猜测P吗?
• M:你只需猜测用户的决定。
• D:但是我在哪里知道呢?
• M:就是这种情况,布拉布拉赫……
• D:我知道,但事情并没有那么简单。
• M:好的,我去找项目负责人,他会给你一个任务。
• D:…

我们有时会收到产品经理的请求。

在一个案例中,我解释说会出现绩效问题,高级主管确认了这一点,所以我们赢了。

下一次我也提出了类似的问题,但是那个老家伙不在,所以我只是做了他们想要的,因为没有人真正关心。我也决定不去。

您的意思可能是向数据库发送一个多条件请求,显示结果,同时显示所有这些条件中的哪一个已命中。猜猜了吗?

• 有时,您可以解释为什么功能是荒谬的,功能被丢弃。

• 有时你可以让比你年长的人替你说“不”。

• 有时,你是资深的(或有影响力的)足以对自己说“不”。

• 有时你可以说“是”,但给任务一个低优先级(永远不要这样做)。

• 有时候你只需要继续下去。

在后一种情况下,您应该确保非常、非常好地完成任务。为什么?你会发光,当你这样做的时候,荒谬的阴影会被聚焦。