当客户在交付时的响应为否定时,如何作出反应?[闭门]

您应该如何避免这种情况:

明确说明将包括哪些内容和不包括哪些内容。

问题可能归结为规范中未指定的部分:

• 客户认为未指明的东西应该在里面,也就是说是暗示的。
• 开发人员认为不应该使用未指定的内容。

对于您拥有的未来规范,您应该有一个catch-all语句,该语句明确指出,如果本文档中未指定某些内容,则可以在完成原始规范后以额外成本完成。

在当前情况下,您应该做什么:

示例:我将使用您认为是常识的功能,但对于所有未来的添加/更改,必须明确指定它。

也就是说,你将不得不做更多的工作,但这是值得的,作为回报,你的客户将签订全面明确的协议。

这一定是一个糟糕的规范吗?不

不可能提及您的客户可能期望的所有内容,因此在您的规范/合同中清楚明确地说明上面提到的全面声明是至关重要的。

减少问题的其他方法:

• 尽早让客户参与,向他们展示早期原型。即使他们不要求。
• 考虑一个敏捷开发模型或类似的东西,这样任务就被定义好了,小的,付费的,无可争议的。

这可能是我改用英语的众多原因之一 Agile development 哲学在我看来,成功避免这种情况的唯一方法是全知全能或让客户大量参与,并尽早发布/经常发布,以尽快获得反馈。这样,您就可以开发客户真正想要的软件,而不是客户告诉您他们想要的软件。

客户:

美国: 不在规格中!

客户: 常识!!

美国: 我们不会试图超出客户指定的范围-我们遵循规范。不实现未指定的功能与实现指定的功能一样重要。我们绝不会怀疑我们的客户,他们重视这样一个事实,即他们完全可以依靠我们按时、在预算内正确、完整地实施规范。

正如其他人非常正确地指出的那样,情况几乎总是比我上面描述的简单交换更复杂。

但是,如果你有一份合同和一份规范,而客户已经看到并签署了这两份文件,那么他们就没有回旋的余地要求你更进一步。

令人惊叹的 抱怨实现该功能,称之为“免费”(确保他们理解你在规范和合同之外工作,并明确向他们发送一份工作账单,以美元显示折扣),并让他们在整个项目上签字。

它将明确表明项目已经结束,你超越了职责范围,任何进一步的“惊喜”都超出了合同/规范的范围,这为你提供了一个良好的保护层,超越了你已经(表面上)拥有的。

如果这是一个用户界面问题,那么你的处境就更不明朗了。

无论哪种方式,我认为你都可以理解客户的立场——如果他们没有使用UI模型,那么不管结果如何,他们都会对结果感到失望——从心理上讲,你和你的客户不可能有相同的想法(尽管常识不是这样的事实!)。

坦率地说,如果这是客户第一次考虑在工作完成之前检查UI,那么至少部分原因是您没有向他们解释好的UI设计过程。这是他们的应用程序的一个关键特性,它与他们的想象紧密结合在一起——在这种情况下,没有人会感到满意,除非他们随着时间的推移“成长”了自己的内部表现,以符合现实。

这种脱节只有通过频繁的用户和客户测试才能解决,这显然是缺失的。这是关于客户教育和沟通的问题,而不是是否符合规范。

-亚当

• 经常与客户一起检查进度,以尽量减少意外。

• 合同:功能规格,加上时间和;带有初始封盖的材料(以便客户感觉得到控制)。

• 总是 比他们要求的多一点,让他们知道你的态度是积极的。

经典案例。。。

当然,你不能免费重做整件事。

有两种方法:或者叫他们走开,或者由你来处理。

• 首先,同情、尊重客户。
• 看看什么是容易改变的。
• 也许可以建立一个新的协议。
• 不要做太多。
• 让他们看到进展和需要做的工作。
• 找到缺失功能的解决方法(可能使用其他优秀功能或可用工具)

用你的常识来说,这很平常,一点也不好笑。

这是固定投标安排的诸多缺点之一。任何时候,业务需要或优先事项发生变化,甚至出现一个简单的误解,都会导致任何事情,从这样的尴尬局面到请律师。如果您有一个为开发时间付费的安排,那么您可以随时对任何更改做出反应,并为做出更改所需的任何时间付费。此外,按小时安排并不妨碍制定计划或作出估计。

但是,一旦您陷入固定出价困境,您的选择是: 1) 这样做需要额外的费用。 2) 免费做。 3) 不要这样做。

方案3最差,方案1最好。如果你与客户有良好的信任关系和良好的沟通,通常很容易达成选择1。如果关系不好,那么你就有更大的问题。在这一点上,只要尽量避免外行。

祝你好运

“你的反应如何?”

问题1-您想继续与该客户的关系吗?认真地如果他们声称未指明的特征是“常识”,那么这可能不是一个好的关系来维持或加强。

如果你想参与,那么,你必须改变这种关系。目前,您有一个消极进取的客户。他们不会说他们想要什么,但他们会说他们不想要的。

这可能是他们的习惯;这可能就是他们赢得让步的方式。或者,这可能只是他们方面的草率规范。

如果你想要这种关系,你的反应有两部分。

1. • 有些东西既便宜又合身。做那些。
   • 那些(不幸的)符合规格的昂贵的东西是个问题。你有麻烦了,而且几乎不得不这么做。

嗯,它没有成功交付。在这条线路的某个地方出现了沟通错误。在不了解细节的情况下,我建议这不是开发人员注入的问题,这可能不应该归咎于客户-需求收集任务不够。这是一个典型的例子,说明了当软件方面没有领域专家,或者需求发现过程没有尽其所能。。。

您如何处理这一点可以很好地决定与客户的合同/业务的未来。承担责任并纠正问题对您的公司来说是一个巨大的机会。

编辑:

这是一个很好的时间来了解这是如何发生的,过程是什么,以及它是如何被发现的。我不会对规则或流程进行重大更改,但为未来的工作制定指导方针是一件伟大的事情。你们公司有一个明显的缺点。失去纠正此问题和纠正流程的机会将是浪费良机。

ZiG,在我目前的工作地点,我已经多次处理过这个问题。我的团队(3名开发人员)试图以敏捷的方式处理问题。我们习惯于收到中流甚至最后一秒的请求(然后根据具体情况进行处理)。

然而,我们明确表示,资源(特别是时间)是有限的,如果不在规范中,我们就不能做出承诺。如果它被认为很重要,并且不适合当前版本,我们通常会计划后续版本。如果它不重要,就列在清单上。

谈到OP的主题和问题:

如果你是一名受雇的程序员,那么我希望其他资源也能与你会面。可能是组织中的“高层”。

现在,如果他们“把你吊在外面晾干”,那么我会推荐以下问题:

a) “好的。我明白了。为什么你觉得这是常识,包括这个功能?我想知道为什么我们没有包括它。”(强迫他们解释他们的思维过程。一个人的常识很少是其他人的常识。)

同样,这假设您是为交付产品的公司工作的程序员。现在,如果你不止这些,也就是说,你是其中的一个上级,那么这里的许多建议都是非常好的。

然而,如果你是一名高级程序员或者是一名顾问程序员,那么首先是最高级的

a) 为未满足此要求的流程道歉。承诺与客户合作,防止此类事件再次发生。

然后是其他策略。不管你是否为修复收费,道歉是客户最重要的行为。再次重申,它值得重复——你并不是在为错过的功能道歉。你是在为错误的设计过程道歉,让它溜走了。当你以这种方式开始,然后寻求解决方案时,客户通常都很随和。

干杯

使用类似SCRUM的方法来避免这种致命陷阱:让客户尽早、频繁地、非正式地、受限地参与开发过程->降低风险和提高敏捷性。

就你字面上的问题而言,如何反应,最好的方法是忽略你的自我(“什么?!在我如此努力地做这件事并达到规范之后?!”),而是专注于一些积极的倾听和达成共识。

客户:你本可以把这个包括进去的!

客户:常识!!

美国:我理解您不高兴我们没有超出规范的范围。看看你对此有何感想,我们怎样才能让你快乐?让我们看看是否有一个过程,我们可以共同创造,将帮助每个人。

本质上,你不想把这变成一场“你说/我说”的死亡比赛。解决这些问题的唯一办法是请律师,然后谁也不会赢。如果您同意规范或流程有问题,请共同努力解决这些问题。

等待那个不喜欢你的软件的人离开,被那个喜欢你的软件的人取代 .

显然,你不能真正依赖它,但是如果你确信你做得很好,并且你的软件真的能满足雇用你的人的业务需求,那么等待它完成是值得的。有时,客户的最初反应并不是他们的最终反应,特别是如果你能很快将他们的担忧融入其中。

不要试图让客户觉得这是他们的错。这可能是他们的错,但让他们觉得这样做不会产生建设性的结果,只会激怒他们。

毫无疑问,需求收集负责人完全失败。项目管理层未能重复交付成果并与客户召开登记会议。

如果它不在规范中,它就不在规范中。作为一个没有特定领域知识的开发人员,“常识”是一个不相关的概念。不同的行业以不同的方式工作,其中一种方法可能非常适合某一特定领域,但另一种方法完全不可接受。

编写良好的规格是一种艺术形式。在我看来,您可以采取敏捷的“分析师/程序员”方法,进行小规模迭代,或者编写并维护 detailed, unambiguous specification . 这两项任务都是高度熟练的任务,并且仍然是迭代的。您仍然需要改进规范。

你无法知道你的客户在想什么。这种情况经常发生在没有任何项目编程经验的客户身上。我给你们的建议是简单地告诉他“常识”在工程(或者编程,如果你们愿意的话)中并不是很准确的答案。

向他展示生活中的另一个例子,这将向他展示你不能构建一些没有写出来的东西。建造一座新房子,建造房子的人需要一个详细的计划。。。他不会把可选的电源插头插上,因为在起居室里有一些额外的电源插头更符合“常识”。。。

我有过一次。幸运的是,不是我创造了这个设计,因为事实证明这就是问题所在。

贵公司与客户之间的沟通尽可能完美,这一点至关重要。一定要相互理解。提问,让他们提问。不要让任何东西在设计中打开。这将是交付时的问题点。并在项目期间定期召开会议(最好提前发布)。

不幸的是,许多开发人员不善于交流,而且许多客户没有意识到他们自己的需求。但是,如果你能缩小差距,你就会发现自己是一个快乐的顾客(而且还会回来)。

这就是为什么我/与我一起工作的团队总是使用 prototype-style

1. 收集需求后,向客户展示软件的早期和基本版本
2. "/" "

你必须尽早开始;尽早且经常地告诉客户,规范/用例/用户故事是一个定义将交付什么的合同。在敏捷环境中,客户有很多机会观察到他们想要的一些“常识”特性并提出要求,这是敏捷方法的优势之一,但是如果你最终开始接受“常识”添加,那么你就在为无限扩展做准备,可能要付出代价。

一些顾客 这你告诉他们不能做的越多越好,最终的争论就越容易。

作为一个年轻人,我意识到你还不能这么做,但其中一个艰难但必要的教训是,有时候你不得不解雇一个客户。

学
我们是我们领域的专家,我们比客户更了解他需要什么。下一次对于下一位客户,我们将提前建议所有有用的功能,让他高兴,并让他支付更多的钱,因为我们是专家,我们知道得更好。