管理上的时空错乱

在微软的时候,有一件事让我印象深刻,启发我在动手建立复杂的IT系统之前,先想一想“自己要完成的目标是什么”,而不是“自己要建立的系统是什么”。这件事就是“英文润色”服务的流程。

可靠的英文润色服务

事情是这样的。微软在上海的全球技术中心同时服务微软美洲和欧洲的客户。为了保证所有工程师写出的英文的邮件不会有太多的语法和使用习惯错误,技术中心建立了“英文润色”团队,全是由英文是母语的人员组成,来帮助工程师修改发出的每一封电子邮件。任何人如果对一份英文的邮件不是很有信心的时候,发信到一个email地址(Distribution List),就可以保证在30分钟以内,得到修改的结果和避免此类错误的建议。每次回复的可能不是同一个人。

这是个不错的服务,我就经常用,对提高英文写作大有帮助。团队保证的30分钟回复的“服务质量”几年来没有有过差错。那个团队对于用户就是一个黑匣子,当一封邮件过去,必然会有一个人(且只有一个人)在指定的时间里回复。

支撑的IT系统?

我一直以为,他们应该有一个IT系统,把所有发到那个email地址里的信件放在一个队列里面,所有的老外到那里去“接”邮件,并把这个邮件的“所有人”的状态改成自己,之后完成审阅,回信,并把状态改成“完成”。。。“一定是这样子的”,我拍着胸脯说“要不然,将近十个人看同一个邮箱的信,岂不乱死了?更不要说保证每一封信都30分钟回复了”。

大家想想,如果你来设计这个系统,会怎么做呢?

神奇的规则

真实的情况出乎我的意料。其实,根本没有任何的IT系统,所有人用的是同一个email账户加上一个规则。规则是这样的:所有的人同时收到所有要阅读的信,从上班开始每5分钟为一个时间段,分配不同的人来值班。比如,9点到9点05是Tom,9点05到9点10分是Jack,依此类推。。。每个人只处理自己邮箱里落入这个5分钟的时间段的信件,其他的都忽略。接到以后,后面的25分钟里面回复前5分钟的信。25分钟之后,进入下一个自己收信的5分钟。理论上,6个人一班,每半个小时一个轮回。而5分钟里面的信件,每个人自己安排,保证在下一个5分钟到来前的25分钟内回复完毕就好了。

就这样一个简单的规则,省去了IT系统的成本,省去了沟通需求,以及维护的成本。一个简单的规则,运行到现在5年了,它就那样简单而可靠的运行着。

这种不用IT系统的方式,在参与的人员少于20个人员变动不大的情况下,是非常合适的。随着邮件量的增多和人员的增加,大不了把时间间隔由5分钟便成4分钟,或者3分钟就好了。在可以预料的将来,这种方式对于这一种特定的需求还是可行的。

这是聪明的做法。

专业的解决方案不见得是最佳方案

这样我想到之前听过的几个故事,同样讲了专业的解决方案不见得是最佳方案的道理。

一个城市建了一个容纳几万人的体育场,而周边的道路还是以前的小路,散场的时候潮水般的人流,导致周围交通瘫痪,不能迅速疏导。专业的市政规划的人员,会给出大规模拆迁,投入巨资拓宽道路的建议,而后来采取的方案居然是在每次比赛结束后,都接上一个小时的文艺表演,这样人流就会分散,缓慢的离开,道路不变,却不会堵塞。而城市里的艺术家就有了一个新的展示自己的机会,双赢,多赢。。。

同样聪明的做法是宝钢解决千年虫问题。专业作法是更换所有设备,保证它们都是两千年兼容,而实际的做法是,把所有系统的时间统一向前调了50年,然后改变一下和显示以及打印相关的系统就好了。

注:真不想提这个吓唬人的千年虫问题了,现在想起来,很多事情非常可笑。当时微软最戏剧性的一幕是,我的师傅等一行来自各种产品组的20多人在1999年12月30日,坐火车到了北京,以保证万万万分之一的机会,上海因为千年虫问题通信中断,停电,停水,在北京还有帮助亚洲其他国家应付服务器灾难的人员,而我们则守在美罗大厦里,等着太阳从爱尔兰开始一个时区一个时区的向上海扫过来。。。时刻等着那可能的“灾难“。那真是一场疯狂的全球party。

“专业”的解决问题,往往会花费比实际要高,因为专业人士的视角不够广阔,会忘记了自己所在的时间和空间,忘记了“借力”和“过犹不及”。

上亿的服务事件?

我经历过一个反面例子。2003年在建立微软全国的服务渠道的时候,我们建了个系统,记录所有客户提交的问题。这个系统的第一版建的非常的正规,所有的表都用大学课本里教的第一范式,第二范式,直到Boyce-Codd范式规划。内键外键齐全。但改动起来非常困难。我问道“这个地方为什么不能这样做?”答曰:“为了性能考虑,我做了限制。你想想,如果这张表里的记录数超过百万,千万,甚至上亿的时候。。。。”我惊讶的说:“从业务的角度考虑,这可能吗?如果真得到你说的量,说不定要付的钱都超过上海的国民生产总值了。。。”后来证明在当时的环境下,还是一个对性能没有要求,但是简单明了,随时可以更改的系统用起来顺手。软件系统应该是有生命周期的,用牛刀杀鸡,常常是把鸡假想成牛了。

管理上的时空错乱

最近管理的书很多,大多都是美国大公司的宝典。我看,可以参考,但不要全搬。美国的大企业是骆驼,个头大,掉头慢,耐俄,七天不吃不喝也熬得过去。中国的小公司,尤其是创业性公司是兔子,灵活,调头快,但一天不吃估计就没有机会活到吃下顿的那天了。所以书店里讲战略,讲“专业精神”,讲“系统思维”等等的书,是为骆驼在它所在的环境准备的,不见得会对兔子有指导作用。CMM好,但不见的在中国软件企业里有用,就是这个道理。以前走访的每个软件园,讲到微软的开发流程的时候,大家都会问一个问题:能讲讲微软还是小公司的时候是怎么做的吗?现在想来,问这些问题的企业老总都是头脑清楚的,知到什么东西可用,什么东西只能借鉴。

把管理成熟公司的做法拿来管理创业公司,这就是时间的错乱;把管理美国企业的方式拿来管理中国的企业,这就是空间的错乱。

注:晚上接待来自《互联网周刊》的记者陈琼,地点还是滨江星巴克,陈琼走到了正大广场下面新开的那一家。估计从地铁里出来以后,大家八成会以为那里就是滨江店,以后要讲清楚才好。
注二:周末开车在杭州度了周末。杭州是个让人心静下来,脚步慢下来的城市。我惊讶的发现杭州的创业家精神在某些程度胜过上海。这是个值得经常来的城市。。。

《管理上的时空错乱》上的45个想法

  1. 杭州是个相当不错的城市,我在那里待了两年多,美丽而且有生机。杭州的软件企业很多,很多杭州的老板都开始投资IT了,包括浙江的“乡村企业家”,这些“闲置”资金的大批量集中必将给杭州带来另外一个发展。这是中国民营资本的强势地带。另外一个民营资本的强势地带是四川。
    很多事情都是经历过来,就能够从细节上处理很多问题。如果没有经历过,就要好好的想想从那里开始了。这是……

  2. 我记得有一次proofread的team把某一个高官发给ARECALL的邮件也给proofread了,还reply all指出该信中所有的语法错误……那次真是捧腹。我估计是他们的outlook rule坏掉了。

  3. hehe, you are more and more a marketing guy. Hope the IT knowledge will help you achieve more and more success, especially long term

  4. 非常同意——先想一想“自己要完成的目标是什么”,而不是“自己要建立的系统是什么”——的说法,就是说在“do the things right”之前要确保“do the right things”。

    这个说法很简单,不过常常被忽略,回帖一则,当作自省!

  5. 那个英语润声的团体规则使我困惑,比如用户在这个过程中出现如下的情况:
    在9:00至9:05这个时间段收到的邮件是10封. 而在9:05至9:10这段时间里只收了2封信.
    因为很多人都是在上班的第一时间打开邮箱.开始回复邮件.
    如果是这样, 是不是他们的分工就出现了不太平均的现象?

  6. Hmmm, Jianshuo show us a good talk with the nice topic. In my daily job life, sometimes I prefer to have the beatiful solution for a certain request from the customer or the internal team.

    The world would be another one, if we can or may change the angle of the view.

  7. “软件系统应该是有生命周期的,用牛刀杀鸡,常常是把鸡假想成牛了。”这话经典。现在开发人员似乎都喜欢“过度设计”,一个简单明了的简易销售系统,他们也能用什么十几个.NET项目来做,然后把开发周期一推再推,把自己累个半死不活,结果那个什么所谓的十几层模式的软件,用起来和维护起来,一点也没感觉到从多层思想中受益多少。

  8. 前两天朋友传了一篇短文,标题是Focus on Problems vs. Focus on Solutions ,意思和你说的差不多,举了几个例子,典型的是美國太空總署NASA發現在外太空低溫無重力的狀況下太空人無法用墨水筆寫字, 於是他們花了一大筆錢研發出一種能在低溫無重力下寫出字的筆,而俄國人怎麼做呢??………………………………………..俄國人用鉛筆……

  9. 这真是篇有意思的文章。
      解决问题的角度,直向还是发散的。我感觉客齐集要走的路,很像是那个体育场。
      这种情况下,很多时候懒人能想出更方便的方法。

  10. 客齐集要解决的问题很多,我看到大家提的意见也很多,都记下了.很多的问题的解决方法,就像iceshow所说的,和那个体育场的方式是一样的.防止虚假信息要用身份验证,但再多的身份验证也不能从根本上解决问题,唯有用线下的方式,树立网络上行为的责任感;为了信息发布有效,再多的流量在网站初创的时期估计还不及一份报纸;对于功能,再多的功能也不能满足所有人的需求,唯有清晰的知道自己要服务的对象,做减法,低得住增加功能的诱惑,才能最终成功.为了长期的成功,甚至要在短期做打基础的工作,而不是开始就冲出去…等等的权衡,每天思考很多,生怕顾此失彼,同时又安慰自己和团队,有时候失彼是为了顾此…

  11. 以前记得看过一篇文章说的是专业和非专业处理问题的方法,里面说到,之所以专业不是说用多么专业和复杂的方法去解决事情,而是用最合适,最简洁的方法去完成工作。这点和wang说的有异曲同工之处。

    ps:blog下方的“欢迎用这个代码链接本贴子”能不能再加一个复制按钮呢?那就更加人性化了 :P

  12. “上亿的服务事件”这个例子agile的开发方式很适合。

    其实,按照agile的理念。一开始都可以用低技术来实现解决方案的,技术的使用随着需求的提高而提高。

  13. >那个英语润声的团体规则使我困惑,比如用户在这个过程中出现如下的情况:
    >在9:00至9:05这个时间段收到的邮件是10封. 而在9:05至9:10这段时间里只收了2封信.
    >因为很多人都是在上班的第一时间打开邮箱.开始回复邮件.
    >如果是这样, 是不是他们的分工就出现了不太平均的现象?
    >Posted by: 陋人 on August 1, 2005 01:31 PM

    一、全体员工写mail的长短不一样,速度也不一样,从完成一封mail的时间来看,第一个5分钟的mail未必就比第二个5分钟里的多。这位朋友可能在以自己的标准来看问题哈~ ^_^
    二、就算每天的邮件分布和时间关系较大,那么我们每一天开始润色工作的人不一样就是了。第一天adam处理第一个5分钟,那么第二天就是john。当然了,这样的系统也不可能让每个人的工作量绝对的一样,毕竟这不是一个“专业”的系统。^_^

  14. 8月3日网摘

    精英?孤芳自赏吧! 再次插播–我出名了 管理上的时空错乱 发扬web2.0的精神,我们该向wangjianshuo,keso,bokee学习什么 博客也相轻- –

  15. 每次看这个blog都很有启发!
    我们就是小小的几个人的团队,也经常存在着沟通问题,本来觉得有IT方便很多,但有时确实不是这样。

  16. 專業

    王建碩在管理上的時空錯亂講的幾個故事都是一個道理:專業的解決方案不見得是最佳方案,簡單的方法有時反而有更好的效果。就如前幾天講的叫外賣的故事一樣,IT方案應該是目標為本而…

  17. 很受启发。

    人都容易把自己熟悉的问题给复杂化,因为太过熟悉,总怕别人说的不是那么回事。其实有时候真的很简单。

    道理明白起来也容易,但做起来难。

  18. Good benchmark idea.

    这个思路对于专注单一命题的垂直思考时,是很好的inside out。感谢jianshuo 的分享。

  19. 网络能挣到钱吗?

    前几天,有位朋友问我通过怎样的渠道把产品卖给客户?怎样通过网络盈利?我说我真的很难在msn上面用几句话回答你。这些问题都太大了。我要么泛泛而谈,你听得舒服却没有什么真正的

  20. 英语润声,听起来不错.我写的英文需要这样的帮助.

    杭州是给好地方,杭州喜欢做生意.比上海还人会做生意.

    shirley

  21. 我不喜欢过渡设计,但是公司的同行评审流程总是会强迫一个设计开发人员做很多无用功。大家都很忙,各有各的事情,参加同行评审之前根本就没有认真看过资料。但是,有人又很喜欢在会议上表现自己,常常提出一些冠冕堂皇的意见,让一个本来很简单的问题复杂化,大家一言一语,出发点都是从系统的稳定性,性能,易用性方面来假设,让人都不要反驳。唉。。。。。。经常为了某人拍脑袋想出的一个可能会出现的问题花费双倍的时间。

  22. 建硕前辈更新一次中文网志可真不易。虽说要给外国人看中国,可好多中国人还等着看你这资深人士的中文网志呢,是不是也顺便照顾一下俺们阿,呵呵。

发表评论

电子邮件地址不会被公开。 必填项已用*标注