我是一名初级程序员。由于我的主管告诉我与客户坐在一起，我加入了。尽管项目成功（从我的程序员的角度）交付，但我看到了客户不满意的表情！
客户：你可以包括这个！
我们：不在规范中！
客户：常识！
作为程序员，遇到这种情况你会如何应对？
ZiG
问问题
1448 次
21 回答
21
你应该做些什么来避免这种情况：
明确说明将包含哪些内容和不包含哪些内容。
问题可能归结为规范的未指定部分：
- 客户认为应该包含未指定的内容，即暗示。
- 开发人员认为不应该包含未指定的内容。
对于您拥有的未来规范，您应该有一个 catch all 声明，明确指出如果本文档中未指定某些内容，则可以在原始规范完成后完成，但需额外付费。
在当前情况下你应该做什么：
除了从您的经验中学习之外，您还应该与客户达成一些妥协。
示例：我会做这个你认为是常识的功能，但是对于所有未来的添加/更改，它必须明确指定。
即，您将不得不做更多的工作，但这是值得的，以换取您的客户将签订的所有明确规定的协议。
规格不好？
它一定是一个糟糕的规格吗？不。
不可能提及您的客户可能期望的所有内容，因此在您的规范/合同中清楚明确地说明上述所有声明至关重要。
减少问题的其他方法：
- 尽早让客户参与，向他们展示早期的原型。即使他们不要求。
- 尽量不要向客户出售最终产品，而更多的是为他的产品提供服务。
- 考虑一个敏捷开发模型或类似的东西，以便任务定义明确、规模小、有偿且无可争议。
于 2008-11-24T19:08:19.313 回答
14
这将是我转向敏捷开发理念的众多原因之一。在我看来，成功避免这种情况的唯一方法是要么无所不知，要么让客户大量参与，并经常提前发布/发布以尽快获得反馈。这样您就可以开发客户真正想要的软件，而不是客户告诉您他们想要的软件。
于 2008-11-24T19:12:54.580 回答
14
客户：你可以包括这个！
我们：不在规范中！
客户：常识！！
我们：我们不会试图超出客户指定的范围——我们遵循规范。不实现未指定的特性与实现指定的特性同样重要。我们永远不会猜测我们的客户，他们非常重视这样一个事实，即他们可以完全依靠我们在预算内按时正确、完全地实施规范。
正如其他人非常正确地指出的那样，情况几乎总是比我上面描述的简单交换更复杂。
但是，如果实施者有一个带有客户签名的规范，该规范基本上实施了一项协议，即“一旦软件可证明地实现了规范中的所有功能，那么它就被认为是完整的”，并且任何额外的东西都在规范，因此在合同之外。
合同本身在这里也可能有一些输入 - 如果您没有签署合同，那么规范中的内容无关紧要 - 到目前为止，一切都是通过握手完成的，整个交易（包括付款）可以根据双方的任何不满下厕所。
但是，如果您有合同和规范，并且客户已经看到并签署了两者，那么他们就没有回旋余地来要求您走得更远。
现在，关于您是否应该实施它的问题：
惊人的！ 你交付了一个产品，他们只有一个投诉。实施该功能，称其为“免费赠品”（确保他们了解您在规范和合同之外工作，并明确向他们发送以美元显示的折扣的工作账单）并让他们在整个项目上签字.
它将明确表明该项目已结束，您超出了职责范围，并且任何进一步的“惊喜”都超出了合同/规范，这为您提供了一个很好的保护层，超出了您已经（表面上）有。
如果这是一个 UI 问题，那么你就陷入了困境。
规范是否充分描述了 UI？它有模型吗？如果规范没有非常详细地描述布局、使用和包含模型，我不会因为这个关于 UI 的投诉而责怪客户。
不管怎样，我认为你可以理解客户的立场——如果他们没有玩过 UI 模型，那么无论如何他们都会对结果感到失望——从心理上讲，你和你的客户不可能有脑子里有同样的想法（更不用说常识不是这样的事实！）。
坦率地说，如果这是客户第一次考虑在工作完成之前检查 UI，那么你没有向他们解释好的 UI 设计过程至少部分是你的错。这是他们的应用程序的一个关键特性，它与他们的想象非常紧密地耦合在一起——除非他们随着时间的推移“增长”了他们的内部表示以匹配现实，否则没有人会在这种情况下感到满意。
这种脱节只能通过频繁的用户和客户测试来解决，这显然是缺失的。这是关于客户教育和沟通的问题，而不是是否满足规范。
-亚当
于 2008-11-24T19:24:50.420 回答
10
期待最后一刻的范围变化——它们总是会发生，所以要做好准备。
经常与客户一起审查进度 - 以尽量减少意外。
合同：功能规格，加上带有初始上限的时间和材料（因此客户感到控制）。然后，当发生变化时，如有必要，请重新协商上限。
永远不要说他们不能拥有他们想要的东西。他们可以免费获得答案！
总是给他们比他们要求的多一点，所以他们知道你有一个积极的态度。
将客户视为与他们在同一个团队中。不要接受在法律上被描绘成对手。
与员工相比，他们可能认为承包商不忠诚。向他们展示你和他们的员工一样致力于他们的成功，你会加倍努力。
于 2008-11-24T19:58:24.830 回答
4
经典案例...
这个问题没有明确的答案，但一切都围绕着沟通展开。应该采取预防措施（例如每周审查或类似的东西）。
当然，你不能免费重做整个事情。
两种方法：或者告诉他们把**关掉或者你处理它。
如果您选择交易：
- 首先，同情、尊重客户。
- 看看可以轻松更改的内容。
- 看看合同。
- 也许创建一个新的协议。
- 不要做太多。
- 让他们看到进展和所需的工作。
- 查找缺失功能的解决方法（可能使用其他出色的功能或可用工具。）
用你的常识，它是如此普遍，它甚至不好笑。
于 2008-11-24T19:16:39.360 回答
4
这是固定投标安排的众多缺点之一。任何时候业务需求或优先级发生变化，或者甚至是一个简单的误解，都会导致从这种尴尬的情况到打电话给律师。改变并为做出改变所花费的任何时间获得报酬。此外，按小时安排并不排除制定计划或进行估算。
但是，一旦您处于固定出价的泡菜中，您的选择是：1）额外付费。2）免费做。3）不要这样做。
选项 3 是最差的，选项 1 是最好的。如果您与客户有良好的信任关系和良好的沟通，通常很容易得出选项 1。如果关系不好，那么您的问题就会更大。在这一点上，尽量避免laywers。
最后一点 - 任何具有“交付日期”的项目都不可避免地会遇到所描述的问题。具有上述日期的项目通常涉及撤退到洞穴几个月以隐藏开发，然后在利益相关者面前一次性释放产品。这是突然的，并为客户的期望和实际产品留下了充足的时间。相反，如果您展示产品的中间版本并每隔几周收集一次反馈，则会发生两件事。首先，您可以获得更好的反馈，最大限度地减少误解，并做出更好的产品。其次，没有一个时间点可以寄予厚望。客户的想象与实际存在的潜在差异要小得多。没有惊喜。
祝你好运。
于 2008-11-24T19:26:32.303 回答
2
好吧，它没有成功交付。沿线的某个地方存在沟通不畅。在不知道具体细节的情况下，我认为这不是开发人员注入的问题，这可能不应该归咎于客户——需求收集任务是不够的。这是一个典型的例子，说明当软件方面没有领域专家或需求发现过程没有尽其所能时会发生什么......
如果是我，我会纠正这个问题并弄清楚如何在未来避免类似的问题。
你如何处理这个问题可以很好地决定与客户签订的合同/业务的未来。承担责任并纠正问题对您的公司来说是一个巨大的机会。
编辑：这是评估这种情况如何发生以帮助纠正它的好时机。有些公司选择彻底改造他们所做的一切，我认为这是一个错误。忽略它也是如此。把问题归咎于人也是错误的。
现在是了解这件事是如何发生的、过程是什么以及可能如何被抓住的好时机。我不会对规则或流程做出巨大的改变——但为未来的工作提出指导方针是一件好事。贵公司对缺点有一个明确的教训。失去纠正这个问题和纠正你的过程的机会将是浪费一个很好的机会。
于 2008-11-24T19:29:24.513 回答
2
“你有什么反应？”
问题 1 - 您想继续与该客户的这种关系吗？严重地。如果他们要声称未指定的功能是“常识”，那么这可能不是维持或增强的良好关系。
如果你想脱离，那很容易。要求他们突出显示您未能遵守并玩该游戏的规范的每个部分。获取每个缺失功能的特定测试标准。拔牙。在确定缺少什么时保持对抗。不要问为什么。只需提前询问所有细节。这是缓慢和不愉快的。但无论如何你都不想要它们。
如果你想参与，那么，你将不得不改变这种关系。目前，您有一个被动进取的客户。他们不会说他们想要什么，但他们会说他们不想要什么。
这可能是他们的习惯；这可能是他们赢得让步的方式。或者这可能只是他们的草率规范。
如果你想要这种关系，你的反应有两个部分。
短期。得到他们满意的东西。他们必须确定具体的变化。您必须用“成本”和“符合规范”对每个更改进行评分。
- 有些东西很便宜，而且很合身。做那些。
- 有些事情做起来很便宜，但不符合规范。三思而后行，让错误的规范导致返工。从某种意义上说，您从他们那里购买了规范；您可能还需要提高标准。
- （可悲地）符合规范的昂贵的东西是一个问题。你在这些方面遇到了麻烦，而且几乎必须这样做。
- 不符合规范的昂贵的东西是每个人的经验教训。详细说明这些计划，包括规范重写和批准。
长期。确保他们没有再次被 PA。尽早并经常回顾，使用敏捷技术。多沟通，多原型，多发布。
于 2008-11-24T19:40:49.327 回答
2
ZiG，在我目前的工作地点，我不得不多次处理这个问题。我的团队（3 名开发人员）试图以敏捷的方式处理事情。我们习惯于获取中游甚至最后一秒的请求（然后我们会根据具体情况进行处理）。
但是，我们明确表示资源（尤其是时间）是有限的，如果不在规范中，我们将无法做出承诺。如果它被认为很重要并且不适合当前版本，我们通常会计划后续版本。如果它不重要，它会列在一个列表中。
我发现的一件事是，您可以让用户在时间 T 同意 Spec S。但是在时间 T + N，让他们记住他们同意 Spec S，或者让他们承认他们这样做了（使用我希望你一直保留的文档！）可能比它应该的更棘手。
于 2008-11-24T19:57:11.883 回答
2
谈到OP的主题和问题：
如果您是受雇的程序员，那么我希望其他资源与您会面。可能是组织中的“高层”。
如果是这种情况，那么你的工作就是回答直接的问题，并控制你的情绪。是的，你可能会因为他们不喜欢你的代码而感到受伤，但是在老板面前表现出任何情绪并不是一件好事。相反，试着保持中立，让其他人处理会议。
现在，如果他们“把你晾在外面”，那么我会推荐以下问题：
a) “好的。我明白了。为什么您认为包含此功能是常识？我想知道为什么我们没有包含它。” （强迫他们解释他们的思维过程。一个人的常识对其他人来说很少是常识。）
b) “嗯，我相信我们可以在下一个版本中包含它。我会留给 XXX（老板）来达成双方同意的方法”（即不要与在场的老板谈论成本或免费赠品。 曾经。）
同样，这假设您是为交付产品的公司工作的程序员。现在，如果不止于此——即您是高层之一，那么这里的许多建议都非常好。
但是，如果您是高层或顾问程序员，那么首先
a) 为未满足此要求的流程道歉。承诺与客户合作以防止这种情况再次发生。
然后是其他策略。您是否为修复收费并不重要 - 道歉是对客户最重要的行动。再次，它值得重复 - 你不会为错过的功能道歉。你正在为让它滑倒的错误设计过程道歉。当您以这种方式开始然后寻求解决方案时，客户通常会非常乐于助人。
干杯，
-理查德
于 2008-11-24T21:57:41.190 回答
1
使用类似 SCRUM 的方法来避免这种死亡陷阱：让客户及早、频繁、非正式、受限制的委员会参与到开发过程中 -> 降低风险并提高敏捷性。
于 2008-11-24T19:15:54.353 回答
1
就你的字面问题而言，如何反应，最好的方法是忽略你的自我（“什么？！在我努力工作并达到规范之后？！”），而是专注于积极倾听并努力达成共识.
客户：你可以包括这个！
我们：不在规范中！
客户：常识！！
我们：我知道您对我们没有超出规范的范围感到不高兴。看到你对此的感受，我们怎样才能让你快乐？让我们看看是否有一个我们可以共同创建的流程来帮助每个人。
本质上，你不想把它变成“你说/我说”的死亡竞赛。解决这些问题的唯一方法涉及律师，然后没有人会赢。如果您同意规范或流程有问题，请共同努力解决这些问题。
于 2008-11-24T19:42:08.747 回答
1
这种方法实际上对我很有效： 等待不喜欢你的软件的人离开并被喜欢它的人取代。
显然你不能真正依赖它，但如果你确定你做得很好并且你的软件真的会满足雇用你的人的业务需求，那么等待它确实是值得的。有时客户的最初反应不会是他们的最终反应，特别是如果你能迅速融入他们的担忧。
于 2008-11-24T19:43:20.663 回答
1
不要试图让客户觉得这是他们的错。这可能是他们的错，但让他们有这种感觉不会产生建设性的结果，只会惹恼他们。
相反，您应该意识到客户只会抱怨他们使用的软件，在大多数情况下是因为他们喜欢它。没有人抱怨没有人使用的软件。客户不可避免地会抱怨您交付的软件，即使您交付的正是他们要求的软件。所以不要出汗。软件永远不会完成。
于 2008-11-24T20:01:55.650 回答
0
毫无疑问，需求收集负责人完全失败了。项目管理的额外失败没有迭代可交付成果并与客户进行签到会议。
但是，您有一个已签署的规范，并且您交付的内容与规范相匹配。因此，您的公司有两种选择：以业务发展的名义核销成本并免费进行更改，或者向他们收取更改请求的费用。
于 2008-11-24T19:12:51.303 回答
0
如果它不在规范中，它不在规范中。作为没有特定领域知识的开发人员，“常识”是一个无关紧要的概念。不同的行业以不同的方式工作，一种方法可能非常适合特定领域，但在另一种方法中完全不可接受。
编写好的规范是一种艺术形式。IMO，您可以采用敏捷的“分析师/程序员”方法进行小迭代，也可以编写和维护详细、明确的规范。两者都是高技能的任务，并且仍然是迭代的。您仍然需要改进规范。
无论哪种方式都不像听起来那么容易，并且都需要能够与客户建立良好的工作关系。
于 2008-11-24T19:14:48.023 回答
0
您无法知道客户的想法。这种情况经常发生在没有任何编程项目经验的客户身上。我向您建议的是简单地向他展示“常识”在工程（或编程，如果您愿意）中的答案不是很准确。
向他展示生活中的其他例子，这将向他展示你无法构建非书面的东西。示例：盖新房子，盖房子的人需要一个详细的计划……他不会放可选的电插头，因为在客厅里，有一些额外的东西更“常识”……
于 2008-11-24T19:16:46.757 回答
0
我曾经有过这个。幸运的是，不是我创造了这个设计，因为这被证明是问题所在。
至关重要的是，您的公司与客户之间的沟通尽可能完美。确保你们互相理解。提出问题，让他们提出问题。不要让任何东西在设计中打开。这将是交货时的问题点。并在项目期间定期举行会议（最好有预发布）。
不幸的是，很多开发人员不善于沟通，很多客户没有意识到自己的需求。但是，如果您可以将差距最小化，您就会发现自己是一个快乐的（并且是回头客）的客户。
于 2008-11-24T19:18:30.603 回答
0
这就是为什么我/与我一起工作的团队总是使用原型风格的方法，这意味着：
- 收集需求后，您向客户展示软件的早期和基本版本
- 客户说“你可以包括这个”/“这是常识”
- 你改变你的设计以反映客户的需求
- 从第 1 点迭代到正式发布
于 2008-11-24T19:50:18.543 回答
0
你必须尽早开始；尽早并经常告诉客户，规范/用例/用户故事是定义将交付什么的合同。在敏捷环境中，客户有很多机会观察到他们想要的一些“常识”特性并提出要求，这是敏捷方法的优势之一，但如果您开始接受“常识”添加最后，您正在为无限扩展做准备，可能会为此付出代价。
一些客户期望这一点；你告诉他们他们不能做的越多越好，最终的争论就越容易。
作为一名初级人员，我意识到你不能这样做——但是——但是一个艰难但必要的教训是，有时你必须解雇一个客户。
于 2008-11-24T20:25:13.903 回答
0
你学习——一切都在学习，没有什么是个人的。
我们是我们所在领域的专家，我们比客户更了解他的需求。下次为下一位客户我们会提前建议所有有用的功能，让他开心，让他付出更多的钱，因为我们是专家，我们更了解。
于 2008-11-24T20:39:30.817 回答