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

微软研发致胜策略读书笔记 身为一个软件开发部门的主管，你的职责是什么？单单 完成项目是不足够的，如果你的目标是这样，那么你会做错 很多事。我认为准确的表述应该是： 带领程序员按进度完成项目，并且让他们能通过项目中在技 术，工资，团队归属感等方面成长。 本文作者用轻松愉快的笔调讨论了作为一个主管，应该怎样 管理项目，并且列出了他在微软的一些做法。或者他可能没 意识到，他提出的解决方法，其实都是针对一 个问题：你究竟想要做什么？ 小到编程，买菜，与人交流，大到管理，人生，无非都是弄 清楚你自己究竟想要做什么。弄清楚之后，通常你就能找到 相应的处理方法。 读完之后我没有单纯的记下要点，我把作者的观点归纳之 后，重写成如下形式。希望能给喜欢读书的同行一点思考的 火花。当然了，最好建议你还是去读读这本书， 然后写下你自己的见解。当你，我，他都有了自己的理论， 或者中国软件业的春天就不远了。项目的讨论精确的项目目 标 作为主管，值得你好好花时间去设定你的项目目标。目标 定下来之后，你就会清楚哪些工作该做，那些工作不该做。 例如你是基础函数库的主管，如果你确定了 #8220;只有所 有模块都使用的函数才是要开发的函数 #8221;的原则，那 么某个模块要求你开发的工作，就不是你的目标了。 每天花10-15分钟想想目标，并且想些解决的小窍门。 例如作者某天是这样想的： Diego负责该函数的开发，有可能需要一本技术手册。 于是他马上去买了一本。 就这样，明确项目目标，提前把影响程序员专心工作的障 碍（包括不必要的会议， email,电话等）一一去除。主管才 能把项目做好。开会与报告 有些会是不得不开的。例如： 1当某个人必须把信息传送给很多人时。 2信息需要双向或多向交流，人们必须立即反问才能了解 信息。 3必须亲眼目睹或亲身经历，信息才能传达给接受者，如 产品示例。 4有些事情须通过讨论才能进行。 但开会中断许多人的工作。所以在开会之前，你必须动脑 筋想想，你开会的目的是什么，有没有更好的方法达到同样 目的。 会议时间应选择工作效率比较低的时段，并且不会打扰程 序员顺序连续工作时间的时段为宜，例如早上刚开始上班， 下午刚开始上班，快下班时。特别的，如果可以选择的话， 在星期一早上或星期五下午开会。这是最没效率的两个时 段。 如果会议确实召开了。 一定要达到目的。即使是假设性的， 有条件的结论。例如，如果其他小组的工作依赖于 Diego的 工作成果，那么你可以问Diego： #8220;两个星期能完成你 的工作吧？ #8221;如果他同意了，那么以此假定作为基础 和其他小组讨论工作，例如进度安排等。 作为主管，避免在会后让与会者递交一份长长的发言报 告。这是双重浪费时间。如果你觉得他们的发言值得记，那 么你自己记下来。再次强调，写无用的报告浪费开发人员时 间。如果你确实要报告，最好单独进行，并且尽量短。进度 微软曾有过惨痛的教训，以进度作为项目完成的指导。任 何进度落后都是不允许的， bug的不断增加不算严重问题， 但只要工作没在排定的时间内完成，就是罪孽深重的。进度 取代了项目目标和软件质量，变成了首要任务，每一个人都 在疯狂的赶进度。 以Mac Excel项目为例，每周的进度检讨加上报告，是微 软用来控制进度的主要手段。除了这些，开发人员害得每周 和测试文件人员共同检讨原因和落后状况。可想而知，只要 进度落后，文件小组和测试人员只好暂时没事做，所有目光 和谈话，都集中在你的程序进度落后上了。 每周经理们会用更新的项目进度报告来更新项目总进度表， 然后分发给组员。于是你一眼就会看到本周落后了多少，整 个项目因此落后了多少。心痛之余，你翻到后 页看看还有多少未完成的工作，上周是几百项，现在还是几 百项，拼命做事，结果似乎毫无进展。就像一个笑话：如果 你每次咬一小口，多久才能啃完一只大象？这 张进度表就是一只大象，我们一辈子也无法吃完。 实在是太过分强调进度了。以至于无论我们做了多少了不 起的事情，都没有半点成就感。我们被落后的威胁淹没了， 再怎么努力，也看不到成功的彼岸。 这不是工作本身的问题， 实在是那种绝望无力的感觉所致。 更荒唐的是，进度表是基于如下原则设定的： 1为期两年的项目所有该做的事情都在进度表中，没有任 何遗漏。 2每人每周实际工作时间 40小时。 3对于每件工作的时间估计完全准确。 4所有程序第一次出来就是完美状态，没有 bug,不需修 改。 这真是天方夜谈。 教训：不要利用进程表来驱使项目前进，这实在太伤害小 组士气了。 在这里，作者提出了他自己的观点：不应该 deadline快到了 才开始紧张，平时就应该保持适当的紧张状态。多想想如何 聪明的工作，不要把时间浪费在没有 价值的工作上，不要浪费别人的时间，用积极的态度推动项