Joel 绝不妥协的抓虫行动
绝不妥协的抓虫行动
作者:周思博(Joel Spolsky)
译:Paul May 梅普华
Tuesday, July 31, 2001
属于Joel on Software, http://www.joelonsoftware.com
软体品质是(或者说缺乏品质)是每个人爱抱怨的事。现在我既然有了自己的公司,终于决定要为此做些事情。过去两星期为了推出新版的FogBUGZ,我们暂停Fog Creek的所有活动,把目标定为清掉所有已知的问题(大约有30个)。
身为一个软体开发者,修问题应该是件好事,对吧?这不一直是件好事吗?
错!
只有当修正问题所得到的价值超过修正所花的成本时,修正问题才是件重要的事。
这些事很难度量,不过并非不可能。让我来举一个例子。假设你在经营一个做花生酱三明治及果酱三明治的工厂,工厂每天可以生产十万份三明治。最近因为增加了新口味(灯笼辣椒酱及大蒜花生酱),产品需求一飞冲天。工厂产能只有十万份三明治,可是需求可能接近廿万。你就是做不出更多的三明治了。另外一个三明治的利润有15美分。所以由于产能不足,你每天可能损失一万五千美元。
不过建一座新工厂可能太贵,你付不起那个钱,而且你也害怕辣味和大蒜味三明治只是一阵流行,时间一过就没了。不过你每天还是少赚一万五千元。
雇用杰森倒是件好事。杰森是个入侵工厂电脑的14岁程式师,自认有办法把生产线加快到两倍。方法大概是跟他在slashdot听到的超频技术有关吧。而且试产时看起来似乎有效。
没有正式上线只有一个原因。有个_小到不能再小_ 的小问题,大约每小时会有一份三明治被碾碎掉。杰森想要修好这个小问题。他认为可以在三天内修好。你要让他去修吗?还是让有问题的软体直接上线呢?
三天后再上线会让你少赚四万五千美元,同时可以替你节省72份三明治的原料成本(不管哪种状况,反正杰森三天后都会把问题修好)。好吧,我不知道在_你_ 的星球上一份三明治要多少钱,不过在地球上绝对要比625美元低很多很多。
我扯到哪去了。噢,对了。有时候_问题并不值得修正_ 。下面是另一个不值得修正的问题:如果你有个问题式,会让程式在开启超级大的档案时完全当掉,不过只会发生在你唯一一位使用OS/2的用户身上,而且就你所知这个用户根本没有大档案。好吧,别修了。这并不算太糟。同样的道理,我通常都会放弃那些使用16色萤幕或者还在用Windows 95而且7年没升级的人。像这样的人不会在套装软体产品上花多少钱的。相信我吧。
不过大部份情况下问题都是值得去修正的。即使是「无害的」问题也会减低你公司和产品的声誉,长久下来对你的收入就会有重大的影响。产品问题多这种恶名是很难逆转的。如果你真的要推出产品的.01版时,这里有些点子可以帮你找寻并修正 正确 的问题:那些从经济面看值得修正的问题。
第一步:确定你知道问题的状况。
以FogBUGZ为例,我们有两种方法可以达到。首先我们会把免费试用伺服器出现的问题全部抓下来,尽可能的记录最多的资讯,然后把全部资料用电邮寄给开发团队。这种作法找到很多很多的问题,效果非常的好。举例来说,我们发现很多人都不会在「Fix For」画面输入应有的日期。我们在这种情况完全没有给错误讯息,就直接当掉了(对web应用程式来说,这表示你会看到一个丑丑的IIS错误而不是预期的画面)。啊!
当我在Juno工作时有套更酷的系统,可以「由外头」自动收集问题。我们用TOOLHELP.DLL装了一个处理程式,每次Juno当掉时就会把处理程式叫起来,把堆叠倾印到一个记录档里然后结束。下次程式连到Internet送信时就会上传记录档。我们在做beta测试时会收集这些档案并检视所有当机状况,然后输入到问题追踪资料库里。这种作法确实找到几百个当机的问题。当你有一百万个使用者时,会当机的状况会相当 神奇 ,常常都是因为记忆体严重不足或是很烂的电脑(你叫得出Packard Bell(译注:某平价电脑品牌)吗?) 你可能有如下的程式:
int foo( object& r )
{
r.Blah();
return 1;
}
你会因为r的参考为NULL而当掉,虽然这应该绝对不可能发生,不应该会有NULL参考的这种_鸟事_ ,C++保证过的。你不一定要相信我,不过当你等得够久,有几百万用户又努力收集他们的堆叠倾印时,就会发现这种地方也是会当的,让你无法相信自己的眼睛。(不过你并不会去修正这种问题。万能的天神啊,请帮这家伙弄一台新电脑吧,而且这次 别 把你找到的所有酷工作列共享软体都装上去。真是狗屎。 )
我们做的另一件事是把每个技术支援电话都视作某个问题的迹象。当我们接到电话时,会试着思考能做什么来避免。举例来说,旧的FogBUGZ安装程式通常假设FogBUGZ是用匿名Internet使用者帐号执行的。这个假设95%的时间都对而其他5%的时候会错,不过这5%的状况最后会变成打进我们支援专线的一通电话。所以安装程式改成会询问帐号。
第二步: 确定你会得到经济上的回馈
你可能没办法_精确_ 算出修正每个问题值多少,不过还是有些事_能_ 做:把技术支援的「成本」算在事业单位的帐上。九十年代早期微软做了一次财政上的组织重整,让各个产品事业单位负责所有技术支援电话的全部成本。所以产品事业单位就开始坚持PSS(微软的技术支援部门)定期提供前十大问题列表。当开发团队集中处理这些问题之后,产品的支援成本也就直线下降了。
这实在有点违反让技术支援部门自己养自己的新趋势,因为多数的大公司都已经这样做了。在Juno甚至还要求技术支援部门对上门求救的人收费以达到损益平衡呢。要察觉问题所带来伤害的方法本来就不多,这样把问题的经济负担由开发者转移到使用者身上,会让你失去这有限的能力。(换来的却是得替 你的 问题买单的愤怒用户,他们会告诉朋友,到后来你根本无法估计所花的成本。不过对Juno要公平点看,因为产品本身是免费的,所以就别再埋怨了。)
有一个解决的方法,就是当支援电话是因产品本身的问题而引起时, 不要 向使用者收钱。微软就是这样做的,效果相当好,而且我也从来没有因为打给微软而付钱。:)应该要反过来向产品单位收245美元或目前一份开发者支援(developer incident)的成本。这样就会把他们贩售该产品的利润全部吃光(可能还多赔好几倍),并确实产生正确的经济诱因。这让我想起到DOS游戏所以是_烂_ 事业的一个原因…通常需要用奇怪的显示驱动程式才能让游戏看起来漂亮而且跑得快,而一通显示驱动程式的技术支援电话就会吃掉_20_ 套游戏的利润,这还得假设Egghead和Ingram(译注:通路商)以及MTV台的广告还没有把利润_全部_ 花掉。
第三步:找出哪些问题值得全部修好
在Fog Creek这种小公司(在我们心里可不小)都是由开发团队自己技术支援电话。成本大约是每天一小时,用我们的顾问费率来算的话大约是一年七万五千美元。如果能把所有的问题都修好,我们很有把握可以降到每天15分钟。
粗略估算起来省下的纯现值约为十五万元,约为62天的工作成本:所以如果能在62天内完成,就值得做了。
利用方便的FogBUGZ内建估计功能,我们算出20个人日(两人两周)可以修好所有问题。所以四万八的「支出」换回十五万的报酬,这_单就减少技术支援来算_ 就已经是很高的投资报酬率。(注意你可以拿程式师薪资和经常开支的成本和我们的顾问费率相比,会得到相同1:3的结果,因为它是一样的)。
我还没开始计算因产品改善而增加的价值,不过现在来算也可以。使用旧程式的试用伺服器在七月共当了55次,遇到当机的使用者共17名。你可以想像这些人里头至少有 一位 会决定不买FogBUGZ,因为他们试用后认为产品的问题很多(不过我并没有真正的统计数据)。不管如何,以现值来说我们损失的业务可能在七千到十万美元之间(如果你够认真的话,要找出确实的数字并不会太难)。
接下来的问题是,比较稳定的产品可以卖贵一点吗?这样子除错的价值就会大增了。我猜想问题的数目的确会影响价格,不过实在想不到有什么套装软体可以作为例证的。
请不要打我!
当人们读到这种文章,难免会得出类似的蠢结论:约耳不认为你应该修正问题。事实上我认为大多数修好的问题都有很明确的回报。不过比起修好所有问题,或许去做_其他_ 事情能获得更高的金钱回报。如果你必须二选一,是要修正OS/2用户会遇到的问题,还是加一个能让奇异(GE)采购两万套的新功能,那么就得跟OS/2先生说抱歉了。如果你笨到认为修正OS/2的事 还是 比增加GE的功能重要,你的竞争者大概不会这样想,所以你就出局了。
这一切都表示我其实是个乐观主义者,而且我相信制作超高品质产品还能得到很多隐藏的价值,只是很难发觉而已。你的员工会更自豪。也比较不会有客户把你的光碟丢进微波炉烤完后,用斧头劈碎再寄回来给你。所以我宁愿偏向品质面(我们真的修好了FogBUGZ里 所有已知的问题 ,而不光是最严重的大虫)而且以此自豪,并且确信把试用伺服器的问题全部清除,能让我们有一个坚若磐石的产品。
这些网页的内容为表达个人意见。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.