拉卡拉便利支付服务：

信用卡还款

手机充值

支付宝充值码和交易号付款

网上账户充值

拉卡拉账单号支付

游戏点卡

公共事业缴费

自助银行，包括余额查询及跨行转账服务

期刊订阅

小额保险

拉卡拉针对个人的服务项目已经有10项了，并扩展到18个省，30个城市，2万个网点，由于和便利店的合作，更贴近社区和大众。

不过拉卡拉要实现盈利还需要依靠中小企业的合作，个人的充值手续费基本无法维持运营。

拉卡拉自己还是蛮看好线下便利支付方式，还在自己的网站上提供了一些调查数据：

2008年中国线下便利支付市场运营商终端份额

中国线下便利支付市场交易规模趋势预测

中国线下便利支付市场用户年龄特征

中国线下便利支付市场用户使用满意度

BTW：目前支付宝，快钱等都不是从个人用户身上盈利

PS:拉卡拉网站

http://www.lakala.com/

拉卡拉的新渠道

拉卡拉：便利店 大市场

可惜还很乱，要慢慢收拾了，顺便也好好休息下。

Now it seems that, their toilets notwithstanding, Google focuses on testing with an intensity that is in the same general ballpark as ours. We both take the discipline and the people who do it seriously. But I think that there are some insights into the differences that are worth pondering.

Specifically, the disparity between our respective developer-to-tester ratios is worth a deeper look. At Microsoft the dev:test ratio varies somewhat from near 1:1 in some groups to double or triple that in others. At Google just the opposite seems to be the case with a single tester responsible for a larger number of bug-writing devs (clearly we have that in common).

So which is better? You tell me, but here are my thoughts (without admission of any guilt on Microsoft’s part or accusations against Google):

1.       1:1 is good. It shows the importance we place on the test profession and frees developers to think about development tasks and getting the in-the-small programming right. It maximizes the number of people on a project actively thinking about quality. It speeds feature development because much of the last minute perfecting of a program can be done by testers. And it emphasizes tester independence, minimizing the bias that keeps developers from effectively testing their own code.

2.       1:1 is bad. It’s an excuse for developers to drop all thoughts of quality because that is someone else’s job. Devs can just build the mainline functionality and leave the error checking and boring parts to the testers.

It’s interesting to note that Microsoft testers tend to be very savvy developers and are often just as capable of fixing bugs as they are of finding bugs. But when they do so, do devs really learn from their mistakes when they have someone else cleaning up after them? Are testers, when talented and plentiful, an excuse for devs to be lazy? That’s the other side of this debate:

3.       Many:1 is good. When testers are scarce, it forces developers to take a more active role in quality and increases the testability and initial quality of the code they write. We can have fewer testers because we our need is less.

4.       Many:1 is bad. It stretches testers too thin. Developers are creators by nature and you need a certain number of people to take the negative viewpoint or you’re going to miss things. Testing is simply too complicated for such a small number of testers. Developers approach testing with the wrong, creationist attitude and are doomed to be ineffective.

So where’s the sweet spot? Clearly there are application specific influences in that big server apps require more specialized and numerous testers. But is there some general way to get the mix of testers, developers, unit testing, automated testing and manual testing  right? I think it is important that we start paying attention to how much work there really is in quality assurance and what roles are most impactful and where. Test managers should be trying to find that sweet spot.

ps:http://blogs.msdn.com/james_whittaker/archive/2008/12/09/google-v-microsoft-and-the-dev-test-ratio-debate.aspx

http://www.infoq.com/cn/news/2009/04/testing-roi

2.选择哪个SOA测试工具？

http://www.infoq.com/cn/news/2009/03/soa-testing-tools

社区

.NET,

Agile

主题

工件和工具,

敏捷技术,

单元测试

标签

测试,

测试驱动开发,

采访

Tellurium自动测试框架是一款针对web应用、基于UI模块的自动测试平台。UI模块是由一组复合的UI对象以嵌套的形式组成，比如，Google的搜索UI模块可以表示成：

ui.Container(uid: "GoogleSearchModule", clocator: [tag: "td"], group: "true"){
   InputBox(uid: "Input", clocator: [title: "Google Search"])
   SubmitButton(uid: "Search", clocator: [name: "btnG", value: "Google Search"])
   SubmitButton(uid: "ImFeelingLucky", clocator: [value: "I'm Feeling Lucky"])
}

Tellurium框架还定义了一套全新的领域特定语言来进行web测试，比如对于Google搜索模块，你可以使用下面的DSL来完成一次搜索测试：

type "GoogleSearchModule.Input", "Tellurium test"
click "GoogleSearchModule.Search"
waitForPageToLoad 30000

目前Tellurium已经发布0.6.0版本，InfoQ中文站就Tellurium的方方面面，特地邮件采访了Tellurium的创始人方剑先生：

1、请介绍一下您自己，以及所从事的工作？

我的名字是方剑，曾经在上海读书和工作多年。2000年在美国佐治亚理工（Georgia Institute of Technology）求学。毕业后在一家美国公司做软件开发工作，从事企业级应用（Enterprise Applications）开发，主要负责服务器端框架的设计和开发，商业应用服务（Business Services）的开发, 和一些软件规范的制定。此外，我还有很强的人工智能和计算机网络方面的研究背景。

2、您开始做Tellurium这样一个自动化测试框架，是基于怎样的考虑呢？我看到有特色的两点是使用UI module-based这样的描述块来定义待测的UI，以及使用DSL来表述测试代码，还有哪些与以往框架不同的设计思想，缘起是什么呢？

在2007年，我们公司开始注意到Selenium测试框架。由于我们用敏捷开发方法（Agile development），在Scrum队伍中，每个人的角色开始变得多样性了。我有个工作（Task）就是用Selenium去测试我们的一个应用程序（是用Dojo Javascript框架写的）。应该说在当时，Selenium是一个开创性的框架，如果用他们的复制和重播模式（record and replay）很容易产生测试脚本。但一旦我开始用Selenium，我发现它还是有一些缺点和不便之处。主要测试脚本是对代码的更新很脆弱（Fragile）。 但是在一个敏捷开发的环境下，一般都有阶段性的用户接受测试（User Acceptance Test），由于程序一直更新，Selenium测试脚本的维护就变成一个很头痛的问题。而且，对于很多企业级应用，复制和重播模式本身就不太适用，比喻我们有很多数据格（Data Grid），它的内容本身就是动态的。其他的问题包括Selenium测试脚本不是结构化的，你可以看到处有XPath，这更增加了维护的困难。因此，我们决定开发一个在Selenium之上的框架来解决这些问题。我做的第一个版本是通过Spring框架和物体工厂（Object Factory）来产生UI元素（Element），使得框架能把UI元素的表达和测试代码分开，自动处理Javascript事件，并在一定程度上能处理动态网页内容。

由于这个框架用XML来配置UI元素，使用起来并不是很方便。在2008年，我用Groovy重写了整个框架并变成一个开源项目（open source project)。新的版本主要有三个大的改变。首先是采用UI Module（UI模块）描述块来定义待测的UI。这样做的好处是系统自动生成运行时的Locator，即使你改变了其中的一些元素，框架本身会生产新的 Locator来适应这种改变。而且框架侧重一个集合的元素，而不是单个元素，这样使得我们可以利用元素之间的关系来帮助我们定位他们在DOM中的位置。此外，这样也增加了重用性，比如，我们可以定义一些Tellurium Widget，在你的测试代码中可以直接定义这个Widget，而不需要重新定义一个个的单个元素。第二个大的变化是用DSL来写测试代码。这样增加了表达性使得用户很容易写和维护测试代码。Tellurium测试代码可以用Java, Groovy, 或纯DSL脚本来写。Tellurium本身也支持JUnit和TestNG测试框架。另一个大的变化是开始用UI模板（UI templates）来表述动态网页内容，例如数据格（Data Grid）。这样使得Ajax应用程序的测试变得可行和容易。

3、 Tellurium主要有那些子项目构成？

Tellurium主要是由Tellurium Core, Tellurium Engine, Tellurium Widget Extensions, 和Tellurium UI Module Plugin（TrUMP）子项目构成。Tellurium Core主要是处理DSL和动态生成Locator. Tellurium Engine是测试驱动模块，目前还是利用Selenium Core. Tellurium Widget Extensions包括一些DOJO和ExtJS Javascript框架的可重用Widget模块。这些Widget被编译成一个jar文件方便用户调用。TrUMP是一个Firefox plugin来自动生成UI Module。

另外，Tellurium还提供两个参考子项目（Reference Projects），分别为JUnit和TestNG项目，来给用户示范如何创建Tellurium测试项目和如何使用Tellurium的各种功能。

除此之外，Tellurium还提供了Tellurium Maven Archetypes，使得用户可以用一个Maven命令就可以创建自己的Tellurium测试项目。

4、介绍一下Tellurium的代码贡献者们吧？

我主要是负责Tellurium的整体设计和很大一部分的代码编程。除我之外，现在还有四个来自美国和英国的队友（team members）。Vivek Mongolu主要负责TrUMP的UI设计和实现。Matt Senter主要负责Maven支持，包括代码的编译，发布，和Maven Repository的维护。Haroon Rasheed参加了Tellurium参考项目（Tellurium Reference Projects）的开发，Selenium Grid的支持和其他的维护工作。Mikhail Koryak参于了TrUMP的开发工作，他是jQuery方面的专家，负责Tellurium的jQuery支持。现在参与Tellurium Engine的开发。

5、你了解在自动化测试工具这个领域，有着哪些和Tellurium类似的竞争对手吗？比如ThoughtWorks的Twist？与它们相比，Tellurium的优势在什么地方？有什么劣势吗？

Tellurium脱胎于Selenium,它的主要竞争对手还是Selenium, 毕竟Selenium已经推广好几年了。要用户用一个新的框架是要花一定的时间的。此外Canoo WebTest也是一个比较流行的网页测试框架（Framework）。但是Tellurium还是有它本身的优势的，如UI Module的概念，鲁棒性好，可重用性好，表达性好（Expressiveness）。用Tellurium写的测试代码的结构性好，比较容易维护。

毕竟Tellurium还是一个新的框架，到现在只有一年多的开发时间。有些特色还有待成熟。此外，Tellurium要用到Groovy动态语言，尽管用户并不一定需要了解Groovy才可用Tellurium，但由于Groovy相对比较新，所以不少人还是有疑豫的。

ThoughtWorks的Twist基本上是Selenium + GSpec, 就是在Selenium之上增加了行为测试（Behavior Driven Test）的DSL。其实我很早就考虑到对行为测试的支持，但精力有限，Tellurium目前还没有这方面的实现。将来会增加的，可以和EasyB框架结合来支持行为测试，或直接实现对行为测试的支持。

6、现在Tellurium的应用情况是怎样的？来自使用者的反响如何？

现在已经有不少Tellurium用户，主要来自美国，印度和欧洲。由于Tellurium本身的特色，如易用，可维护性好，新的功能如对jQuery Selector的支持，使用者的反应还不错。甚至有的用户在自己的公司里给同事作Tellurium的培训。当然，Tellurium还很年青，而且前一段时间由于全球性经济危机的影响，我们对Tellurium的推广还做得很不够。以后会加大对Tellurium的推广。

7、Tellurium在社区采用了哪些方式和开发者们进行交互呢？

我们有自己的用户组Tellurium user group, 用户提出问题往往能很快地得到解答。我们也有LinkedIn用户组让用户之间能更好地交流。此外我们还鼓励用户参加Tellurium的设计讨论和推广。我们会每年从用户中推选出一个最活跃用户（most active user）和一个最有价值用户（most valuable user）。Tellurium将来会设推广队（Evangelism Team），如果某人对Tellurium做了很多推广工作，他／她也可以成为Tellurium正式成员（team member）。

8、Tellurium未来的发展有怎样的规划吗？有计划推出中文的社区及文档吗？

尽管Tellurium和Selenium在概念上有很大的不同，一直到Tellurium 0.6.0, 我们还是依赖Selenium Core作为底层的测试驱动Engine. Tellurium 0.7.0将成为Tellurium发展史上的一个重要里程碑，我们将开发自己的测试驱动Engine使得Tellurium能更好，更有效地支持UI Module，同时可以进行UI Module的缓存（Caching）以增加其可用性和提高测试速度。并可对UI Module进行部分匹配以增加其鲁棒性。在新的Tellurium Engine的支持下，Tellurium widget将变得更容易，更实用，和更有效。其他的发展规划包括TrUMP的改进，行为测试（Behavior Driven Test）的支持，功能测试（functional test）的增强支持, 和IDE的支持。

毕竟我来自中国，当然希望得到更多的来自自己国家的用户的参与和支持。现在我们已经开通中文社区和文档项目，会有相关的中文文档逐渐添加进来，我们也热烈欢迎更多国内的开发者能加入进来，帮助支持和推广Tellurium，谢谢。

9、能给国内的用户一个快速的开始吗？怎么立刻感受到Tellurium带来的好处？

我们提供了一份中文版的Tellurium QuickStart，还有一个短小的演示：十分钟感受Tellurium（10 minutes to Tellurium）。它包括利用Tellurium Maven archetype去建立一个新的Tellurium测试项目，再用 Tellurium Firefox plugin TrUMP去自动生成一个UI Module，然后再写自己的Tellurium测试代码。

如果用户不熟悉Maven, 他可以下载Tellurium参考项目（Tellurium Reference Project）。这个项目是我们用来测试Tellurium项目网页的。包括了各种例子，可以直接运行。

更多有关Tellurium的信息，请参考DZone上的相关资料和Tellurium的Wiki。敬请期待Tellurium在InfoQ中文站的更多技术文章。

Endeca站内搜索(Endeca信息参见http://www.endeca.com/，Endeca使用叫做维度的概念)

出名的站内搜索引擎还有如免费的基于Java的Lucene，园子里已经有很多介绍了。(http://lucene.apache.org/，http://www.lucene.com.cn/)

当然Google的search option也经过了多次改版，最终把option定位在页面的左侧，看来从用户体验上来看，大众还是喜欢使用左边来做Nav的。(http://google.org.cn/2009/05/16/behind-scenes-of-search-options-panel/)

BTW，淘宝的是在顶部：

PS：神奇罗盘的样子和微软的人立方(http://renlifang.msra.cn/)异曲同工

Wonder wheel:

人立方：

上册：

     闽在海中。

　　这句出自《山海经·海内南经》的古语，似乎能诗意地道出福建与海洋千丝万缕的关系。

　　濒海与多山的福建位于欧亚大陆东南隅，背倚众多山地，面朝太平洋，这种独特的地理单元，使福建天然地具备了归顺大海的气质。所以，这块土地有可能是中国历史上最早与海外产生联系的区域之一；所以，这块土地上的人有可能是中国历史上最早向海外发展的人。

　　如是，我们的福建专辑策划中，离不开海，离不开山。上辑我们是围绕着海洋来结构文章，下辑自然就是山了。那么，上辑的封面我们是离不开海洋了。

　　第一张是港口。福建拥有众多的良港，其中的福州、泉州、漳州、厦门四大港口在不同历史时期此起彼伏地成为中国的海上门户，宋元极盛时期，泉州港还是中国的海上零公里处。而厦门港不管是在清代还是在今天，都举足轻重，图片中的厦门港，远远眺望，这座目前在港口综合实力排名中位居福建第一、全国第七、全球第二十二的天然良港一派繁荣。第二张是滩涂。漫长而曲折的海岸线，平添了众多的天然海湾、滩涂，这给福建的海水养殖业创造了良好的条件。耕海牧渔的渔民们在创造物质财富的时候，不经意地创造了一些赏心悦目的美景。罗源湾的海上网箱养殖人家，便是其中的一道风景。第三张是海岛。辽阔的海域与山岭遍布的陆地，让福建仿佛是一部打开的“山海经”。而众多的海岛，则因其独特的地理位置，成为山与海交融的最前沿。这块形似海鸟的礁石，诡谲异常，极具视觉冲击力。摄影师蓝添艺在拍摄她时，一脚踩空，摔成股骨粉碎性骨折，这是他在病床上给我们传来的图片。第四张是福船。中国帆船的建造与航海技术在相当长的历史时期领先于西方，是中国古代海洋文明成就的佐证之一。其中福船功不可没，曾经浩浩荡荡的郑和船队，大部分都是福船。图片中泉州沿海的渔船，恍若那个帆船时代的缩影。

　　最终，我们选择了渔船作为封面。天空中，云破处，夕阳下，历史的雾霭，曾经的辉煌，今日的落寞，在这张图片中，弥漫开来......

下册：

2009年第5期封面 武夷山天游景区 摄影/刘达友

备选封面

备选封面

备选封面

　　《福建专辑》(上)，我们关注的是福建的海洋，蔚蓝色的大海意味着开放、冒险和交流，而当我们在专辑(下)中将目光投向福建内陆，则看到了这座“东南山国”中连绵无尽的群山。它们在带来封闭、阻塞的同时，却也成为了强大的涵养与保存的力量。开放与封闭，冒险与保守，种种矛盾在福建这部“山海经”中得到了奇妙的协调，形成了独特的八闽文化。　　

      第一张图片，出现在我们眼前的是武夷山风景区的天游峰、九曲溪和错落峰群。它“奇秀甲东南”，自古以来便是福建第一名山，盈盈一水折为九曲，“山水若从奇处看，西湖终是小家容”，丹山碧水的秀美一览无余。而远处隐约的群山，则展示了武夷山脉的磅礴和封闭，它不仅是气候和江河的分水岭，也给福建文化带来了深刻的影响。

　　第二张图片是著名的福建南靖县田螺坑土楼群。土楼中的各种形状—圆的、方的、椭圆的一应俱全。从高处俯瞰，如花朵开放在山野之中，又像神秘降落在大山里的飞碟，是展现土楼的经典画面。不过，这幅被形象地称为“四菜一汤”的场景已经多次出现在人们视野中，缺乏新鲜感和视觉冲击力。

　　第三张图片是雄跨九曲溪口的大王峰，它上丰下敛，额状悬崖气势磅礴，颇具王者威仪，是进入武夷山的第一峰。汉武帝曾派遣使者在大王峰南麓设坛祭祀武夷君。不过，茂盛的树丛有些“抢镜”，未能尽显丹霞山峰的壮观。

　　第四张图片展示了流行于福建连城县罗坊镇的一种宗教民俗活动—“走古事”。由于独特的地理文化条件，福建拥有成百上千的大小神灵和难以计数的神诞日和节庆，堪称中国“造神”最多的省。但在讨论中，大家认为它反映的内容略显单薄，难以代表福建内陆人文自然的丰富多彩。

　　最后，我们选择了第一张图片作为封面，“山为锦屏何须画，水作琴声不用弦”，九曲之幽，丹霞之美，武夷山脉之壮阔，在这幅画面中融为一体。

发布会：

http://blog.sina.com.cn/s/blog_48d84e6f0100d3gv.html

http://dp.pconline.com.cn/photoblog/page.do?method=photoPage&from=photoblog&pid=909604

《中国国家地理》2009年第4期 目录及内容预告：

http://cng.dili360.com/cng/ml/2009/04102217.shtml

http://cng.dili360.com/cng/yg/2009/03272211.shtml

《中国国家地理》2009年第5期 目录及内容预告： 

http://cng.dili360.com/cng/ml/2009/05112222.shtml

http://cng.dili360.com/cng/yg/2009/04282219.shtml

福建专辑上：卷首语：一个中国海盗的心愿      http://cng.dili360.com/cng/jsy/2009/04102213.shtml

福建专辑下：卷首语：矛盾的福建      http://cng.dili360.com/cng/jsy/2009/05072220.shtml

PS:

中国国家地理网： http://www.dili360.com/

中国国家地理——新浪博客：http://blog.sina.com.cn/cng

　　只需要4年时间，Google就从一个偏僻车库里的小公司成长为全世界最炙手可热的高科技偶像；而同样花了4年时间，进入中国的Google几经外界质疑，销售团队更换了两拨人马，才终于得见曙光。Google中国宣称，2008年其销售收入的增长达到三位数，实现了全球最快的增长率。艾瑞咨询的报告也显示，2008年，Google和百度的市场份额差距缩短了几近 8%，这是Google正式入华三年多以来首次从百度手中如此大规模地“掠取”客户。

　　Google是一个技术王者，也是一家商业公司。自2004年8月19日上市那天起，这个市值超过1500亿美元、年纯利润40亿美元的“搜索帝国”就成为华尔街的宠儿，其每季营收、净利润、增长率等数据的变化牵动着众多分析师和投资者的心。它发布的每一款产品都能够给Web和通讯领域带来一场革命。Google的LOGO中，红色和蓝色是两种最主要的颜色。它似乎预示着，尽管Google中国的销售业务必须在“红海”中搏击，但其在“蓝海”中产品创新为其创造了更多市场布局的时间和空间。

　　与在中国市场饱受挫折的雅虎、eBay、MySpace这样的国际互联网巨头们相比，它虽然同样遭遇本土竞争对手的严酷竞争，却拥有更为灵活、开放的企业文化。衡量一家公司本土化是否成功的标准有很多，业绩不是唯一标准，却是重中之重。我们试图还原Google中国销售团队走过的这条人员本土化 -产品本土化-运营本土化的内生道路，以探究一家创新型公司在中国如何落地的“普适价值”

　　□ 记者 张娅

　　为了赢得中国市场，Google创造了不少特例，其中之一就是2006年4月12日发布“谷歌”这一全球中文名称，这也是Google唯一一个在非英语国家发布的名字。其在上海设置的广告研发团队和在中国的代理销售模式，也表现出鲜明的“中国特色”。它的最新“中国特例”出现在今年3月30日推出的免费正版音乐搜索。中国是Google在全球范围唯一推出这项服务的国家。为此，英国《金融时报》使用了“谷歌‘中国化’”的标题，并很是煽情地写到：“由此开始，这只是向承认中国将改变世界迈出了一小步。”

　　对于国际互联网巨头们来说，“本土化”仿佛成为了“图坦卡蒙咒语”，雅虎、eBay、MySpace甚至微软都曾在中国市场饱受挫折。1998 年4月，在澳大利亚布里斯班参加国际互联网大会的Google两位年轻创始人也没有想到，面前一个叫李彦宏的中国帅小伙正是因为后来Google的崛起而回国创办百度，并成为Google在中国市场最强劲的竞争对手。

　　衡量Google本土化是否成功的标准有很多个，销售业绩不是唯一标准，却是重中之重。抛开那些汗牛充栋般对于Google创新文化的描述，Google毕竟是一家华尔街的上市公司。尽管大部分“G粉”还是习惯于用神圣的互联网精神来崇拜这家公司，但Google全球副总裁刘允认为，Google中国已经不再只是一个技术公司，而是一个成功的商务公司。

　　近一年多来，Google中国大力推介自己的广告产品和给用户及广告主带来的价值。作为整个亚太地区销售和运营业务的负责人，Google全球副总裁丹尼尔·阿勒格里(Daniel Alegre)表示，2008年Google在中国的销售收入的增长达到三位数，实现了全球最快的增长率。

　　来自市场研究机构艾瑞咨询的报告显示，2008年，百度、Google长时间的平稳竞争态势首次发生逆转，Google的市场份额增加了 5.6%达到23%，百度的市场份额则下降了2.1%到72.0%。这是Google正式入华三年多以来首次从百度手中如此大规模地“掠取”用户。双方在收入方面的差距更小，2008年Google中国的收入规模为14.32亿元，所占市场比例达27.3%，同比提高6个百分点，而百度在2008年的收入规模为31.97亿元。4月12日，艾瑞公布的最新数据显示，Google今年第一季度延续高速增长态势，市场份额首度突破30%。

　　成立之初，Google仅仅花了四年时间便成为硅谷最炙手可热的高科技公司。但进入中国四年多来，Google艰难走过一条人员本土化—产品本土化—运营本土化的内生道路，终于初见曙光。但真正的市场竞争显然才刚刚开始。

　　起步2006

　　2005年7月19日，李开复走马上任建立Google中国工程研究院，意味着这家神话公司正式进入中国。但外人少为关注的是，同时建立起来的还有Google在线服务团队，5个人都是来自美国的“海归”。此时，Google在中国已经有一些自然客户。早期，在线团队的主要工作就是为这些客户介绍Google广告平台的更多功能，提出一些更优化的解决方案。直到后来更多本地人才进入、队伍规模有所扩大之后，在线团队才逐渐加强本地的推广力度。

　　按照Google中国区销售总经理宋中杰的说法，在进入中国之前，Google总部派人花了很长时间去拜访搜索广告产业链上的公司，尤其是代理商，“跑了很多地方，见了很多人，也跟中国互联网业以及商业人士详细了解中国市场”。更为重要的是，此时的百度已经通过发展众多代理、并在全国培养数家大代理商的方式，一跃为最成功的中文搜索引擎。2005年8月8日，Google宣布授权经销商计划扩展到中国，同时公布了中企动力成为Google在中国首家正式授权经销商，在中国境内提供AdWords关键字广告服务销售和支持。代理商现在已经成为Google中国的营收支柱，而在美国，Google几乎60%—70%的销售额来自于在线方式。当年9月，Google的AdSense中国团队正式成立。一个代理商、在线和大客户直销团队以及广告联盟“三位一体”的销售模式粗具雏形。

　　到2005年年底，Google中国的代理商发展到了5家，包括两个全国代理商和北京、上海、深圳的三个区域代理商。但是，代理商们普遍信心不足，基本处于观望状态，真正放在Google广告业务上的资源很少。李开复一开始就认为，Google中国与其去寻找100种改善流量的方法，不如坚持改善搜索引擎技术。因此，Google把大部分精力都放在提高中文搜索网页的质量上。在2006年2月宋中杰进入Google中国时，谷歌内部的资源分配是：在线团队有十几个人，代理商销售团队只有四五个人，大客户团队只有一个人，也缺乏相应的支持和流程架构。“这完全是从无到有的一个建设过程。”宋中杰说。

　　这一年，同时也是在欧美市场凯歌高进的Google在中国备受质疑的一年。有消息称，2006年年中，Google总部甚至曾有一些高层主动提出，是否应该将Google中国的业务与腾讯组建合资公司？Google中国高层团队当然对此坚决反对，认为在那样一个非常时期，如此大的动作会破坏公司内外的信心，这一方案才最终被搁置。2006年9月，由J.P.摩根和互联网分析专家吕伯望共同推出的中国互联网搜索引擎调查报告显示，2006年 Google的市场份额同期下滑了8%，只有25.3%，而“中国的Google”——百度的市场份额超过了60%。2006年底，Google亚太区市场总监王怀南和负责Google中国市场营销的大中华区联合总裁周韶宁先后离职。业界普遍流传的是，周韶宁曾于此前几个月向总部提交了一份本地化方案，其中涉及到中国公司的架构设计以及市场策略，但是总部认为策略过于激进，并且可能影响到其在全球的整体品牌形象而最终否定。尽管此说法后来遭到了 Google中国和周韶宁本人的否认，但Google早期在中国市场未能形成有效的商业渗透是不争事实。

　　从某种程度上说，Google中国的第一个“对手”并不是百度，而是美国总部。雅虎、eBay等的前车之鉴已经证明，互联网世界瞬息万变，跨国公司却往往决策链条过长、考虑问题也难以本土化。对于Google这样一家以“不作恶”为座右铭的公司来说，它还很在意道德姿态上的完善，短短数年间的急速成功也让它极度自信自己的发展路径。

　　在早期的招聘过程中，宋中杰经常遇到向总部报批时被否的情况。这并不是因为总部对Google中国有人数限制，而是员工对于Google的文化认同是Google招聘时一个重要衡量指标。他解释说：“你能不能干是一方面，如果做事方式不符合Google的行为准则和道德规范也是不被允许的。”

　　对于在中国大力发展代理商模式，Google总部也存在很多顾虑：比如说代理商毕竟不属于Google，他们的一些销售和服务行为是否会给公司品牌带来负面影响，在线团队和代理商之间是否会有很大冲突，等等。一个新问题也被摆在了销售团队面前，那就是一向以在线运营为主的Google是否能对代理商提供有效支持。

　　传统上，Google的代理商销售部门由两部分组成，即代理商开发人员和代理商管理人员。而Google中国将其合二为一，按照区域划分，由一个销售人员对代理商从头负责到底。Google中国还打造了全球最完整的代理商架构，比如市场部和商务拓展部(BD)都是其他国家所没有的组织机构。

　　“当时讨论了很久。”宋中杰回忆到，“我们分析了所有开发和管理代理商时的困难和挑战，并列出哪些工作对新增客户很重要，以证明合二为一的必要性。并且，我们在中国市场面对的是大量中小代理商，如果没有一个中央参谋部把作战计划拟好，每一个数据分析和计划制定都交给各区自己做的话，是更加无效的做法，也很难把全国协调起来。所以，我们把商务拓展工作分解下去，看每个步骤是不是都需要，如果需要的话是集中起来有效还是分散到不同的区域、不同的销售人员中更有效。好处、坏处一列，总部也就清楚了。”

　　从2006年下半年开始，Google在中国进行了新的渠道布局，开始发展区域代理。当年第三季度，Google一口气发展了10家代理商，年底代理商已经超过20家。

　　在2006年整整一年里，Google中国销售团队花费了大量时间和总部进行如此沟通，也不可避免地出现过“拍桌子、发脾气”的场景——好在 Google是一家靠数据说话的公司。宋中杰表示：“从一开始，我们基本上每采用一个新方式都能完成既定目标，甚至大部分还超过了目标。这建立起了总部对中国区管理层的信任，后面就走得很快了。原来很多事情我们都要先跟总部谈，后来原则沟通一下就能通过，再后来我们只要和总部一起把目标定好，具体的策略和执行都可以由本地自己决定。”

　　同样在2006年8月，Google AdSense在广州成功举办发布商路演，这在全球也属首创。“中国人更习惯于面对面地交流。”Google大中华区在线销售与运营部经理王莹说，“路演的效果非常好，发布商反馈也很好。我们当年一共做了3次路演。” 2007年，AdSense又进行了13场发布商路演，基本覆盖中国一线城市。2008年，Google在二、三级城市做了3场路演，10月份又把全国所有的大中型合作伙伴请到北京做了一个Google发布商峰会。后来这个经验还被Google总部推广到其他国家。

　　Google大中华区在线销售与运营总监赵东平也发现，与客户面对面的交流给在线团队带来了良性互动。在线团队自己不能进行线下活动，代理商的作用就发挥出来了。“代理商经常进行本地推广活动，提升了Google的品牌。很多人在现场没有和代理商合作，但听代理商讲完后再上网一看，发现可以自助开设账户，很方便，就与我们合作了。”他说，“这其实是代理商在帮我们。”

　　稳定局面

　　最终让外界对Google中国的唱衰之声戛然而止的，是在2007年6月11日Google与新浪实现战略合作。“从今天开始，指责Google不懂本地化的人可以闭嘴了。”当时一名Google中国的工程师如此对媒体表示。

　　2007年1—5月，Google中文网页的搜索量提高了60%，其中不少是原来因为网页不稳定而离开Google的用户。2007年5 月，Google全球CEO施密特访华时对媒体证实，对Google中国的考核包括了流量的提升、广告收入的情况，并非只关注中国团队建设和研究院的情况。

　　与百度强调“社区搜索”，通过贴吧、知道、空间、维基等提高用户黏性从而获得广告投放不同的是，李开复希望通过整合搜索赢得广告主的青睐。Google中国的合作对象包括了中移动、网通这样的运营商，以及从腾讯、新浪等门户一直到影视、饮食领域的垂直网站。

　　此时，两个竞争对手出现的另一个差异是，Google努力通过代理商渗透中国市场之时，百度逐渐取消了北京、上海、广州等大城市的代理渠道，转而做直销，只在较小的市场采取代理模式。由此，百度可以获得更高的利润。

　　此时的Google中国已经度过最初的动摇，希望向外界传导出2007年“加速跑”的印象，但销售并不包括其中。Google销售团队发现，部分客户在使用了Google的关键词广告一段时间后停止了续费。按照竞争对手的做法，Google应该开发更多的新客户以弥补损失，但它选择了另一条道路。

　　这一年被Google销售团队定为“服务年”。他们和代理商一起开发了一个服务模式，对客户群进行分类并提供不同的服务。代理商客服流程也被固定下来，客服工作时间被划分为几个阶段，最小的时间划分是半个小时，每个时间段客服应该做什么事都有详细规定。在此基础上，Google对代理商的人员规模、员工素质和服务做出严格考核，从事海外业务的代理商销售人员还必须通过国家的英语专业八级考试。Google还制定出了清晰的代理商培训课程，甚至精确到了制定代理商员工的职业发展图。

　　或许本人就是一名“G粉”的缘故，网通互联公司总经理樊美勇一直在代理商模式改革中与Google中国亦步亦趋。早在Google进入中国之前，网通互联就一直与CNNIC合作进行中文域名的推广，并帮助当地的中小企业建设网站。如果客户希望在平台上做广告，公司也会代为运作。到了2005年下半年Google中国公布第一批代理商之后，樊美勇在网上找到Google的联系邮箱，主动申请成为代理商。2006年4月，网通互联正是获得授权。

　　与Google中国其他深入中国基层市场的“触须”一样，网通互联对当地市场和客户有足够的了解，但对公司本身却缺乏精细化管理的概念。为节省成本，公司一般每100—200个客户配一个客服。但此时Google坚决要求一个客服只能管40个客户。为此，网通互联投入了大量人力成本。樊美勇在实践中发现，客服管的客户数虽然少了，但管的生意却比以前多了。按照樊美勇的说法，此前网通互联已经积累了400多个Google客户，“转正”之后到 2007年收入同比增长了1.3倍，

　　“黄金账户”是Google中国为代理商配备的又一市场利器，即为客户的关键词广告账户设置合理的结构，使客户的每个关键词都能获得更高的点击质量和点击率，由此客户为用户每次点击所付出的费用大为降低。但因为“黄金账户”至少要求用户设置30个关键词，客户开始也并不认同，投诉一直到了宋中杰那里。宋中杰不得不一再跟客户解释，如果没有那么多的关键词，就不会有足够多的流量触发广告。实践一段时间之后，越来越多的客户在签合同时就直接提出：“ 你必须把我的账户做成黄金账户，否则我就不签了。”按照宋中杰的说法，2007年做完之后，客户满意度增长了30%-40%。

　　从沉默到招徕

　　据说，在2006年Google中国某高层回国走马上任之时，不少朋友都断言，“两年后你必然会退出中国”。艾瑞咨询统计显示，2005年年中，百度、Google和雅虎在中国搜索市场三分天下，市场份额分别为37 : 23 : 21。随后的两年多时间里，雅虎中国发生巨大变动，Google和百度几乎将市场份额瓜分殆尽。到2008年，百度、Google两家的搜索引擎的营收份额之和超90%，而百度和Google合占网页搜索请求量市场份额的93.2%，中国搜索市场进入双寡头时代。

　　这一年，Google广告销售已经不再需要隐藏于搜索背后。Google把中国划分为北京、上海和广东三个区域，在每个区域办公室配备一名总经理、两名销售员和三名客服人员。Google的中国代理商也发展到了26家，除了最早的两个全国总代外，其他的24家都是区域代理商。如何在中国挣更多的钱也成为了Google中国的头等大事。

　　作为Google大中华区营销总裁位置空缺一年后迎来的“营销强人”，2008年1月7日加盟之前，刘允是韩国头号移动运营商SK电讯中国区的CEO兼总裁。业界认为，他对中国电信行业的稔熟与人脉正是Google所看中的。

　　刘允半开玩笑地表示，自己到Google上班第一天的感觉和20多年前初入职场时一样。他回忆说：“当我以高管身份进入其他公司时，公司几乎把什么都准备好了。而在Google，有人把你往办公室一领，再来一个人把电脑装好，然后就都走人了，我觉得也是蛮好玩的。”现在，刘允每天上班的标准装备是西装加双肩背包。他的办公室面积也大为缩减，因为太小而甚至显得有些简陋。据说，刘允的前同事到Google来参观时，完全不相信他就坐在这样的办公室里。

　　Google开放、平等、宽松的工作环境一直为外界所称道。但刘允看到了身上的压力。他上任的第一把火，就是撤换不称职的管理人员，还劝退了一些员工。“我们是一个商务团队，和研发部门还是有一些差别。在原有Google团队的价值和文化基础上，我们需要更集中、更有效率、更有战斗力。”他说。随后，Google中国大规模组建销售渠道和销售队伍，其销售团队已经有几百人，目前还在扩招之中。新团队感受到了比以前更强的目标设定。“我告诉大家我们可以做到那么高的目标，要达到目标需要哪几步，通过团队重组、组织变化和人员调整坚定他们的信心。只要我们能够做下去，Google在中国的发展就非常非常有希望。”刘允说。

　　2008年5月开始，刘允带着团队频繁到两岸三地路演，不断向中小企业说明Google已经有“中国化”的产品和广告形式。截至当年底，Google中国针对中小企业的营销坛论一共举办了26场，全国各地26个代理商也举办了50—60个企业的小型客户推广会。

　　在“传道”同时，Google中国也下决心要改变互联网代理商原有的销售模式。传统的互联网代理商采用人海战术，把任务完全压在销售员身上，对销售员实施放羊式管理。Google抛出了“iSales”精细管理的杀手锏。这一措施将销售划分为数据分析、电话访谈和最终销售三个环节，并且在数据分析环节建立数据库，使每次最终销售环节所获得的信息都可以统一反馈到数据库，成为下一次销售的基础。

　　实际上，早在2007年第三季度，Google中国就开始了试点。第一个“吃螃蟹”的还是网通互联。由于“iSales”模式对原有的销售人员造成了巨大冲击，网通互联一开始试点，下面四个销售经理就走了三个。促使樊美勇坚持下去的原因是：“无论从今后长期发展来看，还是从规模化来看，包括我们要寻求生意突破、订单突破的角度，都必须去做流程改造。”

　　樊美勇透露，为了客服和销售的流程改造，公司截至目前累计投入了50万资金。好在试点给公司业绩的影响只有一个季度。到了第二个季度，公司恢复增长，还基本弥补了上一个季度的损失。在2008年，公司收入同比增长1.6倍。

　　2007年第四季度，Google中国把试点扩大到了5家，并且不断把结果与其他代理商分享，成绩和问题都全面呈现。试点首先打消了代理商对效率的顾虑。宋中杰说：“这种模式的效率当时虽然并没有完全体现出来，但至少效率和以前是一致的，不会比以前低，这点大家都认同。”同时，代理商在销售的透明性、可预测性、可管理性和稳定性，以及人员的素质上都有明显的改善。

　　从2008年第二个季度开始，Google决定在代理商中强制实施“iSales ”销售模式，设定了十条法则对代理商实施认证。执行之外，新的问题又出现了：随着流程的不断优化，代理商管理能力不强开始暴露出来，部门之间的连接也出现了很多问题。又有代理商想打退堂鼓。但Google还是下定决心坚持。到2008年第三季度结束时，有20家代理商通过认证。来自Google的数据显示，2008年底，代理商与客户达成交易的成单率普遍提升了40%以上。

　　两次变革也让代理商对于Google中国的态度发生巨大转变。“早期，有些代理商认为Google根本不懂中国市场，做的东西都是阳春白雪，好看不实用。通过三年的实践，现在没人敢这样讲了。”宋中杰说，“刚开始时，我们说是不是这样做更好，代理商就会说不对，应该那样做。到中间一个阶段时，我们问这样做对不对？他说对，但回去还按照自己的来。现在基本不谈对不对的问题了，我们直接跟他们谈怎么才能实施得更好，代理商也会真正去执行。”

　　纵横对峙

　　对于2008年的工作，刘允给自己打了90分。在他看来，过去是全球总部告诉Google中国如何营销，现在则是中国的营销团队说中国要怎么做，来争取Google全球的支持。

　　刘允声称，2009年Google中国的销售团队将更专注于特定的用户群和特定行业。他透露：“我们的搜索质量已经不亚于任何一个中文搜索引擎，未来希望能够把搜索这个概念外延和扩大，为使用者带来更好的信息。除了已经推出的Google地图和音乐搜索，未来在手机搜索和手机信息以及云计算方面，我们也正逐步走向实际应用。”

　　作为代理商和大客户直销的负责人，宋中杰也希望其执掌的业务在2009年实现加速成长。按照计划，Google中国首先要实现的是客服模式和销售模式的继续升级；在此基础上加大客户覆盖面，代理商销售人员要实现成倍增长，客服要实现80%的成长；随着人员的增加，Google中国销售部门不但要实现自身的人员素质提升，还要帮助代理商选拔和培养人才；为了吸引更多客户，此前Google中国已经推出了静态网站建设以帮助客户对其网站进行诊断和优化，接下来还把一些免费产品进行包装，通过代理商提供给客户，并针对地方大客户引进更多广告创意人才。

　　而就在2008年10月份，Google AdSense推出了广告管理系统，针对发布商运营效率问题提供全面解决方案。在王莹看来，AdSense在中国已经度过了知识普及阶段。她说：“我们的发布商规模越来越大之后，涉及到的网站大小不一，需求也各不相同。接下来，我们将更多去发掘他们深层次的需求，针对提出个性化建议。”

　　同样值得关注的是Google的在线运营业务。赵东平透露，客户位居前两名的行业分别是制造业和零售。为了适应中国客户习惯通过电话而非网络进行沟通的需求，Google中国的在线运营部门最近还新增了一个免费服务电话。这个看似简单的举动，却是只熟悉美国人在线沟通方式的Google迈出的一大步。赵东平认为：“尽管中国市场还属于培育期，在线运营不会像代理商机制那样产生立竿见影的作用。但当这个系统不再复杂、人力成本又越来越高的时候，会有越来越多的客户倾向于使用在线自助服务。”

　　所有这些事情似乎都在暗示，Google在中国已经实现“落地”。2008年第三季度，Google的市场份额为20.8%，百度为 73.2%。在2008年第四季度，由于虚假广告事件百度市场份额下降了1.2%，Google增加2.2%。而到2008年底，百度依然把持着 63.5%的市场营收份额。

　　“刚开始，Google广告模式的设计对于许多中国客户来说还很难接受，但从2007年下半年起情况就有所改变。”樊美勇说，“现在，Google不以价格决定排名反而变成了我们很大的卖点，甚至连代理商要收取20%的服务费也是一个卖点。”

　　针对Google中国今年的专注策略，网通互联已经开始集中一些行业网站资源主动出击：在杭州，网通互联把50个关注度比较高的房地产网站打包成房产联播网，向当地房地产公司推广；针对宁波厨卫生产商集中的特征，公司的重点推广对象则是方太、帅康、欧菱等公司。

　　实际上，中小企业云集的浙江市场是Google中国今年的一个重点地区。按照计划，Google在当地的代理商数量和工作人员都要比去年翻一番。这意味着，除了与同处搜索广告行业的百度短兵相接之外，Google还要在马云的“发家地”与阿里巴巴进行电子商务战的正面对峙。

　　年报显示，2008年阿里巴巴B2B业务的总营收为30.01亿元，同比增长39%，其中国内交易市场占总收入的比重由2007年的28%上升至36%。2005年并购雅虎中国资产并经过三年整合之后，阿里巴巴已经宣布今年要向雅虎口碑网再投入3亿元，把其真正纳入阿里巴巴电子商务体系，雅虎中国的营收也被重新提上战略高度。

　　“任何一个市场都有竞争，在中国也不例外。Google会坚持自己的方向。”刘允对未来充满信心，“我们希望能够快一点把规模做起来，同时，更有效地联合产业链上下游合作伙伴，一起把中国互联网行业做起来，为一些熟悉电子商务的企业和传统企业提供更多的服务。”

　　用“蓝海创新”拉动“红海市场”

　　作为一家以创新为旗帜的公司，如何在复制全球模式的同时与本土市场对接，对Google中国的未来产生着决定性影响

　　2006年，时任eBay中国研发中心总经理的王劲接到了Google大中华区总裁李开复的邀请，希望他加入建立在北京的Google中国工程研究院。独特的企业文化让Google一直是技术开发者们心中的天堂。但王劲有些犹豫，因为他不想离开已经生活了5年多的上海。很快，他又接到了李开复的电话。李开复一开口就说：“告诉你一个好消息，我们要成立一个上海研究院，所以你没有理由不来。”于是，2006年8月，王劲加入Google，以中国研究院副院长的身份在上海参与筹备工作。2007年6月25日，Google中国工程研究院(上海)正式成立。

　　这并非Google中国第一次为争取所需要的人才而就地建立研究中心。此前的2006年3月31日，为了把中文信息检索领域顶级专家简立峰招至旗下，Google设立了台湾研发所，并任命简立峰为主管。由此，北京、上海和台北三地的研发中心共同构成了Google中国强大的本地创新体系。

　　与北京研发中心成立之初一样，为了让Google独特的创新机制薪火相传，总部特地给上海派去了一批优秀的美国工程师，这在Google内部被称为“文化火种”。他们带来的不仅是已经被奉为经典的创新思维模式、文化和价值观，也要具体指导当地工程师如何充分利用Google的创新法则，以及如何开发出符合Google价值观的软件和服务。此外，李开复也从北京调了10个工程师到上海。上海的研发中心很快成长起来。按照最初的划分，北京研发中心主要负责基础搜索技术，上海则侧重于广告的研发。两年多后的今天，Google上海研发中心不仅与销售团队实现无缝链接，并且在内容广告方面占据了全球 40%的核心力量，一些相关的搜索技术开发也被纳入进来，包括Google新闻搜索、财经搜索和图片搜索等等。

　　作为一家以创新为旗帜的公司，善于对创新进行管理的Google是世界上最赚钱的网络公司。Google平台打造的是一个“生态系统”，通过 Google本身与第三方创新者、用户和广告商之间积极互动，形成对各方都有利的良性循环。在这家公司2008年高达218亿美元的总收入中，广告收入占了95%以上。事实上，Google一直占据着这个生态系统的制高点，控制整个系统的发展，并从中赚取超高比例的收益。这不但形成了Google的差异化优势，当它来到中国后，也对其在中国市场的未来产生着决定性影响。

　　复制“80/20”

　　创新是互联网公司在市场的立足点，但Google创新的速度之快、数量之多，常常令其他公司黯然失色。在Google的创新机制中，最为外界津津乐道的是将创新列入员工的工作时间预算，要求技术人员花80%的时间在核心的搜索和广告业务上，其余20%则用在他们自己选择的技术项目上。对管理人员，公司也有类似的规定。这就迫使员工必须腾出时间来搞创新。实际上，内容广告就是Google技术人员利用20%时间开发出来的产品，现在已经成为 Google营收的第二大支柱，每个季度为其带来超过10亿美元的收入。

　　但上海研究中心成立后不久，王劲就发现，中国的工程师总是希望尽快完成工作任务，往往忘记有20%的时间可以自由支配。“我们发现有绝大部分工程师，当他们80%时间的工作目标确定以后，比较喜欢围绕这一目标去考虑20%时间的创新。”因此，王劲反而要鼓励他们不一定要把20%的创新计划和既定工作紧密结合，“让他们可以更大胆一点，更放开一点、更海阔天空地去想一些能够为用户带来更好体验的产品和服务”。

　　除了来自总部工程师展示出来的“榜样的力量”之外，不遗余力复制总部对创新成果的奖励政策，也是Google中国鼓励创新的秘诀之一。

　　Google工程师可以获得的最高奖是“创始人奖”，奖金高达1000万美元。2005年，研发出AdSense的五人小组就获得了这一奖项，其中包括两名中国籍技术人员。该奖项并非以赢利为评价标准，但要求产品对公司做出重大贡献。在此之下，Google还设了其他创新奖励，奖金从几百美元到几千美元。2009年，Google中国推出了“十大杰出工程师”评选。另外一个极具Google特色的是名为“PEER”的奖励方法。在公司内部网站上设有一个链接，任何员工只需要填好奖励对象的名字，并陈诉简单理由，都可以申请对其他同事进行奖励，而且每个人申请的名额没有限制。如果推荐被批准，两三天之内该名同事就会收到一封电子邮件，并且在发工资时就可以看到这笔奖金。

　　“我们很高兴看到，Google中国没有人滥用这种权利，这个是非常好的鼓励大家互相帮助的办法。”王劲说。

　　更为贴近市场

　　由于中国客户更习惯面对面的交流，Google上海研发中心与销售团队的结合在全球范围内也算是最紧密的。

　　每个季度，Google中国广告技术团队的负责人都会和销售经理坐到一起，共同制定当季乃至全年的销售计划和战略。每个星期，双方也有固定的例会，广告技术人员可以从中详细了解各个产品在市场的表现情况。

　　中国的研发中心另一个与Google全球不一样的做法是，工程师会积极参与到公司的销售活动中，不但告诉客户Google的广告产品有哪些中国特色，也倾听来自客户和发布商的反馈和建议。

　　从2008年11月6日开始，为了应对金融危机带来的影响，Google中国曾经在全国22个城市举办了26场主题为“突破·智胜”的“冬日暖阳”企业营销论坛。王劲透露，整个过程都有上海研发中心工程师的参与。每到一个城市，工程师会在论坛上亲自进行产品和技术的宣讲。论坛之外，工程师还在每个城市召开一个和客户的小型见面会。这次的巡回中，很多客户向Google工程师提出，希望代理商能够定期、快速地把一些消息发送到邮箱，以便他们不用登录账号就可以了解到账号动态和广告动态。回去之后，上海研发中心很快研发出“代理商服务工具”，现在已经被Google总部推广到十几个国家。

　　在王劲看来，依托销售团队组织的营销活动，研发中心可以深入到客户基层，获得第一手资料。为了更加了解中国本土的需求，研发中心还鼓励工程师回家乡和母校与Google用户进行深入接触。他说：“这些可能都是我们在实践中和总部不一样的地方，但是理念上确实是一致的，就是以用户为先。”

　　用数据说话

　　Google的创新结合了根据市场反馈而进行的创新和根据技术发展进行的创新。但是，这种百花齐放的战略并不意味着许多产品注定要失败。Google以一套非常严谨的以数据为驱动的创意评估流程，很好地确保了创新的有效性。

　　Google对于分析和数据的重视远远超过其他绝大多数公司。目前，在其上海研发中心有一个专门的小组，负责收集与销售相关的数据，并通过各种方式将海量数据归纳到数十个衡量指标中。王劲具体解释到：“我们可以从地域来分析，广州的客户有什么样的特性，北京客户又是什么样的特性，然后在不同地域做出针对性决策。我们也可以从不同行业来进行分析，了解最近哪个行业发展得比较快，哪个行业具体的用户数多，新建的广告数多，点击率多等等，这给我们的研发工作做出了重要引导。”

　　当然，Google施之于全球的创新实验机制也被复制到了中国。当工程师开发出一个产品时，可以在数据中心申请一部分服务器流量，把产品直接带入到客户面前。Google是否会对此进行更大投入，完全看这个试验所产生的数据。

　　在很大程度上，这些创新实验都受益于Google享有盛名的IT基础架构。它保证了在试验上的收放自如，也使得进行实验的新系统与原有系统之间的无缝链接得以实现。

　　“在我们的创新管理机制里面，我们并没有一开始就对产品进行区分，唯一的选择机制就是让数据说了算，用户说了算。”王劲说，“我们会根据产品的性质来决定在多少流量中进行实验。也许一开始我们只应用在0.5%的流量上，如果用户反馈不错，就逐渐增加到1%、2%甚至20%。有一些实验可能只进行 2%的流量测试就搜集到足够的数据，我们就可以做出决定，让100%的客户马上使用。这样，产品失败的风险可以被限制在很小的范围内。”

　　手机上的大场面

　　在强大创新机制的护航下，Google的技术和战略一直密不可分。Google的使命是“整合全球信息，使人人皆可访问并从中受益”。而要完成这个使命，CEO埃里克·施密特(Eric Schmidt)估计需要300年。有市场人士指出，在微软阴影下长大的Google从企业文化到性格基因里包含有某种因为Google而生的因子，它的心脏是为了与微软战斗而跳动。但在中国，它的手脚却不得不面对百度这样的公司。

　　但王劲认为，Google中国现在做的每件事还都是在为实现以上使命而服务。“很多人认为Google是一个互联网公司，但是我们从来没有把自己局限于只是做互联网产品的公司。比如说手机产品和图书产品，都不属于互联网产品，却帮助我们达到了整合全球信息的目标。”他说，“在不同时期，不同市场，因为不同的产品我们遇到了不同的竞争对手，这是Google整体战略在每个地方的具体表现。可能别人看到竞争对手的市场就认为是我们的目标市场，其实不一定是这样。”

　　在Google的LOGO中，红色和蓝色是两种最主要的颜色。这似乎预示着，尽管Google中国的销售业务必须在“红海”中竞争，但其“蓝海”中的产品战略使得再强大的竞争对手也无法忽视它的存在，这为其创造了更多市场布局的空间。

　　对于下一个“蓝海”，Google的答案或许只需要两个字——手机。2008年9月25日，苹果iPhone(手机上网)上市后不到5个月，Google就发布了“Android”开源移动操作系统(见《商务周刊》2008年11月5日第21期封面故事《手机新三国演义》)。当年10月22日，使用基于Android操作系统的G1手机在全球22个国家和地区盛装上市。尽管Gphone的应用和Google的广告销售没有太多关联，但Google早已经把搜索系统嵌入到了手机中。2008年，Google推出了“手机内容AdSense”，为出版商加入手机内容网络并通过文字广告获得收入提供了方便。今年2月11日，Google为移动运营商和手机网站推出新的“手机搜索AdSense”，该服务可以让运营商和手机网站快速而轻松地置入Google搜索框。

　　在王劲看来，手机平台的发展非常快，功能也越来越趋近于电脑。今天，中国已经有3亿多互联网用户，但与6亿多手机用户相比差距还是很大。“手提电脑和手机之间的界限越来越模糊，手机平台已经在人们生活中占到很重要的位置。”他说，“尽管目前这个市场还在培育之中，但在未来，手机搜索上的广告业务一定会超过互联网。”

　　“我们需要在亚太区强有力地存在”

　　——访Google全球副总裁丹尼尔·阿勒格里

　　对于Google在中国的战略，其全球CEO埃里·施密特(Eric Schmidt)曾经宣称：“我们将以长远的眼光赢得中国市场，中国有五千年的历史，Google对中国市场的成功有五千年的眼光。”现在看来，Google已经不需要等这么久了。8个月前，Google把亚太区总部从美国搬到新加坡，以“背水一战”的方式表现出对于亚太区市场的决心。

　　作为整个亚太地区销售和运营业务的负责人，Google全球副总裁丹尼尔·阿勒格里(Daniel Alegre)几乎全程见证了Google中国的成长。自2004年加入公司之后，他扩展了Google的合作伙伴渠道，包括与中国移动、AOL欧洲、 KDDI公司和NTT DoCoMo公司建立了战略合作关系。在全球经济危机的大背景下，Google如何看待此前在亚太区遇到的困境，又将如何实施新的战略？针对上述问题，《商务周刊》对其进行了专访。

　　《商务周刊》：Google刚刚把亚太区总部搬到了新加坡，这是否意味着亚太区将获得公司更多的资源倾斜？这将对中国市场产生哪些影响？

　　丹尼尔·阿勒格里：对Google来说，亚太区在战略方面非常重要，特别是中国市场。世界上有40%的互联网使用者都集中在亚太地区，超过半数的移动电话使用者都在这里。为了能够达到我们的使命，我们需要在亚太区强有力的存在。此前，Google在亚太区各个国家已经有了办公室，这次只是把亚太区一些高层管理人员从美国迁到新加坡，以使公司在亚太区的决策更加本地化，更贴近本地需求，同时也更快做出决策。

　　Google虽然是在美国成立的，但我们从来不把自己看作是一家美国公司。我们一直认为自己是一家国际公司和全球性公司。无论我们在哪一个市场运作，比如说在中国市场运作，都认为自己是中国经济的一部分，是中国互联网大的生态环境的一部分。去年，中国的网民数量已经超过了美国。如果将来有一天中国网民数量超过美国整体人口总数，我也一点不会觉得奇怪。在移动业务方面，中国也是全球市场手机使用者最多的一个市场。中国市场对于Google来说，有着我们取得重大成功的所有必要条件。

　　《商务周刊》：亚太区虽然是增长最快的市场，但也可以说是全球最复杂的市场。目前，Google依然无法在日本和韩国实现突破，接下来在这两个市场上是否会有一些新的计划？

　　丹尼尔·阿勒格里：你说的没错。即使在世界范围内，亚太区对我们来说都是一个相当多样性的、同时有很强挑战性的市场。但我们认为这是一件好事，因为它使我们能够重新考虑产品战略，使我们更加灵活，更快地适应市场需要。

　　日本是我们在全球所有市场中第一个推出手机广告的市场。我们的手机广告产品在两年半前推出，并且和KDDI和NTT DoCoMo两家日本运营商结成了伙伴关系。目前，无论对我们来说还是对运营商，手机广告都是推动销售额持续增长的一个重要方面。另外，我们在日本的手机上特别开发了地图的运用，这也是我们针对日本市场的一个创新。在韩国，大约在两年半或三年前，我们建立了一个研发中心。去年下半年我们为韩国市场推出了 25款新的产品。由此可见，我们在整个亚太区是做了很多投资的。这些投资一是用于本地化我们已有的产品，另外也是为本地市场，无论韩国市场、日本市场还是中国市场，提供一些针对性的独特产品。

　　《商务周刊》：目前，中国的研发团队在Google的全球创新中占据什么位置？您对2009年Google中国的业绩又有哪些期待？

　　丹尼尔·阿勒格里：Google中国研究院的工程师也主要做两件事：一是把Google的产品本地化，使我们的搜索结果能够更加贴近中国消费者；二是开发一些新产品，这些新产品不仅针对亚洲市场，有时候也可以在全球进行应用，比如我们开发的手机搜索工具可以在亚太区之外进行应用。所以，他们的工作是一种双向关系，也就是说在Google的创新理念下，既有欧洲、北美和拉丁美洲的工程师为亚太区开发产品，也有亚太区工程师为本土市场乃至全球市场贡献他们的才智。

　　2008年对Google中国来说是业绩非常好的一年，我们在中国的收入增长达到了三位数。我们相信2009年会继续这样一个发展势头。另外，Google在中国的市场份额也在持续上升，我们相信这样的趋势也会继续下去。

　　《商务周刊》：那么您怎么看待Google在日、韩两个市场遇到的挫折？您刚才提到2008年Google在中国赢得了三位数的增长，您可以总结其中的原因吗？

　　丹尼尔·阿勒格里：谷歌在整个亚太区的一些发展经验表明，我们应该考虑到在不同的国家，大家有不同的方式和互联网进行互动。比如在韩国和日本，人们的宽带使用率比较高，在网上看视频也比较广泛。所以，我们在推出产品时就要考虑到视频和移动的因素。除此之外，在使用习惯上，日韩也有很多跟其他市场不一样的地方。比如说键盘，无论在中国、日本还是韩国，很多人都不喜欢用键盘进行输入。所以在日本和韩国，我们特意把Google的首页进行了改变。

　　中国是一个充满活力的市场。要归结Google中国2008年的成功因素，答案其实非常简单。首先，我们在中国雇佣了非常聪明的工程师、产品开发人员和销售人员；其次，我们在业务方面非常专注，只做搜索和搜索广告；第三，我们强调创新，我们在中国的研发中心是四年前建立的，现在已经开始到了收获季节。我们已经研发出很多世界一流水平的搜索工具，同时这些新产品更加贴近中国用户，和中国用户之间建立了一种很好的信任，这都反映在我们销售收入和市场份额的增长上。

　　《商务周刊》：那么，您认为Google在中国的营销模式是不是代表了国际上最新的模式？

　　丹尼尔·阿勒格里：我不知道这能不能成为一种趋势。因为讲到趋势，大家常常会想到6个月甚至两年之后。但我认为Google提供的搜索营销平台是一个非常清晰有效的平台。第一，它的目标非常精准；第二，营销计划可以很快实施，也可以很快停止；第三，可以精准针对你需要的消费者。所以，我想把它称作一个解决方案更加合适。这个解决方案为整个广告业带来了变革。它使得广告商可以从非常微观的领域来分析消费者，并且针对他所需要的消费者推送合适的产品。同时，你只有在消费者点击之后，真正和你的品牌进行互动才支付费用。你知道你在广告商的每一分花费都取得了成效。

http://www.businesswatch.com.cn/

http://www.businesswatch.com.cn/Mag/Cover/2009/0506/1449.html

http://www.businesswatch.com.cn/Mag/Cover/2009/0506/1450.html

http://www.businesswatch.com.cn/Mag/Cover/2009/0506/1451.html

View my

729Bookmark to Delicious

Before launching any new website, feature, or upgrade, it has to be tested. The worst nightmare of any programmer, designer, or business is to launch a broken website that drives away users and hurts reputations. It will only create more work, more headaches, and lost profits.

Luckily, there are many great tools for web development testing. These tools test everything from CSS validation to website speed. Making sure that users and customers have a problem-free experience should be the goal of any website. These tools are the final step in that process.

---

1. WebSitePulse Test Tools

---

Want a fast test for response time, file size, and links? WebSitePulse Test Tools provides a series of quick and easy-to-use tests that graph out everything from website speed to link errors. It also provides numbers on file sizes, redirect speed, and DNS.

---

2. XenoCode Browser Sandbox

---

Browser testing is one of the most tedious and frustrating parts of web development. What designer or programmer hasn’t screamed bloody murder at broken alignments in Internet Explorer 6? One of the difficult parts of browser testing is that no developer can have every browser type on a single computer for proper testing.

Enter XenoCode Browser Sandbox, a series of virtual applications that can run all popular browsers simultaneously. It does not even require the installation of software. However, XenoCode’s Browser Sandbox can be heavy in some browsers and is still lacking in a Mac version.

---

3. Firebug Firefox Extension

---

The favorite extension of programmers everywhere, Firebug is one of the best applications around for debugging issues with front-end code and CSS. If there’s any image or style that’s out of line, checking it out with Firebug is the best response. It’s even possible to change styles within the extension to see how a website will actually appear in the browser.

---

4. Load Impact

---

If a website goes viral and Digg, Twitter, and StumbleUpon all converge on it at once, will it be able to handle the stress? Load Impact helps answer that question. It simulates large userload on web servers to determine whether or not they can handle the high traffic load. It comes with a free version and several paid versions.

---

5. Safari Web Inspector

---

One of the gems of Apple’s Safari web browser is its Web Inspector feature. Web Inspector, only available after turning on the development tab, displays stylesheets, images, and scripts on any webpage. However, the most useful part of Web Inspector is its Network feature, which shows in real-time the order and speed in which documents and scripts transfer from the server to the browser. Use it to find which scripts, files, or images are placing the most strain on browsers. Then fix it.

---

6. Web Developer Firefox Extension

---

Web Developer is a robust Firefox extension that no developer should be without when testing a website. It provides a wide range of tests, including testing for broken images, testing layouts in multiple screen sizes, viewing cookie information, and validating mark-up. It’s the ultimate testing companion for Firefox users.

---

7. W3C Validation Services

---

W3C is THE standard in all of web validation. The W3C Validator looks into the markup of any website and display errors based on industry standards. It comes in over a dozen languages and a dozen varieties. Here are some of the most important validators:

- W3C Markup Validation
- W3C CSS Validation
- W3C mobileOK Checker
- W3C Link Checker
- W3C Feed Validation Service

These tools are designed to make websites as fast and bug-free as possible by detecting problems early. At the very least, they will let a developer know whether or not he or she needs to scream at Internet Explorer 6 for a while.

Image courtesy of iStockphoto, karimhesham

http://mashable.com/2009/03/21/tools-web-testing/

其实在3月30号这一天，Google还发布了财经香港版，http://www.google.com.hk/finance，

我非常有幸全程参与了Google财经香港版的测试工作，与北京，台湾及NYC,MTV的同事们合作。

谷歌财经官方介绍视频(ps:不过最近youtube被封了)

Google财经香港版提供的功能如下:

1.HK stock listings in Traditional Chinese w/ 10-year price data（香港繁体版股市信息包括10年历史数据）

2.Interactive chart w/ related local Chinese news（集成新闻香港版信息）

3.Stock screener (股票篩選器) covering HK, China and US

4.Portfolio (投資組合)

5.Local sector classification (分類概覽)

6.Financial statements of HK stocks (財務摘要)

Google财经在香港的推广活动：

发一张设计图以便回顾：

社区

.NET

主题

软件测试,

单元测试

标签

验收测试

WatiN是一个在.NET中自动控制浏览器的开源类库。WatiN从流行于Ruby社区的Watir项目中得到启发，通过与浏览器的交互简化了对Web应用程序的自动测试。WatiN使用C#编写，但是可以使用任何.NET语言编写测试。目前它只支持Windows平台。

与其它.NET平台上的解决方案相比，WatiN 1.0已经有足够丰富的功能，并逐渐成为流行的用户界面与用户验收测试工具，可惜它只能直接支持IE浏览器的自动操作。虽然仍处于开发阶段，WatiN 2.0已经支持对IE及FireFox 2.0/3.0的自动操作。作为最新的社区预览版本，WatiN 2.0 CTP 3，已于2月11日发布。

CTP 3着重于对FireFox提供的更好支持，并包含以下的改进：

• 为Mozilla.Frame实现了新的特性，可访问Frame中文档内部的元素。
• 为Mozilla.Frame实现了新的特性，可访问IFrame中文档内部的元素。
• 为Mozilla.Document（即FireFox和Frame）实现了Eval功能，并增加了IFrame接口。
• 修补了一个bug：在某些情况下会导致Form.Submit方法不等待一个潜在PostBack及页面加载过程的完成。

WatiN通过与浏览器的交互，以及对DOM结构的处理和验证来建立断言，不过WatiN 2.0引入了一个抽象层以便编写跨浏览器的测试。下面的代码示范了一种在Google中搜索WatiN，并判断“WatiN”字样出现在结果中的做法。可见，只需修改一点点代码，就能针对IE和FireFox进行相同的测试了。

手动编写WatiN测试有些令人厌烦，因此社区里又出现了另一个开源项目，能够从浏览器中记录并创建WatiN测试。WatiN Test Recorder并没有发布新的版本，不过它的2.0版本正处于开发过程中，并已承诺会带来一些重大的增强。

查看英文原文：WatiN: Web Application Testing in .NET

社区

Agile

主题

企业级敏捷

标签

管理

风险管理包括风险评估、舒缓风险影响以及监控风险。很多敏捷用家相信敏捷开发项目风险管理过程跟传统项目差不多，虽然这过程在敏捷的内容中较为轻盈，但是在找寻、过滤、优先化以及制造解决方案上的步骤跟传统项目中很接近。

Mike Cottmeyer提出以敏捷开发去识别和舒缓风险影响更为有效，他指出：

敏捷开发方式之所以能有效管理风险因为风险管理过程建立在我们执行项目的结构上，这隐含的意思就是风险在项目中无处不在，风险清单不能包括所有风险，也不 能透过团队会议和定期的风险评估来减轻风险，风险处理必须是不能抽离的思想，我们减轻风险的策略不是处于项目以外，而是影响着如何规划和安排工作的本质。

他把风险分成三类：

• 业务风险 – 涉及项目付运能否带来它所预期的价值
• 技术风险 – 涉及技术方案在若干时间及资金下的可行性
• 后勤风险 – 涉及人与其他基建之间的假设

根据Mike所说，敏捷开发的本质就是要求频密的付运、定时的检察和调整，这本身已经是风险管理。

但是也有人认为敏捷开发不是固有地处理风险。

Jurgen Appelo认为敏捷项目经常缺乏风险的关注。

他认为，

Prince2、PMBOK、CMMI都有包含风险管理的部份，但敏捷方法的书本上就很少明确地看到风险管理的内容，对此我感到莫名其妙。

他同時指出，项目经理经常埋头在项目里，而忽略了整体宏观形势，这导致严重缺乏对风险管理的关注。

另外，James Shore认为有效的风险管理能帮助团队作出更实在的承诺，他建议使用风险倍数（risk multiplier）和Burn-up图来管理项目有关的风险。

风险倍数包括常见的风险，例如人事变动、要求改变、工作上的障碍之类，这些风险倍数让你更准确地于设定日期和估计需要多少故事点数（story potints）。

James建议在团队使用较为精确的开发过程（相对于风险较高的开发过程，可参考James网站上这例子），而且速度（velocity）固定、每个故事都在迭代完结时做到"Done Done"（不仅完成客户需要的功能，而且没留下支持团队的工作，原文出至于James的网站，亦可参考"The Power of Done"一文）的情况下使用以下的风险倍数。

风险倍数

（这些倍数来至DeMarco和Tim Lister的RISKOLOGY模拟器（详文可参考「与熊共舞」一书）以及Todd Little的分析数据）

这风险倍数使用方式如下：

（假设团队的速度为14，十个迭代后发布的话，那么当前可运用的故事点数有140点）

从以上例子中：

让你可以跟项目有关人士和管理人员说：「我们几乎肯定会在发布前完成当中的78点，所以我们先承诺完成功能A、B和C，我们有一半机会能完成总共100点，所以我们安排功能X、Y和Z作为伸延目标，完成好A、B和C之后再去完成他们的。」

所以风险管理在敏捷项目中就如传统项目一样，都是核心部份，重点在于适当的重视、有效地处理而基于这里作出承诺。

查看英文原文：Agile Risk Management

译者附注：

James的网站有更多关于其风险倍数的内容，亦可参考他所写的"The Art of Agile Development"一书，特别是此文没有包括的Burn-up图。此外，风险倍数的使用还有其他注意的地方：

• 「承诺」背后的意义，值得思考的就是「承诺」到底是什么、管理人员如何理解和使用这里作出的「承诺」。要知道，这些还是机会率，如果最后变成合约，又或者客户拿来争议的「论点」，那么也是没有意思的。
• 风险倍数的由来，这里的1、1.4和1.8是如何得出呢？到底又有多适合您的项目情况呢？就连James自己的网页上 也有这样一句 "I'm guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don't track that data" （我在猜这些数字对极限编程的情况有多准确，最准确的方式还是根据过往项目纪录来计算您的风险倍数，但很多公司根本不会记下这些数据），所以千万不要把这 些数字看成什么魔幻数字。
• 延续上面这点，如果公司为了提供「承诺」而去收集项目相关数据，这是否对容户有所得益呢？容户为什么要投资金钱给开发公司去收集数据？客户又如何可以知道投资金钱让公司收集这些数据可以有所回报呢？

其他方法如Prince2、PMBOK或CMMI等对风险管理都有值得参考之处，而跟敏捷有关的独特观点则是减少开发上浪费而没必要的过程和活动，之前在「Scrum的风险管理」也有相关的讨论。

还有，要好好管理风险，评估形势的能力很重要，甚至比其方法更重要，例如如何猜量我们是否在"风险较高进行开发"呢？这里其实可以套用Stacey模型和Cynefin模型来辅助。

PS:

《Rapid Development》一书中对Risk Management作出了详细讲解

进度计划风险的完整列表：
计划编制风险：
1，计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致
2，计划是优化的，是“最佳状态”（但不现实，只能算是“期望状态”）
3，计划忽略了必要的任务
4，计划基于使用特定的小组成员，而那个小组成员其实指望不上
5，在限定的时间内无法建成已定规模大小的产品
6，产品规模比估计的要大
7，工作量大于估算数
8，进度已经延迟的项目在重新评估时过于优化或忽视项目历史
9，过度的进度压力造成生产率下降
10，目标日期提前，但没有相应地调整产品范围或可用资源
11，一个任务的延迟导致相关任务的连锁反应
12，涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多
组织和管理：
1，项目缺乏一个有凝聚力的高层领导人
2，由于前期乏力，项目长时间被搁置
3，解雇和消减开支导致项目小组能力下降
4，仅由管理层或市场人员进行技术决策，导致计划进度延长
5，低效的项目组结构降低生产率
6，管理层审查/决策的周期比预期时间长
7，预算消减打乱项目计划
8，管理层做出了打击项目组积极性的决定
9，非技术的第三方的工作比预期长
10，计划性太差，无法适应预期的开发速度
11，项目计划由于压力而放弃，导致开发混乱、低效
12，管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力
开发环境：
1，设施没有及时到位
2，设施到位，但不配套
3，设施拥挤、杂乱或者破损
4，开发工具未能及时到位
5，开发工具不如期望地那样有效，开发人员需要时间创建工作环境或者切换新的工具
6，开发工具的选择不是基于技术需求，不能提供计划要求的性能
7，新开发工具的学习期比预期的长，内容繁多
最终用户
1，最终用户坚持新的需求
2，最终用户对于最后交付的产品不满意，要求重新设计和重做
3，最终用户不买进项目产品，无法提供后续支持
4，最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做
客户
1，客户坚持新的需求
2，客户对规划、原型和规格的审核/决策周期比预期的要长
3，客户没有或不能参与规划、原型和规格的审核，导致需求不稳定和耗时的变更
4，客户答复的时间比预期长
5，客户坚持技术决策而导致进度计划延长
6，客户对开发进度管理过细，导致实际进展缓慢
7，客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作
8，客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作
9，客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低
10，客户不接受交付的软件，尽管它满足了所有的规格
11，客户期望的开发速度是开发人员无法达到的
承包商
1，承包商没有按承诺交付组件
2，承包商递交的组件质量低下无法接收，必须花时间改进质量
3，承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平
需求
1，需求已经成为项目基准，但变化还在继续
2，需求定义欠佳，而进一步的定义会扩展项目范畴
3，添加额外的需求
4，产品定义含混的部分比期望需要更多的时间
产品
1，错误发生率高的模块需要比预期更多的测试、设计和实现工作
2，校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作
3，在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期
4，由于软件功能的错误，需要重新设计和实现
5，开发额外不需要的功能（镀金）延长了计划进度
6，要满足产品规模与速度要求，需要比预期更多的时间，包括重新设计和实现的时间
7，严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作
8，要求与其他系统、其他复杂系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作
9，要求在不同操作系统下运行将花费比预期更长的时间
10，在不熟悉或未经检验的软件环境中运行产生未预料到的问题
11，在不熟悉或未经检验的硬件环境中运行产生未预料到的问题
12，开发一种对组织全新的模块将比预期花费更长时间
13，依赖正在开发中的技术将延长计划进度
外部环境
1，产品依赖政府规章，而规章的改变将是不可预期的
2，产品依赖草拟中的技术标准，而最后的标准将是不可预期的
人员
1，招聘人员所花时间比预期的长
2，作为先决条件的任务不能按时完成
3，开发人员和管理层之间关系不佳导致决策缓慢，影响全局
4，项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平
5，缺乏激励措施，士气低下，降低了生产能力
6，缺乏必要的规范，增加了工作失误与重复工作
7，某些人需要更多时间适应不熟悉的软件工具和环境
8，某些人需要更多时间适应不熟悉的硬件环境
9，某些人需要更多时间适应不熟悉的编程语言
10，项目结束前，合同制人员离开团队
11，项目结束前，雇员辞职
12，项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率
13，项目组成员不能有效地一起工作
14，由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作
15，有问题的成员没有调离项目组，损害了项目组其他成员的积极性
16，项目的最佳人选未能加入项目组
17，项目的最佳人选已加入项目组，但因政治或其他原因未能合理使用
18，没有找到项目急需的具有特定技能的人
19，关键人物只能兼职参与
20，项目人员不足
21，任务的分配与人员技能不匹配
22，人员工作的进展比预期的慢
23，项目管理人员怠工导致计划和进度失效
24，技术人员怠工导致工作遗漏或质量低下，工作需要重做
设计和实现
1，设计过于简单，无法确定主要事件，并导致重新设计和实现
2，设计过于复杂，导致一些不必要的工作，影响实现效率
3，设计质量低下，导致重复设计和实现
4，使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误
5，产品采用低级语言来实施，导致生产率比预期的低
6，一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发必要的功能
7，代码和库质量低下，导致需要额外的测试、错误修正或重做
8，过高妒忌了增强型工具对计划进度的节省量
9，分别开发的模块无法有效集成，需要重新设计或重做
过程
1，大量的纸面工作导致进程比预期的慢
2，进程跟踪不准确，导致无法预知项目是否已落后于计划进度
3，前期的质量保证行为不真实，导致后期的重复工作
4，质量跟踪不准确，导致无法得知影响进度的质量问题
5，太不正规，导致沟通不足、质量问题和工作重做
6，过于正规，导致过多耗时无用的工作
7，向管理层撰写进程报告占用的开发人员的时间比预期的多
8，风险管理粗心，导致没有发现重大的项目风险
9，软件项目风险管理花费的时间比预期的多

我们组织里曾有许多团队努力采用测试驱动开发（TDD）[1]。偶尔会有一两个开发者成功，但是大多数都失败了。为了更好地找出原因，我调查了团队 的一些成员，发现即使经过了课堂培训，还有更多的事情需要做。虽然这里介绍的问题和想法只适用于中大型的公司，但理解这一点能够帮我们在组织中更好地引入 TDD。

我对组员（他们全都接受过培训）的调查显示，以下问题影响了他们：

• 由于经验不足，大家发现自己直接TDD比较困难。
   
• TDD培训的例子比实际应用简单得多。
   
• 需要更多的时间来实验和尝试，不要有赶紧发布软件的压力。
   
• 实际中应用的语言，比如Visual Basic和JavaScript，在单元测试文档或者课堂练习中从来不会用到。
   
• 常常会碰到很多遗留代码，而培训时不会介绍如何改进这些代码。
   
• 永远没有足够的时间用来学习──随时都有尽早交付产品的（人为的）压力，于是没有时间学习提高自己。

隐藏的问题

我们已经列举了这么多症状，那么冰山下面隐藏的问题是什么呢？

测试驱动开发并不是很难学。学习阶段（指形成根深蒂固的习惯的这段时间）一般会持续2到4个月，期间生产效率有所降低[2]。最终的好处显而易见，开发者也能自己保持该项技术，但问题是：怎么才能做到这样？很多开发者仅仅几天之后就放弃了。

就我见过的方法而言，大多数依赖于课堂培训（或者e-learning）和一对一的辅导。如果做得好的话，这些方法当然不错，可以作为整个解决方案的一部分，但是我认为还需要更多的方法。

课程培训有两个主要的问题：例子太简单，与实际问题关系不大；给大家练习的机会不多。

在线培训（Object Mentor和Industrial Logic，以及其它机构提供的培训），其优点是更有深度。然而练习的机会仍然不多。而且在这些课程里，你与其他学生通常没有交互。听一听你同学和同事的问题，能够加深你的理解。

一对一的辅导只能用于团队中的几个人，很难推而广之。在大型企业里面，专家只有几个，而需要帮助的人有成千上万，所以一对一的辅导更是困难。

看书是个很好的方法，但是很少有开发者喜欢通过读书学习TDD技术，即使有些人发现看书可以缓慢提高其TDD水平。与其它在线教程类似，看书仍然是只能一个人学习。

最后：遗留代码使得TDD难上加难。开发者当然会问这样的问题：“这些对象紧密耦合，怎样才能测试它们？这些代码太复杂了，怎样才能测试这个算法？”

一个解决方法

那怎样才是好的解决办法呢？前面的方法主要有两个问题：没有深度、缺乏协作。一个完整的解决方案需要结合使用多种学习模式，并需要包含以下多种因素。

• 课堂培训——开发者需要对TDD有个基本的理解，对多数人来说，课堂培训仍然是最好的方法。但是需要知道的是，培训本身并不能让人学会并使用TDD。
   
• 在线培训——这有助于加深基本概念的了解。但在所有这些方法中，这一种是可选的。
   
• 耐心——学习并使用TDD需要花费一定的时间，这个时间可能比你计划的更多一些。
   
• 衡量测试覆盖率——使用代码覆盖工具（比如Emma、Cobetura、NCover...）并向组员说明，衡量覆盖率可以让我们知道是否变得好些了，还是变得更糟了。很明显，这没法衡量测试的质量，因此只能用作参考。
   
• 内心感到自豪——开发人员需要知道什么样的代码和测试才是简单的、干净的，并需要感到花时间那么做是值得的。Bob Martin刚刚写了一本新书《Clean Code》，很好地回答了这个问题。
   
• 管理层的支持—— 开发人员需要管理层明确表态，说他们知道转向TDD会花费一定时间，并会“降低”团队效率[3]。他们需要澄清相对于产出速度和不断累积的技术债，他们更 看中的是质量。当不断地生产、生产、生产时，多数开发人员会有压力，所以管理层需要不止一次地重复这句话。说这句话的人等级越高（最好是来自最高层的执行 官），就会有越多的人去听。

• 结对编程——如果你发现自己停滞不前、不知道下一步该做什么，与别人一块编程通常会有所帮助，即使他是个新手，也会使你受益颇多。
   
• 社区——在你的组织里（或者城市里）组建社区，大家互相分享经验。社区可以让你与其他正在学习使用TDD的人通过网络保持联系，可以让大家互相学习成功的经验和失败的教训，社区还能够培养TDD需要的文化。此外，社区提供了一个机会，让大家能够分享新的想法。
   
• 编程道场——是大家在一块练习解决小问题的地方。编程道场提供了一个安全、协作的环境，让大家作为团队一块研究问题，而没必要真正解决这些问题。
   
• 阅读工坊—— 一组人（不超过8个人）定期聚在一起，讨论书中的某一章节。
   
• 教练定期走访——当团队偏离轨道、终止实践TDD时，教练的定期走访能够帮助团队重回正轨。这时与一两个人配对编程，就能够重新感染整个团队。

这一计划的核心是：针对TDD创造交流机会、促进互相协作。以上方法中有3个是关注这一方面的：结对编程、编程道场和阅读工坊。

编程道场

编码道场（使用自由方式）指的是这样一种活动，一小组人（最多15个人）采用TDD一块解决问题（下述内容来自Danilo Sato）：

• 在一个电脑上工作，通过投影让所有人看到输出结果。
• 采用配对编程的方式。
• 配对中的一个人每5到10分钟交换（我们用的是7分钟，效果不错）。
• 编码的人要解释他们正在干的事情，这样观众才能明白他们在干什么。
• 只有当测试通过时观众才能够对设计给出评论，而测试失败时观众不能提问题。
• 如果观众被搞糊涂了，编码的人应该停下来解释他们在干什么。

根据经验，我建议初次尝试要选择一个很小的问题。

阅读工坊

对阅读工坊来说，有很多好书可以选择：

• 如果是Java项目： Lasse Koskela的《Test Driven: TDD and Acceptance TDD for Java Developers》；
• 如果是.NET项目：Kent Beck的《Test Driven Development: By Example》；
• 如果你已经学习了很多：Gerard Meszaros的《xUnit Test Patterns: Refactoring Test Code》；
• 如果你不使用TDD：Michael Feathers的《Working Effectively with Legacy Code》。

典型情况下，团队在一次会议上可以讨论一章或者两章的内容。节奏一定要慢，让大家能够在业余时间读完相关内容，而不是变成了负担。除此之外，要留够充足的时间，让大家对文中的一些条目做深入地探讨。

一块学习的好处

这两个工坊都需要提供皮萨（或者一顿健康午餐）──因为你要求大家在私人时间做工作相关的事情，所以要给他们适当的鼓励。这两个工坊可以每数周进行轮换，以防大家觉得陷入太深。最后，不要指望每个会议上人员都是相同的。

与以自己为导向的学习相比，工作坊和社区是个很大的提高，因为组员致力于交流和协作。其结果是我们能够学到一些根本想不到的事情。

坚持TDD

总结说来，要想成功采用TDD，下面几点是关键：

• 耐心、实践、深度
• 管理层的支持
• 采用多种方法
• 开发者帮助开发者

某大型公司已经使用这种方法，着力提高TDD在其公司内的使用情况。

非常感谢Lasse Koskela、Nat Pryce、Dave Nicolette和Dave Rooney花费时间审阅本稿。

注意

[1] 本文中，TDD是指编码前首先编写测试用例，并采用增量的方法逐渐完成功能。而不是先写完代码，然后再生成大量的单元测试用例。

[2] http://tech.groups.yahoo.com/group/testdrivendevelopment/message/29461

[3] 能够感觉到生产效率会有所降低──比如，一个迭代中交付的故事数量会减少。然而由于一开始就能提高质量，所以这里说的降低并不像看上去那样会真正地降低效率。

作者简介

Mark Levison是Pure Agile Consulting公司的首席咨询师，该公司关注于敏捷和精益，致力于帮助客户每两个星期交付软件。从2001年起Mark就是一个敏捷实践者，曾在一个小团队内引入敏捷实践。过去三年中，作为一个大型独立软件开发商的雇员，他负责在组织里引入Scrum，并指导了多个团队-其内容包括设计TDD的策略，并引入了很多实践支持它。Mark是InfoQ敏捷社区的编辑，并且撰写了数十篇敏捷方面的文章。他还有一个blog：Notes from a Tool User。业余时间，Mark与他的妻子和两个女儿一起享受天伦之乐。

阅读英文原文：Making TDD Stick: Problems and Solutions for Adopters。

• Blogger
• Wordpress
• Facebook
• Twitter
• more

http://www.slideshare.net/JayAre/an-introduction-to-google-analytics?type=powerpoint

1. A Guide to Recommender Systems

http://www.readwriteweb.com/archives/recommender_systems.php

1. 5 Problems of Recommender Systems

http://www.readwriteweb.com/archives/5_problems_of_recommender_systems.php

1. recommendation technologies 系列文章

http://www.readwriteweb.com/archives/recommendation/

–我在哪儿？
–这是什么?
–我可以去哪儿?

怎么样测试这个页面的导航能力呢?

（1） 随机的从你的网站上选择一个页面；
（2） 把这个页面打印成黑白的，并把页面的头部去掉；
（3） 假装你是第一次进入这个网站，并试图回答下面的问题(详见下列问题列表)；
（4） 在一张纸上写下你所想的和答案；

让你们团队的其它成员或熟悉你网站的朋友也与你做同一试验，大家象跳伞一样的进入网站中的任意一个页面，然后把回答记在纸上，你就可以看到网站上什么是你同意的，什么是你不同意的。

问题列表:

作者提供了一些样例给大家参考:

原文链接：http://instone.org/navstress,以上的文章是我翻译原文的，可能会有些用词生疏，请大家原谅!

我自已也用这种简单实用的方法测试过前一阵我所修改的淘宝礼物频道，发现了一些问题:

(1)礼物频道没有“回到顶部”的链接，也就是要标识为“T”的部份；我看了许多国内的网站，包括一些国外的大型网站包括yahoo,ebay等等，都没有这样的一个“回到顶部”的链接，但是Amazon有这样的一个链接，这点值得其它网站学习，当用户浏览一些过长的页面时，为用户提供一种便捷方式，重回到顶部的全局导航位置，以让用户重新开始他的网站漫游。

（2）礼物频道的页面url太长了，真的不是一般人能记住的“http://www.taobao.com/vertical/present/index.php?ad_id=&am_id=&cm_id=140011294184f97f7945&pm_id”,为什么不叫“http://gift.taobao.com/”呢？这样方便用户对这个频道进行记忆，也方便用户将来不需要通过太多的“选择1>选择2>…”的方式进入网站，而是直接输入“http://gift.taobao.com/”进入网站；

     建议大家也用上面的方法对自己的网站进行测试，看看自己的每个页面到底存在着哪些导航的问题！希望能对大家的网站有所改进。

   补充一下：我觉得象这样的测试，最好几个人一起做，然后按上面的问题列表去找到相应的部份，因为每个人到一个页面寻找到上面这些部份的能力与时间都不同，这样作为设计者就可以看看自己的设计有什么问题，比如：“是不是没有到首页的链接呀？”“是不是没有到顶部的链接呀？”页面的主要部份是不是不明显不够好找呀？”等等！

http://ued.taobao.com/blog/2009/01/19/navigation_pressure/