BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

质量是可以谈判的吗?

| 作者 Amr Elssamadisy 关注 0 他的粉丝 ,译者 郭晓刚 关注 0 他的粉丝 发布于 2007年12月4日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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》演讲中讨论了另一种看待质量的方式,他认为代码质量应被视作公司的资产。

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

查看英文原文:Is Quality Negotiable?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

客户不知道自己想要什么 by Guo Xiaogang

客户不知道自己想要什么
还是如何测量质量的问题。我们不容易有一个明确的指标来表示质量,谈判中很难直接讨论。
在谈判的结果中,质量常常是以其它要求来隐含地表示的。
即使存在测量软件质量的指标,粒度大概也是很粗的。质量/时间、质量/成本这些曲线都不是光滑的,不能按客户的要求滑来滑去。
质量的变动还有很多隐晦的连锁反应,难以预测。

客户并非真的不关心质量,而是我们没有清楚客户对质量要求的底线 by Chan Jackei

作为客户来会所,不会真的对质量好不关心,他们想表达的通常是不需要耗费过多时间和人力为代价换取的"高质量",而并不是连基本的功能和可用性都忽略掉。

所以对于PM或者QM,关键的是与客户一同定义好质量目标是什么,一定要让项目有一个可供验收参考的质量标准。

客户并不关注软件内部,而关心他所要的 by zhong cl

一般的客户是不管你用什么多好的技术,设计中的系统架构多么的优良,设置代码写的多么的优雅,一句话,在规定的时间内实现他所想要的稳定的功能就行了。其实从这也可以看出,客户其实也是很关注质量的,只是关注的点和开发方的不同,这其实也就是 关注的粒度不同而已,质量问题不是从谈判中解决的,而是在开发中解决的,不关心质量的软件,最终带给客户和自己都是一个噩梦。

这里的质量可能是指代码坏味道的多少 by 曹 云飞

我们程序员往往很在意坏味道,比如重复的代码,随时重构代码来消除坏味道。而对于客户来所,这些坏味道只要不影响功能,就没有必要花时间去重构。如果客户说没有必要考虑可维护性,那么我会认为没有必要清理代码中的坏味道,在项目规模不是很大的情况下,这样应该是可以节约时间的。也就是说,在这一点,我会听从客户的要求。

基本同意,会选择合适的时机进行重构,才算真正的敏捷! by Zhang Charlie

首先关于本案主题,我觉得应该先把什么是“客户”,什么是“质量”定义清楚,如果大家分别拿着不同的定义在讨论,那是浪费时间。

接着再谈谈重构,虽然好像有点偏题。

重构必然是有成本的。老练的工程师会评估重构的代价,巧妙地选择重构的最佳时机。

极端编程要求我们每时每刻地进行重构,作为“勇气”的表现,这当然是理想情况。对于初级程序员和新手,在把握不好的情况下,不分青红皂白地进行改动、重构,也是一种可以理解的简化(机械化)处理方式。随着开发经验的积累,我想他们也会主动思考出手的时机。


2007-12-5 1:59 cao yunfei 说:

我们程序员往往很在意坏味道,比如重复的代码,随时重构代码来消除坏味道。而对于客户来所,这些坏味道只要不影响功能,就没有必要花时间去重构。如果客户说没有必要考虑可维护性,那么我会认为没有必要清理代码中的坏味道,在项目规模不是很大的情况下,这样应该是可以节约时间的。也就是说,在这一点,我会听从客户的要求。


太极敏捷派
www.zhangxun.com

怎么又回到敏捷的讨论去了 by zhang wei

客户往往关注最直接的东西,比如交付日期和可用性。对于质量,这一个内在的东西,国内的客户往往难于理解:怎么?做的软件bug很多?这不是你们的专业、特长吗?他们倾向于认为软件一做出来就是没有任何问题的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

7 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT