质量是可以谈判的吗？

如果客户对你说，他们对软件的质量不感兴趣，他们只要求在规定的日期必须完成所有规定的事情——你会怎么做？你会听从客户的话在质量上妥协吗？（顺便一问，什么是质量？）

Simon Baker 问道，你是否应该总是做客户希望的事情？

如果客户说他不想要“完美的代码”，只要能完成他想要的功能，质量低劣的代码他也无所谓，你会怎么办？我们的任务是交付客户想要的东西，对吧。那么，你会在质量上抄近道吗？我不会。我会去理解客户的思维，看看是否其实只是短线的想法（“我只想要最便宜的，质量无所谓”），如果他是无知，或者纯粹是糊涂，那我就撒手走人算了。我的良心不允许我在作品的质量上做出妥协。

在ScrumDevelopment Yahoo! 讨论组上也发生了一起相关的讨论，议题是“质量”是否不可谈判的。讨论从 Pierre Mengal 的提问开始：

我正面对一个情况，客户不关心质量，因为对他来说，那属于浪费时间。他们立了一个不可动摇的限期，不允许增加资源，不允许缩减项目的目标范围。如果有必要，他们可以在项目完成之后几个月内把整个应用完全重写一遍。这个绝对不是开发费用的问题（如果到了限期没法发布，他们的损失会以百万计）。

Esther Derby 回以一个疑问：

我对“质量是不可谈判的”这句话很很好奇。

质量并不是一个绝对的词，因此 * 必须 * 经过谈判才能达到一个共同认可的特定含义。就我来说，“我不会牺牲协商好的质量水平”这样的说法更有意义。

Jerry Weinberg 说过“质量是对某人的价值。”我们的任务是找出价值所处的位置。

你可以看看 Jerry 的《Quality Software Management》系列。

Also Kathy Iberle 有一篇漂亮的论文《They Don’t Care about Quality》，里面谈了在不同业务背景中的“价值”：http://www.kiberle.com/2003/STAREast2003.pdf

Lance Walton 揪住价值不存在明确定义的暗示不放。

这里有个很明显的问题，“质量”是个缺乏定义的词。比如，假设“发布某物，即使质量很差”指的是每次用户保存工作的时候软件都会崩溃（如果在崩溃前还真的保存好了，那情况又不一样）。或者假设质量很差的意思是每次按键都要花 10 秒钟去处理。这些情况包括在“发布某物，即使质量很差”的可接受范围内吗？

Alistair Cockburn 举了一个详细的例子：

我刚刚访问过 A 公司，他们的软件比竞争对手 B 公司卖得好很多，让 B 都倒闭了。和我交谈的人说，B 的产品比 A 功能更多，速度更快，Bug 更少，但 B 没有建立现场专家支持部门，而 A 建立了。

从他们客户的角度来看，A 产品比 B 产品“质量更高”。因此客户购买 A 产品而不是 B 产品。

仅仅避免 Bug 和编写可维护的代码还不算交付了质量，还得有人买它。购买的决定指出了“什么才算是质量”。

“质量”的因素多不可数，大多数谈判中谈的是各项因素的重要性排列，每项因素需要达到什么程度。如果你生意不好，“没有 Bug 和可维护”可帮不上什么忙。

Ken Schwaber 在《Agile Quality: A Canary in a Coal Mine》演讲中讨论了另一种看待质量的方式，他认为代码质量应被视作公司的资产。

那么，当客户说他们不关心质量的时候，我们应该听从吗？我们应该盲目地做客户要求的事，还是说忽略他们，因为我们懂得更多？又或者有没有别的途径？我们应该如何与客户交流，才能建造出最好的软件呢？