现在，领导者要做的事是为大家加油打气，为大家灌 推出时期
317 输自信和热忱，有些组员可能会觉得领导者大约是乐观过 了头，但大部分的人都会受到鼓舞，理解在这时候焦虑是 正常的，是可以被接受的自然反应，而且是创造智能财产 过程中必经的压力。在激活阶段的团队工作效率会达到巅峰状态，因为大 势已定，不需要再揣摩或协商。这时候的团队心理有以下 几项特点： 大势已定 产品的功能特色、团队中每个人的角色 几乎是完全定型了。所有犹豫不决的特色不能早点 定案到现在都得删除，组员之间的工作负荷很平均， 产品架构完全确定而且趋向成熟，测试计划正在进 行，文件撰写原本只有纲要，现在要加入细节。此 时一切都没啥好争论的，没有任何疑惑，每个人都 知道产品就要诞生，剩下来该做的事也很清楚，去 做就是了。艰辛的开发工作终会过去，此时，赶紧 把它完工是最重要的。 共同一致的信念 每个人都有一致的信念，我们即 将完成产品，时间一到产品就能推出。现在所有的 痛苦抉择或权衡都已经过去，大家只要专注于眼前 产品的状态就好。产品的催生时期就代表着所有的
318
争议结束。如果现在还有怀疑或争论（到现在还没 解决的话），也只有暂时搁置，到下一版时再说， 否则永远没完没了。此时若是还有人对项目有严重 的怀疑，产品是永远无法进入催生时期的。 每个人都明白 每个人都明白自己该做什么事，也 明白整个团队该做什么事，才能使产品顺利推出。 现在已经没有什么事是不确定的了。所以，只要继 续把手上的工作做出来即可。延误或是对延误的恐 惧，只单纯地和自己的工作有关，不再和别人的工 作有太多的依存。在组员心里曾有的焦虑、飘浮无 依的不安，现在都可以放掉。我常把这个阶段称作“工作清单”阶段，每个小组都把自己的一大串的 工作逐条列在清单上，现在要把清单上的工作逐项 完成，打个勾勾，清单上每一项工作都做完时，产 品就完全推出了。 开发团队的最高领导人必须身先士卒，率先进入产品推出时该有的心理状态，并且信守一切的承诺，才可能带 动所有组员进入这个紧张的时期。对于细节的认知会愈来 愈清楚，在工作步调上也许会有点凌乱的危机，但这时候 领导人最重要的工作就是带领大家专注于产品的推出，凡 推出时期
319 是不太相干的事情尽量排除；在团队中的每一个成员都渴 望推出，看到自己辛勤耕耘的结晶是多么欣慰，领导人必 须将大家对于推出的渴望，转化成完美的推出工作。
产品的推出：推移推移阶段（ship mode: transition），在时间上可以跨过 一个以上的里程碑，视产品性质的需要与产品的推出而定。 基本上，产品推出的推移阶段是产品从开发迈向完成的逐 渐稳定阶段。开发工作仍在进行，直到最后一个里程碑为 止；如果开发工作的重心是增加功能，势必很难同时追求 产品的稳定，自然严重影响产品的推出；由于同时追求增 长和稳定实在太耗费心力，这时候主要的开发活动是除虫， 凡是无法完成的功能特色都暂时放弃。要放弃任何的功能 特色，都难免引起组员的不安情绪，所以，下决定之前必 须审慎地分析评估。如果我们把产品推出当成一条数学上的连续曲线，你 会发现当产品愈来愈成熟，所需的开发人力愈来愈少，产 品推出就进入了完成阶段（我们稍后再详细讨论）。现在， 产品推出的推移阶段即将结束，而将进入早期的完成阶段 时，会有下列的迹象：
320
组员的思考更加保守而小心谨慎，避免掉入开发的 泥淖。 程序置入的动作审慎再审慎，通常会成立一个临时 的特勤小组，检查每一个程序置入的动作，务求事 先防范大幅的不利影响。 增进执行速度和改善使用者接口成为工作的重点， 把产品磨亮打光，以期带给外界深刻的印象。收尾 成为最重要的方向。 修饰的工作完成后，接下来加强产品的稳定度，以 达到推出的要求水准，所有的开发工作已经结束， 清除错虫的工作也已接近尾声。
产品的推出：完成在产品推出（激活、推移和完成）的三个阶段中，工 作重心发生移转，从准备进入催生时期的心理变化，产品 逐渐稳定下来，直到产品推出的完成阶段（ ship mode: e n d g a m e）时，只剩下一个里程碑了，就是“推出”（s h i p p i n g）。在概念上，这个阶段的工作相当单纯，就是 一张工作清单，当上面所列的项目逐一完成，产品就推出 了。工作清单上有几百项，甚至几千项，也不过只是一张 推出时期
321 清单罢了，很多但不会太困难，你没有时间想或做这张清 单以外的事情，每个人只有心思专注在自己该做的事情上。 也许会发生一些状况，使得工作清单上必须增加一些项目， 团队会在一阵“适度抗拒”（appropriate resistance）之后 接受工作项目的增加；这种适度的抗拒，我把它称之为“谦逊的抗拒”（profound resistance）。 这时候每天召开例行的检讨会是个很不错的方式，如果能常常邀集决策者参与更好。会中的议程不拘泥于惯例 或任何形式，但必须是能立即决断的问题，凡是长期性的 目标或一时无法解决的问题，都暂时撇开不谈，下次改版 时再说。管理者参加这个会议的作用之一就是将议题引导 在这个方向上。现在，团队的主要目的是在推出日期时， 产品的品质水准要够好。已经进入倒计时阶段，开发人员 主要的工作是错虫的更正，而且是重要的错虫──这会影 响很多的使用者，或是造成严重具毁灭性的错虫，都必须 优先清除。至于使用者界面的美化、执行速度加快、或是 新的功能，都不宜在完成阶段讨论。B e t a测试版的测试结 果，以及外界的反馈，都以“追求产品的稳定性与避免严 重错误”为大前提，作小幅度的修改。而其他的建议案， 都只是预警相关人员在销售上可能遇到的困难或不利影
322
响，或是下一版的改进时的建议，但基本上，目前不打算 在产品上响应这些项目。
有多少无伤大雅的错虫，存在于你 推出去的产品中？
你必须了解，顾客对于软件品质的要求程度，或是说 对错虫的忍受程度。在你推出的产品中，有多少错虫因为 优先顺位较低，而未及修正就随着产品出门？这些较次要 的错虫会不会造成问题？使用者会不会因此而在操作上遇 到麻烦？由于在产品的推出阶段，稳定是第一优先考量， 所以在决定是否要更正一个错误以前，必须先考虑会不会 因此而造成更大更多的错误；有些错误的修正太冒险，错 误本身的危害并不大，把它列在产品的读我（readme.doc） 档中说明，会比较好。有时候，就像有些人的阵痛期特别长一样，产品的推 出工作如果不太顺利，也可能使上市的日期受到延误，以 下有几个法则提供软件开发团队的领导人参考，以期能避 免在产品推出时发生延误的情形。 下载
法则 48
Violate at least one sacred cow 关怀多于要求
324
身为团队的领导人，你可能巴不得所有的属下都拼命 工作。但事实上，虽然在产品推出阶段所面临的挑战可能 真的需要大家拼命工作，你却不可能“命令”大家为工作 牺牲奉献自己的一切。我曾经见过一些没有人性也不懂人 性的管理者，要求他的组员晚上加班、周末来上班，结果 组员要不是他的命令理都不理，就是在背后嘲弄这位可恨 的管理者。事实上在产品推出的阶段，管理者的作用并未消失， 有些仪式性的动作，虽然很小或很简单，却是意义非凡。 此时领导人应该用实际的行动来表达他对组员的关怀，肯 定他们对组织的贡献，让每一位组员都感受到自己的每一 个角色都是那么的重要，领导者的关怀，可以增强组员的 向心力，对产品的顺利推出有莫大的影响。领导者对组员的沟通应该是具有鼓励性，不是强迫加 班，而是提供方便的加班环境。例如，写一张小卡片给某 位组员（不能用虚假的客套话、公式话，要真诚的关心）、 走廊上餐厅里不期而遇时的几句赞美、提供加班时的托婴 托儿服务、自掏腰包来个点心宵夜，或是让组员可以很方 便地在家工作（简单的远距办公室通信设备）；这些小动 作花费极少，却让组员体会你的关心与诚意，而感到自己 法则48建关怀多于要求
325 的加倍付出是值得的。还有，这些小动作似乎都是与传统 规矩背道而驰，你为了他们而打破这些传统的规矩，也让 组员们觉得你对他们的肯定超过公司给你的规定。一般来 说，优秀的开发人员多少都有点叛逆心理，喜欢对传统的 权威挑战，你用别出心裁的方式鼓舞他们，比用传统的方 式要来得有效。
优秀的开发人员多少都喜欢违抗传统。
以行动表示的关怀，同时还告诉组员产品推出是件值 得纪念的大事。大家合拍一张照片，写一篇小故事，收集 一些开发过程中辛苦的笑料，送个电子邮件恭贺大家产品 终于要推出，或是表扬一下杰出的组员或事迹。这些都是 领导人在这时候可以做的事情，让大家留下难忘的回忆。 好好享受这欢笑的收割吧！因为大家都曾经流泪播 种。产品推出是大家形成一个团队的目的，也是大家同甘 共苦情绪的最高点。这时候团队士气是最高昂的，所有曾经犯下的愚蠢行为和几近干戈的争议，现在一律抛诸脑后。 大家已经完成任务，产品推出了。 下载
法则 49
Beta is not the time to change Beta测试版不是修改 功能的时候 法则49建Beta测试版不是修改功能的时候
327 几乎全世界的人都有这种误解，以为B e t a测试版就是 邀集外界对产品提出设计方面的改进建议，然后让软件 公司对功能做加强或修改。这是完全错误的。（A l p h a测 试又名内部测试，B e t a测试又名外部测试，B e t a测试版是 把即将推出的产品提供给部分顾客试用，另一方面也作 为对市场的试探。）B e t a测试的目的是确定产品是否能在 预计的各种硬件平台与操作系统中正常运作。虽然B e t a测 试的反馈意见很有参考价值，但除非B e t a测试中发现产品 有重大问题，否则不应对功能再做修改，顶多只是更正 错误。所有的建议和反馈都留到下一版时再考虑纳入。这么做绝不表示忽视顾客的意见，相反地，如果你要 把B e t a测试的意见纳入，那你永远没有办法推出产品。你 与顾客之间的关系应该是更亲密、更持续的（请参考本书 第一篇中的顾客关系）。 下载
法则 50
The Beta is for spin develop- ment Beta测试是暖身活动 法则50建Beta测试是暖身活动
329 顾客对产品的第一个印象往往决定了他对产品的评 价。基本上，B e t a测试者的反应，也会是大部分顾客的反 应。行销人员应该把握B e t a测试的机会，了解测试者对产 品的感受，分类并记录测试者的反应，以便在产品的包装、 信息传达等方面抓对方向。即使在这时候主要的信息已经 发布给媒体，敏锐的行销人员仍然能够从Beta测试的结果， 得知那些应该强化或淡化的信息。行销人员应该建立一套 顾客心理学的模型，用来了解顾客在使用产品时的心理状 态及其变化，以及产品信息应该如何根据试用顾客的心理 反应来做调整。毫无疑问，你一定会在B e t a测试中得到一些负面的评 价，这很正常，而且应该在你的意料之中。如果负面反应 很强烈的话，你得设法找出其他的产品优点去平衡它；如 果负面反应很普遍，每个测试者都有，那你得让大众降低 对产品期望的水准，让这个负面反应在消费者的意料之中， 而不致产生吃惊受骗的感觉，这样负面的反应就不会那么 强烈；最后，你得设法让这个产品的缺点看起来不那么严 重，比方说提供解决的操作方式等等。就算B e t a测试活动不是由行销人员所主导，也应该让 行销人员密切参与。在这个时候，与外界的沟通就可说是
330
产品成败的关键了。产品信息比产品本身还重要，现在已 经不是用开发活动来创造产品的形象。 下载
法则 51
Triage ruthlessly 急救术
332
如果软件代表开发团队，那老实说，它一定有数不清 的缺点。欠缺完美是所有智能财产的必然性质。世上所有 的事物都不完美，所以问题不在于判断这个产品好或不好， 而是决定应该修改那一部分，使它比较能被顾客接受或喜 爱。我们把这个判断并修改的过程称之为“急救术”（t r i a g e）。 急救术，当然是个医学名词，在急诊室中医生必须非常迅速地查看所有的问题，采取最急迫必要的急救医疗措 施，然后再依优先级分别施救。软件急救术是非常类似的 观念，先分析各项错误与瑕疵，以及它的严重性，以下是 判断是否施救的准则： 错误的严重性：如果错误严重到必须回收所有已推 出的产品时，那么就必须立即改正这项错误。 明显程度：错误会很明显而立刻被使用者发现吗？ 会不会影响到产品的品质？会影响到产品的形象， 而成为竞争者攻击或嘲笑的把柄吗？ 影响范围：有多少比例的使用时间，会遇到这个错 误？这个错误是大部分的使用者都会遇上的吗？ 修正错误的风险：如果要修正这个错误，会不会造 成软件的不稳定？这需要非常资深又对产品了如指 下载
掌的开发人员来判断。
错虫满天飞 微软团队·成 功 秘 诀法则51建急救术
333
334
团队动态：为了修改这项错误是否需要动用大批的 人力，抑或是一小部分人员投入即可？会不会使已 经忙碌不堪的开发人员更加人仰马翻？ 修正错误后所需要的测试成本：为了任何理由修改 任何部分都需要测试，团队有没有足够的人力来执 行测试工作？时间上允不允许测试？ 一般而言，急救小组的任务是选择和修改产品中最重要的错误，尽量让大部分的使用者在大部分的时间都能使 用愉快。对使用者而言，这项不完美的产品是帮助还是灾 难？他是用这个不完美的产品比较好，还是宁愿不用比较 快乐？这个复杂且严肃的问题，需要工作人员不断设身处 地去设想使用者的情况，揣摩使用者的心情，与使用者双 向沟通，才能探得正确的答案。 下载
法则 52
Don't shake the Jell-0 小心保持软件的稳定
336
处于完成阶段，你必须灌输组员一个观念：修改软件 是一件危险的事。软件马上要推出，这时候稳定绝对是第 一要务。错误修改的成本或风险如果太高，宁愿不要修 改；不必要的修改必须极力避免。产品的推出，就像一盘特大号的、结构脆弱的果冻， 你一摇动盘子，果冻必定会颤动、摇晃，然后逐渐静止。 你摇动愈用力，果冻晃得愈厉害，需要变回静止的时间就 愈长。同样地，你修改任何一个错误，都不可避免地影响 到整个软件的稳定性，等到你的软件像果冻一样恢复静止， 恭喜你，那就是你推出产品的时机了！ 然后，它会再度震动。
Part 第四篇 发布时期
Four
发布时期
339 本书的主要目的虽然在阐述如何以团队方式开发伟大 的软件，然而，我们无论如何都不能忽略与大众的 沟通。软件如果无法让一般大众很容易感受它的伟大、它 独特的优点，又有什么用呢？我的看法是，软件的伟大必 须要经过与大众沟通的过程，让世人都认识它，既然是伟大的软件，当然要让它在历史上记下一笔，让它永垂不朽。 因此，软件产品完成后，必须要有一个产品发布会。产品发布会就是让产品留名青史的时刻，顾客、产业 记者和评论家都在发布会上睁大眼睛看你的软件作品，这 是他们了解产品的开始。即使你的软件不是商业性的，也 不打算特别包装，但仍得利用产品发布会来强调它的技术 性，至少是在一个研讨会之类有很多重要人物聚集的场所 发布你的新技术。无论采用什么方式或强调什么重点，你 的目的是昭告世人新软件产品出炉了，希望大家对它有正 确而清楚的认识。这是软件首次登台亮相，你得让它吸引 众人的目光，尽可能使它的信息清楚地传递给所有的人， 这是你的开发团队和顾客建立关系的大好时机，也是对组 员很大的鼓励。
340
产品发布会是一个充满成功气氛的 活动。
已发布的信息是无法收回的。信息虽然可以重新发 布，但结果大都不理想，人们心中对产品的印象不是新 的信息，而是一片混淆，所以第一次信息发布格外重要。 一个规划妥善的产品发布会，所有信息与气氛的设计都 应该以产品为中心，一切安排都是为了抓住人们的注意 力，让产品在明确的信息烘托之下，漂亮登场，配合精 心设计的各种沟通媒介，务必让每个人都对产品有鲜明 而正确的认识。把产品发布会做成功的好处是说不尽的， 此处择要概述如下： 确定的产品发布会，能够促使团队为确定的目标同 心协力。如果每个人都认为并期待某一件事应该在 某一天发生，就像是一个共同的目标，无形中促使 开发团队把它当作一项有意义的挑战而同心协力。 我建议每一组参与产品发布活动的人，都有详细的 战略规划，因为发布会和产品本身，就像一场战役。 发布时期
341 产品发布团队（launch team）应该与开发团队一样， 应用本书的5 4条法则，应该有共同的目标、懂得运 用策略、有团队精神，发布团队必须把任务当成一 种全心全意的承诺。全体工作人员会感受到产品发 布那种成功的气氛，辛辛苦苦孕育的产品，如今捧 在自己手中，那是非常令人振奋的感觉，这种心情 会感染给会场上的每一位来宾，使产品发布会更加 热烈。 成功的产品发布会能够提高产品的接受度。有些意 见领袖对产品发布会特别敏感。很多人参加产品发 布会纯粹是为了对科技的狂热，或是产品对他个人 有重大的影响，再加上产品发布会本身多少带有戏 剧性，所以，会有很多人带着热情而来，他们会希 望认识你、你的团队和你们的努力、你的软件和你 对这个软件的感情，因为使用你的软件，他们开始 认识你，你和团队的言行气度所表达出来的形象， 也会是他们对新产品的印象之一。事先应该和行销 人员研究好，如何确切地表达这个产品在历史和技 术上的重要性，这和如何发挥产品发布会的戏剧效 果是同样重要。
342
发布会是产品与大众见面的最重要的活动。就像 电影的首映会一样，发布会是产品问世时的第一次 见面；发布会的前置作业与后续的活动都有逻辑上 的顺序，应该事前安排妥当。在 B e t a测试时，你就 应该邀请媒体、重要的顾客、相关领域的权威人士、 你的朋友，试用B e t a测试版，这样的话，他们会对 产品有清晰的概念，也会比较乐意提供自己的感 想，为产品做见证。而在发布会前夕，你私下寄给 这些重要试用者一段小小的摘要，稍微提醒一下产 品的特点，免得他们太忙而不记得产品试用时的感 受。在产品发布会上，这些人就会很自然、很清楚 地向记者宣布他们对产品的看法，等于是为产品背 书一样的效果。发布会后接踵而至的是一大堆的广 告活动，包括传单、电子邮件、产品目录、现场展 示等等。你必须密切注意与会者的现场反应，尽可 能给予足够的支持和服务。这一切细节都是发布会 的一部分，也是产品信息的一部分，不论这些事情 要花你多少功夫，无论你和顾客熟到什么程度，你 都必须将这一切细节都照顾好，确定产品发布会尽 善尽美。 下载
法则 53
Compete with the superior story 伟大的软件应该有一 个伟大的故事
344
软件的故事 每一个伟大的软件，背后都有一个伟大的故事（平庸 的产品当然只有平庸的故事）。信息架构就像软件中的位 元一样复杂交错，因为信息必须以不同的层次传达给不同 法则53建伟大的软件应该有一个伟大的故事
345 的对象，信息必须和接受者发生情感上的共鸣，必须随着 时间和环境而演变修正，信息必须够简单，这样才能强而 有力，但又必须够复杂，这样才能引发接受者更大的兴趣。 很显然地，信息所达到的沟通品质，与产品销售成功与否 有莫大的关系。请切记，你应该有适当的投资放在信息传 递上，就像开发工作一样重要，因为信息和产品是密不可 分，二者都是团队所创造出来的智慧财产。
传统智慧经过许多年的传颂，容易 让人很快接受。
你必须事先仔细思量，以产品的沟通策略来设计的信 息结构应该是什么样子？如何传递出去？应该如何引导人 们的思路，帮助他们开始懂得欣赏产品？你的信息应该包 括这些，才能让无形的智能财产被世人看见。当你站在听众面前，别只顾着示范产品特色，先表达 一下产品所赋予的内涵，把产品的故事说给团队、高级主 管、记者、产业分析师、顾客或投资人听，这个故事必须 具有传统智能的色彩。凡是带着传统智能色彩的东西，都
346
会被自然地传颂，而且在任何专业领域都是共通的语言。 传统智能必定是个小故事大道理。你的故事必须至少 有一条主轴是与科技趋势或市场情况(或是二者)有关，这 样才能让听众觉得你的故事有价值，乐意倾听。故事的内 容必须简明扼要，同时又能引发听众更深入的思考，让头脑灵活的听众觉得其中有些内涵正是我所想过的(共鸣!）， 太玄的言论无法引起在座专家的兴趣，而且绝不能落于俗 套。请注意故事要既简单又有内涵，不要太过简化而流于 空洞，你的内涵一定要让听众觉得非常有价值才行。
要让听众深有同感：“对！这正是我 过去一直在思考的。”
要把产品信息用一个简明、有见地的故事表达出来， 本来就是一个很大的挑战。你必须能够打动听众的心弦， 要让他们深有同感：“对！这正是我过去一直在思考的。” 这不是在宣传你的观念，而是在无形中与听众的思想交流， 引发他去想你提示的问题，让听众用自己的心去体会你的 信息，而不是被你灌输信息。这些信息必须听起来像是常 法则53建伟大的软件应该有一个伟大的故事
347 识，被你说出来，又在他心中产生了共鸣，就会让听众觉 得这是真理。 让我们举个例子来说明信息的内涵，你可以这样开场：“使用者不爱用f o o t b a r，因为它就是这么难用。”这好像是 直说国王没穿衣服一样的反传统─但绝不激进。用一个 大家都知道或愿意相信的事实（也许大家都不好意思宣之 于口），从这个事实紧密地引申出另一个与产品有关的事 实（你要表达的重点，也许直接说会不容易被人接受）， 而且记住不要陈述已经被别人提过的事实（人们会混淆这 话到底是谁讲的）。当我们发布Visual C++ 1.0的时候，我们强调的事实 是大部分的程序设计师还没有从 C换到C + +。我们调查结 果的数据资料显示，有8 0 %的C语言程序设计师打算、即 将或是希望能从C换到C + +，但只有1 0 %的人真正能做到。 媒体和产业分析报告都表示C + +的时代已经来临，但我们 的资料却显示着相反的情形，这是我们要直言说破的皇帝 新衣。
348
直接说出产品信息，未必是最有效 的表达方式。
我们的直言不讳很快打动了人们的心坎，因为这是千 真万确的事实，而且大部分的人都有同感。就算我们不说， 也许大家终究会知道事实的真相，只不过要花多一点时间 和疑惑吧。然后，第二步是紧密地引申出另一个事实，也就是产 品信息，非常简单：即使是对于精通C语言的程序设计师， C + +还是太难了─直到Visual C++的出现为止；我们不 追究为什么C + +那么难，我们只知道Visual C++把它变容 易了。传统智慧通常都以俗谚表达，用一两句简单又响亮 的词句，让人朗朗上口、易颂难忘。政治家都是精于发 明口号的高手，例如：“我们需要的是五分钱的雪茄”、“除了畏惧本身，没有什么好畏惧的”、“不要问国家为你 做了什么，要问自己为国家做了什么”。这些口号之所以 深入人心，因为它们包含了传统智慧，简明响亮，又提 法则53建伟大的软件应该有一个伟大的故事
349 供了指导的功能，没有冗长复杂的理论。尽管喊出这些 口号的人早已故去，但这些口号如今依然存在，而且已 经变成了智慧的明灯，因为世人迷惑时它们提供指引， 如果这些口号没有智慧的内涵，流行过后必定会消失无 形，被人淡忘。好的故事会让人终生难忘，因为它有内涵、有见地， 会让听的人感受到其中的睿智。好故事必须让人们容易联 想，一旦它触动了听众内心的共鸣（因为是很简单的事实）， 人们会很自然地打开心扉准备接受下一个联想或引申出来 的事实，而且接受程度和你打动他们的程度成正比。例如，“某教练的球队总是无法赢得重要比赛”这是第一个事实， 但人们听到之后在自己的内心会这样重述：“这教练不好” 或是“要不是他输掉了关键球赛，可能还是个不错的教练” 这是一般人必然的反应，就是把接收到的信息加上自己的 观感，用自己的话重述一遍。
你诱导听众自己想出来的事情，肯 定比由你来告诉他更有说服力。
350
所以，如果你能将产品故事用个有情节的方式来 述说，那是再好不过了：有背景、有气氛、有情节起 伏、有好人也有坏人、有刺激、有舒缓、有场景变化 等等。找一位故事专家协助你把产品故事说得生动活 泼，又能打动听众内心，并且教会团队所有的人都能 说这个故事。一个好的故事必定以显而易见的事实为依据。但是绝 对不要太多的事实，一般人常犯的毛病是有太多的信息急 于让听众知道，结果流于杂乱，缺乏重点，每位听众的内 心印象都不相同，这是不好的沟通。关键事实不要超过三 项，给听众他记得住的事实，又简单又重要，而且要确定 你的关键事实与你的产品故事密切不可分离。故事必须让很多重要人物重复地说，让听众的印象极 深刻，甚至让听众自发性地跟自己的朋友说。所以，故事 必须以几个重要的事实为根据，流露着感性。以人性为着 眼点，这样的故事必定让人一听难忘。有趣的是，最好的方法是别提重要的事，你要做的 是让听众自己从内心导引出你要的正确结论。比方说， 我们发布Visual C++时，最重要的事是让媒体、产业分析 家和大众了解：微软要重回C + +的市场，带着复仇的决心 法则53建伟大的软件应该有一个伟大的故事
351 要夺回盟主地位，我们决心扭转乾坤。但是我们在任何 行销信息中都没有提到这件事，甚至从产品故事中也完 全看不出丝毫端倪。这个道理很简单，我们如果到处向 人炫耀我们的产品有多伟大，既无法使人信服，反而惹 人生厌。相反地，我们让这个信息从听众自己内心推想 出来，在产品故事中提供足够的线索让人们导出这个结 论。你诱导听众自己想出来的事情，肯定比由你来告诉 他更有说服力。 下载
法则 54
Create a winning image 建立赢家形象 法则54建建立赢家形象
353 除了做出好产品，巩固市场地位，基于以下几个理由， 你还得建立赢家形象： 顾客需要对软件的认同感。软件这东西就像汽车之 类的商品一样，顾客需要对自己买的商品有认同感。 大概是因为顾客花在与软件相处的时间实在很长的 关系，他们希望自己被视为是“某软件的专家”或“某软件的玩家”，从这些名词可以看出来，顾客并 不是“买”软件，而是“采用某软件”（a d o p t），这 一点值得所有的软件从业人员深思再三。 顾客希望自己拥有的东西是大多数人渴望或羡慕的。 软件象征了顾客的身份地位或是他的“工作伙伴”（w i t h - i t - n e s s）。在这个计算机科技日新月异的时代， 顾客用的东西象征了他个人先进的程度，最新的东 西（不论是软件或硬件）表示是最流行、最尖端的， 追求最新最好是一种强烈的动机。如果你自认不受 流行的影响，请想一想你在挑选领带、西装，或购 买车子时，你内心浮现的欲望，你就知道流行实在 是无法抗拒的（请参考法则1 4）。 顾客知道厂商支持的重要性，不希望自己成为孤儿 使用者。顾客不是单纯地买软件，而是与你建立长
354
长久久的关系，他们知道决定使用你的软件之后， 会有很长的时间依赖你在新版本中的进步，他们要 投入大量的时间金钱去学习使用你的软件，他们不 希望买下软件之后厂商倒店，自己成为科技孤儿， 用也不是不用也不是。 对外界的沟通应该不是只有产品信息，还包括塑造人人称羡的赢家形象。嘘别忘了我们的法则5 3，别用直 接说明的方式，胜利者不会四处宣扬自己是胜利者，更不 会泄露自己对胜利的渴望，他就是每次都胜利！ 下载
结束语 结束语 结束语
356
如果一定要用一句话来做总结，我会说：软件开发造 就开发人员（Development develops developers）。也许罗曼·波兰斯基（Roman Polanski）在电影“唐 人街”（C h i n a t o w n）中的情节，正好为我表达了软件开发 的结论：剧中的主角杰克（由杰克·尼克逊饰演），经历 着相当大的内心挣扎，几乎崩溃，他的同伴总是用戏谑的 语气揶揄他：“撑着点吧，这是唐人街。”当然，软件开发是没有什么结束语的，你必须从本书 的开头再经历过一遍又一遍永难超生的轮回，一版又一版
亲爱的朋友，撑着点吧，这就是软件开发！
附 录
善用人才 附录 善用人才
359 对于智能财产的创造而言，最重要的当然是人类聪 明的脑袋，所以项目经理无不希望雇用最聪明的 人，好好照顾他们，让他们做出最聪明的软件，并且组 成所向无敌的优异团队，不断成长、创新，永远能给顾客最新最好的东西。 这些话听起来像是老生常谈，要做到可就是一门大学 问了。 下载
雇用聪明的人 雇用聪明的人 雇用聪明的人 雇用聪明的人
361 要去寻找并网罗聪明的人并不容易，但这方面的努力 是值得的，因为聪明的人才能生存。在软件的职业生涯中， 一个人必须承受许多负面的经验，像是没眼光的老板，错 误的设计决策，浪费时间去做没有用处的软件，分崩离析 的团队，进度严重落后的项目。这些对于任何一位软件工 程师而言都是很大也很痛苦的挑战，但这却是软件业的正 常现象；“聪明”（being smart）是他最有利的条件，靠 着聪明，他可以无视这些困难，甚至能解决团体危机，带 给他有满足有成就的软件开发生涯。当然，智能财产的创 造原料就是聪明才智，所以你必须寻找最聪明的人，网罗 他加入你的团队。 在你面试一位聪明的人才时，请注意以下几种人格特 质： 一、留心言语无法表现的各种智能象征所谓“大智若愚”，智能的展现方式会因人而异，有 时候，真正的聪明看起来却不怎么样，你必须留心每个人 的独特性，绝不要被“聪明”的刻板印象所束缚，注意观 察他自然流露的聪明，虽然或许不是你预料的那种形态。 仔细观察应征者的各方面反应，他如何表现自己的个 人特质？这一点透露出什么信息？从他的面部表情揣度他
362
内心的情感变化，把速度放慢点，分析他，判断一下他有 多少深度和潜力。练习观察人，你会发现很多隐性的信息， 比显性的表征更能让你正确判读眼前的陌生人。用你自己的感情和智力反应来衡量他，这位应征者是 否能挑战比你想得更多更深，探求更微妙的奥义，或是更 快地评估出正确的情势，他的要求是否超过你所能够提供 的？整个面谈的感觉如何？他是否有值得你学习的地方。面谈的时间并不长，彼此的角色是固定而有点僵化的。 应征者的反应是否如你预期？他是否有些言语行为令你感 到意外？他是否很自然地主动打破求职者的传统角色和面 谈的僵硬气氛？如果不然，你是否能打破彼此僵固的界线， 使他卸下求职者和面试者之间习惯使然的刻板形象？他看 来是否够弹性够开通，不会无谓地固执己见？有没有适当、 发自内心的求知欲，或只是因为害怕被淘汰而追求新知？ 如果应征者够聪明，那他大概会使面谈过程发生一些变化， 如果他有能力影响面谈过程，他也会有能力影响开发团队， 或是更复杂的事情。 二、用难题考验应征者你给他一个真实世界的问题，提供许多有关该问题的 背景信息，请他发表看法。当然应征者知道自己正在被接 雇用聪明的人
363 受考试，所以你可能会得到准备过的标准答案，然而，重 要的不是答案，而是看应征者推理的过程，可以从中发掘 他的工作与思考问题的态度（working style）。应征者是否很快地对问题作出错误的假设呢？几乎每 个人，在一开始的时候都是如此。要不然，应征者可能会 对考题要求更多的信息，从中界定问题的架构，然后试着 导出一个看起来面面俱到的答案。有些时候，我会故意给 一个绝对无法找出答案，但我好像确定有答案的问题，看 看应征者如何反应。聪明的人不会掉进自我辩白的陷阱， 因为无论他们的答案是什么都一定是错的，而会反过来问 我，究竟该怎么办。当然，大部分的人都太固执、太有防 卫心，而且就是不懂求助正是最好的办法。试试看如果由你主动提出帮助，应征者会如何反应， 有意思的是，会有无数种大异其趣的结果，我比较欣赏的 是先问问接受帮助是不是弱者的表现，再决定要不要接受 帮助的人。 三、试着教导他们谈谈你的专业领域，看看应征者的反应，他们是 不是能很快地吸收你所讲的东西？会不会询问更深入 的问题？接受它或是抗拒它？应征者是否能够提出更
364
好的看法？ 请记住你的目标是雇用你将来要赋予重任的人，将来要对他充分授权，他要替你管理许多技术，甚至决定你的 软件的一部分未来。应征者如何与权威形象（也就是担任 主试者的你现在的形象）建立关系，是他未来表现良窳的 重要关键。你要的人，必须能把主观的自我心态放在一边， 而专心去解决问题或学习新知。 四、排除审查人才的盲点我常见到在甄选人才时最大的错误，就是管理者过度 重视某一项技术。从征人广告上就可以看出这种倾向：“征求资深软件工程师，必须具备X程序语言技术及Y年以 上的经验”，诚然，拥有技术是考量的重点，但绝非一切， 更重要的是技术之外的东西；即使我们只看技术，这项技 术可能在未来一年之内就会淘汰，我们对技术的观察重点 是此人如何在相关的其他技术中，积累他今天对这个技术 的精熟。我要看他的生涯中，技术学习和积累的过程：他 在什么时候用过什么技术？他的学习历程是否足以证明他 能立刻掌握现在我们要用的技术？ 下载
适才适任 适才适任 适才适任
366
如果你已经雇用了一位聪明的人才，你一定希望他的 聪明才智能够充分发挥，为团队带来长期的益处。如果只 有你慧眼独具，知道他的潜力，而其他的团队成员却不太 能看出他的天赋，那么，他所能发挥的将比较有限。团队 成员的工作性格可以分为两大类：勇猛躁进者（r a c e h o r s e s） 和眼高手低者（o v e r r e a c h e r s）。同一个人在不同的群组或 不同的时间，可能会有截然不同的工作性格。身为管理者 的你，必须知道你的属下是那一种工作性格，他们的个人 生涯是怎么回事，你才能给予适当的辅导，让他们适才适 任，充分发挥。
勇猛躁进者喜欢快节奏勇猛躁进者是那种凡是学得很快、成长很快、表现成 功的人，所以显然他需要更宽广的驰骋空间，才能维持他 喜爱的快速。管理者的任务是肯定他的成功，提供他更多 的表现机会，让他担任的角色范围更宽广，导引他把目标 放在自我的超越上。如果管理者有眼不识千里马，或是打 压他的速度，勇猛躁进者就会欺负实力较弱的人，或是到 处寻觅，试着自行发掘更宽广的挥洒天地。在健全的团队 中是不应该有这种情形发生的。 适才适任
367 就像我那住在爱荷华的父亲常说的名言：“槽里的食 物若是不够，连猪都会互相残杀。”人呢，不是成长就是凋零，不可能原地不动。如果你 的团队推出新产品的周期愈来愈频繁，你的市场占有率愈 来愈高，顾客的满意度也逐年提升，或是任何其他有利的 结果，都表示你的团队正在成长，否则就是退步。对于团队来说，成长所带来的挑战是如何能配合团队 的成长而适当地补充人才，同时避免人数增加所带来的成 长障碍。通常团队人数快速增加的第一个问题是组员开始 烦躁不安，成功的喜悦很快被遗忘，人们开始谈论过去的 好日子。这种现象的发生，是因为管理者没有给组员适当 的挑战。为了改变这种烦躁不安，得来点刺激的，找出几个关 键人物想要做点什么、什么东西会对他们具有挑战性，问 问他们，这东西与我们的软件事业有什么重要关连？他们 希望有什么样的环境？他们梦想创造的软件是什么模样？ 然后，你授权给他们去做适当的东西。成长，代表新的投资，你可能要做全新的东西，让 组员扮演截然不同于以往的角色，不要迟疑，每个人都 需要成长，从最高领导人到最基层的人，成长都是不可
368
避免的，包括你和我。所以，你必须为组员的成长找寻 最适当的出路。
创造力的省思 创造力总是受限于防卫心理，而防卫心理如果 不过度的话，其实是健康的。在一个健康的团队中， 无论创造力怎么被大家高度重视，总是有些改变会受 到抗拒。即使是再小的改变，也得以追求进步为目标， 强化或深化原有的思想或行事方法，才可能行得通。 因此，改变必须架构在原有的基础或是人们已经接受 的事实上，才能顺利推行。可惜的是，即使改变只有 两步，第二步是建构在第一步之上，而不是某种事实， 都可能被最健康的团队所抗拒。真正具有创造性的改变，是要在一个具有自我 超越能力的环境中方能产生。这种环境，不只是接受 一般的改变，把改变视为正常，还要能自发地培养改 变的机会、欢迎改变的来临，而且借着改变把自己推 向一种全新的动态境界。自我超越的团队会把革命性 的剧烈改变当成巅覆过去的思维，以全新面目再出发 的契机。健康的团队不等于富有创造力的团队，团队 适才适任
369 可能很健康但创造力略嫌不足，这并不是最理想的情 况；理想的团队应该充满创造的活力，随时能有新的 想法，要很有勇气，敢于摸索从来没有人涉足的领域， 又有能力取得丰硕的成果。讽刺的是，愈健康的团队，愈以过去的优秀工 作成绩为傲，愈无法接受革命性的改变。这是任何领 域中，整体性表现最好的团队所共有的通病，值得我 们省思。
眼高手低者企图大有作为有些时候，有些组员所希望分配到的工作，事实上超 过他的能力。这种“贪多”的心理可能起源于他个人早期 的工作经验，也许那时候他对工作的渴望没有得到适当的 满足，结果这种过去未满足的心理需求转移到现在的工作 中，造成病态性的好高骛远，眼高手低：即使现在已经是 个完全能充分发挥、各展所长的环境，他还是需要更多的 授权、做更大范围的事、企图扮演更多的角色，永远不能 满足内心的匮乏感，因为他潜意识地极力避免在团队中没 事干。这种病态的“贪多”，就是想要的超过实际所需要 的，而且似乎永远难以满足。由于团队中会自然地设法避
370
免不必要的浪费，其他的成员不会让这种眼高手低者过度 扩张。即使是很优秀的组员，在刚开始学习成熟时也会有这 种情形：他可能分配到一个小范围的工作，但并不明白工 作范围小些其实并不妨碍自己的表现机会，于是他可能抱 怨管理者判断错误，把我大才小用，埋没我的天份。如果 他懂得细心照顾自己的生涯，他就会有更正面的态度去面 对这件事，藉此机会多学习。很可惜，太多优秀人才在这 一关跨不过去，要不就是骤然挂冠求去，要不就是管理者 真的给他太多无法消化的工作，最后的结果都是毁了一个 人在组织里求发展的机会。管理者应该协助属下安然渡过 这一关，这对他个人以及整体团队都是很有利的。 发掘真正的目标你必须用心发掘眼高手低者内心真正的目标。眼高手 低者有一个明显的特征，就是对已经过大的目标优柔寡断， 而且常常是互相对立的两个目标（因为他鱼与熊掌都想兼 得）；这一点很重要，这是你以下的工作的基础。大部分的时候，眼高手低者渴望有一种自我形象，他 想要利用工作内容或价值来标榜出也许超过字面上的意 义。你必须试着发掘出来，他真正想要的或是企图表现的 适才适任
371 是什么样的自我形象。方法很简单，问他几个不错的问题 就行了：这个目标对你而言有什么意义？你觉得这个意义 适当吗？你认为自己有多大的把握能够完成目标？如果你 顺利完成了目标，你希望你的成果可以如何运用？然后， 检视你自己的感觉：这个目标在我看来适当吗？别人的看 法大概是会怎样？谁是最佳人选？如果选择由某人来担 任，是为某人，还是为团队，还是为我自己？ 探求他对软件开发生涯的看法现在你已经了解他的目标了，你现在要决定这个目标 是否超过他个人的能力，或是与团队的目标不合。没有问 题当然最好，但如果二者有差距，你得找出真正的原因。 为什么他对自己的能力有过高的自信？这是偶然的现象或 是此人向来的习惯？你要知道，组员对于别人认定他“能 力不够、做不来”这类的事情是极度敏感的，你必须让他 相信你是站在他这一边，帮助他达成远大志向的人，而不 是阻碍他的人。你必须了解他个人对软件开发生涯的看法，藉助这些 来探索他企图有某种作为的真正理由。也许连他自己都不 知道二者之间的关连，但他对软件开发生涯的看法，绝对 会影响他今天的企图，你得用敏锐的洞察力去发掘真相。
372
方法一样简单，用一些不带价值判断、轻松又简单的问题 直接问他就行。等你相当了解他的看法，了解他如何从自 己对软件开发生涯的期望，导出今天的（事实上过度的） 志向。你来想想看，这种心理机转模式有没有违背团队的 目标？有没有与团队的价值观冲突？他个人的志向是否与 团队的终极目标不谋而合？你的工作是导引他将个人的志向融入团队目标，辅导 他懂得配合自己的能力定出合宜的目标。 找最适合的工作给他现在，你已经完全了解他想要什么，以及他为什么想 要这些；然后暂时把这些信息放在一边，想想看这个人最 适合担任什么角色，找出三件事是他做得比任何人都棒的， 如果让他做这些工作，他可以成为最有成就的人，请团队 的其他成员告诉你他们对此人的期望，如果他本人同意自 己确实对这三件事最为擅长，设法把他的志向扭转成大家 的期望。至少在理论上，加强一个人的长处，比纠正一个人的 缺点是要容易得多。但是身为领导人的你，必须有勇气丢 掉一切对工作角色分配的假设，这绝不像听起来这么容易， 很多管理者都失败过很多次。我认为只有最崇高最卓越的 适才适任
373 领导者才能做到这一点：调整组织，让每一个人的天赋才 干都能淋漓尽致地展现。
新天地 在我带过的团队中，就有这么一位天资聪颖的 女性。她曾经在别的公司有五年的工作经验，当过极 成功的项目经理，由于我们对她过去的经历没有直接 的了解，所以并不太知道她的管理风格和能力。她表 示想当更高的主管，也就是说，她想以“管理者”为 终生职志。慢慢地，我们看到她不可思议的能力。她能够 解决任何人际问题的疑难杂症，不论任何冲突或障碍， 她都能建议最好的方法，也就是说，她有分析问题、 平息争议的天才，愈来愈多的人找她帮忙提供指导和 建议，或请她剖析复杂的情势。这些都是自然发生的， 我并没有使力促成。我仔细观察并思考此一现象，并且与她本人讨 论，我愈来愈觉得，一个健康的团队随时需要像她这 样的人，立即而有效地针砭团队中的疑难杂症。看起 来，有个人专职减少摩擦、平息纷争、提升效能是个
374
好主意，对团队的益处实在很大。如果让她当管理主 任（s u p e r v i s o r）似乎并不适合，她不必靠监督别人 来展现她的才华，她只要大家对她的支持就够了。虽然我们并没有谈出确定的细节，我和她已有 共识，决定成立一个新的头衔及工作内容来配合她的 专长，头衔尚未决定，工作内容则是“效能分析及工 作顾问”。她同时会参加功能特色小组的横向组织， 她的主要工作是解决任何工作效能的问题；她在“效 能分析及工作顾问”的小组中担任领袖，负责建立起 这个创新的工作领域，发展适当的工作规则，训练她 的助手，为公司培养像她一样的人才，为这个全新的 角色奠定日后发展的基础。为优秀的人才创造适当的职位，可以为组织带 来莫大的利益，这是一种“创意管理”。当你发现一位组员的特殊天份，鼓励他充分发挥时， 大部分的人都会表现出有点迟疑的态度。至少我个人和我 的几个亲密的工作伙伴多少也会有这种情形。我想可能是 因为天赋是个人珍视的东西，自己内心容许引以为傲，但 对外则不免戒备恐惧。我们觉得自己因为拥有这些天赋而 与众不同，但我们却害怕把这些自我评价拿出来公开检验， 适才适任
375 因为，这有点风险─万一失败了，那我不是顶没面子， 对自己的价值感可能受到打击。
我也需要鼓励 不久以前，我的主管丹尼斯·吉伯特（ D e n i s Gilbert）帮助我克服了这种心理障碍。过去很多年来， 我常常以软件开发为主题，在世界各地发表自由即兴 式（f r e e w h e e l i n g）的演讲，评价很不错，我自己也 很喜欢，不只是因为这代表对我个人的肯定，也是我 对社会上所有栽培过我的人的一种反馈（演说的内容 就是本书的前身）。丹尼斯知道我的演说颇为成功，很多软件开发 人员都因此获益匪浅，但是，那是在微软之外呀，我 不敢在自己的公司里演讲，要我在自己人面前讲出种 种糗事和内心挣扎，实在太丢人，而且微软内部高手 云集我是再清楚不过，万一讲不好，还引起争议怎么 办？我相信让同事分享我的经验是对大家的帮助，但 我很害怕自己被公开评估，那怕这是我最得意的一项 才华，我就是不想冒着被拒绝的危险。 后来丹尼斯不断鼓励我，给我信心，我的演说
376
真的很精彩，而且我的经验座谈会帮助很多人（当然 包括微软内部的同事）克服工作上的困难，这是功德 无量的（丹尼斯如今大概后悔了，放我去写这本书， 而置Visual C++的工作暂时不顾）。畏惧和自我设限往往会阻碍一个人的发展，这 是个人内在的障碍，而不是来自外界的压力。在充分 授权的环境中，虽然这不是管理者造成的障碍，但是 管理者应该协助属下突破自我设限的障碍。人们对自己的天赋有极高的敏感性，如果有主管赏识 他的天赋，给他机会，鼓励他表现，他会做得比想象中更 好、更卖力。你必须时时鼓励他，给他挑战，支持他的冒 险行动，在他表现不错时，适时赞美他。刚开始时，他会 低估自己的潜力，主管必须告诉他，他能做到的，他是这 方面的天才，主管深信他一定可以表现得令人赞赏，主管 可以用各式各样的法子设法让他明白，没有什么事情比他 所拥有的天赋更重要，其他的困难都是可以被克服的。有很多实例可以证明，主管对属下的赏识和肯定，绝 对是一本万利的。人们通常在受到主管的慧眼赏识时，都 会感到惊喜，会更愿意付出，说是“士为知己者死”当然 是太夸张，但他一定能发挥出更大的潜力；他原本就是在 适才适任
377 做自己擅长的事情，现在表现更好，并且对公司更忠诚， 以回报主管的知遇之恩。对一位专业人员来说，有人能够了解他、重用他，有 人赏识他的才干，就是最宝贵的报酬。一位用心的主管会懂得找出与属下的内心世界沟通的 好方法，这是一项困难的挑战，但一定是值得的，只是回 报方式可能很难想象。用心的主管会花时间了解属下，也 许半小时的谈话却花掉两个小时的事前准备，用心思考你 要告诉他什么信息，注意信息是否能确实而清晰地传达， 不要使他误会、或是引得他的胡思乱想。不要企图一次就告诉他太多，但每一次的信息都要很 清楚，运用你的沟通才能，这是主管的重要任务，清楚的 沟通是双方都需要的。你可以对自己的信息“再确定”，这个动作能够让属 下知道，你不是随便说说，你是真的肯定他的天赋，现在 你是真的授权给他了。 不耻下问当你遇到问题，尽量向周围的人讨教。虽然你自己也 很不错，但一定有别人在某方面强过你，能够支持你。所 以，不要做骄傲的笨蛋，开口求援才是正确的法门。你不
378
是单兵作战，在你身边有一大群优秀的人才可以帮助你。 不必害怕请教别人会使你暴露弱点，相反地，让别人知道 你也有弱点，反而使你更受欢迎，属下更愿意对你忠诚。 设定短期目标给你的组员一个短期目标来展现他的能力，证明他的 进步，告诉他你会给他最好的机会和支持，而这是互相的， 你也希望他表现优异，如果他表示宁可不要这个互惠协议， 那就暂时不谈了；你可以告诉他这是个很不错的机会，在 全部的人中，你相信他最适合担任这项工作，而你十分乐 意提供属下最好的，但前提是属下得有意愿表现才行。现 在由他来选择，如果他不喜欢，你当然只好把机会让给别 的组员。 建立长期计划分派新任务给一个组员之后，他一定希望对这个任务 有比较长远的概念，或是自己的长期发展方向等，他也会 想知道自己应该如何掌握什么原则。也许他不好意思问你， 但这是你身为管理者的重要工作，别偷懒！ 建立评核制度你如何得知个别组员在团队中的表现孰优孰劣？团队 似乎要不就全体成功，要不就全体失败，你如何断定单一 下载
个体对团队的贡献（或破坏）程度？ 微软团队·成 功 秘 诀适才适任
379
软件开发工作就像现在电子游戏（video game）一般， 有很多关（l e v e l），难度愈来愈高。每一个团队成员都在 同一关，希望能有成就而获得晋级，每一关都有不同的挑 战，一开始时大家都会迷惑，觉得好困难，然后开始奋战， 甚至几乎发狂。好不容易到了下一关，游戏规则又不一样 了，先前的发展出来的合作方式在这一关未必有效，搞不 好还有害。一关又一关，团队终于学会如何面对新环境， 而且发展出真正有效的合作模式。评核员工的团队表现，最大的要点是先决定他们到底 在第几关，容易的还是困难的（团队的人数、每个人应有 的表现水准、这一组人的任务性质），然后再来决定个别 成员的表现是优于预期，或是不如预期。这是评核员工绩 效的基本原则。软件开发团队也像电子游戏一般，看你有多少“生命 点数”或“火力”，愈好的先天条件当然愈容易打赢，有 时候输掉实在是资源太少的非战之罪，主管在给属下打分 时也别忘了这一点。评核，是你重新检讨对属下的期望的时候，看看你有 没有忽略谁的天赋、有没有人需要调整脚步、短期的目标
380
是否相对太高或太低。直接而坦白的沟通是最好的方式， 虽然也是最难的方式，组员也需要有此机会和你一起检视 一下，自己所处的挑战是否需要调整，这一关要不要重打， 或是跳到那一关；晋级速度太快并不是好事，也许自己在 这一关中还需要复习，或是前一关有东西还没学全。在每一关中的成熟过程每个人都大不相同，有人是天 才早熟型，有人是大器晚成型。每个人都会自己走出自己 的路，走过独特的成熟历程，终于绽放出属于自己的色彩 光芒。基本上，每一关都是团队的合作，大家互相扶持， 才能跃高到另一个层次，然后看得更宽、更广、更远，个 人的影响力更大，角色更复杂。最后，培养出卓越的领导 能力（可不是监督能力），或是更高的工作效能，而终于 成为公司最宝贵的资产。 下载

返回书籍页