[转载]成功的微软和失败的微软_盛冬平（5698）

http://blog.sina.com.cn/u/1159375663

首页博文目录关于我

个人资料

微博

加好友发纸条

写留言加关注

博客等级：
博客积分：

博客访问：
关注人气：
获赠金笔：0支
赠出金笔：0支
荣誉徽章：

正文字体大小：大中小

[转载]成功的微软和失败的微软

(2006-07-05 19:54:42)

成功的微软和失败的微软

好朋友Geoffrey写了一篇关于M$的blog，中间有两个相关的链接，分别是Joel Spolsky的My first BillG Review和The world as best as I remember it: Broken Windows Theory。

自从昨天看了这两篇文章，我的脑子里一直无法停止思考的一个问题是：一个软件公司，或者说是一个高科技公司，会因为什么而成功，又因为什么而失败。

在Joel的文章中，他提到36岁的Bill Gates（1992年）来review他关于excel macro的功能设计。Joel说，当时的微软有一个传统是，每一个重要的功能Bill Gates都会参加review.

In those days we used to have these things called BillG reviews. Basically every major important feature got reviewed by Bill Gates.

为了准备这个review, Joel提前24小时把一个500页的文档交给了Bill Gates办公室，而24小时后，当Bill Gates来开会时，Joel惊奇的发现，Bill居然自己带着那500页的文档来开会，而且第一页上居然做了笔记。Joel为此感到十分兴奋。在review的过程中，Joel更加惊奇的发现，Bill Gates居然在每一页上都作了笔记。

... and THERE WERE NOTES IN ALL THE MARGINS. ON EVERY PAGE OF THE SPEC. HE HAD READ THE WHOLE GODDAMNED THING AND WRITTEN NOTES IN THE MARGINS.

He Read The Whole Thing! [OMG SQUEEE!]

在review的过程中，Bill Gates问了很多细节的问题，包括一个关键的问题即如何通过VB实现Excel中众多的date/time function. Bill Gates走后，有人说道：

"Can you imagine if Jim Manzi had been in that meeting?" someone asked. "'What's a date function?' Manzi would have asked."

Jim Manzi was the MBA-type running Lotus into the ground.

It was a good point. Bill Gates was amazingly technical. He understood Variants, and COM objects, and IDispatch and why Automation is different than vtables and why this might lead to dual interfaces. He worried about date functions. He didn't meddle in software if he trusted the people who were working on it, but you couldn't bullshit him for a minute because he was a programmer. A real, actual, programmer.

Watching non-programmers trying to run software companies is like watching someone who doesn't know how to surf trying to surf.

作为一名运营了6年软件公司的人，我经常和其他的创业者探讨如何让企业变得更加成功。在这个过程中，我们也时而会抱怨中国的创业环境，人才环境等等。但是Joel的这篇文章让我不得不思考，不得不面对的一个问题是：作为管理者，我们距离Bill Gates这样的人有多么巨大的差距！

92年的微软已经是非常成功的公司了，那时的Bill Gates已经当上世界首富了吧。在那样的一个时候，Bill Gates仍然能做到参加每个重要功能的review会议，并且能够在24小时之内认真看完一个500页的文档，做了笔记来参加会议！不要说CEO，我认识的大多数对项目直接负责的项目经理都无法做到这一点！这里面既有态度问题，也有能力问题。

说道这里，有一个必须要谈到的话题就是，CEO如何在细节和大局之间做出合适的掌控。在高科技行业中，细节和战略有时是很难区分的。Google当年战胜Inktomi赢得Yahoo这个大客户，其page rank算法起了很重要的作用。如果不是技术上的这个突破，以Inktomi当年的实力，Google是无法走入大众的视野的。Apple的iPod获得巨大成功，与Steve Jobs对产品设计中的每个细节都与团队每天讨论到很晚是分不开的。

“专注细节”听起来不错，但也有很多反例，在前面提到的Broken windows一文中，作者（Windows Vista的一个项目经理）很反感的说，微软繁琐的review流程是一种弊大于利的micromanagement，这种流程使得微软的程序员每年只能写出1000行代码，而行业平均值是6000行。

任何一个项目，从产品的研发到最后市场的推广和销售，都是由无数个细节组成的。具体到某一个细节，究竟是CEO来负责还是一个程序员或市场人员来负责，没有固定的模式，但是有一个原则必须遵从——必须由对这个细节真正懂行的人来负责。而这个“懂行”又分为内外两个层面，即内部实现和外部客户。小到一个程序的模块，其内部实现可能一个程序员最懂，但其外部客户——在这个情况下也就是使用该模块的系统——可能是项目经理或是CTO最懂。如果内外两个层面的懂行人是两个人的话，那么在沟通中必然会有损耗，导致最后的结果不那么完美。项目的总负责人一般来说是对外部客户最为理解的人，如果他对内部实现一点都不了解，那么所有成败都只能依赖于该实现人员的理解能力，风险自然很高。而如果该总负责人能够做到：1）正确的判断哪些是最重要的细节；并2）深入了解这些细节，并帮助或确保实现人员做出正确的实现，那么这个项目的成功率就高了很多。Excel, Google web search, iPod这些产品的成功无非也就是这个道理。当然，这种由CEO直接参与项目细节的前提是，CEO在与实施人员沟通时要尽可能的成为内行。假设Bill Gates在review的时候问得问题不专业，反而去问"what is a date function"这样的问题，不仅不会起到任何正面的帮助，反而会从文化上毁掉程序员对于公司的信任，而review的流程也迟早会变成大家集体心安理得的浪费时间的一种形式。（像这个笑话：meetings, the practical alternative to work）

由内行来作决定，听起来容易，但在实际的公司操作中，我们经常会碰到市场人员对产品设计的干涉，财务人员对费用投入的干涉，人事经理对人员奖惩的干涉。这些“干涉”在一个成熟的公司中是必不可少的监督力量，但如果体制、流程设计的不合理，实质上是把对某件事的决策权交给了错误的人（监督人员），结果也就可想而知了。在任何一个层面上，如果最终是外行指导内行，就会导致项目在该层面上出问题。如果这个层面是CEO在公司的最重要产品上出的，那么公司的垮掉也就指日而待了。

文章引用自：http://yebinblog.spaces.msn.com/Blog/cns!726E15D291EFF827!244.entry

阅读┊ 收藏 ┊ 喜欢 ▼ ┊打印┊举报/Report

前一篇：[转载]10件网站推广利器

后一篇：[转载]互联网的草根用户体验和词汇

新浪BLOG意见反馈留言板　欢迎批评指正