结案之后

不久前，才把一个做了快要两年的案子结束掉。有个年轻的同事就问我：『奇怪，照理说结案应该令人觉得很兴奋，可是为什么我一点高兴的感觉都没有？』

我们从小就听了很多『从此以后，王子与公主就幸福快乐的生活在一起』的故事。很多人可能就认为，专案应该像是做爱一样，在末期努力冲刺之后，就会达到最后的高潮，接着就在激情中，完成一个完美的句点。所以到了那一刻，应该会让大家心神俱醉，精神亢奋，快美难言。所以常常都有人说，要召开盛大的party来庆祝专案的结案。

有这种期待的人，去看交响乐团演奏时，大概也会期待乐曲会遵照这样的模式吧。每首乐曲一定要在最后安排最大的高潮。在接近乐曲最后的高潮时，整个节奏就会莫名其妙的加快，声音会越来越大，跟男女交欢差不多。等到乐曲尾声时，所有乐器就会发出轰然一声，然后就突然万籟俱寂，只剩下首席小提琴微弱地用他无力的手拉了几个微弱的抖音，整个演奏就此溘然而逝。还没提他把琴弓抖一抖想甩去他的汗水的样子，与男性曳甲收兵时的景象有多神似哩。

我听的古典乐曲很少，不知道有没有这种奇怪的音乐，不过我做过的专案中，还没有一个是在激昂澎湃的音乐中结束的。有经验的人告诉我们，软体专案的结案跟做爱不同，反倒是跟结婚蛮像的。结过婚的人都知道，筹备结婚本身就是对两人生活的第一个考验。经过漫长的筹画，把很多琐碎的事情都处理好，拍婚纱照，选礼服，订场地，选菜单，选戒指首饰，寄喜帖，送喜饼，遵照双方家长认可的礼仪迎娶，行礼如仪，(都已经什么年代了，还要特地买把纸扇掉下来？)婚宴敬酒，等着被闹洞房...一直到把闹场的人们从新房赶走以后，还得拖着疲惫的身躯，去面临新婚之夜与蜜月旅行。

很多小说都会描写，主角在完婚之后，新人交杯对看，眼中深情无限，彼此沉浸在绵绵密密，无边的幸福中。或许你早就知道了，小说跟实际的生活还是有段差距的。我只能说，如果你没被灌醉的话，有不少人的标准感觉是：『呼！终于结束了。好累啊！先好好睡一觉吧。啥？明天还要出团去夏威夷蜜月？不会吧！』，接着倒头呼呼大睡。半夜还被叫起来吵架，因为今天你家的人还做错什么事情，引起枕边人的不悦。专案结案时，感受其实就很像是这样。

当你辛苦了许久，经过了漫长的开发与验收流程，终于让系统上线了。你认为任务已经了结了吗？不，刚上线的系统可能会出的状况最多。所以我们需要绷紧神经，深呼吸，默默地解决所有没有设想到的问题。该解的问题也解完了，不该做的enhancement也做完了，跟客户一直耗下去，终于可以结案了。此时只会觉得如释重负而已。把一个很重的东西从肩上放下来，不会让我们达到高潮，只会让我们喘了一口大气而已。

除了心理上的感觉以外，专案的结案，真的就代表了所有的工作都告一段落了吗？或许我们可以翻开软体工程的书，看看有关于整个软体开发经费的统计图表，如果你真的这样做，你会发现Maintenance通常占了整个软体开发经费最大的部分。

如果我们从经费这个层面看起来，结案之后，应该才是系统开发真正精采的地方，要不怎么我们会花这么多钱呢？可是为什么我们在学校里面，好像很少谈到这一块呢？

我记得小时候上有关软体工程的课程时，在专案结案之后到底还要做什么，好像在书本里面从来都没有提到过。老师通常也是讲完development process，学期也就差不多该结束了。结案之后到底会发生什么事情，god knows。难怪很多初出茅庐，或是没有结过案的人来说，内心总认为只要结案了，我们的任务就已经了结了，感觉起来，好像只要系统上线了，从此大家就可以屁股拍拍走人，每个人都可以就此过着幸福快乐的日子。

这可能也是因为有蛮多专案都来不及活到结案的时候吧。此外，就工程学上的角度来说，这根本就不是讨论的重点。他们重视的，是怎么把东西给做出来，或者说怎么建立一套可大可久的系统，这看起来才有比较大的成就。盖一间雄伟的教堂，画上金碧辉煌的壁画，跟帮伟大的教堂修补柱子，重新替褪色的壁画上色，哪个有成就感，这当然不言可喻啦。

在这一章里，我想讨论一下关于结案之后的一些现象：

　■很多案子验收时，不管是schedule、scope或quality，都与原先规划的相去甚远
　■上线之后，才是真正恶梦的开始
　■scope/resource/schedule的吊诡
　■文件通常没有随之更新。久而久之，只剩下考古的价值。
　■系统做的越烂，越有保障。做系统的人吃定客户找不到其他的人可以maintain。
　■大多数做专案的公司，低估了保固期间的effort。取而代之的，是持续不断的改版。

以下我想针对这几种现象进行讨论。

很多案子验收时，不管是schedule、scope或quality，都与原先规划的相去甚远
***********************************************

如果你找一个正在企业内部管理MIS系统的人，仔细观察他的生活，你会发现他的工作，有绝大多数，就是在于要想办法让现在正在运转的系统可以持续运转，例如每天要帮新来的员工建email帐号，帮他们灌灌作业系统，教教怎么使用公司的系统，装装防毒软体，印印报表，送修机器…除了这种看起来像是打杂的事情以外，所谓的开发工作就是要不停地修修改改，以解决各式各样营运上面的需求。这边多做一张不一样的统计报表，那里改改wording，修修程式的bug所造成的data错乱…。除了要参加无穷无尽的会议，来想办法找厂商把旧系统换掉以外，这几乎是他工作生活的写照。

很多从事MIS工作的热血青年，如果他们在这个工作岗位上待到退休养老的观念还不是太重的话，只要有机会可以把手头上的旧系统换掉，一开始一定手舞足蹈，欢欣雀跃。认为只要辛苦一阵子，就可以万事ok。可是通常等到历尽千辛万苦，系统终于上线之后，常常会发现自己从一个火坑掉入另一个地狱。

我不知道你是否有过使用信用卡的循环信用或者是预借现金的经验。很多人在刷卡时，看到自己心爱的商品，一开始都会看到一个美丽的远景。我只要付出小小的代价，接着就可以解决我现在手头上的燃眉之急。刷下去，就可以开始过我的优质生活了。

通常等到东西买到手了，一直到回家以后才会赫然发现，怎么这个东西也不过如此而已？真是买贵了，还亏我还特地刷卡打算用循环信用哩。没关系，广告跟真实中间总会有一段差距的。反正我急着用，有东西可以用比没有好。接着等到开始要付帐单时，这才发现：『糟糕，这个月又透支了，没办法了，只能动用循环信用。我必须要维持良好的信用，不然就没有信用卡跟循环信用可以用了。那就缴个最低应缴金额吧。』接着内心就会开始暗自垂泪：『我到底还要付多久的钱啊？』『下回再也不要这样刷卡了。』

等到付款的时间过了，内心也忏悔的差不多了，接着就是要奖赏自己的时候到了。嗯，应该可以再次计划一个完美的刷卡购物之旅。

对于很多客户来说，开发一个软体专案，对他们而言，过程中的感受其实跟使用预借现金或是循环信用差不多。一开始时，总会有一个蛮强烈的需求。觉得这个系统一定要解决我们现在手上面临所有的问题。通常要等到上线时，才会发现：『咦，我们花了这么多钱，怎么就只有这些功能？我们还得要付出这么多钱去做enhancement喔？这简直是一堆诈欺的骗子，在光天化日之下，明目张胆的抢劫。』只是这些抢钱的人，不会拿着枪对你喊：『抢劫』。软体公司最常做的是在他们的系统里面埋下一些炸弹，等到你走投无路的时候，再来狮子大开口。所以在开发的过程里面，客户的内心，会不断地在『有了这套系统，我们所有问题都会解决』的天堂与『我简直遇到一堆整天落后进度，追加预算的无赖』的地狱之间摆荡。

或许我们可以从一个假想的专案来体会这个情形。在某次客户内部工作会议中，承办人正在向大头进行报告，讨论这个专案是否要进行：

业务承办人凯莉：要达成总经理揭示今年的目标：『要用创新，效率，以及执行力来重新改造我们的商业流程，让我们可以更具有弹性，可以更迅速地提供给我们的客户成本更低，品质更高的产品。』(大企业教战守则第一条，把大老板的话拱出来是不会有错的。况且大老板的话每次讲的都是差不多的。)我们需要建置一套可以帮助大家更有效率，更迅速做出决策的资讯系统。透过这套系统当作核心，可以帮我们提供更完善的客户服务。也就是说可以透过这套系统，达成高效率，高品质，低成本的需求。当客户满意我们的产品，我们的营收与获利都会获得稳定的成长。公司赚钱股票也就会上扬，才可以创造员工、股东、以及客户的三赢。(反正我就是要做点绩效出来啦，要不年底发股票哪有份？)

大头：你讲的很抽象，依据你的评估，我们有没有什么具体的指标可以衡量这个专案的成效？有没有什么KPI(Key Performance Indicator)可以参考？(官话打完了，讲点人话来听听。)

凯莉：喔，这在我的下一张投影片里面会显示出来，透过这套系统，可以把我们输入订单的时间，从原来的30分钟，大幅缩减到10分钟。跨部门签核的动作，可以透过单一画面迅速完成…(她滔滔不绝的讲了很久，反正会有一堆编出来的好处。重点不在于真正的好处有多少，重点在于你临场时表现的有多镇定，并且曼妙的身材，加上剪裁合宜的衣服，成功吸引了多少色狼的目光。)，根据估算，可以节省高阶主管每人每天30分钟的作业时间。预计这种改变每年可以为公司节省七百万以上的费用，还可以让我们回覆订单的时间缩短百分之五十。

大头：嗯，那预计花多少钱？多久开发出来？

凯莉：我们今年编列了五百万的预算，打算在8个月内开发完成。

大头：要这么久？那个黛安，你们那个部门预计今年要做多少营业额？我记得我们上次开会是决定你们要做20亿，不是吗？你对于这个schedule有什么看法？

黛安：老板，你记错了，我们讲好的明明是18亿吧？

大头(装蒜中)：哪有这种事？你们这群娘子军这么厉害，多做个两亿不算什么吧。拿出你们的gut来。

黛安(开会都已经讲好了，哪有现在戴顶小高帽就要我多两亿，你当我神啊。每次都这样。)：老板，这个问题我们再另外开会讨论吧。我们还是先回到这次开会的主题吧。(不就是要我压缩schedule嘛，这老狐狸。还要拱我出来做坏人。)业务部门的意见是，如果要达成今年的营业目标，我想这套系统会是很重要的关键。业务部门是希望可以在3个月内就可以看到成果。

凯莉(好个黛安，我上次开会前会时，都已经跟你说好，最少要半年了，现在来个3个月)：报告副总，我们已经评估过了，八个月已经没有什么buffer了。

大头：我们也还是要照顾到业务部门的需求啦。这样吧，我们先以半年内上线为目标，剩下两个月就当做是buffer。既然时间从八个月改成半年，我想应该花个三百多万就够了吧？不要超过四百啰。黛安，那个营收的目标，我再找你讨论。

凯莉想，Yeah！Bingo！Just make：报告副总，没有问题。这个案子如果您核准了，我们就可以开始进行后续的发包作业。

接着这个案子以385万包出去。厂商一开始报了一年的工期，接着被凯莉要求要在3个月内做完。最后成交的deal是在4个月内要可以上线。

布鲁斯刚看到合约，吃了一惊：四个月？哪有可能？不是估了最少要一年的吗？

吉娜：没办法，业务部门已经尽了最大的努力了。现在景气不好，也没办法挑案子了。

四个月后，project当然delay了。凯莉好好地把布鲁斯跟吉娜修理了一顿。不过内心暗自庆幸：『还好我还有两个月的buffer。』于是在status report中，还是报告：『目前进度虽然落后，不过vendor已经努力赶工了，所以应该有机会在期限内完工。』

又过了两个月。系统依然还没有开发完成。才刚开始进入单元测试。

吉娜：布鲁斯，penalty已经要开始了，你们现在到底状况怎么样啊？

布鲁斯：我们刚把程式写完，要开始做unit testing啦。我每个礼拜status report都跟你提过，这你也知道的啦。

吉娜想，真是个不懂得人话的呆瓜：我是说，因为我们有签处罚条款，如果延迟验收测试的时间，是每天要罚钱的。你们现在到底有没有东西可以给人家测啊？我们早一点进入UAT嘛。反正只要开始进入UAT，就不会被罚钱了。反正只要系统会动，就可以给user测了嘛。不管找出什么bug，都是正常的嘛。反正UAT哪有可能没bug。当初在签合约的时候，我早就预料到这一点了。

布鲁斯想，又要这样玩喔？这样玩不是已经玩死很多次了吗？怎么永远都学不会啊？：好啦，如果你真的坚持，我安排下个礼拜开始就进入UAT。

吉娜：Good. Go ahead.

如果你没有在出厂前，把unit test/ integration test…内部的alpha test做完，为了赶进度就开始到客户端进行验收测试，提早进入UAT，对大多数人来说都是痛苦的折磨。进来测试的user个个都发现这是个可怕的地狱。

咦，怎么这个键不会动？咦，怎么流程跑一半就走不下去了？咦，资料怎么都是错的？啊，我这个月的事情做不完了，还要来测这个烂系统喔！

接着当然就会去review bug，依照大公司的习惯，咱们就来个defect review meeting吧。

在这次的defect review meeting上，布鲁斯报告了defect的种类与数量，以及一些关于defect的摘要资讯。

使用者代表辛西亚首先发难：我必须这样子说，这根本就是在浪费我们的时间，我们要测一个完整的scenario，根本就测不下去。我连最基本的输入作业都走不完，这样也要叫我们测？

使用者代表苏珊：对啊，这样的品质怎么有可能继续测下去？凯莉，你说呢？我们浪费了三天的时间也。三天也，没有一个flow是可以走到完的。

凯莉：布鲁斯，你们到底有没有测过啊？你们这样不行啦。自己都没有测好，怎么可以交给我们测？

布鲁斯想，我也知道会有这个问题啊，不过吉娜就要我进入UAT，我又不敢说不要：有啊，我们内部的测试人员有进行测试啊。(是啦，有测啦，只是连单元测试都没跑完。昧着良心讲话，这又不是第一次。)

凯莉：这差太多了吧。你摸着你的良心讲，我们打开天窗说亮话，这样真的有测过吗？你们还没有ready，就不应该浪费我们的时间。

布鲁斯做了不少辩解，不过后来的情况就是再多安排了几次新的schedule，以及新的UAT。与此同时，使用者越来越了解系统，对于系统也越来越没有信心。接着就越来越觉得这个系统跟他们要的不一样。

很多change request，就这样偷偷地溜了进来。因为schedule delay了，布鲁斯对于change request的抵挡能力也被剥夺了。吉娜答应了几乎全部的enhancement。UAT从原来的一个月，延长到超过了8个月，转眼之间系统已经开发了一年四个月。凯莉也因此被大头们盯的满头包。

或许我们该看看凯莉这边的故事。刚开始时。

大头：凯莉啊，到底你们这个系统什么时候会好啊？

凯莉：报告副总，我们现在遇到了一些问题，我想您也知道，系统开发总会有一些不可预见的问题。现在厂商已经积极在处理了，我想这个月应该就可以有初步的成果。

大头：要好好加油喔。这个系统很重要，我们业务部门已经跟我讲过很多次了。希望它可以早点上线。有什么题需要帮忙的，尽量让我知道。

就一开始来说，大家都没有什么deadline的压力，所以气氛一片祥和。接着是project Delay了一个月。

大头：凯莉啊，怎么这个系统还有这么多问题啊？现在状况到底怎么样？

凯莉：报告副总，我们现在已经进行了一次UAT，user已经找到不少bug，厂商正在修，我想我们修好了以后，可以在这个月再进行一次UAT，这次找到的问题应该就可以解决了。

大头：push他们一下嘛。有必要找采购去跟他们sales谈谈。他们的主管是吉娜吗？我来给她拨个电话。

一开始delay的不算严重时，大多数的人都可以接受这种事实。因为每个人多少都为这件事情抓了一个buffer。不过一旦超过了这个buffer，就会开始不悦了。我们可以看看Delay了两个月时的情形。

大头：凯莉啊，你不是说这个月会再完成一次UAT吗？现在状况到底怎么样了？

凯莉：报告副总，我们现在已经再进行了一次UAT，不过这次还是没有达到我们的标准。

大头打断：那你有什么action plan？我们除了被动等他们修以外，还有什么可以做的？黛安已经跟我complain了很多次了。做事要有方法啊，我们怎么可以被动的一直等他们修？你要主动掌握他们的进度啊。好，从现在开始，你每个礼拜跟我报告进度。还有，黛安跟我说，你们做的根本不是他们要的。

凯莉：报告副总，他们现在提出来很多东西，都是先前我们在规划这个系统时，根本没有提到的。在需求访谈时也没讲啊。

大头发脾气了：真的吗？不过因为这个案子的delay，已经造成他们作业上的困难，你还是要请厂商解决啊。不然因为project delay造成的问题是要谁来解决？是你来解决吗？难不成是我？搞什么飞机啊？公司找你们来，是要你做什么的？

凯莉被凶了，不敢再多说什么：我会尽力配合业务部门的需求。

通常，大头们都会相信只要挤的够大力，公牛都会被挤出牛奶来，如果这时你身陷在这个专案中，最大的差别，就看你是那匹倒楣的公牛，还是无可奈何的挤奶工人。相信我，两个角色都不怎么营养。

于是凯莉开始要求布鲁斯每个礼拜交一份status report，以便让她可以跟大头报告进度。同时她开始软硬兼施地要求布鲁斯要吸收change request。

又过了一个月。

大头：再来看我们手上这个麻烦，凯莉，你说说看现在的进度是怎么样。

凯莉：业务部门提了总共有72个enhancement，厂商评估过了，这还要再三个月才做的完。

大头发飙：三个月？那我今年的quota怎么办？你来背？

凯莉默默无语。

大头还在不爽：你们这些人做事就是不用脑袋，一点都不知道变通。你叫厂商想办法先上一个版本。你跟业务部门讨论一下，先把主要的功能先上。剩下的我们慢慢再说。

凯莉：是。

一个phase的系统，变成了两个phase，上第二个phase的时候，你就得要把现在的production data，migrate到新的系统上。而两套系统都需要测试，就会吃掉那已经很忙碌的end user的时间。所以UAT的进度会落后的更多。很多出发点是想要让系统变好的决定，即使立意良善，也会因为没有考虑到的边际效应，造成了完全相反的结果。这种事情在开发软体系统时，屡见不鲜。

好吧，又过了很久很久，终于可以上线了。

大头：凯莉，现在怎么样了？这个案子到底还要拖多久？

凯莉：业务部门的enhancement终于都做完了。而且我们UAT也过了，这一整个round都没有severity 3以上的defect了。只有10个severity 4的minor defect。

大头：喔？这倒是一个好消息。这段时间你辛苦啦。等到上线以后可以规划一下嘛，出国去散散心啊。

凯莉：谢谢副总。我这几天已经跟各部门讨论上线的时间，包含人员训练的时间，机器什么时候要shut down，migrate data…都已经在跟各个部门讨论，等到有了共识以后，我会把整个系统的roll out plan寄出来。

大头：不要忘了还要写一份contingency plan。比较major的task要做一份check list。等到这个系统launch，你就可以好好休息一下。

系统终于上线了。刚上线的一个月，布鲁斯的整个team，几乎是日以继夜地待在凯莉的公司里。终于，经过了两个月，系统已经稳定下来了，这时候也开发了一年半了。

布鲁斯：凯莉啊，我们配合了这么久，你就不要再卡我的尾款了。

凯莉：可是我们还有25个minor bug还没修也。况且上次你们程式错乱，造成我们资料不正确的资料你也还没帮我们修啊。

布鲁斯：你又不是不知道这里有多少其实是enhancement，唉，反正我们都吸收那么多了，不在乎多个一两个啦。你先把这个案子验掉，让我也做点业绩。况且我们还有一年的保固期间。算帮我一个忙。我们都已经一起co-work这么久了，你就帮帮忙吧。

凯莉：好啦好啦，可是你不可以黄牛喔。那些乱掉的资料一定要帮我们改喔。还有这些bug，要帮我们修掉。

布鲁斯：没问题。

经过布鲁斯求爷爷告奶奶一个关节一个关节的打通，这个案子终于验收了。这还算是有善终的。我不只一次看到开发专案的客户与专案团队，在投入了大把的时间与精力以后，草草结束。除了结果不如预期以外，所有投入的心血跟精力，几乎也等于白费了。留下来的当然也是一堆难解的烂摊子。如果想尽办法让它硬上了，也结案了，接着要面对的就是无穷无尽的bug以及enhancement。

当你的scope，schedule，跟quality都与你原先规划的差很多的时候，就等着再另外起一个enhancement的案子吧。就是因为有很多案子都是丑丑的上线与验收，这才让maintenance会变成一个无止尽的大黑洞。

上线之后，才是真正恶梦的开始
***********************************************
不管你做了多少测试，新系统上线，总会有你意料不到的惊喜。

有些时候，是因为你在测试时，并没有办法真实地模拟实际的状况，例如一个网站，尖峰时刻同时上线的人可能有一千人，可是你没有足够的资源，可以让你模拟同时间有一千人连上线的状况。因此当实际上线之后，这一千个人加起来，可能就把你的系统给弄死了。

这让我想到曾经在报纸上看到的新闻。大多数的男生都还蛮喜欢看A片，即使称不上喜欢，最少也不排斥。不过前一阵子新闻报导指出，警察查获大规模的A片工厂，起出了数以万计的A片。因为办案的需要，警方得要进行蒐证，也就是说每个人要日以继夜地看完数以千计的A片。他们得要整天盯着A片快转，然后把会引起生理反应的精采片段，擷取下来，做为呈堂证据。几天下来，每个负责做这种事的警察，每个都性趣缺缺，人人都觉得是一种精神上的折磨。

软体系统也是一样。有些人写的系统，在使用人数不多时，看来一切正常，就跟正常男人悠闲地在家里面看A片一样地轻而易举，是一种令人愉悦的事情。可是当使用人数多到一种数量时，这时就跟我们短时间内看了太多A片一样，系统就会受不了，做出不太对劲的反应。

熟悉测试理论的人都知道，这就是为什么我们要做压力测试的原因。对于压力测试在做什么不太了解的读者，我可以用这个例子来解释，就是把一个男生的精子先榨干，接着开始放映一百部A片，要他盯着萤幕去看，而不会睡着。

在台湾，通常我们不会做压力测试。即使做了，也大多都是做做样子。因为我们大多认为，我们的运气不会那么背。况且，对一个系统这么残忍，这是一件多么不人道的事情啊。不过实际上，你对系统仁慈，就是对自己残忍。没有好好测试系统的极限，等到上线后再来收拾残局，通常都是一件很辛苦的事情。

一般而言，即使我们要做压力测试，我们也找不到那么多的人来做真实的测试，所以大多是靠软体来模拟。然而透过软体来模拟，毕竟还是跟真实的状况有差距。再加上大多数的系统都会有上线的压力，所以稍微变通一下，总是可以想出一些办法，做出可以接受的数据，这种技术上的犯规，对大多数人来说，都是可以接受的结果。反正在大公司里面进行报告时，忙碌的大头们多半就在看你最后的数据，谁会看你的假设？这就跟很多软体在比较效能时，每家都可以宣称它在某方面赢过人家是相同的道理。基本上，没有人说谎，只是我们为了达成数据背后所做的努力，是你们没有办法想像的。

另一个问题也很类似，是资料的量的不同。我们通常为了测试时验证资料方便，资料的笔数会依照测试个案的数目来决定。真实的系统可能有上百万笔资料，可是我们在测试时，可能限于人力与时间，了不起就是有个近千笔资料。百万笔资料跟数千笔资料有着非常大的差距。因此，上线时遇到一些surprise，这也不是什么了不得的事。可是真实上线时，任何这种surprise，都会影响使用者的信心。

笔数太多所造成的最常见的问题，就是系统的performance不好，整个系统跟死掉差不多。User没有耐心以后，就想办法把跑到一半的东西中断掉，重新再来一次。跑到一半的东西，再重来一次，这可能已经远超过开发人员的想像了。会有什么结果，通常谁也不知道。

例如有些人在资料库的操作上下了max这类型的查询，想找资料库里面的最大值。在笔数少时，当然运作的轻松愉快啦，真的上线时，一旦遇上了，你就会听到硬碟呻吟惨叫的声音。系统会赏你一个漏斗，搞不好数十分钟过去了，还是一个漏斗。很多人一看到这种状况，直觉就觉得，这一定是系统有问题，系统当掉了。

根据我们从小使用电脑所累积的经验，很多人还会伸出三根手指头，卯起来把机器重开，再试一次。弄个几次以后，接着通常就会从三根手指头，转成开始骂三字经了，外国人可能会把三根手指头改成用一根中指来替代。有些时候，系统还真的有error message，例如transaction time out那一类的。这时候当然就会上演三字经加长版。举凡这种鸟事，通常都在真的上线时才会遇到。

除此之外，使用者的操作方式，或是使用者所使用的电脑超出预期，也是上线时常见的事情。

很多程式设计师的电脑，配备可能都不错，特别是这年头硬体越来越便宜，所以大家用的电脑越来越好，帮自己的电脑升级，这是所有软体开发人员最大的嗜好。如果不多插一点RAM，实在是对不起这么便宜的硬体。

可是在很多大公司里，很多end user使用的，可能会是你无法想像的老旧配备。上面可能是灌着一些几乎已经快要绝迹的作业系统。遇到这种各式各样的状况，常常会有你无法解释的灵异现象会发生。例如可能这套系统有几百个人在用，没有其他人有问题，就只有一个人的电脑，每次跑你所写的程式就会当机。我们为了这种懒得解决的东西呢，发明了一些术语，看起来比较有文化气息一点，就会说这两者『incompatible，就是不相容啦』，没那么正式的说法是，这两个东西『冲到』了。(作者注：有人说是叫相冲啦，不知道是不是取互相冲突的含意。不过不管你怎么写，应该都解释的通。)

我常常想『冲到』，这个名词到底是从那儿来的。当我看到最近越来越多的命理节目之后，才恍然大悟。所谓这套系统跟你的电脑上面所跑的应用程式冲到，指的就是你的八字跟这套系统不合，就跟小孩子跟父母相冲，就会克死家人一样，是遵循着相同的理论。所以如果你跟一套系统之间犯冲，每次只要是你要用，系统就会出问题；而别人要用，就不会有问题。这表示你会遇到这个bug，最大的原因就是你的命不好，前世又没有好好修行，这辈子才会遭此劫难。准备好三牲酒品，应时水果，加上金银财宝，再把电脑扛去庙里，请神明帮忙收收惊，再捐个一千块点光明灯，应该就可以改善这个状况了。(注：我去翻了一下java周报，管理员在2009年8月13日编辑了该文章文章。