微软研发致胜策略-第2部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


吗？
本章首先来介绍前人的经验。就我所知，对于一个希
望不加班就能如期完成任务的团队，必须把握好的原则，
这是软件开发部门的基本观念，也是往后几章的基础。
专心改善产品
公司付薪水给程序设计师，是要他们在合理的时间内
10
微软研发
致胜策略下载
做出品质精良的软件，但是程序设计师的时间却经常被其
他的事情占用掉了。这样的程序设计师或他们的经理们，
就是因为不了解软件开发的真理：
任何不能改善产品的工作，都是浪费时间
或是偏离方向。
如果您一时不了解这个观念的重要，请想一想以下
两个极端典型的比较：一位程序设计师一天到晚开会、
写报告、阅读和回复电子邮件，另一位程序设计师则专
心研究、设计和测试新产品的功能，试问谁比较容易脱
颖而出？毫无疑问是心无旁骛的那一位，他甚至可能提
前完成工作呢。
我经常发现，团队出问题的原因之一，往往是因为程
序设计师们都在做他们不该做的事：他们花太多的时间准
备开会、参加会议、读写开会记录和进度报告，以及回复
电子邮件。这些不能改善产品的工作，固然一部分是程序
设计师自己主动做的，但更大的一部分是主管下的命令。
曾经与我共事过的一位经理，要求每一位组员要用
e…mail　交一份工作周报，每周开一小时的会讨论目前各人
手上的工作内容，以及其他突发性的事务，开完会后，提
11
微软研发·致胜策略
奠定基础下载
出意见的人负责写出书面报告，交给经理。
这位经理的动机只是想管理每一个细节，但并不了解
这会让团队被无意义的工作压得无法喘息。这些进度报告
真的那么重要吗？那些后续报告的用意又是什么呢？如果
开会时经理自己做个简单的笔记，不就省了这些报告所占
用的时间和精神？
很显然，这个问题的答案必须视您身处的企业环境而
异，但从我刚才所举的实例来说，其实只有最初制定进度
的那份报告是有价值的，其他的报告都是可有可无，甚至
进度检讨会都没有必要召开，而且每次那位经理要求后续
报告时，我都很纳闷，心想：“我刚才不是已经告诉他我
的想法了，为什么我还得再写一遍？”
我不过是偶尔去参加他们的定期进度会议，所以对我
的时间损失并不大，不过，我常在想，不知道公司里有多
少不必要的例行工作正在加重员工的负担？这位经理本意
是尽力把每件事情做到巨细靡遗，但是却违背了身为软件
开发领导者的基本守则：
领导者的任务是努力消除程序设计师工作
上的一切障碍，让程序设计师全力专注在真正
重要的工作─改善产品。
12
微软研发
致胜策略下载
这并不是震惊世界的大发现，而是极简单的道理，但
是，有多少软件开发主管是真的把“消除程序设计师工作
上的障碍”当作积极追求的优先目标，而且确实做到呢？
如果刚才提到的那位经理真的用心去减少组员不必要
的工作，我确信他可以想出更简单有效的方法掌握工作进
行的状况，而不必一再浪费组员的时间开会和写报告。
千万不要把程序设计师的时间浪费在改善产品以
外的工作上。
请不要从字面上解释我的话
我所谓的不要把程序设计师的时间花在改善产品以外
的工作上，请不要从字面解释成程序设计师只许写程序。
事实上，思考如何设计、测试程序和接受需要的训练等等，
虽然不是直接投入在改善产品上，但对产品品质却有重大
深远的影响。如果程序设计师在动手写程序前，仔细思考
过产品的设计，把缺点改正，当然会比一味地埋头苦干要
好得多了。
13
微软研发·致胜策略
奠定基础下载
有些团队的活动，用意是让团队成员在愉快的环境中
工作，提高程序设计师的生产力和士气，虽然看似与产品
无关，最后还是对产品品质与工作效率有正面的帮助。
排除干扰
如果您希望团队能在期限之内完成好的软件，就必须
尽可能排除一切不必要的工作，特别是您打算分派工作给
全体组员之前，请等一下，问问自己，这件工作真的有必
要叫大家做吗？能不能由您自己做呢？比方说，如果您要
准备向上级报告项目概况，非得要所有的程序员停下手边
的工作，为每个程序写一份摘要吗？我倒不这么认为。身
为经理，您应该平时就对项目的进度及一切的状况非常清
楚，不必靠人帮忙就能做出切中要点的演示文稿，而且信
息已经存在脑海中，比起再去汇总整理一堆人的报告应该
是快得多，也更好组织。或许这要花掉您几个小时，但总
比打搅整个团队去做一件与产品无关的工作要好。
我通常会做得更彻底一点。如果我发现一位程序设计
师总是被不能不做、却与产品无关的工作绊住，我会主动
解除这件工作，由我来做好了，这样程序设计师就能完全
专心在软件上面。除非是为了训练，否则没有任何理由要
14
微软研发
致胜策略下载
求程序设计师本人回复e…mail，询问项目的e…mail　交给适
当的经理来回答就行了。凡是能由主管出席的会议或能由
主管执笔的报告，都不应该丢给程序设计师，最好能把这
些开会、报告都废除。
我知道这些建议与大部分的管理课程或教科书上所指
的授权（delegation）　有所冲突，我并不是说这些课程和书籍
错了，而是您在实际工作中应该放聪明点，对于工作的分
派应该更有选择性。如果把工作分出去的目的仅仅是为了
减轻个人负担，实质上您做的是伤害团队生产力的事情。
别人“能”做某件事，并不代表他“必须”做那件事。
您看过整个房子的搬迁吗？我不是指搬家，而是整个
房子从地基上拔起，用车拖着移到别的地方（美国的房子
多是木造的，可以这样搬移）。我们可以把项目比喻成那
间房子，把经理想成开路先锋，他的责任是把前面所有的
障碍物排除，让房子能一路不停地稳定前进，而不是走走
停停，停停走走。
房子前进的时候，领导者不希望每到一个路口就停下
来处理红绿灯，或协调其他的车子让路。他必须事先就规
划好最理想的路线，在房子抵达路口之前，就协调好工程
人员卸下悬挂着的标志灯或是电线等会阻碍行进的东西，
15
微软研发·致胜策略
奠定基础下载
等房子经过了再装回去。他应该避免将拖车停下来缴过路
费，或是等待他跟工程人员开完协调会。
搬迁房子的开路人员明白一件事，如果要房子一路不
停地向前行进，一定要找出所有的障碍，并且排除掉。过
路费当然也可以由拖车司机来交，可是这样一来就得停下
车子，如果由开路人员在前面交不是更好吗？很不幸，有
太多的软件开发经理在不该授权时授权，让组员为了与产
品无关的事情疲于奔命，被外界的杂事干扰正常的进度，
以致项目进度不断延误，甚至停滞不前了。
保护程序设计师不受任何阻碍和干扰
如果我带的不是程序设计师，而是主管。
前面的讨论中，我假定您是程序经理，带的是程序设
计师，但是如果您带的是测试人员、文件撰写人员或是其
他类型的小组，您的原则还是一样的。基本上，身为主管
的重责大任就是让属下专心做他该做的事，不论他该做的
是写程序、测软件还是写文件。
16
微软研发
致胜策略下载
就算您带的全是主管，您也应该决定哪些工作是不必
要的，尽可能免除。开个会了解各位主管们手上项目的进
度，和开个会了解各位程序设计师们手上程序的进度，都
一样是浪费时间，特别是独立进行项目的主管，没有必要
让一位主管了解与他项目无关的概况。主管的时间对产品
影响也很大，浪费主管的时间，他就没有办法做他该做的
事—排除程序设计师的工作障碍。
一定有更好的方法可以减少干扰
身为经理，我在项目的每个阶段都会问自己一个问题：
“我努力的目的究竟是什么？”
我总是不断用这个问题提醒自己，因为太容易被不重
要的工作拉偏方向了。如果您经常把报告或备忘录东修西
修的，换个字型或样式，结果美化文件的时间比写的时间
还长，您就明白我的意思。因为在那一刻，这件工作占住
了您全部的思绪，似乎是最重要的事情，但只要您随时以
整个项目的眼光来看事情，您就不会陷入细枝末节了。
我们谈过了把时间浪费在进度报告和检讨会议的案
例，现在您应该可以回答这个问题：
17
微软研发·致胜策略
奠定基础下载
“我举行进度会议和要求进度报告的目的究
竟是什么？”
我想，主要的目的是了解项目进行的状况，以便及早
发现任何进度上的延误，避免项目发生进度失控，不是
吗？假定没有发生延误，每一个项目都如期完成，也没有
人需要加班，那还有必要报告进度吗？当然不必了。
如果您开进度会议和要求进度报告目的，是想确定项
目进度有没有落后，有必要动员全体去收集这些信息吗？
我不这么认为。我从来不开进度会议，不论我是带新的项
目或是接手其他人带了一半的项目，我第一个废除的就是
这类没有意义的流程，我就是不相信非得用开会写报告的
方式才能掌控项目的进行状况。
至于进度报告呢，它究竟有多重要？我认为进度报告
虽然令人厌恶，但却是必要的，经理总得了解项目是否出
了问题。但请别忘了，进度报告虽然必要，但是它绝对不
会对产品有任何帮助。所以，当您遇到一件必要但对产品
没有帮助的工作，您得寻求这个问题的答案：
“我该怎么样保有这项工作的好处，消除它
的缺点？”
18
微软研发
致胜策略下载