第7部分(第2/4 页)

—Windows的应用编程接口。我们这边必须先行开始，而且必须先完成50％的工作，然而我们只动用了大约1/4的员工来做这个项目。 我所在的团队被吹捧得像顶梁柱一样重要。我们像某种特种部队，迅速赶来然后把原始设备制造商遗留的个别问题一一解决。不过有趣的是我的团队对每个人都所知甚少。我们没有工具，不得不和机器作斗争，并且我们是最后一个发现问题的。原始设备制造商使用崭新的但还不知好坏的芯片，所以当我们的代码无法运行时，也无法判断出到底是芯片的问题还是软件的毛病。这些事虽小，但做起来耗费的时间却是惊人的。 我们的使命之所以对于OS/2的成功如此重要，是因为我们既得与原始设备制造商沟通，又必须能够随时做好任何职位，还得选择合适的设备。而且随着大量的时间花费在使不同的项目小组之间能够互动上，也许我们还要做更多的事情。那里有巨量的、乏味的工作需要做，并且我们无法指望雇用别人来解决问题（你得在每个新人身上花时间培训），要能够区分现实和经理所创造的超现实气氛。 当十字路口抉择的光彩渐渐消失，当第20次听到要跟上项目进度表的安排，你终于明白了所谓的“进度表”，所谓的“最终期限”，所谓的项目纯粹是胡说八道。 ◆ 我在微软的工作是不同寻常的：我参与的90％的项目最终都被取消了，这使我在开发一个注定失败的项目方面成为一个专家。你能够在接触这些项目不久，就觉察到这些项目注定会失败，尤其是像“护身符（Talisman）”这样的项目，看起来就好像是找来一批人专门展示失败的。我认为这就像一个贪婪之人意识到自己将要死亡，抢着展示自己的极乐之地。 这些失败的项目包括OS/2、LANMan、Winlogin、Microsoft　At　Work（后来成为了Windows　CE的原型）、Talisman、Rifff、MSN以及一个尚无名字且闻所未闻的项目，我把这些项目叫做“护身符私生子的回归”。 显然，做失败的项目所带来的后果有3个方面：加薪少，股票期权少，并且更难于跳槽到更好的工作。失败有如一个从山上滚下的巨大的粪球，每个团队成员都被卷入其中而不管他个人的表现是何等的出色。更糟糕的，正如我对我的上司所说的，是管理层常常责备团队造成了这3个后果，而不是将其归咎于项目本身就是失败的，所以我们只能抱着粪球说：“尽管干得很好，但是高层不喜欢这个项目，所以我们就得吞掉这个粪球。” 在解析为何撤消MSN　产品时，我确信我的20人团队都很清楚这个事实。我为我的工作和团队深深感到自豪，在我们部门受到不公正待遇时，我对他们每个人的竭尽全力表示了感谢。我给部门的每个负责人发电子邮件，并发给所有其他人，说了很多感激之词。这封电子邮件很好地抑制了因为项目失败而造成的士气上的挫伤，并且为我赢得了尊敬。 要带着他们应受到的尊敬来对待你的团队并且对他们坦诚相见，这是你作为一个主管最起码要做的。因为他们放弃了周末时间，并且对家庭也无暇顾及—他们甚至常常抱怨失去了自己的梦想和期盼。对我来说，这总是我的项目开发手册中的第一章。 可以毫不犹豫地说，从一个软件开发工程师转型成为一个项目管理者的那段时间，是我在微软最美好的时光。原因有二：首先是你必须对摆在面前的困难有明确的认识，其次是你必须向别人指明目标。这真是令人难以置信：授权别人去工作；构思总体蓝图；并且具备了确认的能力，确保每个人（自己曾经也是其中的一个）都完全被推动去高效地完成这个工作。但事情不止于此，你还要很好地管理你的副手和你下属的各小组负责人，使得他们始终保持清醒，这是预防事情严重失控的最好办法。 我在项目管理上游刃有余，事情进展很快并且我很快就获得了提升。在1年半的时间里，我负责了6个项目并且被提拔到主管级别。 这种在艰难的日子中深陷困苦的经历、失败的项目、反省一个失败的项目的能力，以及我在各种情况下都能保持镇静的习惯，都对我后来产生了深远的影响。从过去吸收经验且对新的项目产生积极作用，并且相信你会赢得你的团队的尊敬，这都是我从微软得到的最宝贵的财富。 我的最大收获，便是永远不要羞于提出问题，而要尽可能多问。我对我参加的项目提出疑问，我对他们的工作安排提出疑问，我把提出问题视为增加透明度的一个有效手段，我思考是什么使我快乐，并且思考我的职业目标是什么。提问会使道路变得更清楚，使选择变得更容易，使理解变得更明晰。它使我在技术领