冰云@Blogging

《博客三人行》25期:敏捷中国2009大会

贴一个我参加的视频节目，呵呵。 关于敏捷大会2009的介绍，这次敏捷大会我在参与组织。不知道为啥，视频里我的声音比较小。。估计主持人李宁没给我挂好话筒！！

由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商ThoughtWorks共 同主办的敏捷中国大会（AgileChina 2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过400位来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管 理人员等参加。本次大会已特别邀请软件开发方法学的泰斗、极限编程XP的创始人、敏捷宣言的创始人之一Kent Beck，敏捷开发权威人士、敏捷宣言的创始人之一Dave Thomas，超过30多年IT从业经历的敏捷实践者Dave Nicolette，敏捷领域大师级专家、咨询师、有近40年行业经验的Fred George等国际敏捷领域专家，以及在团队中成功应用敏捷的上海贝尔、赛门铁克、诺基亚-西门子、eBay、腾讯等公司的项目负责人参与此次大会并分享 他们的心得。

敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，将一改往年的风格，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

2 Comments | Posted in » Agile 敏捷, ThoughtBlogs

Agile Methods - From knowing why to knowing how

我今天出差讲的ppt，第一次在一个舞台上演讲。。聚光灯照的我完全看不见台下人表情，烤的我一头汗。

总结：
Well：观点来自我的论文；时间刚好1小时；图像比较符合；
Less Well：互动不足；乐趣不足，图片找的太匆忙；history部分讲的感觉有点简略；自己画的图貌似有点小错；时间太短，一些观点没法讲透彻。

Tags: Agile 敏捷

5 Comments | Posted in » Agile 敏捷, ThoughtBlogs

也谈电话银行的交互设计

电话银行的可用性研究

（本文是俺2005年6月写的作业，注重内容的同学请忽视此文，偶然翻出来贴上，引用链接好多都已经不存在了。）

随着网络和通讯行业的发展，电话银行、网上银行、手机银行作为低成本终端，得到各大银行的亲睐。目前我国各大银行均开设了电话银行业务，不少银行也同时开设了网上银行和手机银行。

据国外资料统计[1]，实体银行网点每处理一笔交易所需的费用为1.07美元，电话银行为0.45美元，ATM机为0.27元美元，而网上银行每笔交易的成本是0.01元。

电话银行[2]也称为电话银行服务中心，是现代银行业日益走向无纸化办公或线上服务和提高服务效率的必然产物。电话银行业务中，客户无需通过柜台而只通过电话完成所需银行服务，银行通过“人机”（即电话自动语音回答客户咨询、查账等）或“人与人”（即坐席员按照客户要求提供金融服务）对话的方式满足客户的要求。

网上银行[3]又称网络银行、在线银行，是指银行利用Internet技术，通过Internet向客户提供开户、销户、查询、对帐、行内转帐、跨行转帐、信贷、网上证券、投资理财等传统服务项目，使客户可以足不出户就能够安全便捷地管理活期和定期存款、支票、信用卡及个人投资等。可以说，网上银行是在Internet上的虚拟银行柜台。

手机银行[4]又称移动银行，是利用移动电话办理银行有关业务的简称，是移动运营商与银行部门合作，联合向社会推出的一个新服务项目，它是移动通信网络上的一项电子商务。手机银行业务的开通大大加强了移动通信公司和银行的竞争实力。

我国《2004年新银行业消费调查调查报告[5]》的数据显示，大约有14.8%的人使用网上银行，8.74%的被调查者使用电话银行服务。拥有电话的人数显然比拥有电脑的人数多，同样是新银行业务，为何其使用人数差别将近一倍？

造成这个问题的重要原因，是软件可用性的低劣。

衡量一个软件质量的好坏，人们的第一感觉往往是功能的多少。实际上，软件的质量体现在许多种方面。IBM公司曾提出用CUPRIMDSO作为衡量所有产品各方面的指标[6]，即下述单词的首字母：Capability Functionality (功能)，Usability(可用性)，Performance(性能)，Reliability(可靠性)，Installability(可安装性)，Maintainability(可维护性)，Documentation/Information(文档信息)，Service(服务), Overall Satisfaction(综合满意度)。类似的，HP也提出FURPS (Functionality, Usability, Reliability, Performance, and Service)作为衡量指标。可用性是评测软件质量的一个非常重要的标准。

可用性的定义来自于ISO-9241-11标准[7]，是指产品在特定使用环境下为特定用户用于特定用途时所具有的有效性(effectiveness)、效率(efficiency)和用户主观满意度(satisfaction)。

CRM软件发展到今天，大体功能已经基本确定。不同的软件之间，功能差别有限。因此，对CRM软件或系统的评测，主要决定因素之一就是可用性测试。

可用性测试可以应用在不同的范畴（包括软件、网页、硬件）从而针对不同客户的需求而能够更有效率及准确地达到他们的目标动作。

2002年，CRMDaily[8]网站发布了一篇文章[9]，批评了多数CRM软件的可用性。认为它们都没有通过可用性测试。

一个极端的例子是美国某公司花费了400万美金购买了一个著名CRM厂商的产品，但从来没有用它。因为随着实施的开始，他们很快发现，软件的操作方式对于员工来说实在是太难了。

CRM中的客户可分为内涵客户和外延客户。常见CRM系统中的CRM软件和呼叫中心，分别为一般员工代内涵客户使用和普通消费者作为外延客户使用。上述美国公司的例子是员工使用软件，而电话银行是由消费者亲自使用。

电话银行是呼叫中心的一种应用。但随着银行业务的增加，银行方面企图将所有业务都通过电话服务提供。

我国某著名银行，诞生比较晚，历史负担较轻，在早期的网络银行发展中，圈地较早，并且取得了很大成功。然而在电话银行系统的推广中，它却犯了很大的错误，让我们看一个简单查询帐户余额的例子：

电话银行的设计，和网络银行的菜单有根本性的区别。在网站上这样设计，用简单的菜单来呈现非常方便，一目了然。只要简单浏览一下菜单，就可以很快找到需要的功能。而在电话中，如果不是对银行业务特别了解，谁知道使用一个功能要到哪里呢？绝大多数人都没有足够的耐心去使用这样一个系统。

更甚的是，当我没有耐心，需要得到人工服务的时候，居然还会出现选择提示：

我只是一个普通的客户，我很着急的想知道如何找到最近的一处ATM取款机或营业网点。而这需要我输入这么多东西吗？好吧，语音系统，告诉我投诉选项在哪里？我要投诉。

我国另一家著名的银行的电话银行查询余额过程如下，比起上一家，已经好了不知多少倍。

这家银行的网上银行，虽然开发较晚，但后来居上，以良好的界面和方便的功能，一举圈地成功。从上一家银行挖走了不少的客户。但它的电话银行业仍然存在难以使用的问题。

从业务功能上看，或许网上银行和电话银行差不多，然而，电话银行或呼叫中心的一个很大的作用，是获得客户的意见、建议、投诉、抱怨，通过人与人直接对话，处理客户的请求，取得客户的信任，建立客户的信心和忠诚度。这是网上银行、手机银行所不能替代的重要功能。

可用性低下就是电话银行使用人数大大低于网上银行使用人数的原因。银行为交流设置了人为的障碍，阻断了客户的热情。

可用性问题的产生原因，主要是由于软件开发人员对于客户心理和使用习惯不了解，按照自以为是的方式来编写用户界面(User Interface)。在软件发布之前，甚至没有经过客户的真正使用。在软件上线实施后，又舍不得花大力气返工和修整。

而一般的消费者，学历未必高，又没有经过专业培训，愿意花费的学习软件使用的时间也比较少。要想使客户能够很快上手使用，就必须在设计期对软件进行能够全面地、细致的、以用户为中心(User-centric)的交互设计。让软件变成傻瓜式的软件，任何人都可以轻松愉快的使用，真正的让客户满意。

从上世纪末开始，电子设备、电子产品、互联网等一些高新技术大量进入人们的生活。任何新产品和新设备都诉说着这样一个事实：当电脑和传统的设备结合(如电话，照相机，汽车等等)，它会变成另一个难用的电脑。人类使用这些杂交电脑时会产生“软件的种族隔离”[10]，即无法掌握新电子技术的人将无法得到工作，无法融入年轻人的生活，甚至会被社会所抛弃。技术人员努力工作，却漫不经心的构建了新的、更大的阻碍。

当开发人员仔细考虑过用户需求，认真设计了用户操作界面时。事情会变的更美妙。利用电脑的强大功能，我们仍然可以把事情变得简单。之所以以前没有这样做，完全是惯性使然。高技术、高学历的人员认为：这已经足够好了，至少我能使用。

如何解决这样的问题呢？首要办法是，化繁为简，去芜存菁，善用20-80原则，用20%的功能满足80%的客户的需求，不能追求大而全。

据调查[11]在2004年上半年的一次某银行电话银行签约客户回访调查中发现，有近1/3的客户从来没有使用过电话银行。当初签约只是一时好奇，或是营业柜员积极推荐，事后并没有重视。而使用过电话银行的签约客户中，又有2/3的客户只是查查余额，没试过或使用过缴费、转账、外汇卖买、银证通等业务。还有极小部分客户，虽然签约，但是思想保守，不能接受新兴事物，对电话银行的安全保障持怀疑态度。

从上述分析可知，在目前的电话银行中，最常用的业务是客户查余额，偶然使用转帐、交费等功能。以上述电话银行为例，可以改进如下：

既然必须要输入卡号密码，那我们先输入。用技术手段判断是什么类型。至于是否签约，难道银行还不知道吗？为什么要让客户去了解？

进入后，先把最常用的余额提示出来。不需要了解哪个子帐户，只要最近用的。我们只提供最基本最常用的功能。如果需要更多的其他的业务，请再继续选择。但根据调查，大多数的用户都不会继续选择更多的功能。

电话银行的价值，不在于它提供了所有的银行功能。中国人还是最喜欢到营业厅去办理业务。因此，电话银行的设计，应当针对常用的情景来设计。更多的时候，电话的作用，是人与人直接的语言交流。这是任何文字都无法替代的。

在客户关系的管理中，因为电话银行的难于使用而造成的客户的流失，忠诚度的下降，甚至对银行的抵触心理，最终导致客户意见建议难以反馈到银行。银行没有反馈，无法知道自己的错误，或可能认为投诉率的下降或许是由于电话银行的便捷，最后只能恶性循环。

在国外各大CRM软件公司纷纷增强其产品可用性的时候[12]，国内CRM软件的可用性也应当做一些改进。竞争日渐激烈，利润越来越低，但软件使用效果却不佳。提高可用性和交互设计或许是软件企业翻身打胜仗的新法宝。

—————

后记：本文借鉴了Windy姐的电话银行交互设计的例子，不过这篇是从交互设计的角度讨论CRM，呵呵

—————

参考书目

Alan Cooper，刘瑞挺等译，《The Inmates Are Running The Asylum》，《软件创新之路》，电子工业出版，2000年。

王广宇，《客户关系管理方法论》，清华大学出版社，2004年

董建明等，《人机交互：以用户为中心的设计和评估》，清华大学出版社，2003年

参考资料

1 钟伟 - 中国网上银行发展回眸 http://www.doctor-cafe.com/detail1.asp?id=269 2005.06.02

2 金融信息化系列专题(三)：电话银行 http://www.cfn.cn/Statics_pub/Dissertation/ztzj/zt_jrxxh_dhyh.asp 2005.06.02

3 中国银行网上银行 http://supermart.stockstar.com/supermarket/chinabank/wsyh.htm 2005.06.02

4 被寄予厚望的手机银行 http://www.cnii.com.cn/20040423/ca258514.htm 2005.06.02

5 2004年新银行业消费调查调查报告 http://www.ciweekly.com/A20040329298365.html 2005.06.02

6 Software Quality Metrics Overview http://www.awprofessional.com/articles/article.asp?p=30306&rl=1 2005.06.02

7 ISO 9241-11:1998 Ed. 1 Current stage 90.93 TC 159/SC 4

Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability

ISO 9241是关于办公室环境下交互式计算机系统的人类工效学国际标准，它由17个部分组成，根据人类工效学和可用性原理，分别对各种硬件交互设备属性和软件用户界面设计问题作了详细的规定和建议。可以对一个产品设计符合该标准的程度进行评估和认证。

8 CRM Daily http://www.crm-daily.com 2005.06.02

9 CRM Flunks the Usability Test http://www.crm-daily.com/perl/story/18310.html 2005.06.02

10 Alan Cooper，刘瑞挺等译，《The Inmates Are Running The Asylum》，《软件创新之路》，1999年

11 发展呼叫中心的难点及对策 http://www.fcc.com.cn/2005/4-7/10434.html 2005.06.02

12 Usability lifts Siebel CRM http://www.vnunet.com/itweek/news/2085464/usability-lifts-siebel-crm 2005.06.02

PeopleSoft Enterprise CRM 8.9 delivers major usability enhancements
http://www.itweb.co.za/sections/enterprise/2004/0405270752.asp?A=ENS&S=Enterprise 2005.06.02

Tags: design

No Comments | Posted in » Business

严重实用技巧：Word2003中修改尾注位置

这两天一直在写论文，采用了Word 2003（没办法，学校要求格式，不敢用mac的破Word2008），其中一项功能就是添加引用的尾注。然而，这个尾注功能及其的不好用。它存在3个问题。

A 论文要求用[1][2]这样的形式来表示尾注的编号，而word默认的都是(1),(2), i, ii, iii, I,II,III, 子丑寅, ABC,甲乙丙（一）（二）等等不知道谁在用的符号。而且，无法自定义符号！有一个看来貌似叫做自定义符号的按钮，会把所有的数字都替换成统一个符号，例如*。

解决办法是：

1.首先，按照普通方式插入脚尾注
2.CTRL＋H唤出替换窗口
3.前一个替换栏输入^f(此是脚注，尾注用^e)
4. 替换为栏为[^&]
5.完成。

B 尾注一但分页，就会出现一条分隔线。上面写着****我是伟大的分隔线*****

解决办法是：

1. 将当前视图，设为普通视图；
2.选取菜单“视图”——“脚注”，会在下方出现一个下拉框，选择其中“尾注延续分隔符”
3.完成

C 论文要求把尾注区域插在第五章结论和致谢之间。而又限制了每章必须用自己的章节标题作为页眉。这两个需求导致了word的尾注区域不能正常工作。因为尾注只能添加在节的结尾处，或者添加在全文的结尾处，并且不能手动移动位置。而为了每章换用不同标题，必须要每章分节。因此，尾注就只能分散到每节之后，或者全在致谢之后。

解决办法是：（我搜索了很久确信确实没有人提出过解决方案，估计同学们都是手动改的吧。。。）

1. 按照普通方式插入尾注
2. 选择将尾注插入每节之后
3. 正常分节（这时候所有的尾注都在节尾）
4. 到第一节内容中，选择 文件->页面设置->版式->取消尾注。这时候第一节的尾注会自动合并到第二节之中！！！！
5. 重复4直到达到参考文献一节
6.完成。

无语了！！Word，你好变态啊～ MS啊，你这样折腾为哪般？

No Comments | Posted in » Consultant 咨询

请赞同，而不说“不是” － 关于交流和反馈

关于交流

1. 永远不要以否定词开始你的对话

最近经常听到人说话时候把“不是”这个词放在句首，例如有人说：“我觉得这个设计是符合可用性原则的，你看这用户按钮这么大，多好点击啊！”有人说“不是，按钮大不代表可用性就好啊。。。”我认为这是一种很不好的习惯。他在不经意间，把自己的立场摆在了和讲话的人的对立面。甚至他们观点实际上相同的时候仍然不自觉的用“不是”开头。对方听到“不是”，虽然表面没说，但心中早已掀起滔天巨浪…… 这样说话要花很多功夫才能达成一致。（貌似很多老北京都这么说话，很奇怪。）

作为一个咨询师，当尝试解决用户的问题的时候，或尝试推销解决办法的时候，切忌用否定的句子开始阐述。当一个咨询师说“不是”的时候，无论你后面的论证多么的严谨和完美，客户都已经提前丧失了兴趣。有的时候，赞扬谈判对手能够更快的达成一致。

这时候一定要换一种说法：“你说的很有道理，我帮你改善一点……”，“你说的对，如果……能够再……一点……用户体验就更好了”。

2. 交流的唯一目的是达成共识

交流发生于双方发生分歧的时刻。例如你对工资不满意了要和老板交流，再比如需求搞不清楚了要和客户交流，在家里有矛盾了得和老婆交流等等。总之交流这个事件的产生动机总是因为有些东西搞不清楚，而交流的目的就是把这个东西搞清楚，大家对问题达成一致的理解。

然而，很多时候交流的双方忽视了交流的目的，陷入了盲目的交流漩涡。尤其是看到两个人在pair programming的时候，为了一个设计争得面红耳赤不可开交，这时候他们只是为了说服对方、或者证明自己的权威而交流，目的改变了。

3. 交流的基础是尊重

顺畅的交流是建立在互相尊重的基础上。当你和一个人说话的时候，如果他眼睛望向一边，心不在焉，根本不仔细听，敷衍的和你说，这时候说话的人是什么感觉？如果对方用傲慢的语气粗鲁的对你说，“你这个观点很愚蠢”，“我的一个朋友才是我见过最牛的（言下之意就是你不够牛）”，这时候说的人还有没有动力继续说下去？

交流的时候一定要怀着一颗平等的心。。。无论和你交流的人经验深浅，无论地位高低，无论贵贱。

4. 交流是双向的。要用心听，认真反馈

一个很好的实践叫做“Active Listening”，或者叫“主动倾听”。 所谓Active Listening，通俗的说就是指听别人交流的时候，要经常嗯嗯啊啊的赞同，并且不停的问“后来呢？”这个讲故事的人最爱听的短句，以及经常的总结一下对方的观点。这样的主动交流比较能够促进说话的人的积极性，使得话题能够不断的进行。

更重要的，是要对说话的一方提出反馈。工业上说反馈是质量的关键，只有建立了良好的反馈渠道，产品的质量才能达到客户的要求。当然，要区分的是，有时候别人说了一件事情，并不是真的想要听者提供反馈，只是抱怨和发泄一下需要听众而已。

关于反馈和提建议

1. 当你要反对的时候，请同时给出你的建议

在一个风和日丽的中午，你问旁边的同事：咱们中午一起去吃7-11好不好？他回答说：又是7-11啊，不去。或者，你好不容易写了一段感觉良好的代码，给你的同事看，他说：写的不好。（下面没有了）。总有一些人习惯于否定对方的意见建议，又不能给出自己的办法。这样人非常多。

当提出反对的时候，一定要同时给出建议。例如我们做开发过程的回顾会议（Retrospective）的时候，如果光说出不好的地方在哪里而又没有改进建议，那几乎和没说差不多。

2. 提意见建议之前，先赞扬好的一面

意见建议这个词，老外经常会用Feedback。这Feedback是个好词。辞典里说：“If you get feedback on your work or progress, someone tells you how well or badly you are doing, and how you could improve. If you get good feedback you have worked or performed well.”

说起Feedback的时候，隐含的含义就是要告诉你什么做的好，什么做的不好，并且告诉你如何改进。其中更重要的是要发扬好的。而反过来看我国这边，很多情况下我们叫提“意见建议”，意思就是对你做的不好的地方指点一下，在给你提出点改进建议。我国古代曾经有活动叫“批评与自我批评”，更多的是看到了坏的一面，而忽视了对好的一面的坚持和发扬。

有人发明了“建设性意见”这个奇怪的词，难道对应的应该叫“破坏性”意见？貌似从来就没有一个中性的词来指给别人的Feedback。可能是自古以来朝堂上就只有抨击诘责没有正面的Feedback吧，就算有也被归于了阿谀奉承、溜须拍马一类。由于我们的这种传统，在很多情况下，我们给人提Feedback时，都容易倾向于对人进行批评性的评论。而这种评论，是破坏团队关系公司文化的特效药。

3 Feedback的目的是提高效率和增强信心

以前参加过培训，其中一课就专门讲到给人提供Feedback。给人提供Feedback，你只有两个目的：提高对方的效率，或者增强对方的信心。前者，就是针对某些不好的地方提供改进建议，后者，就是对于对方做的好的地方表示支持和鼓励，希望他再接再厉。因此，所有的Feedback，应该都能够达到这两个目标。这两个作用之外的任何其他作用，都不是合适的Feedback。

我们公司内部Feedback的种类有很多，有非正式的Feedback，离开项目的Feedback，半年期的Performance Feedback，面试之后有Feedback等等，但做法都大同小异。首先，想要给人提Feedback，你要先获得对方的允许。反之，你如果想得到别人的Feedback，你要向对方正式提出邀请。

4 提Feedback要针对行为，要具体

人的行为其实都有动机。动机(Motivation)决定了态度(Attitude)，态度决定了行为(Behavior)。例如一个人的动机是想赚大钱，他的态度就会很积极上进寻找机会，他的行为就会表现为愿意参加各种创业俱乐部之类的。

提Feedback的时候，只能针对行为来提，或者说，就事论事，而绝对是不可以针对人的动机或态度提。例如说，提Feedback说这个人太自私，平时总不积极参加活动什么的。这是错误的提法。可以改为：某某最近不经常参加某活动，如果他以后能够参加这个活动，那么他能够在活动中获得什么什么知识等等。如果针对人的动机提Feedback，一来提Feedback的人会先入为主出现偏颇，二来听Feedback的人会听不下去。

另一个提Feedback的时候的常见情况是太空泛。常见的是在提Positive Feedback的时候，有人说：某某非常nice，某某非常容易相处。好话人人爱听，并且这好话都是针对态度的话。然而，这些话纯粹是拍马屁没有实际用途。 要用事实说话，举实例。要说某某做了什么让你觉得nice，某某做了什么证明了他容易相处。这些具体的实例对于接受Feedback的人会起到促进的作用。

另外要避免使用我认为，我估计，我猜，可能之类的词。因为这些词不客观。想对一个人进行了解，只能根据客观事实来判断，而不是可以根据别人的判断而判断。

5 给组织提Feedback就是Retrospective

当我们把上述的实践用于组织和过程，就是敏捷方法中常见的Retrospective了。Retrospective的目的是增强团队的效率和提高团队的信心，一个有效的Retrospective也需要：先提出团队过程中好的一面；当提出不好的时候一定要有具体的改进建议；提出的好坏方面都必须具体，对事不对人。

当我们每个团队的个体成员都学会了如何交流，如何提Feedback的时候，那么团队的自组织和自完善也就很好办了。团队建立起完全平等和安全的交流环境，成员们就会逐渐的去进行交流和反馈。

Tags: Agile 敏捷, communication, consulting, feedback

3 Comments | Posted in » Agile 敏捷, ThoughtBlogs

架设一个BLOG需要整合多少东西？

最近重新升级了我的Blog，BJUG的Blog到Wordpress 2.7.1，以及帮人新安装了Wordpress。期间涉及到了无数其他系统的整合和使用，列举如下。

1 Wordpress本身需要花费功夫的地方不多，比较容易，但Themes要花不少功夫调整，有时还得改CSS。推荐几个Wordpress Themes网站：

- http://themes.performancing.com/
- http://www.blogohblog.com/
- http://www.neoease.com/themes/
- http://www.underone.com/themes/
- http://www.billionstudio.com/
- http://wordpress.org/extend/themes/ - Official

2 访问统计当然要立即搞起来，首选的当然还是Google Analytics，另外加上Analytics Plugin

3 网站要做SEO，要用URL Rewriting，这个需要配置apache修改.htaccess文件的权限，另外要让Google快速索引网站，得用Webmaster服务并加上Sitemap Plugin。

4 网站用了别人的服务器，不能给网站太大压力呀，用Google的搜索代替Wordpress的搜索，用Google Custom Search Engine

5 做网站肯定得想赚钱拉，虽然咱这blog流量这么低估计赚不到什么，不过一分一毛也不能放过。架上Google Adsense 和 阿里妈妈 (审核不知道为啥没通过)，再用Adsense Plugin来管理。当然Feed广告也是一个值得设置的事情。

6 写Blog目的当然是为了展示自己，那“自己”包括什么呢？ 首先是个人的档案，先连上Google Profiles。然后把我在做的(Twitter)，我在读的(Google Reader)(Del.icio.us)，我在看的(Douban)，我的行程(Google Calendar)，我的旅途记录(Flickr)(Picasa)都聚合到我的blog。好在这些服务都支持HTML的Widget，不需要再安装插件了。

7 读Blog当然不能不用RSS订阅，先用Feedburner和Feedsky建立好永久的Feed免得遗忘丢失，然后在里面添加Feedflare以便订阅者再分享和收藏。

8 写Blog当然还要交朋友了。用Google Friend Connect来结识朋友，允许访客通过Google Talk Badge来联系自己，在评论中显示人家的Gravatar头像，安装Gravatars Plugin。让访客只要登录Friend Connect就可以评论吧比较方便，不过垃圾评论一定要避免，好在已经有了默认的Akismet plugin。

9 咱辛苦写好的文章不能被人随便拿走，所以要声明版权。用Creative Commons声明一下咱的文章可以转载，但版权归我且不能商用。

10 还想加其他东西到Blog？试试看Google Gadget的Embed功能。这里面几乎包含了所有的东西了。

11 呃，embed了太多服务blog打开太慢了怎么办。。。那。。只好。。把js代码改成异步读取。。用Google AJAX APIs异步调用JSON或RSS。。复杂了

12 最后，别忘了备案，@diamondtin同学没备案服务器已经被端了。

嘿，自己架设一个博客要干这么多事情，容易吗？  这个貌似可以提供一种专门的咨询服务了，专门为人架设博客。

11 Comments | Posted in » Consultant 咨询, ThoughtBlogs

QCon Beijing归来感想及总结

昨天和前天参加了两天QCon Beijing的会议。有所感想。

关于话题和话题的质量

听了2天的Session，发觉人的演讲水平确实能够很大程度上决定一个Session的好坏。这里说的演讲水平不仅仅是指台上的语音、声调、手势、姿态，还包括他做PPT的能力。

第一天的话题我主要听了敏捷开发部分。

Martin Fowler的Ruby Session特点是组织严谨。不愧是俺公司的科学家。观点的逻辑组织非常的严谨。所有的观点都有证据，满篇都是调查、数字、统计。基本上可以说，这个Ruby的话题可以作为论证Ruby在软件开发中价值的一篇很好的论文。结论是Ruby在ThoughtWorks被认为是Positive的选择。老马底气充足，吐字清晰，一口不标准的伦敦音非常容易懂。美中不足的是两点：1 他图片上的颜色选得很难看，2 PPT中采访的几个人说的话由于音响噪音干扰听不太清楚。

Henrik Kniberg的多团队敏捷胜在图片详实。他用很形象的图表示了团队的组成，又通过很多现场照片具体列出了实践的过程和问题。印象最深的部分是那个IPM的例子，90人的团队IPM/Planning的Session面对面来做，甚至不惜把人从不同的地方飞过来。总之讲的比较务实。一个值得借鉴的做法是他把图片中的人脸模糊化了以避免冒犯客户。

傍晚参加晚宴。晚宴中有位老外讲敏捷Session，明显的犯了几个演讲大忌：1 对听众了解不足。从敏捷历史甚至软件过程的历史讲起，认为下面听众都不了解。整个主题只讲了为什么要敏捷这一个话题。反正我是觉得没有新意。2 演讲的ppt很失败。一页八行句子，他还在照着读。加上现场音响不好，后面的人听不清楚。于是有的人开始私聊，隔一会儿抬头读一下PPT上的字。会场噪音更大。

之后的大师论坛还是很有趣的。几位老外＋Ben Wang在台上论述他们认为的企业开发发展趋势。话题不外乎云计算、动态语言、多语言编程、开源、敏捷/精益等。多数老外的论述比较充分，证据和推论都很清晰。其中唯一令我觉得不靠谱是Rod Johnson同学，他说了一些话让我觉得很费解，例如Opensource is good，because developers have to like it. 还勉强类比Tomcat是精益的软件，Websphere是不Lean的。说的有些不够令人信服。

第二天开始的话题主要是网站架构。

一开始是Rod的话题。他的演讲语速非常慢，慢到一句话都要分3短句来说。上述的Tomcat/Webshpere问题又被抛出。后来才知道SpringSource现在在维护Tomcat，这么做未免太着相了。。总之这个Session很平淡，没有什么出彩的地方，印象不深刻。

之后是EBay的话题。这个Session被讲过好多次了，唯一的问题是PPT字太多而且太小。。我们坐最后一排根本看不清楚第三级的字。强烈建议Randy下次改改PPT。这个Session概括了大规模Web的最佳实践、模式以及问题等等，可以作为这第二天全天话题的一个总结。虽然没有具体的实施例子，但把问题分析的很清楚。在什么情况下，应该采用什么样的策略，好处是什么，坏处可能有什么等等。

上午最后一个是一个讲Agile+CMMi的。这个Session的最大问题不在于演讲技巧了。。而在于他的观点本身，听了一会儿我们就听不下去了，决定提前去吃饭。后来Steven发帖提到：Joke of the day: “Repeatable and Controllable Agile Processes”

下午的话题是重头戏，估计大多数人是冲着这个来的。

首先是来自支付宝的程立带来的SOA治理。这个演讲的PPT可以说是最炫的PPT之一，画了很多的非常华丽的过程、架构等图，如果作为售前用PPT将非常有冲击力。然而，这个话题听的令我一头雾水，到后来基本全部LOST，不知道他在讲什么。归其原因，我认为有3点：1 演讲所提到的架构和我平时所理解的架构不是同一个“架构”。貌似这里提到的架构分很多种层次，例如公司架构、组织架构、业务架构、应用架构，不同层次有不同的关注点。SOA治理这个词更偏向于治理而非SOA，因此对核心名词语义的不同理解导致了从一开始我就没能跟上思路。2 演讲的PPT似乎没有一个清晰的逻辑主线。前后的逻辑关系我没能听清楚。 3 下午第一场，刚吃完饭，未免有些小乏。  以上原因导致该话题完全脱离了本人的理解范围。

豆瓣洪强宁的Session在会前被冯大辉狠狠的赞了一次。因此这次被报以的期望很高。该Session按照时间顺序组织。从豆瓣一开始上线的情况、架构选择，到后来不同用户级别时候出现的不同问题，应对措施，解决办法，甚至相关代码。非常完整和清晰的展现了豆瓣架构发展里程和其中所采用的具体策略。这样具体的Topic非常的精彩。强宁的演讲技巧也蛮好，语速发音都很专业，一定是练过。有趣的话题，专业的演讲，加得当的Slide，个人认为本Session可以当之无愧的成为QCon今年最佳Session。

有道的Session是关于日志分析。话题其实可以讲的很有趣，但遗憾的是邓毅同学的PPT做的貌似太过简单。原本可以讲的很详细很有趣的故事被简化到了若干的纯文字中，非常可惜。如果能够多一些图，更好的组织一下故事，可能会是一个非常精彩的演讲。

优酷网邱丹的话题也是关于性能和扩展性。由于优酷和豆瓣本身的区别，其对扩展所采用的策略和方式都非常不同。这个演讲的PPT做的有点山寨，图片看起来太简朴了。邱丹同学的演讲技巧还需要进一步加强才好。优酷和豆瓣的话题加在一起可以看做是对EBay Randy话题的完美诠释。一面是具体实践，一面是总结的模式和最佳实践。

从第二天下午的演讲，可以明显的看出，一份精彩的演讲，其讲师的技巧、PPT编写、话题的组织、以及对听众预期的满足都非常重要。任何方面的欠缺都会导致Session的精彩程度大大降低。

关于活动组织和对下次活动的期望

本次活动是QCon第一次组织国内的大会。能感觉到QCon在组织方面做了很多的努力，但规模貌似还是有些保守了，可能是怕第一次做太大万一失败有压力吧。组织方式上有很多方面值得其他办活动的人借鉴和改进。

组织方面：

路标提示。虽然在网站上写清楚了地址，但现场的标记似乎还不是很清楚。只看到会议厅最前面有个白板上画着地图，这白板应该放外面去。尤其一楼门口应当设置一个大大的广告牌。很多人一开始都找不到这地方。

吃饭时间和方式。目前大家同时放学去吃午饭，结果排长队或者没地方坐，结果导致下午会议延时开始。这是典型学校食堂遇到的问题。。一般学校都靠错开吃饭时间来解决。但显然这会议时间错不开，不妨弄点简单食物，或者延长午休时间。

午休时间如何利用。午休时间大家好像在会场里面没啥事情，于是就有人播放美女视频。。这个时间其实本可以是各个厂商展示的好机会。

茶歇。。有点山寨。。咖啡饮料都装在一个19升的矿泉水桶里面送来。。可以理解这是为了减少成本。不过貌似这方面还是可以改进一下下的。另外吃的和饮料都摆在一个桌子上造成了拥堵。

主持人和课程组织。这次活动主持人的作用没能很好的发挥出来。每个主持人都是该领域的专家，如果他们能够更多的露面和讲话就更好了。例如晚上可以分会场让每个主持人来组织活动。

晚宴的组织。晚宴时候最大的败笔就在于座位的摆放。其实晚宴更多的应该是社交活动，有没有椅子都不重要。重要的是大家应该能四处走动和别人搭话交流。晚上饮料提供的不够哎，喝了点水就没了，再说半天话口干的很。

设施方面（理想会议场馆建设指南）：

讲台布局。这次的场馆讲台中央很宽大，但作者只能站在一个小台子边上做演讲，两边的投影幕布太小了，字小了看不清。如果有场馆能提供TED那种讲台就好了。下回找个舞台或剧院试试看。

会议厅。这次分了两个厅，大厅很宽敞，但是小厅非常的狭小，很窄很长，屏幕又小，又不够通风。因此小厅的效果不好。理想的场馆应该是能有大厅一个，多个50－100人的小厅才够用。

网络和电源。现在越来越多的活动鼓励大家twitter或者上传现场照片，这样网络和电源就成了必需品。这次的无线网络的DHCP不能用，因此很多人都没法上网。电源也是稀缺物品。

存物柜。现在这季节大家都穿个大衣来，进屋又要脱。如果有场馆能够提供一个地方挂衣帽就更好了。如果能临时锁书包就更佳，因为大家很多都带着电脑来，中午又不放心放会场，只能背着去吃饭占用食堂空间。

当然拉这些只是我自己的理想中的场馆。貌似这样场馆真不多。

对于下一届QCon的期望，当然是希望能够像QCon london一样举办5天每天5个track一共近百的Session才好。这才能显示出QCon在技术社区的影响力。

关于参会的目的

从公司角度来讲，公司来参加这样的会议一方面是建立自己的品牌，看是否能有业务机会，一方面也是可以支持公司员工学习交流。

从个人角度讲，参加QCon学习知识只是一方面，其实最大的目的还是来交朋友。这次俺结识了几位新朋友，例如冯大辉、洪强宁，也见到了以前网上聊过很多但一直没过见面的几位，例如林昊、苏锐、Steven Mak麦天志，还见到了好久不见的老朋友吕晋、InfoQ编辑团队一小撮人等等，嘿嘿，非常的高兴。遗憾的是时间有限没能一起去吃饭哎。

有一些参会人，来了之后就光听讲座，听完之后不提问题也不和人交流，这样的参与者回家之后能获得什么呢？公司花几千元买的门票，不是让你来上课的。想听讲座的人在家呆着听视频看文章多好，还省事。

Tags: qcon, qconbeijing

3 Comments | Posted in » Agile 敏捷, ThoughtBlogs