Archive for the ‘杂谈’ Category

兴趣?

Friday, July 16th, 2010

我时常听到类似这样的说法:

“小时候我很喜欢音乐的,唱歌很好,老师经常夸我。我自己也很喜欢唱歌。可是后来上大学的时候家里人不让我报考音乐学院……”

结果呢,我看到的是基本被搁置一边的天赋,和大量的时间用来看花边新闻八卦杂志研究时尚美容等等等等。

“其实我是个写代码的。我不应该在这里,应该在一个角落里快乐的编写着代码。”

结果呢,我看到的是在真正需要写代码的时候,表现出来的迟钝和生疏。

我也看到很多很多时常将兴趣挂在嘴边,行动上却吝惜投入的人。相信你也看到。或者你就是。

兴趣是一种信仰。

当你真的觉得某些事情是你真正热爱的方向的时候,就应当真正的花时间去追求。原地期待不会有任何结果,朝三暮四更不会。朝九晚五然后说没有时间不是借口,全力投入的一两个小时的产出将远远超出你的想象。

我曾经劝说过很多人,放弃平凡的工作去追求自己真正热爱的人和事。然而真正接受建议的人很少。四平八稳往往是大多数人的选择。很多时候激情、冲动、莽撞之间划上约等号,弄的人搞不清楚这股情绪到底是什么。年长者考虑太多,出于善意,他们往往会说,

“年轻人,别冲动。”

可是,不冲动,是年轻人么?!

兴趣是一种信仰。而信仰要体现力量,需要长时间的近乎虔诚的朝拜和练习。整天挂在嘴边的兴趣不是兴趣。天天练习,以此为生活准则和行为习惯,并且得到广泛认可的小有所成,那才是真正的兴趣。

Disconnection(连接中断)

Friday, May 21st, 2010

连接中断这件事情其实不仅仅是物理现象。

《阿凡达》里面,氧气舱里Jack的连接线被拔除意味着他无法在潘多拉星球上与那些纳美人无法再交流。此时纳美人看见的Jack似乎是一个毫无生气的尸体,而氧气舱内的Jack则对发生在纳美人群体内的事情一无所知。还记得面对即将碾压而来的巨型机器,公主疯狂的拖拽着毫无知觉的Jack。而已经断线的Jack则像一个橡皮偶一般,毫无知觉。而一旦连接线被接上,Jack瞬间可以对现状作出反应。

《水云间》中,梅若鸿的十年前的结发妻子为了成全他而投湖自尽,大受刺激的梅若鸿近乎成为植物人,似乎他与整个世界已经断线。无数的好友、亲人都没办法叫醒他。最终是杜芊芊胸前的红玫瑰纹身,唤醒了他,使他与这个世界重新相连。


在我注意到的沟通不畅的现象中,很多情况是,参与沟通的个体与与整个沟通场景之间连接中断。如果只是一个人产生中断,那么沟通过程对于这个人而言会是比较痛苦的;但如果这个人非常重要,比如是领导或者其他话语权比较强烈的,那么其他人会比较痛苦。他们的痛苦,与上面描述的两个案例是没有太多不同的——花费了大量的气力,其实不是为了最终解决什么问题,而是为了与场景产生连接。简单的表现就是:花费大量的时间去描述问题本身,而非去谈论解决方案。

前一篇文章中,我发现我所花费的大量的时间所营造的,只是让每个参与沟通的个体与场景之间产生连接。在绝大多数情况下,一旦连接建立,问题就已经解决了一大半——剩下的事情就是依赖每个人的创造力去将问题解决。沟通最大的问题,是你以为它发生了,其实它没有。在《世界咖啡——创造集体智慧的汇谈方法》这本书里面,我看到大多数费尽心思的氛围营造——包括4-6人小圆桌,无处不在的摄像头,大屏幕,可以书写的餐桌布,等等,都是为了将连接建立的成本降到最低,让连接迅速建立,从而让沟通的效率更为集中的体现在价值创造上,而非问题澄清上。

这个说法也可以解释为什么我们需要可视的状态墙进行任务管理,为什么需要将应用程序的原型图贴到到处都是,为什么需要尽可能多的保持结对更换、尽可能多的进行面对面沟通,一切都是为了保证连接是常在的,否则连接一旦中断,你期待着谁会在胸前纹上鲜艳的红梅花去让谁清醒呢。

原来是人祸

Thursday, April 15th, 2010

这里这里,读到了如下信息:

西南干旱后,很多人认为,是由于下雨少所致,也即天灾所致。但是,查一下新闻后,发现类似的“天灾”一直在上演(仅以云南的新闻为例):2004年,我国南方“遭受53年来罕见干旱”,云南在干旱之列;2005年,云南“遭遇近50年来最大干旱”;2006年,“云南遭遇20年来最严重旱情”;2007年,“云南大部地区降水不足,气温偏高,旱情日趋严重”;“2008年云南连续近三个月干旱”;2009年,“云南省遭遇五十年一遇的严重旱情”;2010年,云南“秋冬春连旱”百年一遇……

我实地调查得出的结果是:西南干旱,一分天灾,九分人祸。

如此险地都被刨开用作农田
如此险地都被用作农田

桉树
所谓的高经济作物桉树,让物种变得单一,成为绿色的沙漠:雨水来了泥土流失,大旱来了与其他植物抢水。


一旦金钱成为从上至下追求的目标,那么什么都变了。由于在认知上的局限性,当时空上因果关系看不到连续性的时候,人索性放弃了任何信仰。60年代建立的水库设施,在改革开放近30年的时间里,就不记得修葺,以至于雨季存不下水,旱季没有水;片面的认为绿化就是种树,将侵略性极强的桉树大面积栽种,所到之处,除了桉树草木不生,动物也不来,彻底破坏生态平衡;一旦没有水,没有想办法解决集水的问题就到处打井寻找地下水,导致地下水位下降,进一步造成不可预知的影响;“先污染、再治理”带来的是花10亿去污染,然后花10倍以上的代价去治理;为了城市供水,农业和农民一起被边缘化,为了GDP, 大量的炸山开矿填海围田……

一些悲剧正在上演:情人湖上的别墅听起来如同烹食天鹅肉一样让人悲愤;沙漠上好不容易防风固沙的沙棘生态林被弄成高尔夫;还有一些扑朔迷离的东湖填湖事件,就发生在我的家乡武汉——我不敢想象,失去东湖的武汉人,会愤怒悲伤到何种程度……

这些,我们又能做些什么呢?为什么生活越现代,信仰就越匮乏?《阿凡达》中潘多拉星球上的惨胜,或许只是导演一厢情愿的美好愿望——真实情况也许是,世界之树被连根拔起,所有的树木被砍倒,地面铺上水泥和柏油,大量的超导矿石被拉走——或者留下几棵树,作为观光景点,建立一片别墅群……在最终资源毫无利用价值之后,这颗星球被毫不留情的废弃,成为宇宙中的垃圾……

何为完美

Tuesday, April 13th, 2010

iPad出来了,这个被压扁的iPod立刻引起了大众的吹捧。当然也迎来了众多评论家挑剔的眼光,什么不支持多任务,没有摄像头,没有USB插口之类的“七宗罪”。作为乔布斯粉丝,我一笑而过:乔布斯如此聪明并且追求完美的人,难道没有意识到这些缺陷吗?在他眼里,难道这些不值得去做吗?

无独有偶。今天有个人打开浏览器窗口,打开CruiseControl的Dash Board页面,等着看Build Result Tab下面会不会出来构建过程的输出结果(其实就是构建控制台的输出)。他等啊等啊,5分钟过去了,就是没等到。

“你为什么要看到这个信息?”
“因为这个信息有用啊”
“有什么用呢?”
“这是用户友好的一部分,不然我只看到一个正在构建的图片,却不知道他正在做什么”
“……嗯,听起来有道理,那么,即便你能看到了,又能做什么呢?”
“……还是有点用的吧?”
“你看到这个信息无法停止无法取消只能等着,如果你真的想看,完全可以到CruiseControl服务器上看,否则只能影响自己手头的工作。再说了,哪个人提交之后会等着刷这个屏幕来看构建信息呢?”

我承认能够显示这些状态当然更好。但是在过去多年使用持续集成服务器的经历中,我却不记得是否真正想起看这个构建过程——老实说新版本的dashboard我一直是不喜欢用的 – 老式的更好用一些,信息精炼,有效,迅速,直观,加上声音指示,团队所需要的仅此而已。完美的持续集成服务器,就像所有的服务器应用一样,需要的是健壮,稳定,不错报,主动通知,而不是像愚蠢的Windows更新程序一样,隔一段时间弹出来告诉你,我要如何如何了,你是否同意——很多时候都没有选择(现在的更新程序已经好很多了)。

我见过许多在错误的完美之路上走得太远的产品:Notes – 大量的功能堆砌,我敢肯定80%的菜单都没人点开过;HTC Dream (G1) – 在硬件尚不完美的情况下使用Android多任务操作系统导致系统响应毫无悬念的变慢;Windows Vista – 错误的认为华丽是系统的首要任务而将可用性置之于外;金山的剑网三 – 模仿了魔兽大多数设计在山水场景花了太多功夫但打击感和操作感觉使其无法真正引人入胜。

你要的完美是什么?这是一个值得思考的问题。有时候我们被完美蒙蔽了眼睛,过多的专著于某些细节不能自拔而对主功能产生忽视。精雕细琢的局部完美往往耗时过久,如果这些不能在真正意义上产生巨大的价值那么就是一种更为巨大的浪费。例如37Signals的Campfire – 直到现在开发团队都拒绝在聊天框里加入富文本编辑的功能(例如加粗、笑脸符号之类的),他们说“用户完全可以通过字符,例如 *强调* ^_^ 笑脸 来表达。这种功能,我们不会做”。但是与此同时,他们在图片的分享,复制粘贴的支持上花了大量的功夫。

完美不完美,取决于产物想向外界传达的意图。只有充分理解了这些意图,才能真正明白完美的局限性 – 不是处处完美,而是在必要的地方。

体制化

Sunday, February 7th, 2010

These walls are kind of funny like that. First you hate them, then you get used to them. Enough time passed, get so you depend on them. That’s institutionalizing

来自《肖申克的救赎》。

越来越觉得,所有的咨询工作,最终的目的,是唤醒被体制化的人,唤醒他们原本的认知,唤醒他们原本为之追求的希望,唤醒那些原本属于他们现在却不得不依赖于指令规则的直觉。

闲话:关于敏捷

Wednesday, September 23rd, 2009

(10:09:50 PM) Stephen H. Wang: 好像很久没看到你上网了。:)
(10:10:52 PM) Michael: 最近白天都不用电脑
(10:10:58 PM) Michael: 工作原因
(10:11:06 PM) Stephen H. Wang: 哦,不用电脑?太神气了。
(10:11:11 PM) Stephen H. Wang: 神奇
(10:11:22 PM) Stephen H. Wang: IT业居然不用电脑*-)
(10:11:45 PM) Michael: 做咨询了…主要靠说话
(10:11:59 PM) Stephen H. Wang: 我们领导明天准备给我们安排一个讲座:Refactoring – Martin Fowler的书。
(10:12:04 PM) Michael: 哦
(10:12:08 PM) Stephen H. Wang: 哦~~~~原来如此,好工作!
(10:12:12 PM) Michael: 谁来讲
(10:12:17 PM) Stephen H. Wang: 内部安排的。
(10:12:28 PM) Stephen H. Wang: 可是就是这个领导,居然不认可你们公司的工作流程…
(10:12:33 PM) Stephen H. Wang: 我只有无语了。
(10:13:04 PM) Stephen H. Wang: 我第一次看这个书,说实在的,收获太大了。
(10:13:20 PM) Stephen H. Wang: 越接触敏捷,越觉得你们公司厉害。
(10:13:54 PM) Michael: 哈哈
(10:14:00 PM) Stephen H. Wang: 越来越觉得ISO,CMMI那一套似乎说得好,行不通。 – 软件还是人写的。不是过程写的。
(10:14:17 PM) Michael: 。。。
(10:14:21 PM) Stephen H. Wang: 除非有无限的资源,否则,初级程序员写出的代码质量不高。
(10:14:22 PM) Michael: 你不是现在才了解吧…
(10:14:41 PM) Stephen H. Wang: 第一次接触敏捷的时候知道这个概念,但是现在是实践出真知。
(10:15:06 PM) Stephen H. Wang: Daily Build, Night Release….
(10:15:37 PM) Stephen H. Wang: 而采用瀑布式根本做不到,怎么应对市场变化。
(10:16:00 PM) Stephen H. Wang: 不过,近期也有疑问,就是敏捷如何做测量。
(10:16:21 PM) Stephen H. Wang: 怎么判定软件的质量好坏。例如,以前提到的千行代码缺陷率。
(10:16:42 PM) Michael: 。。。
(10:16:45 PM) Michael: 你自己觉得呢
(10:16:51 PM) Stephen H. Wang: 不知道
(10:16:54 PM) Stephen H. Wang: 所以才疑惑
(10:16:57 PM) Michael: 我们的客户前一阶段就问了这个问题
(10:17:12 PM) Michael: 我的回答是 — 这就是一个扯蛋的指标
(10:17:12 PM) Stephen H. Wang: 我想转型的时候都会有此一问。
(10:17:24 PM) Michael: 当然没这么说…
(10:17:27 PM) Stephen H. Wang: 那么,如何判定敏捷以后的质量呢?
(10:17:38 PM) Michael: 按照Story来
(10:17:46 PM) Stephen H. Wang: 是因为自动测试 – All passed 所以就是质量过关了吗?
(10:17:47 PM) Michael: 每个Story的缺陷数量
(10:18:00 PM) Stephen H. Wang: 可是,每天一个发布,如何统计缺陷数量?
(10:18:22 PM) Michael: 你要想到 缺陷率是典型的后置式检查
(10:18:32 PM) Stephen H. Wang: 对!完全同意
(10:18:37 PM) Michael: 而敏捷里面所有的实践,质量是隐含的,不可侵犯的
(10:18:49 PM) Michael: 这就是我们所说的Built Quality In
(10:19:09 PM) Stephen H. Wang: 嗯,这个概念的确是很好。
(10:19:12 PM) Michael: 从项目的一开始,质量检测环节就贯穿始终
(10:20:11 PM) Michael: 比如,刚开始写Story, 就要和测试人员定义验收条件;开发Story采用TDD的方式,通过测试来检验功能,类似于砌墙的时候先扯水平线,然后开始铺砖
(10:20:27 PM) Stephen H. Wang: 嗯。
(10:20:34 PM) Michael: 一般的敏捷项目,测试代码与开发代码的比例至少是1:1。我们的项目一般是2:1甚至3:1
(10:20:50 PM) Michael: 千行代码缺陷率对于敏捷项目而言是个笑话
(10:20:57 PM) Michael: 因为代码行数是个很扯淡的指标
(10:21:16 PM) Stephen H. Wang: 呵呵,这个指标是针对以前的过程式开发而设立的。
(10:21:20 PM) Michael: 分母都没意义,分子除以分母更没意义
(10:21:50 PM) Michael: 比如说,你用2000行写了一个功能,发现了1个bug;我只用了20行,也发现了同样的bug. 是不是说你就比我厉害呢
(10:22:07 PM) Stephen H. Wang: 同意。
(10:22:49 PM) Stephen H. Wang: 可是 – 社会平均生产率这个词总还是能够说明一些问题的吧。
(10:22:50 PM) Michael: 开发软件是一项艺术活动。代码行导向的指标完全将其视作计件工人。
(10:23:13 PM) Stephen H. Wang: 是的,即使MS,也有Software Factory一说。
(10:23:23 PM) Stephen H. Wang: 日企更是大行其道。
(10:23:44 PM) Stephen H. Wang: 所以,有一个词:软件蓝领就应运而生了。
(10:23:56 PM) Michael: 软件的生产率仅仅取决于可工作的软件。所谓的生产率应该是产生可工作的软件的效率。代码行只是手段
(10:25:27 PM) Michael: 比如,你每天写1000行代码,没有可工作的软件,因为你只写数据库后台了;我每天只写50行,数据库弄一点,前台加一点,当天发布,第二天客户就能用。按照代码行统计,你的工作效率是我的20倍;但按照可工作软件的角度,你的效率是0
(10:25:52 PM) Stephen H. Wang: 换个贴切的词,我的效果是0
(10:26:34 PM) Stephen H. Wang: 也就是说,我每天都给客户发一个“可用的”软件,永远的beta是这个意思吗?
(10:27:20 PM) Stephen H. Wang: 那么你研究过ISO关于质量的6个特性吗?
(10:28:13 PM) Stephen H. Wang: 错了,是ANSI/IEEE
(10:28:39 PM) Michael: 没..
(10:28:41 PM) Michael: 啥特性
(10:28:57 PM) Stephen H. Wang: Functionality, Reliability, Usability, Effetioncy, Maintenability, Portablity.
(10:29:11 PM) Stephen H. Wang: 他们还分解成20几个小的特性。
(10:29:15 PM) Michael: 这个没错啊
(10:29:37 PM) Stephen H. Wang: 我们的测试人员在担心,如果不用手工测试,无法确保这些特性都达到预期的指标。
(10:29:51 PM) Stephen H. Wang: 这个就是我疑惑的地方。
(10:30:16 PM) Stephen H. Wang: 当然,我也在想,他们是为了保住饭碗,拼命地证明自动测试工具无法全面达到测试目的。
(10:30:33 PM) Stephen H. Wang: 但是Agile的团队,会不考虑这些吗?我想不会的。
(10:31:41 PM) Stephen H. Wang: 比如说吧,一个B/S的系统,应该能够运行在,windows 2000/xp/vista + IE 6,7,8 or Linux + FF or Chrome or Mac + Safari…
(10:32:01 PM) Stephen H. Wang: 可是这些全测试的话,人工测试会花开发几倍的时间。…..
(10:32:22 PM) Michael: 保住饭碗是个很正常的需求。正视这个需求,Agile有更好的办法解决
(10:32:50 PM) Michael: 那就是,测试人员与开发人员属于同一个团队,在一张桌子上一起工作
(10:33:36 PM) Michael: 测试人员的手工测试有价值,但正因如此,所以要将那些无价值的人肉回归测试纳入到自动化中,让测试人员有时间做更有价值的手工测试
(10:34:01 PM) Stephen H. Wang: 我知道Agile的这个做法,可是这正是CMMI最反对的地方。他们认为开发和测试应该分属两个不同团队,测试人员的工资,奖金,评定等都不受开发经理的制约,这样他们才能有勇气去测试并公开全部的bug.
(10:34:23 PM) Michael: 你觉得合理么…
(10:34:30 PM) Stephen H. Wang: 似乎两者都合理。
(10:34:40 PM) Michael: 开发人员跟测试人员彼此仇恨就对来两者都好吗
(10:34:40 PM) Stephen H. Wang: 所以我最近一直在迷惘着。
(10:34:50 PM) Michael: follow your heart…
(10:35:17 PM) Stephen H. Wang: 而那个做法正是规避仇恨的方法。如果归于同一团队(非Agile模式下),测试人员真的没有勇气提出Bug。
(10:35:37 PM) Stephen H. Wang: 所以,我想Agile肯定有另外的理由,使得测试人员勇于提出自己的见解。
(10:35:42 PM) Michael: 勇气是敏捷基本价值观之一
(10:35:54 PM) Michael: 你不提bug, 是对开发活动的不贡献
(10:36:03 PM) Michael: 这只是个假设
(10:36:30 PM) Michael: 事实上,敏捷团队里面,测试人员的成长比普通测试团队里面的成长更快
(10:36:39 PM) Michael: 而且开发人员的测试观念也成长更快
(10:36:40 PM) Stephen H. Wang: 比如:刚才提到的千行代码缺陷率,这个可能才是真正的引起开发和测试之间有矛盾的地方? – 因为Bug率直接影响了对开发人员的评价。
(10:36:58 PM) Michael: 其实从根本上说,就是个绩效问题
(10:37:09 PM) Michael: 按bug数量基本上是没戏的
(10:37:47 PM) Stephen H. Wang: 可否这么理解,开发团队和测试团队在一起,组成一个新的Agile团队,他们在一起,为了一个共同的目标而奋斗,一荣俱荣,一损俱损,才是能够让测试人员勇于提出Bug的根本原因?
(10:37:54 PM) Michael: 程序员产生代码行,测试人员消费代码行并提出bug, 这个貌似完美的生态系统粗鲁的无视软件开发完整性的客观规律
(10:38:00 PM) Michael: 没错
(10:38:13 PM) Michael: 整个团队只有一个目标:产生高质量的交付
(10:38:45 PM) Michael: 在此目标之下,以尊重 交流 反馈 勇气 简单为基本做事价值观和原则
(10:38:55 PM) Stephen H. Wang: okay,Quality和Delivery你都提到了,那么Cost呢,前两天听到一个老实说,敏捷是高成本的。我就更疑惑了。…
(10:39:06 PM) Michael: 谁说的…
(10:39:12 PM) Michael: 胡扯
(10:39:17 PM) Stephen H. Wang: 一个搞ISO/CMMI的老师…
(10:39:30 PM) Stephen H. Wang: 来跟我们讲如何进行软件的QA活动和Measure活动。
(10:39:50 PM) Michael: 靠,这样的话,如果没有充分的根据,会被喷的不像样子
(10:40:21 PM) Stephen H. Wang: 是啊,可是听课的大部分都是CMMI的忠实粉丝,所以我就没有多言,但是心里却很鄙视她的说法。
(10:40:53 PM) Michael: 你读过精益相关的书吧
(10:41:08 PM) Stephen H. Wang: 没有读过,只是听过TW的讲座。初步了解一点。
(10:41:24 PM) Stephen H. Wang: 知道这是起源于Toyota的一个生产汽车的思想。
(10:41:27 PM) Michael: 精益里面的核心观念:价值 价值流 流动 拉动 尽善尽美 这个你应该略有所知…
(10:42:32 PM) Michael: 核心思想是分析所有经营活动,找出其中的价值,找出价值流及其浪费点,使其流动,通过前端市场拉动,并让整个过程尽善尽美
(10:43:17 PM) Michael: 例如,软件开发中有价值的活动有 需求分析,架构设计,编码,测试,部署,客户演示等
(10:43:32 PM) Michael: 价值流基本与上述过程类似
(10:44:08 PM) Michael: 然而,这个价值流存在巨大的浪费:从需求分析到最终客户演示,在CMMI中需要几个月甚至一年的时间
(10:44:12 PM) Michael: 这是流不动的
(10:44:42 PM) Michael: 而敏捷里面,消除了漫长的等待而状态转换
(10:45:01 PM) Michael: 在一个短短的2周迭代开发中,上述所有活动都有一个完整的闭环
(10:45:23 PM) Michael: 客户可以在最多2周的时间里,得到一个完整可用的应用
(10:45:34 PM) Stephen H. Wang: 嗯,看来还是这个说法,就是非常多的瀑布迭代组成了一个敏捷整体。
(10:45:59 PM) Michael: 嗯
(10:46:01 PM) Stephen H. Wang: 那我有个故事要跟你分享一下。
(10:46:11 PM) Stephen H. Wang: 我去年到今年做了一个项目。
(10:46:24 PM) Stephen H. Wang: B/S的,java +jsp + DB2 + websphere
(10:46:33 PM) Stephen H. Wang: 采用了CMMI的开发方式。
(10:46:55 PM) Stephen H. Wang: 大约有100个左右的story(不知道你们的story是以什么级别划分的)
(10:47:10 PM) Stephen H. Wang: 最终制作了130多个页面。
(10:47:44 PM) Stephen H. Wang: 我的做法是这样的,先进行需求分析,彻底的分析,将每个细节都分析透彻,没有遗漏,没有二义性,没有错误….
(10:47:51 PM) Stephen H. Wang: 然后,组织开发团队进行开发。
(10:48:13 PM) Michael: 嗯…
(10:48:17 PM) Stephen H. Wang: 在我们公司几近变态的测试下,1次性通过测试。(这是以往没有的经历)
(10:48:33 PM) Stephen H. Wang: 我想知道,如果用敏捷的话,这么大规模的系统,你们大概需要多少个人月。
(10:49:03 PM) Stephen H. Wang: 我现在已经收到客户的需求变更要求。 – 我知道,如果用敏捷,那么这些要求将会在中间出现。而不是现在。
(10:49:22 PM) Michael: 我们不会这样估计。
(10:49:36 PM) Stephen H. Wang: 是的,我了解,这正是不同之处。
(10:49:59 PM) Michael: 我们会每个迭代给出一个交付版本,一般每两周给客户看一次
(10:50:05 PM) Michael: 让客户决定优先级
(10:50:25 PM) Michael: 当然在这之前,有一个大约2-4周的需求全面分析和优先级排序阶段
(10:51:13 PM) Stephen H. Wang: 我的需求分析投入了4个人,2个月。也制作了Demo和上千页的文档。我跟客户用了3整天,确认了所有细节。
(10:51:34 PM) Stephen H. Wang: 然后客户签字,这个就作为开发的依据 (当然,我这次的做法和以前比已经改革了许多)
(10:52:40 PM) Stephen H. Wang: 状态图,流程图,ER图….这些都是辅助我对需求进行分析的工具
(10:53:07 PM) Stephen H. Wang: Demo做的和成品都差不多了。就是数据是假的。
(10:53:38 PM) Michael: 这种做法叫lofi-prototype
(10:53:50 PM) Michael: 俗称原型法
(10:53:53 PM) Michael: 也不错
(10:54:13 PM) Stephen H. Wang: 正是如此,惭愧的说一句,我是在本公司第一个这么做的人。
(10:54:33 PM) Stephen H. Wang: 之前的系统更糟糕。质量不如意 – 这也是我一直探究如何解决的问题。
(10:54:51 PM) Stephen H. Wang: 举例来说,你们的测试人员会不会对左对齐右对齐,进行定义?
(10:55:31 PM) Stephen H. Wang: 就如这MSN的IM框,显示的log一定是左对齐的。
(10:55:31 PM) Michael: …啥叫左对齐?
(10:55:39 PM) Michael: 有啥用呢?
(10:55:49 PM) Stephen H. Wang: 并且,换行的时候必须根据窗口的大小自动调整。
(10:55:57 PM) Stephen H. Wang: 这是Usability的一项。
(10:56:10 PM) Michael: 如果客户需要,我们就做
(10:56:13 PM) Stephen H. Wang: 试想一下,如果Log都是右对齐的,我们看起来会是什么效果?
(10:56:28 PM) Stephen H. Wang: 可是如果客户没提呢?你们会主动的询问客户吗?
(10:56:33 PM) Michael: 当然会了
(10:56:43 PM) Michael: 但…这个左对齐是常识吧
(10:56:50 PM) Michael: 我们不做决定
(10:57:04 PM) Stephen H. Wang: 呵呵,这个不是常识……这个是技术。
(10:57:26 PM) Michael: 通过每个迭代的客户showcase, 让他们来提。然后统一放到剩下的,没有开发完的需求中,进行估计和优先级排序
(10:57:54 PM) Stephen H. Wang: 金额怎么对齐?日期怎么对齐?页面太宽了,HTML不能对每一列都设置固定宽度,如果这么做,等于对所有的都没有设置。
(10:58:37 PM) Stephen H. Wang: 所以,需要空一列不设置宽度。这样才能够在窗口缩放的时候自动适应大小。并且,可以适应多种分辨率,从1024*768 ~ 1280*1024都可以
(10:58:55 PM) Michael: 。。。你想说啥
(10:59:16 PM) Stephen H. Wang: 那么,空出的那一列,基本上都是显示内容最多的那列,okay,我们通常会对齐进行截断字符串,并且以tooltip的形式显示出来。
(10:59:24 PM) Stephen H. Wang: 那么截多长呢?
(10:59:29 PM) Stephen H. Wang: 这个也要问客户吗?
(11:00:15 PM) Stephen H. Wang: 我想,客户不会像我这么细,连这个问题都一一说明的。
(11:00:49 PM) Stephen H. Wang: 所以,我们的做法是,主动提案。这个地方左对齐,那个地方右对齐….并且有一套我们自己的标准(这是CMMI的常见词),然后经客户认可就行。
(11:01:41 PM) Michael: 核心思想是一样的,就是多与客户交流
(11:02:07 PM) Stephen H. Wang: 可是,CMMI的缺点也在于此。
(11:02:27 PM) Stephen H. Wang: 就是做事的是人,虽然有标准,但是遵守的程度却无从判定。
(11:02:40 PM) Stephen H. Wang: 于是,就出现了千奇百怪的现象。
(11:02:44 PM) Michael: 哈哈
(11:02:46 PM) Michael: 没错
(11:02:54 PM) Michael: 这边的客户提了一个观点
(11:03:27 PM) Michael: CMM的规矩多,但大多数都是用来破坏的;Agile的纪律少,但是要求绝对遵循的
(11:03:41 PM) Stephen H. Wang: 比如:那个截断字符串,有人认为应该写一个java函数,然后,讲显示的内容截成20个字符固定长度,结果中英文不一样长……
(11:04:11 PM) Stephen H. Wang: 而CMM中不会规定,截断字符串应该怎么截断。编码规范当中也没有写,于是就有了余地。
(11:04:26 PM) Michael: 呵呵
(11:04:48 PM) Stephen H. Wang: 然而这样的程序交到客户那里,客户说不合格。
(11:05:43 PM) Stephen H. Wang: 而Agile用的都是高手吧?
(11:05:58 PM) Stephen H. Wang: 所以,不会出现这样的问题也会出现错误的情况吧?
(11:08:13 PM) Stephen H. Wang: 我最近在写一套新的系统,准备采用Agile的方式,(可惜,还是我一个人,扮演n个角色)。
(11:09:23 PM) Michael: Agile对人的要求确实很高
(11:09:36 PM) Michael: 不仅仅是技术层面
(11:09:46 PM) Michael: 态度和人品也有相对较高的要求
(11:10:36 PM) Stephen H. Wang: 我觉得知识范畴需要的太广了。
(11:11:20 PM) Stephen H. Wang: 光页面布局就非常多的知识。
(11:11:35 PM) Stephen H. Wang: 你看过那本书没 《Don’t meke me think》
(11:11:51 PM) Michael: 看过
(11:12:01 PM) Michael: 这类的书多了
(11:12:06 PM) Michael: About Face 2.0也不错
(11:12:29 PM) Stephen H. Wang: 可是我所看过的软件,大多数都是左右结构,上下结构,或者上左右结构,左上下结构….
……

文化的风化与侵蚀

Sunday, September 20th, 2009

常常听说,一个团队的文化就是团队负责人的文化; 一个公司的文化就是公司领导人的文化。究其原因,就是因为领导人的喜好和评判标准极大的影响着团队成员的荣誉感与价值观。这些观念和标准是在长期的工作和合作工程中不断碰撞不断沉淀下来最终得到的一个利益博弈的结果,表现出来的形式就是形式各异的企业文化,或者公司文化。

企业文化具备强大的同化能力。它是超越规章制度之外的一个做事方式、价值观的基本指导。许多公司的新员工培训采取的各种各样的方式,无不是想尽快让新员工适应这个公司这个大团体,与其他成员一起,向同一个方向使力。在《额尔古纳河右岸》中,年迈老人采用眩晕、饥饿、清洗肠胃等方法来训练原本桀骜不驯的老鹰称为帮手的过程,与这种文化上的趋同手段并无本质不同。

当在一个环境中已经具备一些文化认同的人,到了另外一个环境,有哪些行为会使得原本坚信的东西觉得恍惚?哪些事情会导致原本坚定的信仰开始动摇?哪些则会干脆彻底的重建原有的行事方式?

首先是寂寞。在东西方的神话中这类的例子屡试不爽。比如西游记里面各式各样的妖怪,大多是寂寞的发疯,逐渐忘记了规矩,成精之后下凡找点乐子。甚至是魔兽世界中众神的代表,泰坦萨格拉斯,在长达数万年的孤身与恶魔斗争中的,逐渐丧失了对正义的信仰,结果导向了恶魔的一方,称为整个世界的敌人。电影《无间道》中的卧底,长时间在正义与邪恶之间游走,最终也恍惚的分不清正义与邪恶。将一个人或者一个团队扔到孤立的地步是使其受到侵蚀的最简单的方式。有些人意志坚定,能撑较长的时间,有些人意志薄弱或者干脆正处于文化成型期,此时的寂寞很有可能直接导致文化上的风化、孤立与重塑。

随之而来的是诱惑。西方的哲学体系里面,人是有原罪的——例如贪婪、背叛。当有足够多的诱惑来临的时候,诱惑带来的好处、守护带来的艰辛,使得人的原罪发挥作用,原本坚信的东西开始逐渐动摇。

在实际的工作中,这些首先能看到的好处就是荣耀的来源。例如,在公司里面,人人崇尚敏捷,尊重事实,注重实效。做到这些能够得到同事、领导的赞赏。而当进行长期咨询工作的时候,发现客户对面面俱到的计划、华丽的图表等表面的东西更加赞赏。长期下去,工作的中心出现偏移,获得认可与赞赏的诱惑使得行事方式发生变化,长期下去,当这些行事方式成为思维习惯,带来的文化的变迁使得返回到原来的工作岗位时觉得陌生。

与荣耀相对的是惩罚。我们都是在正确与错误的事情中不断获得反馈和成长。一旦得到某些惩罚,很有可能对心灵造成很长时间的创伤,并且在长时间内处于敏感戒备状态,无论是新的环境还是旧的环境,都处于不信任状态。例如,派一个来公司不久的人,接受了公司文化培训,去处理客户现场问题,结果被客户大骂一顿。这位新员工可能在很长时间内萎靡不振,并且对公司和客户处于非常不信任的心理状态。

趋同心理则是最后一个效果最缓慢的因素,它的表现最快但是影响最慢。每当我们到一个新环境我们总想表现的跟当地的人一样,以获得最大程度的认同——起码从外表上——那些妖精都知道变成人形呢——如果客户西装领带,我们也不好短袖T恤;如果客户习惯在每个周五举办酒会,我们也乐于参与,等等。这些都是外观上的,但长时间的趋同很容易让人从外观上和内心上逐渐妥协并转换——就像中药,虽然见效慢,但终究是见效的,而且有可能是最能根治的。

< 请谨慎理解这篇文章——我没有在这片文章中给出任何防御性或者建设性的建议,甚至你都有可能无法看出我的立场。文化的变迁很大程度上是主观的,根据原因不同,我所经历过的文化沙漠的形成大多数组织领导在既得利益与文化建设之间的平衡不足造成。>

侬今葬花人笑痴,他年葬侬知是谁

Saturday, April 18th, 2009

不清楚要为什么取这个标题,事实上我要说的只是关于一个名叫魔兽世界的游戏,在九城运营近4年之后,丢掉了代理权,被网易夺走的商业故事。

新闻链接:九城与暴雪谈判破裂 网易拿下魔兽世界代理

1. 变,与不变

小的时候我总在看,好像好多东西都是长久不变的。每天要上的学,要见的老师,要走的路;每学期要放的假,每个季度要干的农活,每年要变冷的冬天,要发大水的夏天。从05年公测开始的时候就开始玩的魔兽世界,在我看来从开始就天经地义。不只是我,还有几百万拥趸的玩家。我们习惯了在游戏中交互,习惯了在半夜喊着OOXX强力队一边鄙视着一边M过去,习惯了跟朋友一起大呼小叫,习惯了25人乃至40人开荒灭到装备红,当然,也习惯了在服务器卡,红延迟,宕机的时候大骂着九城,的机器,的客服,的老板。这一切似乎不会变。

从合约的解除几个月后,这一切都变。未来是不是变得更好我不知道,NGA上大多数的玩家居然更倾向于不要换代理。因为担心几十万分钟的点卡,因为这是第一个游戏,因为这个游戏带来了太多的换了。

我在想,我们抱怨只是因为,我们习惯了抱怨吧,这么大的用户基数,出错的哪怕是万分之一,虽然宏观数量不大,但摊到自己头上都不好受。我自己就遇到过一天不能登录的情况,然而事后证明不是服务器的问题,是某省网络切割的问题。我不在网吧玩,不用简单密码,不跟别人共享帐号,号也没丢过,也没有麻烦过GM。平心而论,九城代理的魔兽给我带来的更多的是欢乐而不是痛苦。

2. 真的是香饽饽?

在4年的代理时间里,魔兽世界给九城带来了无比的财富:上市,大量的现金储备,几百人的研发团队,丰富的运营经验。“离开了魔兽世界的九城,是没有魔兽世界的九城”,这是一种姿态。不得不说商业是残酷的。魔兽世界占据九城90%以上的收入来源,这使得他谈判完全没有筹码。魔兽的成功又进一步刺激暴雪的胃口,下一轮谈判的筹码只会越来越高。魔兽真的会给网易带来更多的收入?我完全不这么想。魔兽世界对我而言早已没什么吸引力,游戏体制的僵化,游戏创意的枯竭,换不换代理商我都不会继续玩了。这款游戏已经进入了老年期。就像一根甘蔗,九城已经咀嚼了精华的部分的60%,剩下的头和根的一点点:要么有水分却没甜头,要么有甜头却很难啃。

3. 闲聊扯淡

这世界已经扁平。看看NGA或者游侠网,你会感叹玩家的探索能力和创造能力:汉化的,做音乐的,绘图的,写同人小说的。玩家的品味在这个国际化的舞台下已经提升。与此同时,只有约莫10年历史的中国游戏产业却再挣扎。GameRes上每一年的总结评估都让人沮丧。“人傻钱多”的玩家逐渐成为曾经有追求的游戏策划者要娱乐的对象,并一再挑战着玩家的智商。我玩过一些现在流行的免费游戏。我老婆看见的时候说,跟魔兽相比,他们就像玩具。玩家的品味是国际水平的;国内开发商的开发能力却差了好大的档次。因此我钦佩能够真正自主研发并且做出来的,比如剑网三。这是一个最好的时代,这是一个最糟糕的时代。很多人把游戏当作商业,特别是资本人。但在更多人眼里,游戏是艺术。真正的艺术品的产生需要你拥有崇高的信仰,以及不被俗世侵蚀的决心。

RichClient最佳实践在InfoQ发表

Saturday, March 21st, 2009

基本上就是过去两年做RichClient的总结,谈到了异步、事件管理、视图、缓存等。内容相对来说有点小高端,面向读者是至少有几年分层Web开发经验的开发者;或者正在做RichClient/RIA开发的开发者。

RichClient/RIA原则与实践(上),谈到异步和视图;

RichClient/RIA原则与实践(下),谈到事件、线程、缓存。

PS. 春节前就写完的东西,到现在才墨墨迹迹的发完,这样算来,一年也写不了几篇像样的东西。

专注,在写作室

Saturday, March 7th, 2009

从功能上说,这只是一个简单的文本编辑工具。他甚至不支持任何高级的编辑功能,例如加粗。

他甚至没有菜单、工具条、状态栏。

我为什么要做这个“在写作室”呢?

因为,每当我打开一个庞大的文本编辑工具的时候,除非我特别专心,否则很容易被分心:那些颜色,那些不同的工具条,菜单。

当又一次我的写作因为这个原因中断的时候,我决定做这个“在写作室”。它只需要完成两个功能:

自动保存。不仅仅是文字。还包括光标位置、滚动条位置。下次我继续写的时候,他能完全恢复上一次的状态。

保护注意力

现在,如果你 在写作室 ,你会发现,你只看见纯黑的背景,和白色的光标。没有任何多余的信息。开始写吧。放心,它会自动记录你写的每一个字。只需要无聊的时候晃动鼠标,你会发现这个应用的所有功能。简单到不需要帮助文件。

为什么这个名字?因为我在新加坡的公寓里,44楼有FreeWiFi的阅读室,很安静。我通常在那里写代码写到很晚。

点到这里开始使用吧>>
分享你的写作体验,豆瓣线上活动:在黑暗中写作>>

另外说一下,IE可能会有意向不到的错误。Firefox/Safari完全测试。如果你在使用Mac, 那么最好不过了。

常见问题解答

Q: 这个。。。到底是个啥东西?除了写东西还能干啥?
A: 简单的回答:除了写东西,啥也不能干。甚至,它只是一个纯文本的编写工具,不支持任何格式化、图片等。它的不同之处在于,打开就能用,极其简单的界面(默认情况下没有任何菜单、按钮)和强烈的视觉反差(黑底,大白字),让你在在想写东西的时候能够真正专注在写,而不是其他。在现在这个信息淹没人的时代,注意力是最珍贵的资源。在写作室,尝试着通过更极致的方式来保护你的注意力。

Q: 好黑啊。。好空旷啊。。好孤单啊。。。
A: 嗯,是的。它不是twitter/google doc/开心网/facebook,热闹到你干点啥别人都能看见。从某种意义上说,它是一个相当私有的空间,专注于给出更高质量的产出。为了避免过于强烈的反差,它并不是纯黑和纯白。有些人觉得很刺眼…有些人觉得很爽。也许在以后会添加更多的配色。但…空旷将会是常态。忍受寂寞是成就高质量必经之路。

Q: 为啥子要用google帐号登录呢?不会记录我的密码吧?
A:inwritingroom托管在Google Appengine平台上,所有的程序和数据都在Google的服务器群中。每个人都有google帐号,登录的过程只是告诉google,你要使用这个应用程序即可。inwritingroom不可能持有任何跟密码相关的隐私信息。当然,为了保存每个人的文章,需要将文章与google帐号关联起来。

Q: 我的文件会丢吗?需要保存吗?
A: 一般情况下,你只需要专注的写就行。inwritingroom会随时保存下来你的修改。取决于网络情况,保存可能会延迟几秒。它保存的不仅仅是你写的文章,还包含你当前编辑的位置信息,这样当你下一次进来写的时候,它会自动跳转到你上一次的编辑位置。

Q: 多文件支持吗?
A: 如果你写累了,将鼠标移动到页面的顶端,你会发现一个工具条:保存,文件列表,全屏三个按钮。点击文件列表,你会看到写新文章的按钮。

Q: 全屏。。。好像有bug
A: 嗯,是的。有时候全屏模式和普通模式之间切换的时候内容不能同步。请少用这个功能,我正在考虑采用其他技术实现真正的全屏。

Q: 嗯,再问一次,你为啥要做这个,未来计划?
A: 出差的时候,忙起来很累,闲起来很无聊。想写点什么的时候太容易分心。花了大概4个晚上的时间写了这个(Python忘的差不多了,不然能更快些)。这些文字就是在写作室写的。除了自己用之外,我也很想看到有类似经历的用户。未来打算的功能,主要是两方面吧,配色的多样化,页面功能继续精简。现在功能还是太多了。