有一天，我们的QA Lead让我谈了谈关于QA的看法，之后，对我说，我觉得你可以在QA Community活动上站在Dev的角度讲一些对QA的理解，这篇blog就是便是我所讲内容的一个总结。我知道，这绝对是一个费力不讨好的话题，因为在很多的开发人员眼中，自己是建设者，而QA是破坏者。所以，让一个开发人员在QA面前，尤其是在一群QA面前，对QA品头论足，是非常有难度的。

所以，我讲一些自身的经历。

说到QA，首先想起的便是测试。从我刚开始接触编程的时候，我就知道测试是必需的，否则，怎么能够知道自己写的程序是对的，就像考完试需要检查一下卷子一样。那个时候，除了了一些最基本的程序之外，我还写过一些有界面的Windows程序，于是，关于测试，留给我的第一印象就是点这点那，到处乱点。

工作之后，虽然知道了QA这个角色的存在，但很长一段时间都没有和QA在一起工作过，所以，客观的说，那段时间一直觉得QA是一种没有技术含量的工作。直到有一天，一个长时间没有QA的项目，能够卖钱了，领导觉得有必要提高产品质量了，于是派了个QA进到项目组。他是我后来的一个非常好的朋友，当时是部门QA方面的负责人。

我们的项目是一个服务器的应用，所以，从外部的角度来看，主要就是一个发起一个符合我们用到协议的消息包，然后看看得到的应答。其实，我一直对这个项目很有信心，因为它已经在一些地方上线运行了，而且从当时的情况来看，我们还算舒服，没有经常性的被客户从睡梦中叫醒。

QA进行的第一个测试就是发了空消息包，结果系统报错了。我第一反应是“你怎么能这么用”，是的，感情上有些接受不了，甚至有些气愤，我一向很有信心的代码，就这么非常轻松让人给弄崩溃了。稍微平静了一下，我觉得其实也没有什么大不了的，毕竟是自己的代码中真的有问题，所以才让人抓住。

经过一段时间，我越发深刻的认识到QA在项目中的作用，虽然我们在写代码的时候，已经考虑了很多的异常情况，但总还是有很多我们意料之外的情况被QA发现，随着项目的进行，发现和修改的bug越来越多，我们对自己的项目也越发有信心了，不过，回想起之前的代码，那样的产品质量也在线上运行了好长时间，多少有些后怕。

这时QA在我心目中，已经不再是那个没有技术含量的工种，我对QA开始充满了敬畏。真的是敬畏，尊敬和畏惧并存，敬的是他们总能给产品质量带来提升，畏的是他们总能不断在自己感到骄傲的代码中发现问题。和我们的QA聊过几次才知道，原来QA的工作也分验证性和破坏性的，原来他们的工作也是需要缜密思考的，原来他们的工作也是需要很详细的计划。突然发现自己曾经对QA的理解，基本上完全是门外汉的水平，误解是很让人郁闷的，就如同每每我说自己是做软件开发的，家里的邻居通常会说，什么时候有空帮我们家装台机器吧！

后来，我和这个QA兄弟一起跳槽到了另外一个部门。他的工作范围本质上说还是在QA的范畴。由于这个部门做的是偏研究性质的，所以，他的工作名义上称为验证，主要是看部门研发的算法有多大的进步。最开始的时候，一般是一周做一次验证，主要的原因就是因为运行加上总结需要很长的时间，于是，这位兄弟想办法开始把一些工作自动化，随着自动化程度的提高，验证周期也逐渐缩短，后来，我离开了这里，据说，现在这个自动化验证系统已经达到了很方便的程度，只要敲一下命令，它会自动部署到几台机器上运行，然后，搜集结果产生报表。就这样，原本一周一次的过程，简化到几乎随时可以做。如果让我选择这个部门产生出最有价值的东西，我会把票投给这个自动验证系统，甚至超过了部门研发的算法，只可惜养在深闺无人识。

为了讨论这个关于QA的话题，我问了自己一个问题，为什么QA能够想到我们开发人员想不到的地方。我自己给出的答案是，二者站的角度不一样。开发人员通常是站在实现的角度，所以，通常我们会更多的关注如何把这个功能做出来，也就是规定动作，而QA是站在用户的角度，如同我们自己使用软件通常是不会看软件使用手册一样，QA总会用到一些规定动作之外的用法，也就是自选动作，所以，二者之间必然存在一些差别。既然存在差异，QA发现一些自己无法发现的东西。

如同我之前对QA有一些误解，想必也有很多开发人员对QA也存在一些误解。所以，对于QA而言，增加与项目成员之间的沟通应该是一个很好澄清误解的方式。沟通，对于任何项目都很重要，不仅仅局限于开发人员和业务分析人员之间，QA也应该是这个沟通环节中重要的一部分。只要有可能，QA都应该是从项目最初介入，这样一方面保证了QA与项目成员之间在一开始就建立起良好的沟通环境，另一方面，他们的经验和技能可以保证大家在最初的阶段就注意到一些问题，正如我们QA Lead在Agile China所讲的一样，Build Quality In。

这个关于QA的话题的最后，再聊聊ThoughtWorks QA。作为一个ThoughtWorker，除了做好自己本职工作之外，我们也要把自己工作中总结出的好的方面告诉别人，无论是以文章、blog或是讲演的方式，所以，QA也不应该例外。

在关于CodeJAM的那篇blog中，我写道，希望将来有机会把这个面扩大一些，让其他公司的人来和我们一起来做。

周末没有休息，和几个同事参与了一个类似于CodeJam的活动，两天做一个小系统，开发工具还是ROR。不同的是，这次是和客户的开发人员一起工作。

客户的开发人员之前没有接触过ROR开发，所以，这次活动开发的需求，可以说是小得不能再小了。与其说这个活动是为了开发这个系统，倒不如说是给他们进行一个展示，一方面，展示我们的工作方式，另一方面，展示ROR开发的威力。

最初，我并不了解和我们一起工作的这些开发人员的水平，所以，我以为主要的精力要放在开发上。等我真正开始工作，写上几行代码的时候，我才发现，对于这些从来没有了解过Ruby和Rails的人来说，就是简简单单的几行代码，也需要我用大量的口舌去解释。这时，我突然意识到，对这个项目而言，写多少代码其实已经变得不那么重要了，同他们的沟通，远要比写几行代码重要得多。

虽然和我们一起开发的这些人都有一些开发经验，但他们之前的工作经验并没有给他们提供像我们这样开发的机会，所以，需要解释的，不只是ROR的技术，更多的是一种工作方式。比如，第一天下午的时候，我几乎大多数时间是在和人解释测试，不是如何TDD，而是讨论为什么要做测试，以及测试和业务代码的关系。他们会问，我写完一个功能，刷一下页面，看看结果不就可以了，为什么要写测试，他们会问，测试代码在运行时起到怎样的作用，他们会问，如果测试不影响业务代码，我为什么要写它，等等。这个时候，我不得不把思路拉回到我刚刚接触这些概念的时候，给他们提供一个合理的解释。

总结的时候，这些开发人员普遍的感觉是大开眼界，这时，有一种自豪感在心底升起，正如gigix所说，这种一出手就能给人带来震动的感觉，很好。

这是一个非常好学的团队，在开发过程中，他们会不断提出各种各样的问题，因为我们所做的几乎一切都与他们原有的工作方式有着巨大的差异。两天时间，不仅仅是我，所有参与这次活动的ThoughtWorker都解释了大量的东西，以致于每天结束时，都会有一种口干舌燥的感觉。

不过，他们也有一些担心，如果我们离开，失去了我们的支持，他们该如何走下去。这是一个非常好，而且也非常现实的话题。这种开发方式在ThoughtWorks是一种理所当然，而在他们的开发团队，因为原有开发习惯在作祟，会让他们遇到很多问题。我们能够给出的，只是一部分建议，可能要他们更多的探索和坚持，以及也许日后与我们的进一步合作。

对于他们而言，这是改变的开始。

上周末，Agile China，因为家里有些事，我没有参加。

作为一个ThoughtWorker，错过这次活动的遗憾并不是像之前以为的那么大。首先，这次活动所涉及到的内容，大多是内部讨论或是讲座涉及到的东西，再有，这次活动做得比较好的地方是很快就放出了活动的讲演稿和视频，所以，可以随后弥补一下错过现场的遗憾。

真正值得遗憾的是，错过了一次与人交流的机会。

有时，我会想，公司为什么要举办Agile China这样的活动。在ThoughtWorks的工作这段时间，敏捷已经成为了一种工作习惯，我甚至不觉得它有任何特别的，对我而言，它只不过是一种恰当的工作方法而已。与很多书上介绍的敏捷方法，几乎没有太大的差别。

最近，一个朋友给我写了一封邮件，给我介绍了一些他心目中应该如何做持续集成，这是他读了一些东西加上了一些自己思考的结果。不过，在我看来，所有这些内容和我日常工作中使用的持续集成差别几乎没有。显然，当这些内容还停留在他思考中的时候，我们已经在实践了。显然，他对这方面的了解还是有些不足的。事实上，这位朋友也很愿意提高自己，只是周遭的环境能够给他的帮助太有限了。

和Darwin聊过，ThoughtWorks带给我们的并不是直接技术上的进步，而是为我们打开了一扇窗。与不同的人交流，会让我们拥有更开阔的视野，总有很多新鲜东西在等待我们了解。

还是那句话，敏捷不过是一种恰当的工作方式而已。对比于所谓的传统开发方式，敏捷给人的感觉是很不同，但如果真正在工作中使用它，消除了它的神秘面纱，也不过如此。但真正有多少人能在工作中使用。它这是一个问题。只读几本书，照着几个实践去做，就“敏捷”了吗？未必。看到很多人在抱怨敏捷，不过，很多说法都是想象或是教条的结果。

公司举办的Agile China实际上是一种经验分享，告诉大家，我们在做什么。正如我前面所说，这些东西其实并不是什么新鲜东西，但对于不了解它的人来说，它就是新鲜东西。

闭塞，是阻碍人不断进步的绊脚石。

当意大利顶着世界冠军的头衔来到欧洲杯的赛场，没人会怀疑它会从小组顺利出线，尽管它所在的是所谓的死亡之组，毕竟失去齐达内的法国如同失去了灵魂的人，巴斯腾的荷兰总是给人激情有余、实力不足的感觉，而罗马尼亚，它的辉煌可能还停留在哈吉的年代。

小组赛前两轮，似乎一切一切都在朝着不利于意大利的方向发展。荷兰一下子成熟起来，3:0斩意大利于马下，4:1横扫法国，对世界杯冠亚军的一视同仁让荷兰一下子成了欧洲杯冠军的头号候选。而首轮0:0沉闷战平法国的罗马尼亚，面对意大利的时候，突然被激发出无穷的活力，与意大利打了一场激情四溢的比赛。在这场比赛里，裁判似乎对世界冠军并不友好，上半场让托尼的进球化为乌有，下半场又判给了罗马尼亚一个点球。

意大利是一支奇怪的球队，每当站到悬崖边上，它总能爆发出惊人的能量，82年的足球丑闻和06年的电话门为意大利带回了两座世界杯。这一次，意大利又一次站到悬崖边上。这一次，布冯发挥“失常”了，作为队长的他，扑出了穆图的点球，让意大利保留住出线的最后一线希望。

两轮战罢，没有人看好意大利，有人在替荷兰谋划着败给罗马尼亚，挤掉世界杯冠亚军。

当世界杯冠亚军再次站到一起，早已没有了06年的光环，多少还有一丝的苍凉。毕竟他们为之而战的不再是金杯，而仅仅是一个小组出线名额，甚至胜利者都无法掌控自己的命运。

老天在作弄意大利未果的情况下，于是，选择了作弄法国队。

开赛不久，新一代法国攻击核心——里贝里便在一次拼抢中受伤下场。如果说这只是作弄的序章的话，那么，头两场表现可以用失常形容的皮尔洛开始把这场作弄推向高潮。第25分钟，皮尔洛用他最擅长传球方式，将皮球送到禁区里面那个守门员无法出击而又在后卫身后的位置，托尼恰到好处的挺球，让客串中后卫的阿比达尔只有在背后犯规。点球、红牌！

在AC米兰已将头号点球手位置让给卡卡的皮尔洛，又一次站到了点球面前。事实证明，复活的皮尔洛是无可阻挡的，1:0。如果说还有比被红牌罚下的阿比达尔更郁闷的话，也许就是纳斯里，这个开场替换里贝里出场的法国小将，还没来得及把身体跑热，就因为这次犯规带来的人员调整，被一个中后卫换下。

在这场比赛中，复活的不仅仅是皮尔洛，还有米兰的新后卫赞布罗塔。于是，两个复活之人，开始在法国后防线面前一次次送出威胁球。如果不是德甲今年的头号射手——托尼忘记带来得分能力，也许意大利早早就会大比分领先。与之形成鲜明对比的是，赛场的另一端，法国前锋亨利和本泽马，两个人只留下孤独而无奈的身影。

下半场开始不久，换下9个主力的荷兰队打进罗马尼亚一个球，意大利人看到了出线的曙光。巴里混小子卡萨诺的盘带为意大利队赢得了一个禁区正面的任意球。这时，头号任意球手皮尔洛已经离场。站在任意球面前的是罗马新贵——德罗西，他也是意大利的新10号。当他的重炮轰出，亨利——没能将足球送入意大利球门的法国前锋，无意中用脚尖改变了足球的方向，法国门将回天无力，2:0。

当荷兰队攻入第二球的时候，意大利人开始庆祝了，他们抓住了救命稻草，成功上岸！

bug这种东西，只要存在，早晚会暴露出来，即便是深藏25年。不过，我们了解到的bug大多不具备很深的资历。有些不幸的bug会被QA们扼杀在摇篮之中，稍微强壮一点的也许可以生存到系统发布之后。

拜IE6所赐，我们的系统刚刚上线，便有一个bug浮出水面。经过验证，这是IE6处理直接打开附件（如PDF、PPT等）的错误。不过，好在这是一个广泛遇到的问题，使得这个bug连午饭时间都没有坚持到，便被消灭了。

按照对客户的承诺，我和另外一个同事要在办公室支持到晚上10点。上午的时候，我们的QA和客户努力了三个小时，并没有发现其它问题，于是，我们想当然的认为我们可以按“点”下班。就在我们俩准备收拾东西回家睡觉之前，从睡梦中醒来的客户终于发现了bug。于是，我们只好在深夜来临之际，开始了bug征服之旅。

有bug不是什么坏事，发现总是比不发现好。

在客户和PM压力之下修改代码并不是什么愉快的经历，好在bug们都是一些友好的家伙，很容易就定位到。不过，因为客户在线，所以，必须强迫自己把事情做得尽可能按部就班：本机测试、提交到主干、提交到分支、部署到测试环境……

感谢之前大家辛勤努力编写的测试，让我们很容易就知道自己的修改在系统内会造成怎样的影响。通过所有测试的那一刻，心头如释重负。在这个原本很是紧张的时候，多了一份自信。我喜欢这种感觉，虽然忙碌，但依然从容，一切尽在掌握之中。

这个无眠的夜里，身边还有自己的Pair，有专程赶来帮助我们进行验证的项目组的老大哥，当然，还有一直都很辛苦的PM，一个敬业的团队。

一起想一下，程序发布之前的情形。

印象中，这应该是一个手忙脚乱的阶段，一大群人奔前跑后，忙着处理各种各样的问题，尤其是bug。许多人回忆自己经历的时候，往往会很有成就感的说，在某某程序发布之前，忙了一整夜，终于在程序发布之后，回到家里，一觉睡了N个小时，俨然一副历经沧桑的样子。自己经过的，既有有过连续十几天工作十几个小时，为了赶上发布日的经历，也有连续几个熬到后半夜改bug的痛苦。虽然这些都是不错的日后谈资，但当时，那是透支的感觉。

现在，我在等待发布。

是的，等待！

Story的开发工作早就已经完成，bug修改也到了尾声。代码已经冻结，Mingle上可供开发的卡已无踪影，有一种闲暇无聊的感觉。

这已经不是第一次体验发布前的闲暇了。记忆中，最近做过的几个项目，到了最后的几天，都会出现无卡可做的情况。最极端的是有一次，在PM的陪伴之下，打了多半天的游戏。

对比之前的经历，这样的经历显得很特别。原本在我的印象中，越是临近发布，应该越是忙碌，而这种一下子闲下来的感觉，真的是让人有些不适应。

这个时候，PM就成了给大家找事的人。比如，他会组织大家进行一些讨论，看看之前那些做得好，做得不好，以便在后续的工作中进行改进。比如，他会把一些属于下一个阶段的任务拿过来，让大家分析一下，提前热热身，有些手快的家伙，甚至会顺便把一些任务做完。

这样难得的清闲，多半要归功于合理的计划和控制。其实，想想之前的经历，最终期限并不是合理规划出来的。事实上，大多数情况下，对于要做什么，以及这些工作的工作量究竟有多大，并没有很好的估计，所以，往往就是指定一个发布的日期，剩下的就是靠人了，其结果就是为了赶上发布日期，拼命的加班加点，那种透支需要很长一段时间才能恢复过来。

而现在做项目，所要做的一切都是经过大家一起估计出来，包括客户和开发团队，大家对于软件开发的实质认识得比较清楚，所以，不会做一些杀鸡取卵的事情，于是，所有的一切，都会按照预期一步步进行：开发团队也不会为了追赶进度，而损失了软件的内在质量；客户会重新认识他需求的价值所在，做好优先级排序，而不会不明就里的要求全部完成。这是一个合理的开发过程，一种软件开发应有的状态。

准备发布了！

有人问我，在目前这个项目中，和外国同事一起工作的感觉如何，我答曰，他们更职业。

这里说的职业，并不是说他们写出的程序本身有多么神奇，恰恰相反，他们写出来的程序和我们写出来的程序，看上去并没有多大的差别。之所以，他们给我留下更职业的感觉，主要是日常工作的一些细节。

刚开始进入项目的时候，我们几个中国同事对项目完全是一头雾水，甚至Rails开发都很少，所以，在和他们一起工作的过程之中，就需要他们为我们做大量的解释，而这种时候，他们总是表现得非常耐心。有时候，语言上的障碍让我们不能一下子抓住他们说的重点，他们就会不厌其烦的一遍遍解释着，直到我们表示自己真正的理解了。

刚刚入门的人难免会问一些愚蠢的问题，他们并不会嘲笑，反而会认真的给你讲解，这会给人以极大的信心，不会因为问题的愚蠢而被打击了积极性。回顾自己之前在工作中的表现，在这一点上，我做得总是很不够，我愿意给人解释一些问题，但对于简单的问题，我有时会表现得不屑一顾。实际上，谁没有从笨笨的初学阶段走过来呢！对于初学者，鼓励的作用更大一些。最近一段时间，我会和几个新近加入项目的同事一起工作，自己刻意在这个方面注意了一下。

前些天，有一些来自产品环境的任务，要对产品数据做一些修改。这些外国同事对这种问题的想法是，写个脚本解决它，即便数量不是很大。所以，那几天几乎每天都是在写脚本。其实，对于数据量不大的一些修改，手工修改可能来更快，但是，每次都用脚本解决问题，一来可以锻炼一个用脚本解决问题的好习惯，二来可以避免做一些让自己头疼手工操作，将其转化为编程问题，解决起来更有乐趣，再有，以后遇到类似的问题，有之前的脚本可以参考。这里不得不说一下用Ruby写脚本还是很方便的，Rails项目的开发和维护都用Ruby，很大程度将二者统一起来。

项目进行性能测试，一个外国同事将测试结果放到了一个电子表格中，做成了动画效果，很高兴的给秀给我们看。因为在他看来，那是一件有乐趣的事，尤其是一群人乐呵呵的围绕在他身边看他的工作成果。

我们的开发平台是Mac，基本上就是一个Unix平台。所以，我们的外国同事经常会给我们展现他们良好的运用Unix命令的能力。他们经常将一些Unix命令组合起来，完成一些辅助开发的工作，很大程度的提高了工作效率。

在我们项目的Mingle里面，有一个Dev Standup的页面。在日常的开发中，一些解决起来会有些困难部分或者影响会比较大的部分，就会记录在这个页面里面。一方面，分布在中国和美国的同事都有机会知道对方做了些什么影响比较大的部分，另一方面，双方也可以协作解决一些对方觉得头疼的问题。

在ThoughtWorks做程序员，幽默感是不可缺少的一环。所以，经常会出现这样画面：“你能帮我一下吗？”，“不”，然后，一个人过去问什么事；“一个问题”，“一个答案”；两个人正在讨论，有一个人过来说“我觉得有道理”，另一个过来说“我不这样认为”……

这是一个全国哀悼的日子，为那些在地震中逝去的生命。

关于地震，我一直想写点什么，又不知从何下手，因为我着实不是一个愿意记录悲伤的人。但我还是决定写一些东西，让思绪飘散一下。

这注定不是一个平静的年景：雪灾，火车相撞，地震。国难让中国人空前的团结起来。

对我而言，今天也是姥姥过世三周年的纪念日。我是姥姥一手带大的，对姥姥有着深厚的感情。所以，我深知亲人离开的痛苦。地震让那么多人失去了亲人，对于活着的人，那是一种折磨，无论你怎样的坚强。

和老妈通电话，她对于地震的记忆要比我深刻，因为75年的海城地震和76年的唐山地震，对于家里都是有影响的。因为曾经离地震很近，所以，她更知道今天的地震意味着什么。

地震时，我以为自己眩晕，后来，才意识到不对，但也并没有往心里去，因为念高中时，学校离矿区很近，矿里放炮的时候，就会感到楼在晃。当我得知地震发生在四川，北京可以感到明显的震动，我知道这会是一场灾难。

其实，最近一段时间，我有意无意在回避关于地震的消息，因为我知道，那些消息会让自己心痛。

有人以为，有些公司或个人捐款是在作秀。如果真是这样，我希望这样的秀越多越好，只要是对灾区有益的。

默哀那一刻，站在办公室里，耳边是响亮的喇叭声和警报声，思绪是混乱的。

自然面前，人很渺小。这是我写在自己饭否上的一句话。渺小的一方，价值何在？在抗震救灾的过程中，一个个感人的故事给了我们答案：人性的光辉。

今天到CSDN参加了一个关于开源的讨论，谈到了自己参加开源项目的感受，也谈到了公司的一些情况。关于自己的部分，前前后后在blog里提到了不少。这里稍微整理一下自己对公司开源情况的一些理解，不见得完全正确，只是基于自己看到的和理解的，如果哪位同事觉得不对或不足，不妨站出来纠正或补充我。

ThoughtWorks是一个咨询公司，这意味着我们有很多机会参与到不同领域的开发之中，也就让我们的经验可以得到不断丰富，更重要的是，我们有机会知道哪些经验是可以复用的。一些可以被复用的知识就在开发过程中被识别出来。ThoughtWorker们是一群愿意不断把事情做得更好的人，于是，就会有一些人把这些可以复用的部分提炼出来，将其开源，把这些知识分享到给社区。据说，CruiseControl、RubyWorks就是诞生自ThoughtWorks的实际项目。

ThoughtWorks最有价值的部分是人。和这样一群人一起工作，只要你把自己的想法抛出来，就会有人愿意与你讨论。相信大家都有类似的经验，很多时候，自己想一个问题很容易走进一个误区，而和别人稍微讨论一下，即便这个人的言论本身并不能给你带来太多的价值，但这个讨论的过程会让自己的思路逐渐清晰起来。ThoughtWorker们是一个巨大的思想来源，这样一群人之间的讨论经常会激荡出各种各样的火花。一个业余的例子是上周五下班之后，一群人玩编故事的游戏，其结果是包括周边的人在内，大家都已经乐得直不起腰了。

开源，需要一个环境。如果周围的人都在做开源，自己就会以为开源是一件理所当然的事情。列在公司开源网站上的项目，其实那只是一些比较知名的项目，也是冰山一角。平时，不经意间和某个人聊天，你就发现，原来身边的这个人正在做一个开源的东西。大家在一起讨论的时候，也经常可以听到这样的话，那就不妨开源一下试试。陶公子最近发起了一个关于Domain Model的讨论，我就对他说了类似的话。

公司内部有一个Innovation Community，也就是说，公司是鼓励大家进行创新的。经常会收到公司内部关于Innovation的邮件，介绍一些最近一段时间有人做的一些事情。其中很重要的一环就是一些ThoughtWorker新近发起的一些开源项目。gigix最近就在一次Innovation Community活动上，介绍了fluorida。

如果一些开源项目能够证明自身的价值，公司也是愿意投入一些精力将它完善。Selenium和CruiseControl就是这样在ThoughtWorks的协助下，得到了快速的成长。当然，不只是公司员工的项目，对于一些其它有价值的项目，公司也会投入一定精力去做，比如Ruby和JRuby。

有了这样的土壤，开源也就变得自然而然。

敏捷软件开发中，与客户的沟通是一项必不可少的内容，因为只有客户才知道他们自己想要的是什么，只有他们才真正了解自己的业务流程。于是，在ThoughtWorks，客户来访是很常见的，这不，我们的客户今天就来了。

一大清早，客户就到了办公室，他们给我们做了一个关于项目的介绍，让我们有机会聆听一下真正使用这个系统的人究竟如何看待这个系统，他们为什么会有这样的业务流程，在他们看来，哪些东西才是最有价值的部分以及他们希望这个系统未来会在他们的工作中起到怎样的作用。虽然在这个项目也工作了一段时间，但我也只是知道有哪些东西，对于为什么是这样，完全没有概念。今天客户的到来算是给我们补上了欠缺的一课。

对于开发者而言，客户到来的作用很直接的体现在某些细节问题的确定上。通常，我们有了问题会问我们的BA（业务分析师），但BA不能给出答案的部分，就只能等待客户的回答了。原本因为时差的关系，一旦涉及到客户，这个过程至少需要一天。而如今客户就在身边，一旦我们有了问题，几乎瞬间就可以得到解决，开发周期大大的缩短。当然，客户不会一直在这里，所以，趁着客户在的这几天，我们要充分发掘他们的作用。

以前也曾经历过客户到来，但这次给我留下的印象却特别深刻。因为，客户让我们近距离的接触到他们的业务。

我们的项目是一个关于宾馆审计的项目，简而言之，有人制定标准，有人按照标准进行检查。虽然听起来很简单，但是系统里面的概念却离我们很远，很难想象究竟是什么样子的。今天，客户就带着我们亲身体验了一下做审计的感觉。

我们去的是客户旗下的一家五星级宾馆，宾馆的总经理带着我们在宾馆内部进行参观，过程之中，还为我们解释了很多真正的检查过程中会出现的问题，在这个过程中，一个个曾经因为写程序而听说过的名词不断的出现在耳边，那个曾经遥不可及的概念，一下子变得异常清晰。上午的讲解和晚上的参观让这个系统变得更加真实了。以前只是住过宾馆，还从来没有从其他角度想过问题。今天的参观，明显是抱着“找茬”的心理。顺便说一下，我们的“审计”还真起到了一定作用，有人在宾馆的游泳池边上的宣传牌上发现了错别字。

客户到来，还有一个很直接的好处，那就是，给了我们一次team building的机会。即便单从这个角度说，我们也总是欢迎客户来访的。^_^