Archive for the ‘ThoughtBlogs’ Category
Thursday, May 7th, 2009
我今天出差讲的ppt，第一次在一个舞台上演讲。。聚光灯照的我完全看不见台下人表情，烤的我一头汗。
总结：
Well：观点来自我的论文；时间刚好1小时；图像比较符合；
Less Well：互动不足；乐趣不足，图片找的太匆忙；history部分讲的感觉有点简略；自己画的图貌似有点小错；时间太短，一些观点没法讲透彻。
Tags: Agile 敏捷
Posted in Agile 敏捷, ThoughtBlogs | 5 Comments »
Monday, April 20th, 2009
关于交流
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
Posted in Agile 敏捷, ThoughtBlogs | 3 Comments »
Thursday, April 16th, 2009
最近重新升级了我的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同学没备案服务器已经被端了。
嘿，自己架设一个博客要干这么多事情，容易吗？ 这个貌似可以提供一种专门的咨询服务了，专门为人架设博客。
Posted in Consultant 咨询, ThoughtBlogs | 11 Comments »
Thursday, April 9th, 2009
昨天和前天参加了两天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
Posted in Agile 敏捷, ThoughtBlogs | 3 Comments »
Sunday, September 28th, 2008
此指南为我所在的项目引入新BA的参考步骤，并非ThoughtWorks官方指南，仅适用于特定项目的特定情况。
Task 1: 请自己去认识团队的所有人。
BA肩负着交流者的使命，需要和客户和团队都创建一定的关系，主动去认识每一个人，做自我介绍，发放名片，请大家多关照，以后合作愉快。
Task 2: 了解项目背景
BA应该是最了解项目背景的人。项目之后的驱动因素，项目的目标，项目所解决的问题，项目的流程，项目所涉及到的其他系统，项目的范围，项目的涉众，项目的用户，项目的发布蓝图，项目的当前状态。
Task 3: 简单了解敏捷开发过程
在敏捷的过程中，BA处于一个承前启后的角色。BA需要了解项目过程中的各个术语，项目迭代的长短，交流方式和频度，客户如何计划，如何给客户展示，每天何时开始工作，项目状态交流方式，团队的分工，分布团队的工作方式等。
Task 4: 了解BA工作职责
BA的日常工作包括很多事。每个迭代让客户确认需求，与客户沟通，澄清问题，询问细节，电话会议，组织讨论，给开发团队介绍业务，保证开发速度，在mingle上管理需求，确认defect的优先级，回答开发人员的问题。
Task 5: 学习基本BA技能技巧
BA的基本生活技能包括：和业务人员的交流能力，和技术人员的交流能力，足够的展示能力，能够可视化的表现需求，演讲文稿制作，英语交流和写作，商务信函的处理，控制会议的简短和有效，有条理的描述清楚需求，分析复杂的需求和过程，快速发现用户问题，设计良好的用户体验，逻辑的分析和叙述问题。
Task 6: 尝试完成当前项目的工作任务
快速了解系统功能，阅读项目的需求清单，在本机实际运行项目，测试和了解项目的功能，Shadow当前的有经验的BA，接手简单的工作，处理业务邮件，参加需求讨论，阅读以前的相关文档。
Task 7: 了解BA的Career Path
和sponsor坐在一起，了解行业中的BA能做什么，我们公司的BA做什么，BA发展发展方向有哪些，公司提供哪些机会给BA发展，公司提供什么培训，明确自己的兴趣爱好，搞清自己对生活与工作的权衡，找到自己的前进动力，确定自己的发展目标
Task 8: 制定自己的学习计划
确定一个短期计划，确立学习和努力目标，制定近期的实现步骤，阅读参考书或资料，定下review时间，为自己创造压力，然后努力的开始做这份有前途的BA职业吧。
附录：新时代情况下对新BA的四大要求：
要聪明，客户时间紧团队任务重，没有人有空把一个事情解释很多遍。
要谦虚，在没搞清楚问题之前不要自以为全盘了解。
有条理，要能够在毫无头绪的需求中有逻辑的分析出可行的方案。
英语好，不仅仅是读写，听说更加重要，并且要是business english.
Tags: Agile 敏捷, Analyst, Business
Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 需求分析 | 1 Comment »
李默，ID冰云，ThoughtWorks公司高级咨询师、业务分析师，敏捷过程教练，BJUG创始人。目前主要专注于互联网产品需求管理与市场营销的合作、产品交互设计、敏捷组织方法等方面的工作。联系方式: icecloud (at) gmail.com 
