微软研发——制胜策略（史蒂夫·马魁尔）.pdf

致 谢 有太多太多微软出版社 （Microsoft Press）的同仁们，虽然我不知道每 一位的名字，但他们贡献的心力让许多信息从稿件变成了书本，让读者们分 享，实在功不可没。首先谢谢 Mike Halvorson（他是这本书的主要支持者） 和 ErinO’Connor（她是本书的手稿编辑，和我一起工作了将近一年，合作 非常愉快，这本书也等于是她的）；Jeff Carey对本书内容的热烈反应使我 受到鼓舞；Deboran Long一流的文字功力让我省掉无数的时间，还有其他担 任审校和编辑的同仁，Alice Smith、Therese McRae、Pat Forgette，让我 可以心无旁骛地写作；负责排版的Peggy Herman不厌其烦地一再尝试不同版 面，务求最佳效果；Kim Eggleston调整她为 《零错误程序》所做的漂亮设 计以求切合本书的旨趣；还有 Judith Blocn、Wallis Bolz、Barb Runyan、 Jeannie McGivem、Sandi Lage、Shawn Peck、John Sugg、Geri Younggre、 DeamHomes等多位微软出版社的同仁，多亏了你们辛苦的工作。 我想在此特别感谢我的两位良师Anthony Robbins和 MichaelE.Gerbe， 他们指导我如何带领团队，对我影响很大。Anthony Robbins常主持训练高 级主管有效推动业务的研讨会 （也许他的个人成就训练班更让人耳熟能详， 那也是很棒的课程），对Anthony熟悉的读者应该可以在本书中看到他的影 响力；Michael E.Gerber发表过 “为美国企业带回梦想”的演讲，也写过《E 的传说：企业失控与拯救之道》一书，虽然似乎与软件开发没有一点关连， 但是Gerber有不少见解完全改变了我对软件项目本身、以及如何执行软件项 目的看法。 我非常幸运，能和这么多优秀的同仁一起工作，并完成这本书。他们慷 慨地将经验和见解让我分享，他们大都曾担任过多年的程序设计师或项目经 理，完成过许多策略性项目。他们是本书的审阅委员，以保证本书的建议都 能切中时弊，是正确的解决问题之道。他们是 Paul W.Davis、Melissa Glerum、Eric Schlegal、Alex Tilles；在这里我还要特别感谢Dave Moors， 他以多年担任程序设计师、项目经理、开发部总监，以及最近的总裁经验， 为本书润饰。同时，还要感谢 Ian Cargill在本书撰写初期所提供的宝贵意 见。 史蒂夫·马魁尔 作者序 这本书是发生在微软的真实故事，也许您读过之后会觉得微软真是糟。 至少这是我在写本书时的疑虑之一。我曾经考虑要不要把一些地方轻描 淡写带过，或是干脆跳过不写，但是最后我决定除了人名都换掉以外，一律 老老实实地保留所有事件的原貌，好让这些故事对读者更加实用。除此之外， 我相信读者不会因为本书就看扁了微软，微软既能够在产业中独领风骚，当 然不可能都是笨蛋在当家。 本书大部分的事例，都是我在微软负责为遇到麻烦的团队实施在职训练 时亲身经历过的。所谓 “问题团队”，就是进度严重落后、程序的品质无法 达到公司要求的水准，或是程序设计师一天到晚拼命工作而成绩却极为有限 的团队。从与这些问题团队的相处，我很明显地感觉到，他们都在犯同样的 错误，而且一再重蹈覆辙，不仅如此，我还发现连那些做得很成功的团队也 犯着同样的毛病，只不过发生得比较少、或是及时弥补过来罢了。 每一次研究团队的问题，我总是发现项目经理几乎不去思考项目本身， 而只管写程序。项目经理不去注意控制进程，不去预防可能发生的问题，不 去保护组员免受杂事干扰，不去把项目目标进一步详细划分，也不去拟定创 新或积极的计划。总之，项目经理应该去思考，但却把时间花在做事上了。 其实说起来也不是项目经理的错，他们不是被训练来当主管的。他们原 本是程序设计师，某天忽然不知怎么的变成了主管，他们知道如何把程序写 得呱呱叫，但不知道如何带领团队，只好继续做他们最专长的事情——写程 序，然后让项目自生自灭。 很不幸的是，大部分的程序设计师根本不认为自己需要知道如何推动项 目： “我又不是项目经理，何必考虑这些？”他们认为真的当上了项目经理