微软研发致胜策略-第3章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
那么就会一直保持前进，而如果团队觉得自己一定会落后
进度的，那么，惯性和自我预示的心理就会使它相信自己
是永远的失败者，导致士气非常低落。
请不要误解我的意思：如果一位程序设计师明明工作
了8 0小时，却只能完成进程表上2 7小时的工作，那一定有
什么地方搞错了；也许他最近做了太多人员面试的工作，
或是开了太多的会，或是最近e…mail 太多，或是他正在调
整自己的情绪，主管应该和他一起找出问题。但是，即使
是他个人不懂得善用自己的时间，也不该用进度报告使他
难堪。我们待会儿有更好的方法解决这个问题。让我们回
到前面提出的问题：如何保持进度报告的好处，又不必忍
受它的缺点？其中一个答案是设计一种新的进度报告，非
常容易写，既不花时间，且内容是正面性的。
以下是我的方法（我相信您一定可以想出更多更好的
方法）：
◆ 每当有人完成了一项新的功能或特色，就发个e …
mail 给大家。
21
微软研发·致胜策略
奠定基础下载
◆ 每当进度快要落后了，就到我的办公室私下讨论原
因，我们一起开动脑筋寻求解决之道。
就这么简单。依我的方法，典型的进度报告可能是这
样的：
“我已完成Faxmangler 的搜寻与取代功能。Frank”
主管应该看一下结果，然后回一个：
“我检查过F a x m a n g l e r的搜寻与取代，不太顺畅，请
再修改。Hubie”
或是：
“很好，继续加油！Hubie”
想想看，如果大家经常收送这类正面的e … m a i l，一定会
觉得充满干劲，这和可恨的进度报告多么不同！程序设计师
会很乐意看见这类的好消息，当自己送出完成工作的信息时，
也会很有成就感；没有人会觉得这是很讨厌的报告。当某位
程序设计师觉得自己可能要落后了，我会和他谈，研究将来
如何避免这种事情。是我们在制定进程时疏漏了某一个重要
环节吗？或是时间表定得太乐观了？是不是有个错虫（ b u g ）
在作祟，害得程序很难写或无法测试？不论问题是什么，我
们一定想办法解决掉，并且预防它将来再发生。
我只要靠这两种方式，就可以完全掌握项目进行的概况。
22
微软研发
致胜策略下载
上级要求的话，我也可以轻松写出项目演示文稿，根本不必
劳驾别人，所以我带的程序设计师不会因此而被打扰。
更棒的是这两种反馈方式产生了双重好处：第一，团
队成员经常感到项目又向前迈进了一步；第二，这对主管
和属下都是很好的学习机会，我们不会耸耸肩，无所谓地
说：“反正进程一定会落后的，没啥大不了。”因为我们会
认真面对问题，商讨对策。
为了强调进度报告的正式性，而把它弄成一件沉重不
堪的工作，这就是主管过度重视进度而忘了自己真正的目
标。结果陷入了流程的陷阱，倒把产品丢在一边了。
只有当您非常清楚您和您的团队该做的是什么，您才能
用最少的时间和最少的挫折去完成项目目标。回头检讨一下
遭遇过的困难； 有没有办法可以改善？有没有更好的方法，
让工作愉快些？至于那些对产品没有帮助的杂务，如果可能
的话，还是免了吧—至少不要把它丢给程序设计师。
永远记得自己真正的目标，然后让团队用最有效
又最愉快的方法把它完成。
23
微软研发·致胜策略
奠定基础下载
被成功的喜讯围攻了？
您可能会有这样的疑问，如果每个人都把自己完成某
件事的讯息发给大家，会不会塞满了每个人的电子信箱。
实际的情形是，每天的e…mail 并不多，因为信息不会送给
每个人，而是只送给同一组的四到五位程序设计师而已。
微软比较大的团队可能有多达50 位的程序设计师，
但是都会分成小组，每一个小组大约有五到六人。每一个
小组负责项目的一部分，有一个明确定义的目标，有一位
组长，也有自己的进程。小组内的程序设计师当然也属于
整个团队，但是以每天的程序开发工作而言，只与四五位
程序设计师有关而已。
事实上，即使是50 位程序设计师的大型团队，每个
人收到的“完成ＸＸ”的e…mail 也不多，数量稳定，刚好
够让每个人感觉到工作的进行，绝无爆炸之虞。
明白说出目标
您所认识的人中，有多少位一早起来突然发现奇迹，
选了几门神奇的课程就拿到了计算机硕士学位？有多少人
随便收拾一下东西就搬到了您的隔壁？听起来不太可能
吧。没错，一般人不会兴之所至就去修个学位或搬家，这
24
微软研发
致胜策略下载
些都是计划过的，他们会决定：“我要成为程序设计师”
或是“我要住在迪士尼乐园旁”，然后筹划一番，再采取
行动，才会达到目的。
可是，生活中的确有些事情是不经意就发生了，您可
能靠运气就得到一份好工作，或是福星高照在股市捞了一
笔。很不幸，推出一套软件的目标，并不比“我们要完成
WordSmasher”具体。
不错，大部分的时候您都可以完成目标，但问题是，
在这之前，有多少时间被浪费掉了？虽然您运气好，得到
了一份理想的工作，但之前也许有好几年频频跳槽；或者
您先细细思量自己适合什么样的工作，然后找到符合自己
条件的几家公司寄履历、面谈，会比较稳当？
我所辅导过的案例中，有六个总是在失败边缘挣扎的
团队，他们都有一个共同的特征，就是目标太模糊。其中
一个案例的情况是，小组的任务是做出使用者界面的函数
库，给2 0个左右的其他小组使用，他们做得人仰马翻，还
被别的小组抱怨函数库既笨重，错虫又多，很不好用。
当我和这位组长共同检讨工作清单时，我问他项目的
目标是什么。“为MS…DOS 的应用程序提供像Windows 环
境的使用者界面函数库。”我问他还有什么。
25
微软研发·致胜策略
奠定基础下载
“您的意思是？”
我说，他刚才的答案太模糊，能不能说得更具体些？
“嗯，函数库应该做到零缺点。”
我点点头，再问：“还有呢？”
他想了一下，耸耸肩，答道：“我想不出来了。”
接着，我说明任何函数库的主要目的是存放每位需求
者必要的公用程序，不是大家非得用到的东西是不该在里
面的。他很同意，认为这一点是显而易见的。但当我继续
下面的讨论，我开始不确定他是否真的懂得这一点。我指
着工作清单上的一项，问道：“这是做什么用的？”
“那是Works 小组要求的，是用来。。”
“对其他小组有用处吗？”
“没有，只有Works 小组会用到。”
我指着清单上的另一项，问道：“这个呢？”
“那是给CodeView 小组的。”
“那，这边这一项呢？”
“是Word 小组要的。”
我们一路看下去，我发现他对任何要求都来者不拒。
我想他也知道函数库中应该只有大家都要用的程序，但他
在做决策的同时并没有确实把握这个原则。他的目标只是
26
微软研发
致胜策略下载
“为MS…DOS 的应用程序提供像Windows 环境的使用者界
面函数库”，有没有办法说得更详细些？
目标是为MS…DOS 的应用程序提供像
Windows 环境的使用者界面函数库，只包含对
每个小组都有用的程序。
如果把目标定义精确些，就可以发现很多程序其实是
不应该放在函数库中的。在我们检讨完工作清单后，我开
始研究另一个问题：“很多小组抱怨，函数库中每次一放
入新版的程序，就会发生链接失败，这是怎么回事？”
“喔，那很简单，他们只是忘了修改自己程序中的函
数名称而已。”
这我就不太懂了，于是我请他给我一个实例。他的小
组修改过函数库中的b u g了，或是加强了该函数的功能，
然后就连名称也顺手改了，用另一个更能表达其功能的函
数名称；或者是做了一点小小的修改，然后把函数名称一
道改了，以强调所改的差异部分。
这位组长不了解其他小组怎么会如此大惊小怪，不过
是改个名字而已，非常简单啊。他从来没想过，有20 个
小组要因此检查所有的程序，把所有用到函数库的地方都
27
微软研发·致胜策略
奠定基础下载
改过来；他也没有想到，经常链接失败的函数库是很不好
用的，函数朝令夕改，别的小组会无所适从，根本不知道
程序应该是什么模样才对。
如果这位组长稍微花点时间，从别的组的角度来看看
这个函数库，他就会明白放入新版程序时，与旧版能兼容
是多么重要。大家都希望既用到新的程序代码，希望所有
的程序都能链接成功，没有任何失败。
于是，我们把项目的目标再更具体化一些，那是：
目标是为MS…DOS 的应用程序提供像
Windows 环境的使用者界面函数库，只包含对
每个小组都有用的程序，而且必须和其他部分
的程序版本一致。
现在我们理清了影响这个函数库的重要相关因素，我
和组长一起定出了清楚而明确的项目目标。我们发现，只
要用心考虑各因素之间的关系，考虑一项行动会造成什么
影响，很多细节就会变得显而易见，而且是可以事先建立
正确的规范，避免事后再来花更多时间收拾残局。只要在
做出决定之前想一想，“我要这个函数库能做到什么？项
目的目标是什么？”很多问题都能迎刃而解，组长可以轻
28
微软研发
致胜策略下载
易决定什么是该做的，以及该如何做。
如果做得更彻底一些，组长可以花几个小时，甚至几
天来订出详细的项目目标，这些目标不一定要博大精深，
只要目标能够写下来贴在容易看见的地方，随时提醒、随
时指引，让项目朝着正确的方向进行就可以。
如果函数库中都是全部小组需要用到的，函数库就会
体积小些、精简而标准化，新增的功能特色就比较容易做
出来，开发小组就不必拼命加班做一大堆只有少数人用得
到的函数。想想看，只要把目标稍微理得清楚些，整个项
目的方向就会有惊人的改变。
理清详细的项目目标，可以避免在不必要的工作
上浪费时间。
相互依赖
项目失控最有可能的原因是小组之间工作上的相互依
赖：一方必须依赖另一方把工作做完才能进行自己的工作，
而且若是彼此的配合或沟通不够好，整体工作必然受到不
29
微软研发·致胜策略
奠定基础下载
利的影响，依赖愈多，愈容易失控。使用共享函数库有很
多好处，这是人尽皆知的事。但是身为组长的人，必须衡
量是否该把这部分的程序代码放进函数库，所获得的好处
与必须忍受的缺点—让其他的工作依赖于它，孰轻孰重。
任何领导者，必须牢记并且实践以下的座右铭：
尽可能减少项目中小组彼此间的依赖。
想想看，万一函数库的开发工作进度落后了，又未能
及时采取改善措施，对其他的小组有多大的伤害！负责函
数库开发的小组会拖累大家的进程，使大家不由自主地一
起延误，若不能及时挽救，项目就真的失控了。
另一方面，如果依赖函数库的小组听说开发函数库
的小组无法在规定时间内完成要求
