微软研发致胜策略读书笔记

1、微软研发致胜策略读书笔记身为一个软件开发部门的主管，你的职责是什么？单单完成项目是不足够的，如果你的目标是这样，那么你会做错 很多事。我认为准确的表述应该是: 带领程序员按进度完成项目，并且让他们能通过项目中在技 术，工资，团队归属感等方面成长。本文作者用轻松愉快的笔调讨论了作为一个主管，应该怎样 管理项目，并且列出了他在微软的一些做法。或者他可能没 意识到，他提出的解决方法，其实都是针对 个问题： 你究竟想要做什么?小到编程，买菜，与人交流，大到管理，人生，无非都是弄 清楚你自己究竟想要做什么。弄清楚之后，通常你就能找到 相应的处理方法。读完之后我没有单纯的记下要点，我把作者的观点归纳之 后

2、，重写成如下形式。希望能给喜欢读书的同行一点思考的 火花。当然了，最好建议你还是去读读这本书， 然后写下你自己的见解。当你，我，他都有了自己的理论， 或者中国软件业的春天就不远了。项目的讨论精确的项目目作为主管，值得你好好花时间去设定你的项目目标。目标 定下来之后，你就会清楚哪些工作该做，那些工作不该做。例如你是基础函数库的主管，如果你确定了 “ 只有所 有模块都使用的函数才是要开发的函数 ” 的原则，那 么某个模块要求你开发的工作，就不是你的目标了。每天花 1015 分钟想想目标，并且想些解决的小窍门。例如作者某天是这样想的：Diego 负责该函数的开

3、发，有可能需要一本技术手册。于是他马上去买了一本。就这样，明确项目目标，提前把影响程序员专心工作的障碍（包括不必要的会议，email，电话等）去除。主管才能把项目做好。开会与报告有些会是不得不开的。例如：1 当某个人必须把信息传送给很多人时。2 信息需要双向或多向交流，人们必须立即反问才能了解 信息。3 必须亲眼目睹或亲身经历，信息才能传达给接受者，如 产品示例。4 有些事情须通过讨论才能进行。但开会中断许多人的工作。所以在开会之前，你必须动脑筋想想，你开会的目的是什么，有没有更好的方法达到同样 目的。会议时间应选择工作效率比较低的时段，并且不会打扰程 序员顺序连续工作时间的时段为宜，例如早上

4、刚开始上班，午刚开始上班，快下班时。特别的，如果可以选择的话， 在星期一早上或星期五下午开会。这是最没效率的两个时 段。如果会议确实召开了。 一定要达到目的。 即使是假设性的， 有条件的结论。例如，如果其他小组的工作依赖于 Diego 的 工作成果， 那么你可以问 Diego ：“ 两个星期能完成你 的工作吧？ ” 如果他同意了，那么以此假定作为基础 和其他小组讨论工作，例如进度安排等。作为主管，避免在会后让与会者递交一份长长的发言报 告。这是双重浪费时间。如果你觉得他们的发言值得记，那 么你自己记下来。再次强调，写无用的报告浪费开发人员时 间。如果你确

5、实要报告，最好单独进行，并且尽量短。进度微软曾有过惨痛的教训，以进度作为项目完成的指导。任 何进度落后都是不允许的， bug 的不断增加不算严重问题， 但只要工作没在排定的时间内完成，就是罪孽深重的。进度 取代了项目目标和软件质量，变成了首要任务，每一个人都 在疯狂的赶进度。以 Mac Excel 项目为例，每周的进度检讨加上报告，是微 软用来控制进度的主要手段。除了这些，开发人员害得每周 和测试文件人员共同检讨原因和落后状况。可想而知，只要 进度落后，文件小组和测试人员只好暂时没事做，所有目光 和谈话，都集中在你的程序进度落后上了。每周经理们会用更新的项目进度报告来更新项目总进度表， 然后分

6、发给组员。于是你一眼就会看到本周落后了多少，整 个项目因此落后了多少。心痛之余，你翻到后 页看看还有多少未完成的工作，上周是几百项，现在还是几 百项，拼命做事，结果似乎毫无进展。就像一个笑话：如果 你每次咬一小口，多久才能啃完一只大象？这 张进度表就是一只大象，我们一辈子也无法吃完。实在是太过分强调进度了。以至于无论我们做了多少了不 起的事情，都没有半点成就感。我们被落后的威胁淹没了， 再怎么努力， 也看不到成功的彼岸。 这不是工作本身的问题， 实在是那种绝望无力的感觉所致。更荒唐的是，进度表是基于如下原则设定的：1 为期两年的项目所有该做的事情都在进度表中，没有任 何遗漏。2 每人每周实际工

7、作时间 40 小时。3 对于每件工作的时间估计完全准确。4 所有程序第一次出来就是完美状态，没有bug ，不需修改。这真是天方夜谈。教训：不要利用进程表来驱使项目前进，这实在太伤害小 组士气了。在这里，作者提出了他自己的观点：不应该 deadline 快到了 才开始紧张，平时就应该保持适当的紧张状态。多想想如何 聪明的工作，不要把时间浪费在没有 价值的工作上，不要浪费别人的时间，用积极的态度推动项 目。总之，不应该在dealine快到来时，才动脑筋去想解决办 法。平时就应该养成良好的工作习 惯。如果你觉得时间紧迫，那么你开会总结一定不会说： “ 这个问题，我们留待以后再讨论

8、 ……” 你和组员一定无法容忍事情的拖 拉，要不删除这项工作，要不立刻把它完成。进度的急迫多数是由于不正确的考虑，不正确的工作方式所 导致。如果你定的日程表让组员产生了落后恐惧症，为了赶期限而牺牲了产品质量，那么该检讨的是这 个进度表而不是组员。如果你定出的日程表是个无法完成的 目标，那只不过是打击团队士气。 一旦组员发觉已深陷绝境， 那你就永远无法让他们表现出最佳状态。他 们就会另某高就，找个是人做的工作。项目控制在完成对进度的讨论之后，作者提出了他对项目控制的见 解：1 进度是基于某些因素上软件的大致完成日期。不要迷信它。不要草率

9、定出不可能的期限，导致组员为了赶进度而不 顾一切。2 把长期的大项目，分成几个完整而独立的小项目，各小 项目必须有一个主题。这样既能营造适当的紧迫气氛，也让 大家有完成目标的成就感。3 制定测试和质量监控规范，这些规范可能涉及产品的速 度，健壮性，安全性等，你必须考虑并定出标准。通过质量 检测规范的小项目，才算真正完成。警惕，不要把小项目写 成 hello world 之类毫无意义的测试程序。 该有的功能绝对要 有，该达到的要求绝对要达到。4 产品的质量远比期限要重要。发现 bug 立刻清除。你不会知道一个 bug 到底有多严重，存在 bug 的软件产品，会让 在，你会不知道项目究竟什么时候能

10、完成。加班项目的完成比例被严重高估。更坏的情况下，由于bug 的存如果进度落后，那表示有个地方出错了。在没有找到问题 并解决之前，不要粗暴的要求组员加班。这种加班是没有用 的。如果你以进度落后为由，强迫组员每天工作12 小时。那么他们很可能把私人活动也安排到工作时间里，并且在可能 轻松的时刻尽可能偷懒。因为他知道每天必定工作 12 小时， 不妨把私人活动如看新闻等也在上班时完成。加班，通常是 浪费时间的面具。事实上，拼命工作并不是成功的关键，成功的关键是有 个明确的目标，具体而切合实际的计划，以及每天不断的向 这个目标迈进。（微软不强制员工的上班时间， 所以作者如此讨论。 但事实 上，在中国，

11、加班一样是最没有效率的控制项目的方式。即 使你强迫员工每天 12 小时坐在电脑前，他也很有可能面对 屏幕发楞。疲倦的头脑是不可能产生任何创造性活动的。加班的目的只是为了赶上进度而已。为了改善我们的工 作，还有许多手段可以达到这个目的：1 明确工作目标：程序员是不是被太多的杂务打乱了开发 工作？例如不必要的 email ，不必要的电话、讨论、会议。作为主管，你有责任把这些障碍找到并一一清除，还程序员个专心开发的环境。中午，快2 合理安排工作：例如，看 email 应该在早上，班时看，不要在开发过程中让它打乱了你的思路。早上是 最有效率的时候，让头脑完成有创意的工作，而其他时间用 来编码等等。再一

12、次强调，你必须牢记自己的目标：按进度完成项目并让 组员成长。只要你开动脑筋，你一定能想到更好的代替加班 的方法来达到目的。加班并不是完成这个目标 的唯一手段，事实上它是最差的，能不能赶上进度且不说，肯定妨碍了组员的成长。它并不是你的救命稻草，如果你依 靠加班来完成你的管理工作，或者你该考虑走 人了。 项目检讨对项目进行检讨总结的意义不言而喻。但要避免大而无当 的总结。检讨应该能做到：1 指出项目的问题所在2 根据问题，考虑防范措施和实际的解决办法（虽然有可 能只是建议）3 总结经验心得。将来如何利用。以下是一个例子，给出了两个项目检讨的对比：第一个：问题：某软件包的 Beta 版使用者觉得他们

13、的测试报告好像 没人注意。因为 bug 在每一版都出现，这主要是因为我们没 有建立一套系统的方法去追踪外部的 Beta 测试报告。所以我 们将来应更小心的追踪外部的 Beta 测试报告， 并加强后续处 理。第二个：由于对 β 测试报告的疏忽。不仅影响了项目，也影响 了关联的其他项目。 经理已经同意重新考虑三个追踪 Bug 的 系统，我们将在三者中择一使用， 以便追踪项目的测试报告， 我们还要把 bug 和清除 bug 的行动记录下来。这个报告是很有效的。他提出了清楚的解决方案，详细的执行步骤， 由谁负责， 什么时候该完成， 应用在哪几个项目。还建议了 bug 的查找方式。值得

14、一提的是，不要等项目结束了才想什么是值得一写 的。应该养成平时经常记录的好习惯，积累是随时的。管理 艺术评估方式年终评估是最没用的评估。对员工的评估应该随时的进 行。员工有什么不足应该立即指出，并为他尽量想个改善的 方法，让他能立刻成长。不要单纯在年终评估记录员工的不 足。沟通技巧有些员工看起来很依赖主管解决问题，其实不过是他们的 沟通方式有问题。碰到这种员工，你可以要求他们：1 清晰表达他们待解决问题是什么2 有什么解决方法，包括他赞同的和否决的3 陈述赞同和否决的理由。这样下来，通过和员工多次沟通，或者你会发现你的员工 并不笨，他们只是不懂得沟通技巧而已。句话，你和员工的一起成长是你的目标

15、之一，所以不要 采用生硬粗暴的方式去对待员工。动脑筋想些更好的法子。人员培养态度正确你必须让你的组员态度正确。1 发现 bug 立刻清除。越晚抓 bug 越难抓，并且能让程序 员总结经验。还有，如果 bug 太多，那么程序员的功力高下 立现。2 除非我已经完全测试过了，没有 bug 了，否则程序不算 完工。3 以用户的观点来看待软件，尽善尽美。4 改正 “ 这不可能 ” 的态度。 最好的方法是明 确目标，然后找出正确的解决方案。5 鼓励提问。他可能不知道答案，但他有权提出问题。6 未完成的功能，绝对不要给用户。7 善于利用别人的成果。写好的测试过的代码，

16、只要符合 自己要求，就应该用。重复就是浪费。8 注意提高自己代码的复用性。提高技术如果某个程序员在你的项目已经毫无进步，并且他渴望提 高，那么让他到其他项目去吧，让其他接他的班。短期来看 你损失了一个得力干将，长期来看，你为公司培养了两个人 才。新兵训练：先让新人学会一些通用性技术，这样他到其他项 目组也能用。然后才让他们学会项目专有的技能。训练他们 多思考。在设计阶段，他们要想得很缜密，确 定这样的设计没有纰漏，写程序时要动脑筋，要懂得怎么思考怎么测试这个程序才确保没有bug;遇到bug时，不要乱猜，要思考如何有系统的搜寻 bug 藏身 之处，要学会判断是否有相关 bug 没有现身；不但要学习如 何对