 | | |
| | |
|
Spaces home  Wesley's blogPhotosProfileFriendsMore |  Tools   |
|
Wesley's blogLa vie est belle!
July 01 GoKart Racer小结昨天去Burlingame赛车了 [1] 戴上头罩（形象可参考CS的匪的造型）、再戴上头盔后，感觉视野变小了很多，再把风挡拉下来后，世界就变得不真实了。有多不真实呢，跟NFS之类的赛车游戏有一拼... [2] 戴头盔的时候，发现貌似和戴眼镜是个race condition，于是差点就deadlock在那里... [3] 赛车的时候，平时在马路上一直想做而不敢做的动作，比如甩尾之类的，做了个畅，到了逢弯必甩的地步。然后赛完后跟高手讨教经验时得知，甩尾是最低效的转弯方式之一 [4] 怪不得我的比赛成绩惨不忍睹呢 [5] 那么，高手们都是怎么转弯的呢。这个是八仙过海各显神通.. [6] 赛车45分钟（15分钟qualify + 30分钟supertrack race）的效果大致相当于做500个俯卧撑。之后做一些很需要臂力的事情（比如吃晚饭的时候要用筷子）的时候，酸胀的胳膊时刻在提醒我，哥们，悠着点，一次菜少夹点，还有，那个很重的带壳的啥啥啥菜就别夹了... 于是我想起了野狼说的话，在需要能量的时候，胳膊里面的一个麦芽糖会分解成2个乳酸... [7] 然后，我就想起来好像报名参加公司的乒乓球赛了，貌似小组赛会遇到某号称曾经是当年浙江省冠军的同学。我忽然有一个很坏很坏的想法： [8] 吃完饭坐进自己车里的时候，扶着方向盘，热泪盈眶： power steering就是好啊......... 然后一路轻轻盈盈飘飘忽忽地回家了... [9] 对了，推荐Millbrae的香满楼。菜不错 :) June 27 推荐《功夫熊猫》长大之后就很少看动画片了。前阵子好多同学都推荐这部片子，我就也去看了一下。 貌似跟《The Forbidden Kingdom》是一个类型的。但比The Forbidden Kongdom要好看多了。里面有些内容貌似还蛮有启迪意义的。哦，还有，无极拈花指很强大。 看完之后我有一个古怪的想法。Mac OS X的下一版不是叫Snow Leopard吗，下下个版本会不会叫Panda呢........ （如果我没眼花的话，后来被打败的“太郎”看起来像是一只snow leopard） 推荐《黑暗森林》 是刘慈欣的科幻小说。《三体》的第2部。也是《地球往事》系列中的一部。5月下旬出版的，当时正好国内有同学要来加州，我还特地打电话叫他们帮我带。以前别人托我带书都是带美国才买得到的原版技术书（比如这本 http://wesleybao.spaces.live.com/blog/cns!B8C72620C46CF4CA!3983.entry ）。我则从来都是让他们给我带闲书  这本书如果要剧透的话，其实书名这4个字就概括了全部内容了，但如果不把这本书看一遍是不会理解书名是什么意思的（其实我看到咒语那一段就有点猜到了）。 这本书在我看过的科幻小说中可以列入最好的10部之一。具体评论懒得写了。豆瓣上有好多评论 http://www.douban.com/subject/3066477/ 。 推荐《审计风云》 （严重剧透，慎入） 看到yiyi推荐，就去看了一下。 刚开始就出现了很雷的一幕。某位很有才的奥迪特同学是这样描述的： 一排，大概有五六部很豪华的黑色车子，像国宾车队一样，浩浩荡荡地开到某大楼，下来了一群man in black的奥迪特，每人手里一只黑猪，大概十几二十个人，以大趴为首排成一个三角形向大厦内部进发。同时，大厦里面也迎出十几二十个人，以老板为首，情形请参照山口组斧头帮对拗。于是我就觉得这个片子有戏。看完第一集，果然很雷... 我就不评论了，还是copy-paste一下别人的作业吧... 对了那个不算很PP但看着很有味道的MM有点面熟，应该是《日本沉没》里的女主角。 今天在sophie的推荐下，我得知08夏季档日剧出现了一部描写奥迪特生活的巨作——审计风云！因此我迫不及待地问她考了过来，在回家的差头上就开始观看。看完第一集的印象，我还是觉得飞机趴比较有人性。做实业的应该是比较无辜的吧，他们是在做事和创造价值的，这一下就被搞破产实在是太于心不忍了。要怪就得怪银行太黑了。严格趴貌似是给银行当枪使了，借刀杀人。要是我去做奥迪特我就审银行的时候严格一点，审实业的时候放水一点。不过我也搞不懂为啥银行要把做实业的搞破产。按理说，企业破产了那么欠银行的钱不就是变成坏账了吗，莫非日本的破产制度不是这样的? Anyway，期待下一集~~ June 25 是沟通问题吗<过几天再接着写信息社会的白银时代，今天先讨论一个其他的话题>
昨天开了一个会，讨论的主题是如何促进产品部门、core tech部门、IT operation services部门之间的沟通【注：每个部门都分布于几个不同的site，有些site位于不同的时区、不同的洲】。我一听到这个话题就犯困。这种讨论过一万次都没带来什么改变的事情，还不如讨论世界和平或者保护环境或者希拉里为何要退出总统竞选的问题更有意义一些呢。于是我准备第一万零一次给出我的招牌标准答案“多进行一些cross-functional team building（also known as 公款腐败）以增进感情促进沟通”之后就趴下睡觉。
不过在睡着之前，我竖着耳朵听了一下，发现这次同学们其实是挂着communication的招牌在讨论collaboration和teamwork的问题... 于是我就又醒了... 首先，L同学和S同学倒了一下苦水： 1. L同学是负责A产品的project manager。A产品是以service的方式deploy在data center的，经常需要IT operation services部门的同学帮忙，但是她发出去的email经常隔好久才有人理睬，而且答复显然很没有营养，于是她只好escalate到对方的老板或者老板的老板，或者让自己的老板帮忙escalate。这样，要get things done就会感觉很费劲。 2. 跟L同学一向很搭调的S同学是做B产品的senior engineer，他诉苦说，他做的产品需要用到一些core tech部门提供的component，但是用最新的component有时候会遇到一些问题（可能是他的用法错误，也可能是component本身的bug，诸如此类），他写email给负责那个component的team的人询问，也经常是隔了一万年才有人理睬，而且解决办法通常都是凉拌，不解决问题。这样，如果遇到的问题会block他们的产品的下一步开发的话，这个事情还是蛮头疼的。 然后大家就开始七嘴八舌说要建立什么process或者提倡什么practice... L同学建议每个component team和service team都要有一个integration specialist来专门为产品部门提供服务，J同学说这样恐怕会增加很多headcount，估计老大不会批，要么设立这样一个role，让某些人身兼多职地扮演这个role吧。 我要说的是，这些都很有道理，都是很好的建议，但是别忘了，我们公司曾经是把R&D engineering部门和sustain engineering部门完全分开的啊，sustain部门的唯一职责就是解答同学们各种各样奇奇怪怪的问题，满足大家各种定制版本或者bug fix release的需求。我们曾经有过这样的process的，还有过非常详细的workflow。产品部门有啥问题吗? 在相应的系统里面创建和提交一个case好了，sustain team是一定会在规定的时间内答复的。这是那些专门做sustain的engineer的本职工作。
那么为什么我们公司后来要逐渐撤销sustain engineering部门（global的撤掉，各个regional的依然保留），把相应职能并入研发部门或者技术支持部门呢。也是有理由的。[1] 这样一来研发部门就比较有动力release质量比较好的产品（或者component），而不会为了赶工牺牲质量并指望sustain engineering部门帮他们擦屁股。因为如果有啥麻烦，最后是他们自己给自己擦屁股 [2] 研发部门有domain knowledge，是这个产品或者component领域的专家，解决问题会比较快，而且两个部门合并也可以省去一些转移某个产品或者component的ownership的开销 [3] 这样一来研发部门就会比较有动力build supportabilty into product/component（比如log功能要认真做，该提供的自检功能要提供，诸如此类），而build supportability into product/component是好的engineering practice。 当然这些都是摆在台面上的原因。台面下嘛，这么一折腾撤掉一个部门自然就可以把一些headcount省出来做其他事情啦，然后嘛有一些人会被promote啦也有一些人会被打压下去啦，诸如此类。 哦，请大家一定要留意“把一些headcount省出来做其他事情”这一句话。因为我觉得这才是问题的关键。 用屁股想也能想到啊，总体上要做的事情增加了，总的headcount却没变，那么除去效率提升的部分（这部分实在很有限），大概每人要做的事情也变多了吧，那么是不是有一些事情的priority只好降低一点，做起来只好敷衍一点了呢。我想，诸位同学都接受过高等教育，并且有着良好的职业素养，大家都不会缺乏沟通技巧，也不会缺乏团队合作意识。不过呢，大家也都不笨，都知道团队合作跟本职工作比起来，本职工作好像跟饭碗以及奖金更加直接挂钩一点，都知道要先完成本职工作然后如果有时间再去给其他team的同学帮忙的。锦上添花的事情大家都爱做，但如果赶着织锦都还来不及，那么“添花”往往就只好被忽略掉了。 所以，在一个大多数员工都100%时间在忙着做自己本职工作的组织里面，teamwork和collaboration的状况一定是不甚令人满意的。同学们自己想想是不是这样，不太忙的时候，有人来找你问问题或者请你帮忙，你是不是通常都会觉得很开心（啊，有人需要我耶，有人来请教我耶，这感觉真好啊...）都会很热心帮忙的。而忙得焦头烂额的时候，你是不是会恨不得在办公室门口挂上请勿打扰的牌子，把电话线拔掉，或者干脆在额头上贴个请勿打扰的标签。 果然，另一位倒苦水的同学的案例印证了我的想法。D同学是C产品的tech lead。这个产品需要用到某个component的某个改版（或者是要求那个component team提供一个bug fix release，具体细节记不清了），于是他就发email给那个team提出这个要求，于是那个component team的同学们把email给forward来forward去的拖了几个月之后某位group manager或者engineering director或者site director回复说“不好意思，这个事情我们目前没有resource做”。然后D同学就怒了，让他的老板把事情escalate给对方的老板的老板，最后就escalate到了Executive VP of Engineering那儿，然后EVP同学说没有resource么就找几个人先暂时把其他的事情放一放来做这个事情吧，然后这个事情就搞定了。 这里面是可以找出来沟通上值得斟酌的地方，比如那个escalate到EVP那儿的事情，事情是解决了，但是以后这2个team乃至这2个engineering site的关系会怎么样呢，呃，偶很professional的，所以偶以君子之心度君子之腹地认为，他们也会很professional的不会因此影响团结才对 啊扯远了，还是让我们来追溯到刚刚那个问题的一开始。当事情还没有escalate到EVP那儿的时候，为啥core tech component team或者IT operation service team的同学们要“打太极”呢？呃，因为......... 其实那个group manager被逼急了都把大实话说出来了啊，“这个事情我们目前没有resource做”，这不就是说他手下所有的engineer都忙得焦头烂额了实在没功夫来做这个计划外的事情吗。那么为什么EVP一插手这个事情就解决了呢，因为这样一来那个group manager就没有耽搁本职工作的责任了，“是老大发话说先把手上工作停下来把花锈上去再把锦织完的哦，最后如果锦没有按时织完大家可别怪我哦”。 那么，我们就很容易看到，如果不增加dedicated headcount而只是增加一个product integration specialist的role，让某些engineer兼任这个工作，其实并不能保证及时给产品部门答复，因为既然是兼任，那么具体到某一个engneer，他手头的事情还是要prioritize的，如果那时候他在忙于赶工做那个component的下一版，那么对于关于component的前一个版本的用法的疑问或者要不要出一个定制版本，他还是无法在不影响手头工作进度的前提下及时答复的。如果是增加一个甚至多个headcount专门做这个事情，并且对于这些人的考核指标就是“及时解答产品部门的问题”，那么本着you get what you measure的原则，会需要建立一个process和workflow，用一个case tracking system来管理每一个query或者request的submission -> assignment -> solution这整个lifecycle并且根据这些数据来评价这个人的performance，那么就会有一些overhead。而且除了report line不一样之外，其实又回到前面的sustain engineering和R&D分离的状况了。而且，当reuse的程度越来越深，越来越多的common feature被抽象成component，为每个component设立一个这样的headcount的overhead实在有点大。要知道，在比较大的engineering organization里面可能会有几百个这样的shared component供各个product team选用，而某些component的developer也就1个人，而且很可能是做某个产品时发现这块功能相对独立而且对其他人也有用就顺便拉出来的（我之前讨论过关于reuse的问题 http://wesleybao.spaces.live.com/Blog/cns!B8C72620C46CF4CA!2855.entry ），这样的component有owner但是没有dedicated headcount。 如果让每个component的owner都必须sign up某个query/request tracking system而且要measure他的response time，这实在不是好的做法。这样一来，肯定会有人觉得好心把component独立出来给别人用不是自找麻烦吗，那还不如不要这个component了，大家各做各的重复功能好了。但是，如果让各个用其他team的component或者service的team继续suffer from poor response time & quality的话，那么project manager们就会觉得这个external dependency很麻烦，是个很大的risk啊，本着降低risk的原则还是能不用就不用其他component吧。所以，上述这2种情况都是不利于促进reuse的，不利于engineering部门整体productivity的提升。 那么解决方案是什么呢？其实很简单，只要让大家用80%的时间做本职工作，有20%的空闲时间，那么所有问题都解决了。如果用80%的时间就能织完锦，那么剩下20%的时间，如果有人有需要的话，自然就可以用来添花了。有问题就回答其他team的人的问题，没有问题也可以看看书提升一下自己或者动动脑筋发明一些东西申请个专利什么的。这样，整个organization的teamwork、collabration水准，以及innovation的踊跃程度，以及大家工作开心和满意的程度，都会得到提升。也根本不需要花费很多功夫找人挖空心思设计什么复杂的process啊workflow啊什么的，再费心去实施performance tracking system什么的。话说回来我遇到啥问题需要找别人帮忙时还真不太喜欢去登陆那个内部的helpdesk网站然后很麻烦地submit case、update case，track progress然后最后close case时还要填一个survey来表达对对方的response的满意之情或者不满之处。有时候我一想到找人帮个忙要这么麻烦就觉得还不如自己死磕一下把事情搞定算了。这些可都是lost的teamwork和collaboration，也就是lost productivity啊。 如果问题是同一个site的同学能解决的，我喜欢跑去当面问。如果不是一个site但是同一个时区的另一个site，我会打电话。如果是地球另一头的site的同学才能解决，我还是习惯用email。这些是最自然的沟通方式。大家都是很professional的助人为乐的好孩子，无怨无仇的，只要对方没有忙到焦头烂额，通常都会很乐意向我提供帮助的。Teamwork和collaboration，本来就应该是这样很简单很自然的。 我们都知道，打球的时候，不管是篮球还是足球还是网球羽毛球乒乓球，投篮、射门、扣杀，都不要用10成力量。9分力量就差不多了，不然的话动作会变形，很容易投不进/射不进/扣出界。 我们也知道，额定载重8吨的卡车其实通常能装下10吨东西，但最好还是别超载，甚至不要装太满，8吨的卡车装个6吨货物就差不多可以开走了。 凡事留有余量总会有一些好处的。那么工作也是一样的，不要把员工的时间用得太满。 June 09 信息社会的白银时代, part 3前面part 1中提到了“信息就是金钱”，讨论了信息和金钱的类似之处。让我们再来看一下信息和金钱不一样的地方。 1.信息是独特的、不可替代的。 你入住酒店的时候，刷A银行的卡刷不出来（因为A银行的结算系统正在维护或者升级中）。你只好对前台的MM抱歉地笑笑，说，那要不刷B银行的卡吧？或者付现金可以吗？前台MM会怎么说呢，她当然会说OK。这是因为金钱是可替代的。存在A银行的10圆和存在B银行的10圆没啥差别，和一张10圆的纸币或者2张5圆的纸币也没什么差别。 那么，假设你MM的照片存在Google的Picasa相册，你的ex-GF的照片存在Yahoo的Flickr相册。有一天你忽然想用你MM的照片做桌面，结果Picasa返回一行信息说“很抱歉，系统正在维护或者升级中，你MM的照片暂时无法访问。”这时候你会转而去访问Flickr相册用ex的照片做桌面吗？呃...后果可能会很严重... 这就引出了另一个问题。当你入住酒店的时候，你不会费心思去考虑应该刷A银行的卡还是B银行的卡还是付现金。随便选择一种支付方法都是可以的。但是，当你要找MM照片的时候，你就会回忆一下，究竟是存在Picasa相册还是Flickr相册，还是Facebook相册，还是Windows Live Spaces的相册，还是家里的书房里的电脑，还是客厅里的电脑，还是笔记本，还是办公室的电脑... 还是某个移动硬盘里，还是刻录在哪张光盘里了，还是在智能手机里，还是在哪张SD卡上... 如果记不起来了，那么可能得在每台电脑上搜索一下，再在每个移动硬盘上搜索一下，再去每个在线相册搜索一下... 这还是挺麻烦的。 2.信息是可以复制的，而且复制成本很低。 你可能会说，既然信息是可以复制的，那么岂不是可以解决前面说的“独特、不可替代”的问题了吗。干嘛要把MM的照片存在Picasa，ex的照片存在Flickr呢，把MM的照片在Picasa和Flickr各存一份，ex的照片也两边各存一份，不就解决问题了吗？要看照片的时候哪里可以访问就用哪里好了。记不起来放哪儿了也不用一个一个去找，随便选一个找一次就够了，反正哪里都可以找到。 那么，同学，Picasa虽然是免费的，但只有1G空间，或许不够你把MM和ex或许还有ex-ex的照片都传上去。另外，把同一张照片分别上传到各个在线储存空间，你不觉得很麻烦吗？照片还好说，如果是会经常更新的文档呢？如果费了很大功夫把一个文档到处复制之后，文档又更新了，是不是再到处重新上传一遍呢？ 信息的复制成本确实很低。但依然是有成本的。 3.信息的拥有者不是很好确定 对于金钱，确定拥有者不是难事。除了掉在地上或者飘在空中的钱，其余的大概都是有主的，并且通常在某个特定的时刻只有一个主。但是，因为信息很容易复制，信息的所有权变就成了一个复杂的问题。就算可以弄清楚究竟哪些人（应该）拥有这个信息，如何确保其他人无法获得这个信息也是一个复杂的问题。 这可不是一个小问题。在进入信息社会之前，我们整个社会的游戏规则是按照“这个苹果如果属于你，那就不属于我”的思维模式来制定的。（或许好朋友可以分享一个苹果，但如果要细究，还是“这半个属于你不属于我，那半个属于我不属于你”。）这是我们立法和执法的依据。但信息的特征注定了这样的游戏规则不再适用。于是，在制定出新的游戏规则之前，很多人都在努力尝试让信息变得跟苹果一样不可复制，以便套用现成的游戏规则。 比如，软件复制之后就可以安装使用了，对于某些人而言，这可实在糟糕，于是人们发明了一种称作“序列号”的东西。但是，序列号本身也是信息，也可以很容易地复制啊，怎么办呢，于是人们又把序列号和不可复制的东西关联起来，比如电脑，比如软件狗（这是一种硬件装置），比如U盘。一个序列号在一台特定电脑上激活之后就不能在其他电脑上用了（甚至你的电脑如果换了主板或者其他主要的配件的话也无法继续用那个序列号了）。或者，如果没有插入那个含有密钥的U盘或者软件狗的话那个软件就无法使用，诸如此类。 不过，这些并不是什么好办法，也没有从本质上解决问题。（不信的话问一下陈冠希同学就知道了。） 所以，在新的游戏规则建立起来之前（耐心等一阵子吧，这个游戏究竟应该怎么玩，貌似那些负责制定规则的大人们还搞不太明白），对信息的所有权是一个比较复杂比较难界定也比较难强制执行的事情。 那么，以上这3点差别意味着什么？ 这意味着，管理个人现金资产一个钱包就够了（里面放一些现金，放几个银行的信用卡和借记卡）。但是，个人数字资产的管理是一个更复杂的问题。 这意味着，对于小企业而言，管理企业现金资产一个老板娘一本帐本就够了。但是，对于数字资产的管理，一个老板娘显然是不够的。（呃，我可没有鼓励各位老板向韦小宝同学学习的意思哦...） 这意味着，无论GDP怎么增长、无论各国央行如何增发纸币、增加纸币的类型，银行和个人都不需要“钱币搜索引擎”。没人会关心我那张序列号是123456789ABCDE并且上面有我涂鸦的一双小脚丫的10元纸币现在究竟躺在哪个银行的哪个保险箱的角落睡大觉，还是在谁的钱包里等着被花出去。但是对于信息，我们已经不知道离开搜索引擎怎么过日子了。 这意味着，如果你在报纸上看到银行被抢了，那么就算你在这个银行有存款你也不会太介意。毕竟，银行被抢，那是银行的事，不关你的事。只要银行没倒闭，你不用担心自己的存款。就算银行倒闭了，还有银行的保险公司呢（同学们可以Google一 | ||||||||||||||||||||||
Profile
Blog
Photos
Lists
Friends
心得如下：
（因为需要踩刹车，会损失动能.........）
我都有去买一堆橡胶轮胎撞死的念头了........ 我们这组开在第一的是个MM
可见，女人飙起车来也是很恐怖的 
在比赛前一天邀请那位前冠军同学来玩GoKart race...
