Part 第一篇 布局时期
One
布局时期 15很多探讨软件开发的书籍都假设自己存在于理想的状 态下：团队本来就应该非常专心且克尽职责地完成 工作，并完全掌握任务的本质；他们收集得到完整的需求 情报，建立设计规格，并导引软件原型（p r o t o t y p e）一次 又一次的蜕变；他们请求使用者参与，使用者便会全力配合，而且非常认真地与开发团队共同完成深入的需求分析。 所有的事情都是那么完美顺利。很不幸地，理想状态是不 存在于现实世界的，在真正的软件开发项目中，您可能看 不到一丝一毫属于完美顺利的景象，而且看到的恐怕只有 一堆的问题。不只是问题，还有可怕的挑战。优秀的开发团队在布 局时期必须做的事情多如牛毛、广如大海，我们大略分为 五个范畴：组织、竞争、顾客、设计、开发。布局时期的 工作是多维的，而且必须在每一个细节中都能综合、兼顾 所有预期的结果。 下载
组织开发团队 组织开发团队 组织开发团队 组织开发团队 17我所谓的组织，是指集结适当的人选分别担任下列角 色并参与设计：项目管理（Program Management）─负责制定开 发日程、与外界沟通、寻求技术方面的后勤支持。 软件品保（Quality Assurance）─测试与评估软 件的品质。 程序开发（Development）─写程序、抓错虫。 产品管理与行销（Product Management/Marketing）─负责整个产品的形象定位，传递正确的产品信息 给顾客，以及产品的上市发表、与传播界的沟通。 系统文件与使用者教育( D o c u m e n t a t i o n / U s e r E d u c a t i o n)─负责以文字表达正确的产品使用方法。(这里所谈到的设计，是指软件产品的设计，不是指 写程序或程序设计。读者耳熟能详的“程序设计师”， 译自P r o g r a m m e r一词，虽然这种工作有相当的设计成 分，但这种设计比较不是艺术性的，而是工程性的。 原 作 者 甚 至 鲜 少 使 用 Programmer 一 词 ， 而 以 D e v e l o p e r表达。概略地说，软件产品设计是厘定目 标，事先定义出软件要做到的功能，本产品预定要满 足什么需求，目标顾客是什么样的，主要的硬件或操
18作系统环境等等。—译者注)您不一定要将自己的团队成员划分成这五种角色（虽 然我认为这是最有效率的做法），但务必要确定这些工作 都有适当的负责人选。请注意每一种角色都有参与设计， 如此每一位成员对项目都有整体性且清楚的认知，使每一 位成员的目标是一致的。如果您的开发团队无法合作无间，对于目标老是有不 同的意见。那么，首先要做的是找出不团结的真正原因。
品保人员（QA）是少数民族？ 如果品保人员认为他的工作是测试程序，而开发人员 认为他的工作是写程序给品保人员测试，那就得小心了，这是一个警讯。这种情况会造成开发人员和品保人员之间 的疏离，开发人员的优越感会使品保人员感觉自己是被歧 视的少数民族，当然会影响到软件的品质。品保人员的最 主要功能，是不断鉴定和评估产品的现状，是否在品质上 和功能上确实遵行产品目标，而让其他的人员专心投入他 的职务。品保人员的评估工作是一项整体性、持续性软件开发 活动中的一环，而不是偶尔来点缀一下。好的评估报告在 组织开发团队 19本质上应有客观的分析和衡量标准，如此才能导引软件产 品符合现实的需要。这种导引的重要性是不容轻忽的。因 为在开发过程中，开发人员可能因为一些偶发的小事或某 种无关的灵感而不知不觉地偏离了现实的需要，暂时忘记 了什么才是产品最该有的功能。品保人员的职责就是为软 件的品质把关，以现实、客观而市场导向的眼光，不断地 检视软件产品。
谁来设计产品？如果项目经理、产品经理、开发人员不断争论谁有权 设计产品或是各执一词，这是一个愚蠢的开发团队，只会 关心自己的权威；然而，真正的权威是来自于对现实状况 的精确掌握。产品设计的目的是将最好的想法列为产品的 基础，每一位工作人员都应该为此努力。至于什么是最好 的想法，应该在项目真正开始之前就通过实地检验。市场 调查是很好的方法，不需要太多的时间或成本，就可迅速 平息大家对于产品设计的争论。我们在下文中会讨论如何 增进彼此之间了解，这也是解决方法之一，精确缜密的思 考通常能使问题柳暗花明。
20
权力争夺战会迫使人们心胸狭窄， 互相竞争而不合作。
产品设计的争论是权力的争夺战，会使人们心胸狭窄， 互相竞争而不合作。可能有人主张产品在这项功能上有所 不足，结果焦点变成了功能而不是产品本身。一位有智能 的领导人应该将争论视为组织出现问题的症状，而去发掘 问题的根源，这比仲裁这项争论要有用得多。在这方面我 的经验与传统所谓的智能刚好相反，我认为用职权裁定谁 有产品设计权是毫无用处的，虽然改变正式的产品设计权 或许有点帮助。老实说，谈这个谁来掌权、谁来负责的主题并不有趣， 而且解决这个问题非常浪费时间。组织健全的团队是适才 适任，各司其职的；此外，每个人的除了各自专司的角色 之外，还担任一般的角色（ generic role），这一点也受到 管理者的肯定，因此角色与能力之间的关系能够取得和谐。 一般角色会使团队更能融为一体，互相支持。团队是一种 平衡的生态，人与人之间的职权界线像是和睦邻人的关系， 组织开发团队 21于是，对每一位单独个体都有足够的尊重，整体的效能也 达到最佳化。这种平衡的组织生态是自然生成的，强制性 的外力干预只会造成负面的影响。如果团队成员彼此的关 系无法做到亦邻亦友的和谐，领导人必须分析原因。通常 如果利益分配不公平，或有多人争夺同一项利益，或是提 供的报酬不够齐全，不平衡就会发生；有时候管理方面欠 缺弹性也会造成资源必须用人为的方式重新分配，效果不 一定会好。在任何项目开始之前，项目经理必须弄清楚团队中有 哪些地方需要特别的注意，尤其是团队的变动性（ t e a m d y n a m i c s）。就像团队中的每一份子必须清楚要做什么工 作、有什么资源、目标在哪里，项目经理也必须设计自己 所要带领的团队该有什么样子，自己该如何“激活”这个 团队。因此，我们导出了法则1。 下载
法则 1
Establish a shared vision 建立一个共同的目标 法则1建建立一个共同的目标 23乍看之下，这何需赘述，但这却是相当困难的事。团 队中每一位成员都必须非常清楚我们要做什么、成品会是 什么模样、基本的产品策略是什么、什么时候必须完成。 凡是与共同目标相冲突的看法都必须转化成一致，而不是 把它消音。和谐的共识是绝对必要的，否则软件不可能做 得好，很多事会复杂化而难以收拾。建立共同目标的方法从独裁式的极端到放羊式的极 端，中间有无数不同的方法，但在我们讨论这些方法之前， 得先说明何谓目标，毕竟目标的建立已是现今衡量领导能 力的指针之一。简单地说，目标是共同的希望，对未来的 事情所描绘出来的景象。目标一词常被政治家或经济学家使用。任何一位好的 领导者，都有责任为其追随者创造目标。以我的看法，领 导者对其组员心理状态的掌握与认知，是目标的开始，然 后领导者对于组员之间复杂的心理状态认知、修正、建立 共同点，融入领导者的个人特质，使得领导者与组员、组 员彼此之间的防卫界线逐渐消失。有共同的目标才能建立 团队的认同感和归属感，大家会觉得我们是一个整体，这 是团队气氛的心理基础。
24
团队的认同感和归属感，能消除个 体的自利行为。
通常，共同的经验可以作为领导者的感情移入，领导 者用各种不同的形式告诉追随者：我们过去是那样，我们 现在是这样，而我们将来会是什么样。不论是否有共同的历史，“成功的领导者”能在团队 中营造共鸣，而“群众煽动者”则不能。当组员对领导者 意见相左时，最常见的反应不是直接反对，而是：“是啊， 我们也是这么认为，但我们该怎么办呢？”这时必要的努 力、鼓励和妥协都可能发生。领导者应该自问：“如果换 他们来领导，他们会怎么做？我该如何将他们复杂的情绪 转化成行动力？”这些问题的答案能帮助领导人解决大部 分的问题。有远见的领导者会构思一个美好的前景，需要大家共 同努力创造；而群众煽动者则是对现状不满，意欲去之而 后快。有远见的领导者会带领不同心态的人朝共同的目标 努力，有时为了长远之计而放弃近利；而群众煽动者则是 下载
逞一时之快、急功近利的人。 微软团队·成 功 秘 诀法则1建建立一个共同的目标 25
领导能力与目标是来自领导者与组员之间的心理共鸣， 若非如此，目标会流于虚幻，也无法带动团队迈向成功。
共同的目标
26微软程序语言部门的故事 1 9 9 2年的微软程序语言部门，情况实在不乐观。 那年的四月，微软发表了 C 7。C 7花了超过两年的时 间开发，经历无数次的进度落后和品质恶化，似乎是 一场永无休止的死亡进行曲。而微软的竞争对手已经 抓住这个机会，在Wi n d o w s版的C和C + +上面获得很好 的评价。C 7在很多地方都不足以与之竞争，虽然它有 精美的包装、动人的价格、优异的类函数库( c l a s sl i b r a r y）M F C 1 . 0，和微软素以见长的最佳化执行码编 译器(c o m p i l e r)。这些优点只能使微软勉强维持不被淘 汰出局，但很显然下一版非得大幅扭转劣势不可。微软的C / C + +开发团队经历了好几年的流年不 利，光是项目经理就换了三次。丹尼斯·吉伯特（Denis Gilbert）是新任的资深开发部经理，而我是新 任的行销兼使用者教育部经理；虽然我们都从未领导 过这么庞大的团队（超过两百人），但我俩都充满斗 志，企图有一番作为。杰夫·赫伯（Jeff Harbers）管 理A F X小组，这个小组集结了微软的精英工程师，负 责为C/C++的产品提供“所见即所得”（What You See 法则1建建立一个共同的目标 27Is What You Get, WYSIWYG）的类函数库工具。他 们的经验极为宝贵，虽然两组人马的文化差异刚开始 难免造成点小摩擦。程序语言部门是微软中最古老的部门，第一个 产品就是比尔·盖茨与保罗·爱伦（ Paul Allen）合 写的 Basic直译器。当微软进入操作系统与应用软件 领域之后，程序语言的重要性相对降低许多。微软的 重心转移之后，尽管微软的程序语言产品有占先的优 势，但开发者的辅助工具方面则跟不上竞争者了。在1 9 9 2年，大部分的微软高层主管都希望重新 振作这个部门，也许是被忽略得太久了吧，我无意批 评他们，但我猜多少也是微软扩张得太快太广所致， 无论如何，这使得我和丹尼斯肩负着更重大的责任， 更强烈地希望把事情做好。对我们的压力与期望不只来自微软高层，还有 来自专业杂志的负面评价和使用者的责难，甚至微软 内部同仁也轻视这个部门。大家都说我们缺乏目标， 是一群笨蛋，要不然就笑我们 C 7品质不良，完成日 期老是拖延。就连比尔·盖茨的电子邮件也会带上一 句─程序语言部门是全微软最笨的一群人。这一切
28不只是没面子而已，我们实在该做点什么。回想过去这段时日的发展和本部门堆积如山的 工作，我们（主要是丹尼斯）发现本部门一直被以下 的几个错误所蒙蔽： 我们无法完成任务，因为我们没有足够的能力。 即使我们每件事都如期完成，也一样会失去市场。 我们没办法叫媒体不批评，或叫使用者不要抱怨。 我们的人力素质和数量可以做一个项目，最多两个。 跨出重要的第一步丹尼斯征询过所有的经理人的意见，要求他们 将各项项目作个评比，发现每个人都认为Caviar 是最 重要的项目。Caviar 就是Visual C++ for Windows 3.1 的计划代号。我们的结论是只要将C a v i a r做得好，又 能在适当时机推出，就是打赢了一场重要战役，甚至 会带来最后的胜利。第二重要的项目是B a r r a u d a，基 本上就是Caviar 的Windows NT 版。我们必须立刻加强这两个项目，幸运的话两个 都能完成，但若做不到，至少要集中火力在 C a v i a r。 我们把所有的资源都集中在 C a v i a r ，期望它赢得 Windows 3.1的市场胜利。 法则1建建立一个共同的目标 29于是我们把手上大大小小的项目逐一列出，要 大家票选自己认为最重要的项目，以期形成初步的共 识。但丹尼斯并未加强这个共识，他甚至并未再邀请 组员发表意见，因为他已做了决定。我们明白C a v i a r 一定要赢，虽然希望渺茫，大家都愿意尽可能贡献自 己的力量。丹尼斯召来了全体组员，向大家说明我们要如 何打败竞争对手。我们必须将不重要的项目放弃，并 且重新整编改组。这是一个好的开始，但只不过是开始而已，其 他重要的条件诸如团体共识、决断能力、清楚的目标、 组员心理上的满足感等都还差得远。丹尼斯注意到整 个团队都为无法打败竞争对手而感到愤怒而沮丧。他 自己也有一股驱动力，想把这一切好好整顿。他感受 到只要有人把胜利的希望带进团队，全体组员都会发 誓：“我们要赢！”Caviar 会成为 Windows 3.1 的 Visual C++。 丹尼斯的决心点燃了整个团队，Caviar非赢不可，虽然大家对于部分项目必须牺牲放弃不免情绪反弹。 显然丹尼斯已经创造出成功的必要条件，但他还缺少
30充分条件。 问题接踵而至这群人从来不曾形成团队。我们也没有跨部门 的协调组织，而且当初所期望的充分授权管理方式（consensus-style management)还处于很幼稚可笑的阶 段。我们没有跨版本的产品计划，也没有详尽的技 术规划，过去也从来没有成功的经验作为开发程序 的参考。几乎每个人都高估了我们如期完成的能力， 即使对于我们刚刚设立的新目标也是如此。但无论 如何，弃车保帅的策略和改组行动确实为部门注入 了新的动力，但结果还未见分晓，我们可不知道是 否能一举奏效。几个月过去了，事实告诉我C a v i a r实在不太可能 如期完成，事实也告诉我非得如期完成不可。我们已 决定在 1 9 9 3年的Software Development’93 We s t展览 上发布 Visual C++ 1.0，同时铺货在各种通路上，要 让竞争者来不及反应。这是我们成功的关键，也是我 们士气和信心的关键，最后的期限是1 9 9 3年 2月2 2日。 然而，这时的开发工作只能说是一团糟。我们 仍不断添加零星的功能；好的一面是我们还在不断提 法则1建建立一个共同的目标 31升系统效能，坏的一面是几乎无法将模块建构成完整 的产品，甚至无法每天产生一次完整的执行档。开发 人员把软件品保当成是黑箱作业，每天丢一份雏型给 品保就继续埋头苦干了，根本不管品保人员为时数周 的测试。大约在推出前的四个月，我受到了赫伯的严重 警告，他很坦诚地告诉我，如果我真要做好这个产品， 必须改变一些做法。他使我了解到除了我自己，没有 人能阻碍我做该做的事。我明知道该做些什么，却往 往因为某些因素（大多是个人的因素）而退缩不前。 我现在是行销经理，虽然过去在微软的 R & D部门曾 经领导过1 5个项目，但从未加入过 C++的团队，如 果我再不好好表现，我大概就是第三个卷铺盖走人的 经理了。赫伯的忠告使我明白我太消沉了。我可以清楚 看到事情是如何一塌糊涂，我有责任改变它，而不是 逃避它。赫伯向来以毫不遮掩、实话实说闻名，而且 总是能够一语中的。我终于被他的话点醒了。于是我和丹尼斯讨论了眼前的困境。我们其实 无法确定该怎么做才对，但都明白非得有一番彻底的
32改变不可。当天下午我们便召开了一次小组会议，这 件事本身就极不寻常，抓这么多人过来只为宣布一件 小事？是的，我们要在组员的心理上制造一个转折 点。我们为了求胜已经尽可能减轻不必要的负担， 而我们仍然在市场上失利，在同类产品评比中输给对 手，我们已经受够了失败的滋味─总是在进度严重 落后的情况之下做出平庸的产品─而我们明明知道 自己可以做得更好。只要我们同心协力，我们一定可 以在期限内做出最优良的产品；没有人能阻挡我们， 只除了我们自己（当然也有些不可知的因素）。我愈 思考眼前的处境，以及它对微软公司、对我们的意义， 就愈觉得斗志高昂。我们有士气、充满活力，一切成功团队所需的 条件我们都有了，只除了共同的目标。我个人有个想 法：我们不但要追上日程，也要做出最伟大的产品 Visual C++ 1.0，要令所有的人都刮目相看，尤其是 那些一向对我们避之惟恐不及的营销人员。我们要扭 转战局，让对手俯首称臣。 我的求胜心很强，但矛盾的是，我却不敢告诉 法则1建建立一个共同的目标 33我的同事。没有人阻止我说出心中的想法，倒也没有 人要求我说，这种时候个人的感觉似乎已经不重要。 我害怕自己被嘲笑：“他是谁啊？新来的嘛，这搞行 销的家伙想教我们写软件？”然而我再也无法沉默，再不做点事情我在微软 就混不下去了。那天下午我终于告诉全体组员我的感 受，也问问他们的感受：“我受够了挫败，你们也是 吧？作为全微软最差劲的项目经理，我恨透了，外界 的批评令我觉得丢脸，你们也是吧？Visual C++是最 伟大、最值得骄傲的产品，你们难道不这么认为吗？ 我知道我们可以如期完成它，而且用它来给对手一个 迎头痛击，不只我一个人这么想吧？我们将创造微软 的明日世界，我们会大有作为的，不是吗？”结果，几乎每个人都有类似的感受，纷纷发言 为我补充。我终于整合了共同的目标：我们要准时完 成 Visual C++ 1.0，没有什么事情比它更重要。所有 的资源都投注在这个清楚明白的目标；不必要的枝节 可以牺牲，其他的项目（即使是N T版的Visual C++） 都可以暂缓，全部的人、钱、机器，都押这一注，而 且得立即行动！
34会后我们紧接着要求每一个工作小组至少提出 五项具体务实的建议，只要对 2月2 2日完成 Vi s u a l C++ 有帮助的想法，请大家务必提出来。我获得了 许多宝贵的建议，本书的第三篇“推出日期”中，就 有许多很棒的观念是来自这次的建议。而此时此刻， 大家的心理上和情绪上都有完成目标的强烈的决心， 因此会主动告诉管理者该做什么，然后确实去做。而 我和丹尼斯则负责提供工作环境，凡是对目标有帮助 的，我们都全力支持，甚至包括一些背离传统却实际 可行的构想，这就是员工领导的管理风格( m a n a g e - ment-led style)吧。 我个人觉得，在任何项目的执行过程中总有些“关键时刻”，使大家在心理上和情绪上因此凝聚成对 目标的共识，对共同的目标产生共鸣，对事情的优先 级形成清楚的认知。我无意夸口Visual C++的团队有 多伟大或领导多卓越，我的目的是指出在大家一片士 气低落时促成大家态度转变的关键因素。首先，有人察觉到了团队发生问题，并勇敢地 指出来。赫伯以他多年丰富的经验，独特的真知灼见， 看出了我们在胡乱挣扎；虽然我们的做法基本上是正 法则1建建立一个共同的目标 35确的，但却不够。赫伯没有任何义务帮助我们，但他 仍然不吝直言。赫伯在这件事情上，完全克服了人性的弱点。 一般人很少会主动帮助并未求助的人，尤其是软件开 发这种智能财产的工作。赫伯首先必须对自己的看法 有足够的信心，并且在心理上要冒着很大的风险；然 后，赫伯确信自己的行动对事情有所助益；最后，他 必须不介意是否失去我的友谊。为了帮助整个团队， 他必须冒着得罪我或整个团队的风险。他的忠言刺伤了我的自尊心，激起了我的防卫 心理，并且刚开始时不断和他争辩。他说我搞砸了一 切，我应该彻底改变做法。我用尽自己的脑力和心力 反击他的“帮助”。而他则以关怀和冷静的事实击退 我的不理性。直到凌晨四点，我还特别记得他冷冷地 说：“别管我的语气，别管是谁告诉你这些，忘掉你 的骄傲，只要你听得进去我的话。”渐渐地，我想我可以接受他的劝告了，我的情 绪平息，思考也变得更有建设性。我开始觉得不必因 为接受他的建议就感到自己不如他，我太骄傲了。想 通了这一点，我的创造力和旺盛的活力又恢复了。
36这个事件的教训是，我们应该坦诚将事实告诉 那些当局者迷的人，我们应该告诉他们问题在哪里、 他们的潜力在哪里。如果你的心胸够开阔，当你犯错 时就会有人及时纠正你，甚至提供更有用的建议。如 果你的忠告被曲解成太骄傲或自以为什么都知道，或 者“你是谁？凭什么批评我”，别管他们的防卫心态， 直接告诉他们的情绪正在混淆事实。如果他们说：“什么，你以为只有你懂软件”你只要在被拒绝前简 单告诉他们，你只不过提供一些想法，又没有恶意， 何不试着了解呢？单纯的沟通的效果可能会昙花一现，你必须真 的以彼此的情谊为赌注（有时甚至冒着失去工作的危 险）来讲出实话，如果不是这样，可能很难突破对方 的心防，而打从心底接受你的建议。这种实话实说需要高度的技巧与智能，但却是 建立共同目标的基础之一。经过不断发掘出最真实的 情况，才是鼓舞团队士气的金钥匙。然而，真话也得有人听才行。事实是最残酷， 实话最难听，但不论是你自己发现或别人告诉你，你 终究得接受它；缺乏自信心或安全感的人比较难接受 法则1建建立一个共同的目标 37事实，而抗拒事实或情绪反应会使人丧失创造力，或 是发生错误的直觉。这是两个阶段的过程，你不只要学会接受事实， 还得学着传达真实的信息。传播事实的最佳媒介是情 感，这是你用之不竭的，多付出你的关怀和好意，让 事实被正面地接受。即使你被拒绝，你也可以达到鼓 舞对方的目的。我们终能如期完成 C++的开发，而且它确实是 一件伟大的作品；微软的行销部门也全力支持我们。 我们终于打败竞争者，虽然压力和威胁还在，但我们 毕竟扭转劣势，赢了这一仗。往后的日子里，我们逐渐建立了版本控制的规 则，我们可以每隔固定的期间发表新的版本，以及共 享版本（请参阅法则3：建立开发多版本的技术规划）， 但最艰苦又最令人难忘的、团队精神最炽热的，还是 那第1版的经验。 下载
法则 2
Get their heads into the game 使大家主动投入 法则2建使大家主动投入 39如果每个人都在认真思考如何使团队更有效率，这个 团队自然就比较容易表现出高效率，反之亦然。听起来又 是老生常谈，但事实上，让每个人的思考都动起来是一项 管理上的重大成就，这需要有人用智能和努力营造出这样 的环境，才能让它发生。这种全体一致为整体设想的思维，其重要性绝不致被 高估，但其困难性却常常被忽视。在团体思维之外，每一 个人都有自己个人的想法，不能说不对，却常常是问题发 生的根源。每个人都有自己的思想、价值观、信念，也许不会表 达出来，当然也不是每件事都非得说出来不可，但是团队 中大部分的事都值得花时间沟通，特别是有人的想法非常 敏锐时（请参阅附录）。每个人的想法都值得注意倾听， 而且其所隐含的信念都值得花时间了解，尤其是有流言、 断章取义或误会发生的时候。人们的行为来自信念，人会为行为改变信念，也会为 信念改变行为。
创造力的可贵
在一个需要创造力的环境中，好点子是愈多愈
40好。你只要鼓励大家有这种共识，很容易造成深远的 影响。假设大家在讨论一个问题时遇到瓶颈，没有好 点子，你的做法是，规定每个人至少提出一个或两个 好点子，然后你就会发现气氛动起来了。有好点子是令人愉快的事，尤其当两个看似无 关的点子，凑在一起突然变成一个崭新的、更复杂更 丰富的好主意时，大脑中的愉悦中枢会受到刺激，所 以创造力总是伴随着喜悦。有人倾听或了解自己的想法也是令人愉快的事。 最棒的是你的好点子被大家广为使用或接受，这本身 就是心理上的很大的快慰与满足。想出好点子是内在 的脑部活动，但当别人恭贺你或肯定你的点子，你会 禁不住开心地微笑。好点子是具有感染性的。真正的好点子应该像 病毒般广为散播，每个听到的人都会感受到创造性思 考的快乐。好点子具有相乘的效果。当好点子打破某些错 误的假设时，会有更多更好的点子被激发出来。创造性思考能培养你的洞察力和头脑敏锐度， 以及对新想法的成本、价值等的评估能力。 法则2建使大家主动投入 41创造性思考只有好处没有坏处。虽然培养某种 特殊的创造力不是件容易的事，但“想出好点子”本 身很单纯，你多用它就会磨亮打光，一旦时机到来， 创造力就会像核反应一样，绵延不断地增生扩大。 为什么组员会怠于思考或是不敢说出想法？ 因为他们认为没有人会重视他的想法。 因为他们认为该由别人告诉他该做什么事。 因为他们认为这样做没有什么好处，只会使老板皱 眉头罢了。 管理者只管发号施令而已。 如果人们的想法被采纳，他们就会愿意思考和表达想 法。如果他们的新点子能够被团体接受，就表示值得实施， 团体的力量会更强化好的想法，这就叫做“授权共决”（empowered consensus）。或许有更适切的名词表示这个抽 象的观念，我选用这个名词是因为它表达出决策形成的两 个重要过程：主动思考与尝试表达。 下载
法则 3
Create a multi-release tech- nology plan建立开发多版本的技 术规划 法则3建建立开发多版本的技术规划
组员如果乐于参与我所谓的“技术规划”（t e c h n o l o g yp l a n），会对未来更有信心。授权共决是所有信赖的基础， 技术规划是它的结果之一。在民主式的授权共决中每个人 都有投票权，参与技术规划的决策。更重要的是，每个人 的想法都受到重视，被认真地评核。技术规划是团队行为 的基础，在最理想的情况下，它包含了全体组员最好的想 法。技术规划是组员对团队工作的契约，也是团队的宪章。 一年大约修改一到两次，以适时反映每一位组员的意愿， 这么做会让组员更有安全感，更愿意信赖彼此和未来。技 术规划勾勒出了大家信赖的未来的蓝图，因此，假定有一 位组员对目前分配到的工作觉得不太喜欢，没关系，下一 次改版时他可以挑个比较有兴趣的工作；或者有一位组员 不喜欢现在的产品方向，可以暂时退出，等下次技术规划 修改时再加入。技术规划对于日程的掌握也有帮助：开发人员总是想 把一些了不起的功能加入，常常和进度不能两全其美。如 果有技术规划，开发人员会信赖未来，他有的是表现机会， 不必急于一时。另一方面，开发人员很清楚该在适当的时 间做适当的事，既不会负荷过重，工作品质也更能掌握。
44当每个人都很明白在这个产品中自己该做什么，事情就很 容易被精确掌握。其中的关键就在这种“割爱”的艺术。
一个技术规划的实例 有一次我受邀担任一个软件开发团队的顾问(不 是微软)，协助他们建立技术规划。他们的资深项目 经理出身该公司主要的技术部门，决定集中力量在 一个五年计划(即使两三年的时间对科技来说就已经 是全面改观了，我一般不建议定这么长的计划日 程)。当时，他们正在讨论各种新技术能为工作带来 的好处。在讨论中有一个主题很有意思，是他们年久失 修的关键程序。这个程序庞大而脆弱，有很多错虫， 跑得很慢，其中有一部分的程序代码甚至已经超过1 0 年。组员中没有一个喜欢它，很多地方根本不符合现 代的设计原则，他们甚至不愿去碰这个大麻烦。我想每个公司或多或少都有这类的程序：程序逻 辑纠结交错、缺乏弹性、冥顽不灵，简直令人头疼。 这种程序最后会变得无法维护，更别提加入新的功能 法则3建建立开发多版本的技术规划 45了，结果是大大限制了开发团队创造优秀软件的潜力。 我把这种情况称之为“软件开发的恶性循环”， 你不可能在推出下一个版本的同时，彻底翻修旧程序。谁能承担得起重新经历一次软件开发的整个过程，只 为了将程序改写，而这段期间很可能降低或中断客户 服务，在程序还没有变得更有弹性而能搭配新功能之 前，客户可能得等上好几个版本的时间。比恶性循环更深一层的问题是：为什么会有这 种怪兽程序？是技术总监失职，没有好好监控软件的 品质？项目经理坐视程序败坏至此，竟不能防微杜 渐？在你没有弄清楚真正的病灶并矫正它以前，就算 重新修缮了现在的麻烦程序，同样的问题还是会一再 发生。不要在损坏的地基上重新修筑倒塌过的房子， 那是白费力气！在这一组开发人马中有一群新成员，新的资深 经理带着一群新的工程师，负责这段伤脑筋的程序代 码；当然，这也为这个团队和这个程序带来新的活力 和希望。他们打算重新架构这段程序，以便融入更好 的技术，提高产品的使用价值。 这个小组经过一番研究之后，倾向外购一项全
46新的技术，作为未来开发的基石。当他们向决策当局 提出这项建议时，反应是两极化的：赞同的人认为即 使外购也可能有兼容性的风险，但旧程序实在太难清 理不如放弃；反对的人则认为团队有能力重整旧程 序，只要管理当局给他们机会。项目经理也搞得不知如何是好。这位资深经理 在情感上倾向放手让属下好好努力，去清理他们数年 来不断奋斗的怪兽程序，但她又实在不放心这群属下 是否真的准备好迎接这项重量级挑战，尤其是想到他 们过去不怎么样的记录。她不认为这是原先管理者的“错”，虽然是他们的疏忽以致程序腐化到这般田地。 一般而言，如果管理当局对技术是压榨而非培 养，优秀的人会离开，苟且的人会留下，最后组织和 技术一起走下坡。在本实例中，有不少的新人（包括那位项目经 理）觉得这套旧技术实在活得太久，该被淘汰了。也 许大家所缺乏的只是管理当局的承诺，包括技术生涯 规划、创造力的突破和员工福利等等。这位项目经理 希望她的努力可以改变这种状况。 最后，她决定做一次技术规划，然后冒着被开 法则3建建立开发多版本的技术规划 47除的危险充分授权给开发团队，果然不只使得怪兽程 序浴火重生，而且只花了一次改版的周期时间，也扫 清了许多地雷暗礁。成功的背后，她也失去了几位主 张使用外购新技术的人员。下一次她修订技术规划的时候，她不只是让开 发小组参与，还设法训练主管们也能参加并了解这个 决策，让负责准时完工的技术人员梦想和希望有机会 呈现在技术规划之中。她也鼓励其他的主管们参加这 些讨论，这样做事的时候会比较容易沟通，也更不会 错失任何好主意。有很多方法可以制定技术规划，但最重要的原则只有 一个。优良的技术规划有很多好处，也许“割爱”是最重 要的。技术规划会让您知道将会走到哪里，更容易掌握该 做什么，采取什么方法，如何就会更接近目标。而且，惟 有完善的多版本技术规划，才能帮助您准确详估工作量。
修订技术规划 另一个我所观察到的技术规划实例也是加强共 识的最佳典范。由开发小组和项目经理中派人组成的 技术观察员，花了一两个月的时间起草大致的技术计
48划（请参考法则5：刺探敌情）；然后这份草案被全 组人分别传阅、加注意见、讨论激辩，最后被交给负 责执行的开发人员（大约80位）。同一时间，这份草案也在高阶主管之间传阅， 他们会参照许多其他的技术规划后，定出多版本的产 品计划。他们通常不会修改技术规划，因为他们知道 这是所有组员的心血结晶，也是得来不易的团队共识。 然而，他们发现了一个问题：这份规划看起来像是一 大串互不相干的产品特色（ f e a t u r e），这样蔓杂的目 标怎么能激励开发人员呢？怎么可能向全世界描述他 们有这么样的产品─有几十个不显眼特色的产品？然后经理们归纳出来，这些产品特色分属于五 大类型：策略、竞争、顾客满足、投资，以及他们称 作“典范性”（p a r a d i g m a t i c）的功能诉求。典范性的 功能是指有计划地放在 n个连续版本中的产品特色， 最终目的是改变使用者的工作方式。这套分类当然不 是说典范性的功能不属于竞争或策略，或是策略性产 品特色与顾客满足感无关，这么划分只是为了比较精 确地描述。 “策略性”产品特色与最基本的环境和限制有关。 法则3建建立开发多版本的技术规划 49譬如说是本产品支持什么操作系统？采用何种对象模 式（object model)？产品需要什么等级的中央处理器（C P U)？支持哪种程序语言？此外，策略性产品特色 也涵盖了公司发展其他产品线的全面性策略。例如公 司卖的打印机，就必须写驱动程序去支持。“竞争性” 产品特色基本上是为了对抗竞争者而设计的，特别是 竞争者有而我们没有的功能。虽然不必每一项竞争者 的功能都要放进来，但倘若其中有特别巧妙或特别吸 引媒体注意的功能，就值得投资。这一类的产品特色 是数目最少的。“顾客满足性”产品特色基本上是大家已经耳熟 能详，且顾客大都需要的。多去听听顾客的声音，产 品特色就会更能搔到痒处。这部分的产品特色数目最 多，但开发成本相对较低。“投资性”产品特色是技术方面的前瞻性投资， 其效益可能在未来的一或数个版本中都未必能明显看 出。毋庸置疑，投资性产品特色是未来大放异彩的潜 力，它能带来未来版本中的典范性产品特色。这个项 目的重点是使开发人员善用每一分钱的投资。 “典范性”产品特色可以改变使用者的工作方式。
50基本上这是整体开发人员梦寐以求的目标，在每一次 改版中放进刻意设计的巧妙功能，逐渐引导使用者。 通常这是行销部门持续性对外宣传的产品特色，它甚 至能改变整个游戏的竞争规则。我们可以说：如果典 范性产品特色成功的话，没有人能跟你竞争─除非 他也有这项特色。在本例中，项目经理将技术规划中所有的特色加 以整理，分别归入这五大类，并决定在这五大类中分别 要投入多少的资源、占整体投资的比重，并且做出相对 应的技术需求分析，当然要符合内部资源和技术的分配。 这一部分我就留给读者当成家庭作业，您自己思考一下， 以您的条件、产业竞争型态等因素来看，五大类产品特 色中，其所占资源比例应该如何分配呢？然后，整个开发团队在接下来连续大约五天的 时间，每天开会约两个小时，逐步讨论出下一版产品 的技术规划的细节，整个计划就此拍板定案。这五天 是大伙儿发表意见的最后机会（当然啦，事实上计划 永远是可以变更的，这样做是为了强化计划的效力）。 因为计划的制定是由下而上，不会有任何人跌破眼 镜；因为管理阶层负责综合各方意见而形成完整的、 法则3建建立开发多版本的技术规划 51有系统的产品特色，组织目标会被大家接受；整个过 程开放而民主，每位成员都获得充分的授权，最后的 争议也会最小，很能共识凝聚，热忱也会很强烈。没 错，整个团队会深刻感受到共同的目标。这是我所见过最理想的规划过程。我写本书的时 候，他们的产品已经上市了，真的是很棒的产品呢！ 每个人对技术都应该有一份使命感，都有追求 进步的内在欲望，然而新点子可能因为缺乏适当的分 析或时机不成熟而被排除于计划之外。团队成员必须 明白真正的工作内涵，并且能够理解有时候新点子虽 好，但总得经过慎密的分析并证明实际可行又有足够 的效益才行，而好的想法若能被团队审核过关、形成 共识，最终还是会实现的。如此可以减少未经深思熟 虑的提案，对整个产品的稳定性颇有助益。最后，将产品特色分为策略性、竞争性、顾客 满足性、投资性、典范性这五大类的用意是，给经理 人一个管理上的指针，便于监督各项资源的运用以及 诊断问题。比方说，如果失去了技术上的领先地位， 管理者就应该加强典范性的投资，而相对降低其他各 类的投资比重。 下载
法则 4
Don't flip the bozo bit 别做笨蛋 法则4建别做笨蛋 53我再说一次，软件是智能财产。必须运用智能，才能 得到软件产品。若能用更快的速度结合更多的智能，软件 的智能财产价值就愈高。这是显而易见的事实。曾经有人 问我：“在软件产业中最重要的事情是什么？”我毫不犹豫地回答：“让大家思考。” 信不信由你，大部分的人都不愿意思考。他们认为自 己乐于思考，但事实上并非如此。保持脑袋空空很容易，在微软我们把这种人叫作 b o z o，意思是笨蛋。永远没有 人会注意笨蛋的所作所为，即使他真的有贡献，他也不会 有任何份量。笨蛋当然是不可信任的，你对笨蛋惟一的期 望是但愿他不要搞砸事情。然而每个人都有可能是笨蛋。你自己反省看看，是不 是知道自己在做什么，是不是觉得自己一点能力都没有？ 小心，笨蛋可能就是你。在我的部门里，这种德行是不允许的。我要每一个 人都全心全力地投入，每个人都得有贡献，每一个人都 可以侃侃而谈我们的产品─如何在市场上竞争、何时出 新版本等等，而且每个人对产品的看法都一致，不会众 说纷云。 判断一个人是否在思考，最简单的指针是看他是否专
54心倾听别人的看法，并且立即给予直指核心的响应。面对 优于自己的看法，我们必须平息一开始的那种竞争心理或 防卫反应，别人当然是经过一番智力淬炼才能想得出这些， 我们应该公正地评判这些新的、可能很有价值的信息。
别让自己成为笨蛋 法则4建别做笨蛋 55懂得思考的人当听到诸如批评或别人比较优秀等不顺 耳的话时，会把自高自大的心理干扰过滤掉，并从沟通中 接收正确的信息。他们能够避免下面两种心理现象：第一种心理现象是防卫心理，让接受信息的人无法忍 受别人的批评。在创造智能财产的工作中需要很多的情绪 和创意投入（像是自己心血结晶的宝贝孩子，有一份特殊 的情感），别人对产品或制程的意见往往会听起来像是讽 刺。懂得思考的人在三思之后，会将自我的主观意识排除， 然后接受信息的真实内涵，不过这种人并不多见。
将自己的意见强行加诸于他人者， 其实是笨蛋。
不懂思考的人不但不会请求别人赐教，反而在别人好 意提供信息时过度防卫，而导致正面的冲突，所以无法对 信息作出正确的判断，对事情毫无建设性。如果这种现象 不断地发生，信息接受者会有两种可能的反应：一是这项 信息确实很重要，二是这个笨蛋在将自己的意见强行加诸 他人。结果呢？当然是后者。
56第二种心理现象是相互排斥，发生的可能性更高。如 果向别人提出建议，但对方却因为恐惧或其他负面情绪而 排拒，久而久之，这位好意的建议人就会认定对方是无法 沟通的笨蛋。团队中有人无法沟通是极危险的事情，这会导致团体 中人际关系的恶性循环，对团体能力造成莫大的伤害，而 且几乎无法弥补。而且一旦管理者认为某人是无法沟通的 笨蛋，团队中的其他人都会跟着这么认为。对这个问题的药方是加强每个人正面的沟通能力，能 够虚心接受别人的意见。如果你正试着传出信息，而对方 似乎无法接受，那么换一种比较轻松的方式做做看，至少， 试着向对方解释他的封闭令你难过。相反地，如果有个家 伙不断灌输你“差劲的”想法或是“恶意”的“攻击”， 放下自尊心彻底反省，是不是原始本能的防卫心理蒙蔽了 你的判断力。如果你能在团体中实践这个准则，当你不小 心犯错时就会有人及时纠正你，团队才能在和谐中进步。
死亡进行曲在大多数的软件开发项目中，一开始多半都在做前一 个项目的收尾工作。如果你的项目是以这种方式展开序幕 法则4建别做笨蛋
57（很不幸几乎所有的软件项目都是这样的开场），这个过程 被比喻为“死亡进行曲”（death march）。
为了赶时间，产生了太多没人能懂的 程序代码。
当前一个项目拖得太久（也许是为了更前面的一个项 目而晚了几个月才真正开始进行），也许因为项目经理忽 略了该注意的地方，或是因为客户的强烈抱怨你食言而肥， 或是前一个项目的到期压力太大而影响了软件的品质，或 是虽然前一个项目还算顺利但人员筋疲力尽想暂时歇会 儿，这一切的理由都埋下了延迟和品质不良的种子。为了 如期完成软件，工程师明知其中有不少有错虫，明知程序 写得多松散，甚至没把握程序能够正常执行，为了赶时间 只好牺牲自尊心，放弃对“我的作品”理想的执着，他们 无法以自己的作品为傲，以通过软件争霸战的残酷考验而 自豪。在符合进度且产出稳定的开发团队中，最后每个人 都会是团队的英雄，牺牲自己无私奉献终能完成任务，事 实也确是如此，软件开发是多少人绞尽脑汁的成果啊！
58然而现在他们认为自己应该得到一些适当的休息，有 适当的奖励或充电的机会，做些自己有兴趣的事情，或是 玩玩他们心爱的计算机。重点是，他们无论是用爬的、用滚的，还是被鞭子赶 的方式，毕竟如期完成了软件，也许不是那么漂亮完美， 总是达成了目标。任何有开发时间限制的软件，到最后工 程师大概都是除日程之外什么都顾不了，这是非常巨大的 压力。然后紧接着又一个项目开始，不知道又要投入多少 脑力，这造成各种有形无形的员工的反弹，其中最可怕的 是那种江郎才尽（b u r n - o u t）的感觉，这将是团队最迫切 也最严重的危机。
江郎才尽 软件工程师那种“江郎才尽”的感觉，就好像 巴拿马运河的建筑工人染上疟疾一般，一发不可收拾。“江郎才尽”是你再也无法承受压力的感觉，那是一 种极度的疲惫和沮丧，只有软件从业人员会染上，其 症状包括： 确信这个软件正在榨干所有的人的精力。 觉得这个项目管理简直乱得无可救药。 法则4建别做笨蛋 59 一想到要出下一个版本，就觉得头晕想吐。 对于任何企图解决问题的作法抱着愤世嫉俗的 态度。 完全无法沟通。 对计算机失去兴趣。 工程师染上这种“病”时，不论《P C周刊》(P CWe e k )或《信息世界》( I n f o w o r l d )(或是 D r. Dobb’s 和Midnight Engineering)等杂志看都不想看，觉得科 幻小说荒诞可笑，虚拟实境(Virtual Reality)不过是人 工智能的游戏，新版的 M F C手册懒得去翻，甚至对 最新款的计算机毫无兴趣。基本上，就是软件工程师 那种做出最好的软件的狂热，已经消耗殆尽或是转移 到别处，只剩下颓废。其实管理者也可能发生这种“病”，这是必须特 别防范的，因为发生在管理者身上的症候特别容易传 染到整个团队。对一位软件开发人员而言，计算机的狂热是他最 重要的动力泉源，对某些人而言这是一种终极的自我 实现。就像是笔之于诗人，颜料之于画家，程序编译 器是软件开发人员心灵之所系，用以发挥才情的工具。
60当热情燃尽时，将自己的智能倾注于软件开发的那种 无怨无悔，也就随之化为一堆肮脏的灰烬。我和每一位软件从业人员一样，非常害怕染上 这种综合症。如果不加以防范，这就像是艺术家的陨 落一般，会使软件从业人员的职业生命骤然消失。
江郎才尽的感觉 下载
法则 5
Use scouts 刺探敌情
62在开始下一个项目之前，先刺探敌情吧！ “侦察员”（s c o u t）是军队中先派出去侦察敌情的“探子”。他们负责先了解四周的环境和敌我界线、我方资 源、寻找安全的驻扎地点、确认最好的前进路线，并且随 时注意任何敌方行动的迹象。长久以来，当一群人在一个 危险的旅程中，通常都会先派出侦察员去了解一下前方的 路况。倘若软件项目不是大批精英的危险道路，就没什么 好谈的了，所以当然得派个先知先觉者去为项目事先“侦 探”一番。
倘若没有人事先研究出最适合的路 线，各版本的开发过程就像在沙漠 中胡乱游荡。
“侦察员”必须敏锐地嗅出任何软件产业的蛛丝马迹： 软件开发团队与大环境之间的依存关系、正在开发中的操 作系统新版本、与本项目有关的技术发展现况（也许还得 另外找人来研究这项新技术）等等。“侦察员”能建立或 修订多版本的技术规划（请参阅法则 3），他们访问顾客、 法则5建刺探敌情 63学习有竞争力的新技术（至少要有基本的了解），并且研 究决定项目该以何种方式或路线进行。“侦察员”必须能够提出硬件最低需求的建议书，分 析所有的使用者需求及各项软件开发规范，准备原型产品， 草拟未来的产品计划，以及建议下一版产品的重要特色。“侦察员”的任务和贡献可以说是无限的。倘若没有 人决定好最适合的路线，你的开发过程就会像在沙漠中迷 失了方向，版本与版本之间毫无组织和明确的方向，注定 了悲惨的命运。虽然有好的侦察员不能保证情报够充分， 至少“侦察员”会让你不致盲目乱走。
侦察员的重要性 最近我与一家大公司的 M I S部门有接触的机会。 他们在过去三年内成功地将原本在大型主机上的终端 机全部（有上千部之多）换成 P C及Wi n d o w s的作业 系统与网络环境。可想而知这是非常艰巨的任务，需 要大量的人力与金钱，和一段很长时间，整个公司在 这个转换的过程中，受尽各种煎熬。完成了Windows 和 P C的转换之后，M I S部门开 始发展一套分布式的应用软件，以期充分发挥新科技
64的效用，这是他们第一个重大的投资回收项目，预计 降低的成本和增加的利润可达每年数百万美元。这个工作团队大约由1 0 0个人所组成，主要是软 件工程师与品保工程师，大部分都是公司的新人，或 对技术还不是很熟悉，再加上对公司而言也是第一次 开发这种关键性任务（ m i s s i o n - c r i t i c a l）软件，可想 而知他们一定得克服无数的困难。在我与他们接触之 初，这个项目的进度已经严重落后，并且大大超出预 算，更糟的是眼看期限就要到了。这项 PC 软件的项目自开始至今已经有三年了， 当初他们开发软件时规划的硬件、网络协议等环境早 就已经过时，目前所使用的软件开发工具和操作系统 竟然落后了两个版本！这三年来，硬件价格大幅滑落， P C效能大幅提升，所要求的硬件运算能力也提高了 几倍，他们使用的 P C已经在市场上绝迹，但运行在 上面的应用软件却无法淘汰。我实在无法帮助他们解决这个难题，只能说这个 实例证明了“侦察员”的重要性。当年他们几乎是凭 着直觉和谨慎保守的作风来决定软硬件环境和工具策 略：“我们尽量不要改变任何东西，反正它能用就好。” 法则5建刺探敌情 65倘若他们曾经好好调查一下计算机的发展趋势，倘若 他们曾经考虑过兼容性的问题，他们就会知道必须使 用最新的工具和最新版的操作系统，并且尽可能将未 来的发展也估算在内，多花一点钱也是值得的，也不 会因为当年决策错误而造成今日难以挽回的局面。不过还好，这支勇敢的 MIS团队毕竟最后还是 圆满达成了任务，成功地完成了新的软件。这次他们 学乖了，事先派了两位最优秀的组员担任“侦察员”， 做了一次彻底的技术调查和完善的规划，终于在危机 爆发之前将之化解。老实说，对于类似上例的公司，我只能感到同情。计 算机科技进步太快太剧烈，冲击着组织不够健全的公司， 旧的系统难以割舍，新的技术又逼着你不得不进步。是的， 使用第0版的软件也许会让你惶恐，但从第 7 版升级到第8 版可能意味着重大的进步。如果你做决策之前，好好做 过“侦察员”和完善的规划，而且知道这些对系统的重要 性，你就会乐于接受科技带来的改变。本书强调的基本观念是，我们并不企图减缓科技进步 的速度，也不是要建立僵化的系统，而是要在改变中获得 益处，将不断变化的科技管理得宜。行动总比停滞好，行
66动力高的组织会有较高的适应环境能力。“侦察员”就是 为科技的改变而准备的，如果你决定永远停着不动，那你 不需要“侦察员”。当然“侦察员”也可能带来问题。如果他对多版本计 划没有非常清楚的认识，他可能不知道要侦察什么；他们 也可能不懂这项任务的重要性而随便做做。“侦察员”必 须要非常了解自己肩上所担负的责任：一旦选错了一个操 作系统或开发工具，可能会害死整个组织。另一方面，“侦察员”本身也可能因为这项任务的重 要性而过度膨胀自我，看不起其他的人，自以为是“定 义未来的人”。团队中的其余成员会因此而觉得沮丧，对 未来的方向完全没办法掌握，觉得自己不受重视；甚至 以为事情已经多得做不完，管理者竟然把人调出去研究 无关的技术：“我每周工作 70 小时，而那个家伙悠闲地 在看书!”这种抱怨在派最顶尖的人去当“侦察员”时尤 其会发生。团队成员对“侦察员”的工作不免嫉妒。当“侦察员” 比当开发者好─比较光鲜亮眼、比较先进、比较酷。当 几个月的“侦察员”似乎真是不错，你可以观摩别人的公 司、跟厂商谈谈、玩玩软件原型、趁机多充实自己的技术 法则5建刺探敌情 67能力、有权力影响未来的方向。但是“侦察员”不参与软 件开发，只负责做初步的规划、培养团队对于目标的共识。 如果“侦察员”能够让团队信任，并凝聚出真正的共识， 开发人员就比较能够自在工作，相信这些担任“侦察员” 的优秀同事是在为大家的未来披荆斩棘地开路。对开发团队来说，“侦察员”能够运用得愈成功，代 表他们愈相信项目经理的领导，团队的共识愈强；不论 是否处于技术转换的过程，对团体和个人都是一种很好 的现象。 下载
法则 6
Watch the ratio 注意人员的组成比例 法则6建注意人员的组成比例 69项目经理经常犯的错误之一，是以为只要雇用软件工 程师就好，其他的人都不必要，或是让软件工程师占整个 团队很高的比例。也许是认为开发人员愈多，写出来的程 序就愈多，这是错误的观念，项目的目的是完成软件，不 是完成很多程序代码。在开发团队中，事实上有一些工作 是不适宜交给软件工程师的。在我的小组中，比例通常是 6位开发人员，2～3位品 保人员，一位项目经理，以及两位技术文件撰写人。在微 软的各个部门中，这个比例会稍有不同，也许和您的人员 比例也不同；但基本原则是开发人员和品保人员的比例不 超过2:1。其实真正负责软件如期完成的是品保人员。当 进度落后时，我们第一个要看的是品保人员：人数够不 够？有没有充分授权？有没有确实参与设计？进度上能不 能跟开发人员配合良好？能不能一有问题出现就立刻提出 警告？品保人员和开发人员的理念一致吗？是不是跟开发 人员过度亲密而放水？对于人员的组成比例应该着重于有效的人数比，而不 是实际人数比。一个健全的软件开发团队一定要符合上述 的人数比例原则，平均每一位品保人员所支援的开发人员 不超过两位：前者是思考并监督软件的状况是否达到预期
70水准，后者专心写程序和抓错虫。注意人员的组成比例， 可以帮助（但不保证）团队的运作取得平衡，记住，平衡 才是你真正的目的。 下载
法则 7
Use feature teams 运用特色监督小组
72在微软的C + +开发小组中，我们就用过特色监督小组（feature team）的横向组织。我觉得这是非常好的做法， 对整个团队的工作品质产生了绝佳的影响。 如果你问一个品保人员他的工作是什么，他会回答：“监督软件开发的进度，确保如期完成，并且确保品质达 到预定的目标。”他绝不会说：“测试程序。”那是肤浅的 答案。品保人员的工作是如期完成软件，是开发“产品”， 是去了解顾客，而且还知道技术规划中每一件大大小小的 事情进行得如何；可以说，品保人员必须要管我们的产品、 我们的市场和我们的整个事业。我们的团队组织像一个二维矩阵，传统的组织模式为 经，特色监督小组为纬。以经理、品保、开发、文件四种 角色，虽然是一个传统的阶层式组织，但还算相当扁平化 的；除此之外，这四种角色必须各派代表参加特色监督小 组，每一项产品特色都有专属的特色监督小组，以确保每 项特色都能照日程做出来，这个小组必要时可自行开会。(特色( f e a t u r e )一词，也有人为了听起来较大众化而译 为功能，这是因为中文里的功能一词，意义非常广的 缘故。事实上特色是指完成某项功能的独特方法，特 别是与竞争者不同的地方，它适用的范围很广，您可 法则7建运用特色监督小组 73以说，采用C o n t r o l - C . C o n t r o l - X . C o n t r o l - V来操作“剪 贴簿”是微软产品一贯的特色，您也可以说，某软件 具有随插即用的特色。—译者注）特色监督小组运作模式有几个重要因素：分别是充分 授权、赋予责任、融入任务、建立共识和地位平等。特色 监督小组是我所经历过最神效的组织方法，我将它的五项 重要因素讨论如下：充分授权（E m p o w e r m e n t） 像特色监督小组这样的 编制似乎比较非正式，无法像阶层式的组织那样容易管理， 但它需要被充分授权才能发挥作用。譬如像开发人员，他 们是“专才”，几乎专职负责某一特定的技术领域，若是 让他们完全主导一项产品的设计显然太不智，如果加进一 些别的角色，形成“通才”的局面，就平衡多了。单靠经 理人的决定，恐怕不够全面，我看过太多好的（或坏的） 决策，一下子就被另一位经理完全推翻，我倒是没见过特 色监督小组把事情搞砸过。也就是说，只要特色监督小组 能被充分授权，并且发挥它的作用，就可以确保决策的品 质。（当然特色监督小组的必须挑选适合的人参加，本书 附录中将说明这一点。） 赋予责任（A c c o u n t a b i l i t y） 我认为软件开发问题中
74最有趣的就是赋予责任这个主题。我们讨论过的题目是：“你负责什么？”我的理论是，大多数人的思考都没有好 好利用到，因为人们并不把提出新想法当成自己的责任之 一（请参考法则4：别做笨蛋）。首先，人们可能认为：“这不是我的责任范围”，因此 少管闲事，不提任何有建设性的提议。如此一来会有很多 不良的后果，尤其是当事情没有用语言沟通，会引起许多 误解、猜忌、行动力的相互抵销，而最后只有用行动来抗 议了。
只要单纯地请对方表示看法，这样 的姿态很容易解除对方的心理防线。
其次，如果建议的来源真的说出了他的想法（可能要 冒很大的风险），被建议的对象很可能产生防卫心理（又 不是你的事情，管什么管嘛！），导致争端。有时候，防 卫心理是非常隐讳的，特别是当这个组织的文化将防卫心 理视为缺点时。讽刺的是，愈是成熟的团队或个人，愈会 执着于现有的优良管理制度，愈会提出各种反驳的理由来 法则7建运用特色监督小组 75证明现有的做法才是最好的，不需要什么建议。第三，除非建议者克服自己的攻击心理，否则这个 建议可能永远到不了对方的心中。就像防卫心理是普遍 存在一样，攻击心理亦然。通常提出建议的人都有某种 攻击性或包含价值判断的态度，这也是绝大多数的人都 有的弱点，而受到批评的人会感觉到威胁而更强烈反弹， 于是提出建议的人立刻下结论：这人是个笨蛋，沟通的 大门立刻关上。有很多建设性的想法就此消失。我所想到惟一的解决 办法，就是所谓的研讨会（w o r k s h o p）。在研讨会中人们 主动上前邀请同事提出批评指教，这样单纯的提出、接受、 反馈的循环中，每个人都会受到批评、提出建议，这是比 较容易让人卸除心理武装的气氛，比较容易对事不对人， 如此单纯的信息传达让每一个人都轻松接受建议而愿意改 善。令我惊讶的是，由于研讨会的练习使得组员熟悉沟通 技巧，最后反而不需要经常开研讨会了。我有过多次运用研讨会的方式解决软件开发问题的经 验。方法像是个案研究（case study），由一位志愿的组员 主持；这个案例当然是现在发生的真实情况，通常是关于 组内的人际关系，主持人先描述案例的大致情况，有时故
76意不说明当事人的名字，比方说： ──我实在无法接受这种想法。 ──没有人看我的电子邮件（指建议）。──某人根本没有把心放在项目上。 然后其他的人开始讨论，询问主持人关于此案更详细的信息，并理清一些盲点，或是询问主持人尝试过那些方 式，之类的问题。最后事情会在讨论中澄清，问题也就差 不多解决了。前述的两种简单方法会产生两项很重要的结果（从来 没有让我失望过），其一是这样的讨论会造成非常多的新 点子伴随而生：你会看见主持人不断地说：“这个想法太 棒了！”然后当场记在笔记本上；其二是这种案例研讨的 结论通常可以应用在其他类似的情况，人们会发现，这就 是我上个月讨论过的某案嘛！当类似的过去案例累积到相 当的数量，人们就会发现本案也不是什么特例，然后就会 发现处理这类事情的通则，把它记在笔记本上作为日后的 参考。 法则7建运用特色监督小组 77
在横向的特色监督小组中，一个人的 成功或失败是完全透明的。
“赋予责任”有很大的好处，很少有应用上的限制。 如果一个组织健全的团队成员，对于整个任务的过程─ 设计、开发、除错、品质、期限─彼此都负有责任，就 会自然地互相给予建议和建设性的批评，而且用正面的态 度接受。因为每个人都有相同的责任。一旦建立团队的责 任感，这种对责任的认知会分享、传递到团队中的每一个 份子。融入任务（I d e n t i t y） 充分的授权和责任感，使人具 有控制权和影响力，愈能使自己与任务融为一体。控制权 愈大，融为一体的一致性愈高。这种融为一体的一致性是 开发任何好软件的先决条件，它会将个人的心理状态健全 与否，表现在软件作品中。譬如说，有一个人心中有挫败 感或是自我毁灭的倾向，就会在他所负责的软件功能中表 现出来。 在横向的特色监督小组中，每个人会将产品当作他的
78任务，而非狭隘的技术而已。没有什么人可以推诿塞责， 一个人的成功或失败是完全赤裸而透明的。你不能责怪管 理不良，因为你自己就是管理者，你不能责怪其他的功能 支持人员没有好好配合你的产品特色，因为你们是相互负 责。因此，你有责任自己找到答案，你有责任克服自己的 障碍。建立共识（C o n s e n s u s） 共识是特色监督小组的气 氛。因为大家聚在一起的原因是“产品特色”而非功能， 由于责任是互相的，敞开心胸是安全也是必要的。我见过 有些特色监督小组自动地重新组织他们的关系，建立共同 目标、重新规划资源、适度修改日程，而没有发生严重冲 突。即使有冲突，由于不是对人的或是出于私心，通常都 很容易解决，不需要主管以职权介入。地位平等（B a l a n c e） 由于特色监督小组的每一位成 员都是不同的背景、专长，不同的工作角色和不同的观念， 没有谁比谁优越的情形，所以每个人的地位都是平等的。 通常人们对于不属于自己专业的领域，反而会有一些全新 的看法，刺激彼此打破过去的观念限制或盲点，激发更好 的创意。由于各人的意见来自不同的着眼点，就可以使产 品的开发顾全更广的层面，而更周全、完美。不同角色的 下载
人会关心不同的问题： 微软团队·成 功 秘 诀法则7建运用特色监督小组 79
项目经理：团队目前的状况如何？开发过程顺利吗？ 领导是否有效而得宜？我们走到开发周期的哪个阶段？进 度是否控制得当？需要别部门协助的地方是否已经取得支 持？我们的目标明确吗？还有什么尚未完成的工作？本周 的工作主题是什么？品保人员：我能不能依照预定的时间自开发人员手中 取得阶段性程序代码？程序有什么样的错虫出现？这些错 虫对付得如何？有什么功能尚未开发出来？程序的执行效 能如何？本周的产品状况是否合格，需要对谁提出警告 吗？项目经理知不知道程序的稳定程度？我们团队的沟通 如何？是不是每一个人对产品状况都有相同的认知？本周 合理的短期目标应该是什么？开发人员：本周我能不能完成预定的工作进度，将阶 段性程序代码交给品保人员和文件人员？这一段程序代码 写得够好吗？使用者需不需要这个功能？这个程序容易使 用吗？程序是否执行够快体积够轻巧？我清除了所有的错 虫吗？有没有人因为在等待我的工作进度而耽误进度？我 是否完全了解本周的短期目标？我的工作是否符合策略上 的方向？而且工作内涵对技术规划有无贡献，或只是个早
80晚会被丢掉的垃圾？产品经理／行销：产品特色是否吸引顾客（包括潜在 顾客）？我该如何生动地表达这个产品的特色？它能否牵 动顾客心中的心理或情感反应？我们应该如何修改产品， 才能加强顾客的购买欲？当顾客听到我们的产品时心里会 有什么样的反应？顾客在什么时候会使用这个产品？产品 特色是否能加强我们与顾客之间的关系？媒体是如何报导 我们的产品？开发这项产品特色背后的动机是什么？我是 否完全了解产品特色及其重要性？准时完成的可能性有多 大？我是否应该向公司说明产品的不确定性有多高（或是 非常确定）？产品成功推出的机会点在哪里？技术文件／教育训练：这项功能是否以更容易的方式 使用？我对它的说明够清楚吗？使用者接口能不能设计到 不必学就能操作？如果我现在还没有完成文件，会不会太 迟？这项产品特色是否已经通过品保人员的核准？我对这 项产品特色有什么感觉？我能不能用更简洁的方式来说 明？其他的组员认同我写出来的文件吗？虽然特色监督小组是非常的重要，但要成功地组织起 来可不是件容易的事。在传统的阶层式组织中加入横向的 特色监督小组是非常困难的转变，这种转变上的困难可能 下载
来自团队的内部或外部。 微软团队·成 功 秘 诀法则7建运用特色监督小组 81
在特色监督小组的内部，本身就会面对相当大的不确 定性，大家不知道自主权的范畴是什么，只知道我们是一 组人，应该在一起做事，但不确定的该用什么样管理方式。 特色监督小组的本意是突破传统角色的藩篱，但是组员却 会很自然地以原来的传统角色来为自己的定位，如此特色 监督小组的作用就会明显受限。开发人员常常会主导小组 的运作，导致使其他的功能不容易发挥。如此一来，特色 监督小组的横向组织功能大概只能改善沟通，这似乎与它 的高成本（组织小组、召集开会、物色人选、行政作业等 等）完全不成比例。
在很多人的心中,所谓的团队只不过是 虚伪矫情的共识和假装一团和气罢了。
而且，人们总是要等到问题已经很严重时，才会成立 特色监督小组。如果这个时候管理阶层放手让他们自行决 定命运，组员反而会有被抛弃的沮丧感。向来不习惯自治 的组员突然要组织起高难度的特色监督小组，一定会觉得
82非常不安。特色监督小组的功能在这样的情况之下很难发 挥，问题反而很可能雪上加霜。特色监督小组本身也充满了矛盾和冲突，因为在很多 人的心中，所谓的团队只不过是虚伪矫情的共识和假装一 团和气罢了。特色监督小组惟一不可磨灭的贡献是创意，代价是无 数不眠的夜、对拒绝的害怕、对个人勇气的磨炼。于是，“冲突”便成了特色监督小组的标志，虽然它也是成长的 动力。所以，项目的初期往往看不出来特色监督小组的重要 性，因为没有什么挑战性，特色监督小组看起来像是管理 阶层在搞的流行玩意。最后特色监督小组还是会发挥很大的效用，只要它能 被适当的组织和赋予足够的权力。它有资源、有创意、有 管理者支持，能够发挥惊人的力量，在关键时刻，他们会 发现自己竟然能够搞定这么多、这么重要的事情。当然在特色监督小组内也有它的问题。很多头脑优秀 而充满创意的人不敢提出他们的构想，有一种内在的负面 力量阻止他们将自己的天份表现出来。大多数人都会害怕 在团体中被排斥，这种心理源自于做个乖小孩的童年经验： 法则7建运用特色监督小组 83由于父母很少会限制小孩的发展，因此小孩对于“不要这 样”的信息特别敏感，为了保护自己，尽量表现得与大家 一样，服从于大多数平庸者的价值体系，而不太敢表现自 己的才能。然而，与众不同才是软件开发的成功要素。这种自我设限的负面行为，虽然在一般的生活环境中 是正常现象，但在正常的软件开发环境中却是病态。一般 人都会为了在阶级系统中求生存而学会“善伺上意、察颜 观色”，自然而然地会去迎合管理者的态度而改变自己的 行为。然而，管理者也会不知不觉地发出“停止！不要这 样”的信号（也许是出自盲目的策略或单纯的固执，就像 父母对孩子的行为教育一般），导致属下害怕功高震主、 得不偿失。管理者应该率先鼓励人们尽量发挥，对于优异 的组员表示肯定和支持，至少对于不同的意见采取开放的、 正面的态度。另一方面，每个人对于这种意见自由也会有不同的反 应。每个人感受到自己被充分授权，一肩挑起一件大事的 成败责任，会自然地把这种情绪传达给团队中的其他成员。 这种个人自由（personal liberation）在不同的时机会以不 同的样貌呈现，也会以不同的方式强化，每个人都不一样， 但这并不容易被观察出来。每个人都需要被挑战、被鼓励、
84被栽培；弹性和耐性使个人形成团体，而以自己的脚步共 同成长。这种成长过程虽然艰辛，却是成为优秀智能工作 团队的先决条件。
在特色监督小组中容易发生奇怪的对 话，像是谁能决定什么事，除了控制 之外到底该有什么样的管理角色是管 理者应该担当的。
我也同时注意到，每个人对横向组织（特色监督小组） 的参与程度，恰好与他原功能组织（例如系统文件等角色） 的成功程度成反比。如果整体组织的功能表现不彰时，其 中某个功能部门的表现还算不错，致使这个部门的表现显 得突出，那么在整个组织效能改善之后，原来的疏离感反 而使得这个部门的人较不容易融入横向组织中。我们再来谈谈特色监督小组可能面临的外部问题。参 与者本身所隶属的功能部门管理者（如开发经理、品保经 理等等之类的各式经理）有他原来的部门目标，现在要抽 调人力参加特色监督小组，当然不免有些挣扎。也许其原 法则7建运用特色监督小组 85属的功能部门不是那么有创意，但在这“疯狂的特色监督 小组”成立之前，他们对组织也有一定的贡献，或多或少 都对特色监督小组抱持着对立的态度，毕竟，他们已在原 来的专门领域建立起一定的责任感和权威性，现在要他们 加入一个陌生的组织，做一些自己不擅长事情，而且在原 本未被授权的环境中，他们凭者能力取得一席之地，但现 在不需要了，却在新环境中被授权却更多，使得他们对原 有的成功价值产生怀疑，因而使他们更难适应新的环境。 管理者知道如何以传统的方式推出软件产品，当他看到特色监督小组刚成立时所作的尝试，会觉得太幼稚了， 会感到非常地担心：“他们这样做是错的，应该由我来做， 或是由我来教他们如何做。”这真的是善意的关心，管理 者无法忘记自己对产品的责任，会怀疑特色监督小组是不 是疯了（我自己就曾经这么想），竟然让这些没有经验的 笨蛋决定技术与产品的发展方向，并且管理者从前犯过的 错误他们现在一样照犯！管理者学习在“鼓励属下”与“控制属下”之间取得 平衡，于是发生奇怪的对话，像是谁能决定什么事？除了 控制之外到底该有什么样的管理角色？如果不是管理者该 做的决定，那么他要如何负责？如何自处？如何定位？
86当年我也曾经怀疑过，和其他多位资深经理怀疑我们 为什么要大费周章地成立特色监督小组，我曾经在深夜醒 来，自问我们究竟为什么要这样自找麻烦，想出这种疯狂 的主意使每个人都全心投入。渐渐地，我们了解到管理者 的角色应该是教导、挑战、鼓励，并肯定这个创意思考的 过程。如果我们的观点是对的，事实自然能够证明它。在 授权给特色监督小组的同时，经理挑战组员假设的前提， 让他们能够自我检视自己的动机和行为，协助他们达成共 识和化解冲突，并让他们明白管理者了解他们，会支持他 们的决定。我们训练组员自己去追求效能，这是非常基本 的要求，因为我们要让组员自行负责，让组员有能力决定， 并且以自认最理想的方式去实现。
权威是来自学识，而非职位。
当然，这整个过程是循序渐进的，就某种意义来说， 它仍然不断地在发展。有很多时候，小组希望由经理直接 替他们做决定和设立目标；也有些时候是经理不当地命令 小组做事。传统性的功能组织和横向特色监督小组之间， 法则7建运用特色监督小组 87没有全然的界线。但是在这一切都在转变中，我清楚地感 觉到大家都朝着正确的方向在进步。在一个理想的项目中，基本上有两种角色存在：创造 者（c r e a t o r）和推动者（f a c i l i t a t o r）。创造者是一些专业 人员，例如开发程序、行销、软件品保和文件撰写；而推 动者则负责凝聚团队共识和维持最佳的开发环境。在这里 可以无忧无虑地尽情发挥创意，有充足的资源解决问题和 实现理想，组织的运作非常有效率。推动者就是项目经理 或一般的管理者，他们的能力不直接显示在产品中，但却 是推动产品成功的保姆。推动者必须像创造者一样对最后的成果负责，而创造 者也必须像推动者一样对团队共识负责。让两种角色互相 负责是很好的做法，可以互助互补。传统阶层式组织的重 要性逐渐降低，权力来自于知识，而非地位，这是一项革 命性的突破，值得所有的软件开发组织深思。
88
管理者的角色是舵手 下载
法则 8
Use program managers 项目经理的职责
90项目经理是软件开发团队的一份子，他的职责是： 领导大家定义出一个成功的产品。 引导大家对产品注入深切的期望和信念。 带领团队将理想实现，变成可预见的产品诞生。 要定义“项目经理是什么”，倒不如从定义“项目经理不是什么”，还比较简单些。一位项目经理实际所扮演 的角色并不是一般人直觉上想到的工作性质而已。项目经理并没有（或只有很少的）正式的权力或地位， 至少刚开始时是如此，所以项目经理通常会为此感到非常 地焦虑。笨蛋项目经理可能以为他的工作是写出软件规格， 让其它人去写程序、测试程序、撰写文件等等，最后完成 项目经理心目中理想的成品。在最好的情况下，别人会认 为他天真；在最坏的情况下，别人会认为他愚蠢、成事不 足败事有余。在项目经理可以对团队有任何的价值之前， 不应该有任何直接的控制权；幸好，一个健全的开发团队 不会让这种事情发生，组员会适时阻止项目经理不当地直 接控制。当然这类事件会导致在项目经理心中有些气愤和挫 折，因而要求上级授予更多的权力，如果上级愚蠢到真的 这么做，就会导致更严重的愚蠢事件（请参考法则 9：要 下载
权威，不要霸权）。 微软团队·成 功 秘 诀法则8建项目经理的职责 91
通常是等到情况已经坏到无可救药 时，项目经理才会明白“政治”只 是合法的借口。
对于这类项目经理的挫折感，我见过很多不同类型的 反应。最常见的一种是项目经理开始对他真正的角色─ 领导─做出负面的、反叛性的行为，这种行为通常是通 过对“政治垃圾”（political bullshit）的厌恶来表现。除了 对科技要有一定的知识之外，软件开发团队的领导人还得 具备对人性高度敏锐的观察力，必须能够看出在团队外在 行为背后那些隐藏着的情绪因素。可想而知，有些专案经 理为了避免那些剪不断理还乱的人性问题，开始寻求比较“清爽”的自我形象，而在软件公司中免不了的科技挂帅 文化，很容易视“政治”为畏途。当然，驾驭技术要比掌 握人性要简单多了。然而，当人们抱怨政治的奸诈诡谲时， 其实是对不良领导的反感所致。不幸的是这种不满的情况 比比皆是，健全的组织却少得多。于是失败的项目经理把
92过错推到“政治”这个字眼。然而，大概要等到情况已经 坏到无可救药时，专案经理才会明白“政治”只是合法的 借口，他应该用领导代替控制，才懂得为自己的偏执负责。 有谁愿意身处于乌烟瘴气的组织环境？但是当项目经理或 任何人伤害组织的健全性时，那就是走向失败。虽然刚开始时项目经理对自己的角色非常不确定，不 能肯定自己对项目的贡献度，还对政治嗤之以鼻，不过当 他了解到应该以领导代替控制时，就会觉得一切都得心应 手。项目经理应该是以栽培和教育的全方位领导，来引领 软件的发展。项目经理应该要有技术的背景，而且必须在两种层 面非常专精：一是对开发产品所使用的技术很熟悉，二 是拥有建构软件的技术领导能力，而后者是本书主要的 讨论范围。项目经理必须精于哄骗、驱策、鼓励、要求 他的团队做出最好的软件和表现出最好的工作效能，他 清楚知道软件制作过程中每一项的投入和产出细节，他 必须懂得用最好的方式定义产品和维持健全的技术。最 后，项目经理还必须是团队的发言人，面对媒体、客户、 以及整个组织。 项目经理是维系团队灵魂的关键人物，他应该是擅长 法则8建项目经理的职责 93沟通和倾听的人，具有设身处地为他人着想的本领。总之， 项目经理是软件开发的核心人物。
团队的精神在此我强调一个观念，在后面也会再重复提及：软件 代表着创造它的团队。你想了解这个团队？看看他们的软 件就知道了，反之亦然。我特别强调这个观念是因为这是 软件开发管理的基础。在某一个时间点或是从某一段描述 中，或是从这个团队的行为，常常无法准确判断这是个什 么样的团队，但软件不会说谎。软件会忠实地展现创造它 的团队：一切优点和缺点，天赋和天谴，从潜伏期的小病 到最极致的团队合作。若对这个团队有任何疑问？他们的 软件作品就是答案。如果你的询问对象是人，你还得注意 他的表情和肢体等等隐性语言，但是如果你仔细研究他们 的软件作品，你不必问任何人就知道他们团队有没有问题。 软件会自我表达，它绝不说谎，也不隐瞒。这项理论是软件开发管理的基础，可以用一个恒等式 表示： 团队＝软件 (team = software)
94基本的原则是：如果你对团队有任何疑惑，去看他们 的软件；如果二者一致，你可以相信自己看到的团队现状。 相反地，如果软件未能表现出应有的水准，表示团队有问 题，不论团队看起来多么健康，你都应该去分析、去发掘， 找出问题解决掉。
团队的精神 法则8建项目经理的职责 95团队等于软件，不错，但团队是什么呢？你是以什么 方式或风格领导这个团队？我相信软件开发的关键是与“团队精神”（group psyche）保持密切的连系（P s y c h e是 小爱神丘比特所爱的美少女的名字，原意是灵魂或精神， 这里的灵魂不是宗教上的含义，那是s o u l，精神也不是强 调团队的合作协调，那是t e a m w o r k，group psyche是指一 群人所共有的中心思想和心理状态）。这样说很抽象，下 面是“团队精神”的具体描述：1. 一群人同心协力，集合大家的脑力，共同创造一项 智能财产。2. 个人的创造力是一种神奇的东西，源自于潜在的人 类心智潜能，它被情感丰富，而被技术束缚。3. 一群人全心全意地贡献自己的创造力，结合成巨大 的力量。结合的创造力由于这一群人的互动关系、彼此激 荡，而更加复杂。4. 这种复杂的情况之下，领导变成像是人际互动的交 响乐指挥，辅助并疏导各种微妙的人际沟通。5. 在团体中的沟通和互动是正确而健康时，能够使这 一群人的力量完全结合，会产生相加相乘的效果，抵销互 斥。沟通顺畅能使思想在团队中充分交流传达。
966. 团队工作的品质比时程更重要，而作品的伟大是需 要对“团队精神”特别加强，才能达成。“团队精神”可 视为个别成员精神的平均值，而个人的精神（p s y c h e）则 是使他能感觉、能思考、能推论的内在力量。7. 倘若忽视了“团队精神”，则只会有平庸的成果。 那么，如何照顾“团队精神”呢？我的答案就在本 书中。 下载
法则 9
Be an authority ， not an authority figure 要权威，不要霸权
98在组织中，大多数人都会寻求一种权威，而不在乎这 种管理风格好或不好。这种心理现象可能是因为人们希望 重建来自家庭的权力结构：父母亲控制并保护孩子，而孩 子依靠父母。无论这种需求来自何处，人们迫切地需要权 力和依靠的对象，以致将领导者投射成权威的化身──也 许另一方面管理者也有迫切的掌权欲望吧。权威的目的是让每一位团队成员都有自己的专业权 威，和团队的专业自信，这才是管理者真正的权威。在任何社会中，人们总是会将群体投射到自己所熟悉 自在的心理结构，这种倾向在工作团体中特别明显。人们 会很自然地将工作中所遇到的他或她，比拟成过去相处过 的人物，特别容易将管理者当成父母，更有甚者，团队中 最优秀的人可能会将组织中的高层人物比拟成某位权威人 士。这种奇怪的不理性现象必然造成管理者有一种“霸权” 的形象产生。就像在家里一样，一个健康的组织一定会经历三个阶 段：孩童期、青春期和成熟期。在团队成立之初的孩童期， 组员通常会不知不觉地将管理者当成无所不能的权威人 物：决定事情的人、保障资源的人、主宰奖赏和惩罚的人。 而组员则早已预设了自己的角色：服膺阶级。由于他们对 法则9建要权威，不要霸权 99权威的信赖，在组员心里会投射出一大堆“应该如此”的 模式到管理者的形像上，他们会说：“事情应该是这样。” 并把团队与管理者之间的关系看得单纯而天真。这种管理 者“应该如此”的模式包括了领袖特质、权威和成就等等， 其实没什么实质上的意义，睿智的管理者应该避免浪费时 间去探究在每个人心目中的权威形象。
让每个人都有权威，而 不是让管理者独霸权力
100
人们倾向将管理者当成像父母般的 权威。
如果管理者接受了这种幼稚的权威形象，和不健康的“领导者－团队成员”关系，整个团队就永远停留在孩童 期。千万记住我们的目标是让团队中的每一个份子都有权 威，而不是把权威集中给管理者。管理者也许要花一点时 间才能让大家接受这个观念，也许在过程中会有人抱怨， 但团队一定要有对权威的正确观念才能成长。对于一个不 成熟的团队，为它描绘目标比凝聚它的共识容易，你可以 召集所有的人在一起，告诉他们你为他们拟定的目标是什 么，这是短期的做法，长期来看，一定会有技术或产品的 专家脱颖而出，主导大家对产品的目标，而管理者必须相 信并支持这个目标，并且将它传递给整个团队。
充分授权 我很想找另一个字来表达“充分授权”(e m p o w e r- m e n t)的涵义，因为这个字现在已经被用滥了。不论它 法则9建要权威，不要霸权
101 用什么样的名词表达，这个观念永远是创造智能财产 团 队 的 中 心 价 值 。 人 们 经 常 分 不 清 楚 准 许（p e r m i s s i v e n e s s）和授权（e m p o w e r m e n t）的差异，前 者是“让组员去做任何他认为最好的事”，后者是“让组员能够思考，然后尽全力去做”，完全是不同的 两回事。充分授权是让组员能够全力发挥，无所阻碍， 是为他们清除各种不同的障碍，让他们以自己的力量 达到某种成就。自由是充分授权的基石，让他自由判 断和实行判断，自由地思考和表达他认为应该思考和 表达的事情，自由地冒险尝试，而不必怕受到额外的 惩罚。充分授权是充分学习的结果，而不是忽视他， 让他胡搞瞎搞。当管理者对属下说：“这是你的决定” 时，他必须已经提供完善的支持─训练、信息、资 源─让属下能够做出正确的决定，这样才算是充分 授权。否则的话，让属下做决定等于是弃他于不顾。如果每个人都能获得充分的授权，那么在冲突 发生时该怎么做决定？这是一个理论上的问题，实际 上不会发生。在充分授权的环境中，不是无政府的混 乱而是事实和才能领导一切，每个人都有安全感，因
102
此而会放弃因为骄傲所造成的愚蠢、去除自我的狭隘 心态，于是软件的设计开发以及决策问题就变成是单 纯的资源分配运用。一个充分授权的团队有能力分析 各种方法的优点和缺点，并且能够选择对目标最有利 的方法，决策没有对或错，而是在产品功能、资源与 时间三者之间的权衡（trade-off）。你知道如何组织团队，辅导团队成长，由于你提供好 的技术和程序等等环境，充分授权团队如期完成软件产品， 不断成长再成长，这一切造就了你个人的权威。你的见识 是“团队精神”、“团队作品”以及二者之间的关系。你真 正的权威是来自这些事情，而不是公司赋予你的阶级或是 地位，也不是属下的权威依靠需求所投射出来的虚象。但 威权是人们对权力形象的需要，那是向人们保证有人关心 他，有人保护他的利益，有人让他尊敬崇拜，而不是真正 的权威。那么，真正的权威会有什么影响力？那是你知道自己 在做什么，让组员了解你在做什么，并且让组员和你一起 努力，大家一起为目标创造价值。一个孩童期的团队自然不太懂得接受充分授权，有人 会抱怨没有目标，缺乏明确的目标，并且不愿去做困难的 法则9建要权威，不要霸权
103 决策等等。这种时候，要激发团队成长最好的方法是集中 心力在软件如期完成的目标上，管理者只要对软件产品进 度和品质负成败责任，让每一个人都卷起袖子干活儿，不 要去理会什么阶级和分工的界线，专心使软件如期完成， 将目标单纯化，排除一切干扰。管理者以这种姿态融入团 队的工作，很自然会打破霸权迷信，引领团队自我成长。 这是“权威”，是行动，是一起创造软件的工作，绝不是 谁决定什么、谁决定奖惩的“霸权”。 下载
竞 争 竞 争 竞 争 竞 争
105 在任何市场中，都会有下列四种情形之一： 没有竞争对手。 与竞争对手不相上下。 落后竞争对手。 领先竞争对手。 无论是那一种情况，都必须对市场未来的方向、竞争对手可能的动向以及自己的竞争地位与走向做出正确的判 断。
人类学缩影在我们开始分析这四种市场状况的不同性质和适当对 策之前，让我们先花点时间思考天然竞争的经验。我想由 人类学专家来谈会更好，但我觉得商场上的竞争环境在本 质上是人类竞争的缩影，还可能更激烈些。在竞争中，只 有胜利者和失败者两种角色。威胁、梦想、恐惧和希望萦 绕在参赛者心中，在内心复杂而对立的情绪冲击之下，激 发出创造的能量，使他能一心致力于创造伟大的成就。商业竞争源自于人类对战争的原始渴望，其本质就是 征服敌人、掠夺其财产和毁灭其未来，和野蛮人比起来说 也许只是形式上比较美观吧！竞争就是将他人的资源据为
106
己用，以敌人后代子孙的生活环境为代价，换取自己后代 子孙的更优越的生活环境。虽然现在的人类竞争已经不再以生命厮杀，但却发展 出团队对团队的资源竞争，而且不再以猎物、财产或领地 为标的。我们也许可以获致一个结论：现存的人类，是那 些倾向以合作方式共同追求某项目标的人群，我们把这种 合作的倾向（genetic predisposition，原意为遗传体质，是 作者的譬喻）称之为“团队合作”（t e a m w o r k）。对某些人 来说这个名词意味着软弱的仁善和无效的好意，但一个比 较夸大的比喻是：一群邪恶的狼正在分食一只羔羊，狼群 不会为争食羔羊而自相残杀，只会残杀所捕捉到的猎物。
为了竞争，必须合作 竞 争
107 团队侵略具有毁灭性的力量，听起来不怎么令人舒服。 事实上商业的竞争行为只是千百年来人类演化活动的现代 版。我们可以合理地论断，人类之所以选择团队合作能力 的基因存活下来，因为这是非常有效的成功方程式，比任 何其他非团队合作的策略都更有效。因而我们不得不相信 这样的竞争和演化过程仍然在持续进行着。我并不想对这项人类特质作任何的道德判断，但我 个人倾向相信这种团队合作的特质在人类演化过程中扮 演着极重要的角色。文明、沟通、爱、忠诚、信赖，甚 至狡滑和想像力都根源于这种特质。征服对手、弑杀猎 物和夺取生存空间的欲望在人类活动中展现无遗，我们 在思考群体组织和竞争情势时必须将这些因素都列入考 虑。在你的团队中的所有的人们，都是曾经合作并取得 胜利的人类后代。如果我们将竞争者视为敌人，那么市场就是大家争 夺的猎物，或是给企业后代的丰沛资源的土地。如果我 们夺取了市场，就等于是掠夺了敌人的财产，将敌人赶 走或歼灭。我们必须了解，任何有利可图的市场都会有竞争者 出现，只是时间早晚的问题。竞争者会组织他们的团队
108
和你抗衡，争夺你的市场，拼命地想将你逐出摧毁，你 也是一样。
软件竞争在你展开任何项目之前，都必须对竞争态势做彻底 仔细的评估。在这个软件开发生存日益困难的行业中， 竞争是比较私人性的，不像在传统产业中整个企业处在 一个较大的领域中竞争。软件的创造是个人的思考和创 意，而竞争则是个人的智能对个人的智能，其竞争态势 的变化也比任何一种传统产业快得多，并且游戏规则也 不太一样。传统产业是对每一张订单，比比看谁的处理 行动最快最敏捷，但软件业就复杂多了。我们已经站在 信息科技的尖端，某一些软件产品、技术可能在一年之 内就完全改头换面。因为在产品的生命周期还没到尾声 时，市场就可能已经发生根本的变化，所以很难将软件 的竞争当成单一的市场来看待。 竞 争
因为在产品的生命周期还没到尾声时,市 场就可能已经发生根本的变化,所以很难 将软件的竞争当成单一的市场来看待。
因为软件业变化得太快，软件产品的全球性行销策略 就必须既新颖又深入。高科技的进步是以令人窒息的加速 度在奔驰，每天都有新的变化。 2 0 0 0年的版本当然要比1 9 9 9年的版本功能更强大，而向全世界宣传新版本有什么 新的、高价值的特色，就成为重要而紧急的任务。如果你无法时时掌握时代的脉搏，如果你怠于响应周 围迅速而剧烈的变化，特别是竞争者的行动，如果你不能 持续地创新原有的技术，永远保持领先，那么别人马上就 会趁虚而入，取代你而成为市场上的优胜者，掳获顾客的 心和他们的荷包。
确定了你的情况之后，应该先考虑 采取标准步法。
110
软件的竞争 很显然，在任何竞争环境中都会有无数的方法反击对 手，但我们仅讨论前面所提的四种典型。就像棋局一样， 有一些开场的标准步法（classic moves），就像是对招一样，有什么样的攻击招式，用什么样的对应招式，就看你所面 对的情况了。 下载
法则 10
Alone A market without a competitor ain't没有竞争对手？未必 是好事
112
我们常听到某家公司认为自己在市场上没有竞争对 手，因为他们有独特的产品特色、渠道，或是他们的定位 独树一帜，没有人能与之相提并论。当然，在某些情况下， 上述的说法可能是真的，尤其是一些新开辟的市场，或是 非常专门、具有独占本质的市场。不过，在一般的情况下， 这种定位并不恰当，理由如下：首先，这种说法代表了一种错误的价值观，认为“没 有竞争对手”是一件好事，有些公司夸耀自己没有遇到竞 争者，并且认为这代表了灿烂的景象。我认为这个观点不 一定对，如果一个市场够健康，它一定会吸引竞争者。事 实上，竞争者通常会采取和你有相同功能的行销策略，“帮忙”你形成一个市场，和你同时开拓市场。 第二，如果竞争者紧追不舍，抄袭你最成功的产品特色时，你要领导市场就非常困难。但是竞争者的抄袭动作 也等于是肯定了你的市场领导地位。经验证明，成为市场 中的惟一会导致某种不安，不一定是好事。如果你决定投 资开发一项划时代的新技术，你需要有一个可比较的标杆 来证明自己有长足的进步，而且必须造成市场上的某种冲 击。如果没有人想要你的市场，这个市场还有什么价值？ 第三，如果你是市场中的惟一，就没有办法在顾客心 法则10建没有竞争对手？未必是好事
113 中建立鲜明而独特的形象。诚然，在顾客心目中你的公司 和你的产品功能会是同义词，但他们对你的技术特点还是 模糊不清的。顾客既没有选择，也就没有认同。顾客如果 经过比较才选择购买你的产品，他们才能识别你的特点（i d e n t i f i c a t i o n），也才能够解释他为什么做这样的选择。 然而若你是市场中的惟一，顾客在心理上就没有必要特别 去认识你的特征，去了解你和别人不同的地方。很多非常 棒的想法之所以没有被采纳，是因为本来就已经是惟一了， 没有可比较的对象来显示它的优异。每一项采购都是一种 大胆的冒险。虽然在导入软件的初期，厂商可以和顾客密 切地合作，共同努力，并建立良好的关系。但大多数的情 况是：顾客如果在市场真正起飞之前购买惟一的产品，最 后都会感到失望和幻灭。
市场中的独占者，反而很难向顾客 传递独特的产品信息。
当然，我们前面提过了，市场中的惟一有两种情况： 一种是新兴市场（nascent market）。为了成为市场先驱，
114
快速扩张市场占有率是每一个软件公司的梦想；然而很 不幸地，要在一片处女市场中开疆拓土需要庞大的投资， 风险也高，大概只有最大也是财务最健全的公司才会考 虑，或者是那些恰好早就已经在顾客心目中占有一席之 地的公司。开拓新兴市场至少会有两个层面的问题：首先，如何 将信息传达给顾客？新功能和新技术通常很复杂，很难解 释清楚，必须做过相当大幅度的浓缩和摘要，才有可能清 楚地告诉顾客。除非你有一位沟通天才，再加上顾客正好 有明显且紧急的需要，而你的产品正中红心，否则你的行 销费用将和效果将不成比例。第二个层面的问题是，通常新产品都需要大量的行销 活动，时间拖得愈长，胜算就愈低。在你经过包装、塑造 产品形象、定价、建立渠道和一般性的沟通之后，你已经 没有多少预算了，也许撑不到第二回合。对于独占的竞争态势，不需要再多谈了，如果你没有 竞争对手，你应该知道，而且你大概也晓得该如何维护你 的市场。 下载
法则 11
Dead beat Break out of a feature shoot-out 竞争者紧追不舍？推 出创新的功能特色
116
在白热化竞争的市场态势中，尤其是当第一名尚未确 定时，大家都会竞相推出创新的产品功能，以显示与对手 的差异并吸引顾客的青睐。此时评估产品优劣的重点是看 谁的产品有什么功能特色，以及品质的高下程度。你大概 听过c h e c k - b o x（条列出数个选项，使用者在需要的选项 打上一个小叉）的勾选方式吧，类似这种的产品功能特色， 常常用来当作评比的项目，看看市场中的产品谁有／谁没 有这个特色。结果是免不了开发一些花俏的产品特色，只 是为了满足媒体评论者，或是某些经销商的要求，让他们 觉得这个产品不落人后。 这种竞争方式的成本很高，也没有效率。
愈来愈多的产品功能特色，会使软 件庞大而脆弱。
如果撇开定价、渠道、服务等因素不谈，纯粹就软 件本身来看，有两种主要的策略可以赢得产品特色的竞 赛（feature shoot-out）。一种方式是你推出遥遥领先竞争 者的产品特色，使他在一两个产品周期内都无法赶上。 法则11建竞争者紧追不舍？推出创新的功能特色
117 这是蛮力的方式（brute-force approach）。这个策略的困难 是，由于你的创新必须有大幅度的跃进，产品的复杂度 会明显飙升，很难以简明而有力的方式向顾客说明这个 产品特色如何使用、有何好处等等，而且功能特色会一 次比一次更难做，软件产品会因此庞大而脆弱，稳定性 不易维持，软件愈庞大，改版就需要愈长的时间，这是 无法避免的。当你采取这种大幅跃进的功能特色作为竞争策略时， 必须是你的竞争者也采行相同的策略，而且你能确定他的 特色无法跟你相比，而且在短时间内也无法赶上，这种方 法值得一试，但不是最好的方法，而且这样做并不能创造 出伟大的软件。另一种能够赢得产品功能特色竞赛的策略是大量投 资在典范性的功能特色（paradigm-shifting features）上， 而且功能特色要多到让对手无法在这个典范性领域中与 你一较长短，通常至少要有三项才够安全。一旦你建立 了在这个典范性领域中的王朝，你的对手就会暂时被逼 退，即使对方原本略胜你一筹。缺少几个竞争者有的（也许华而不实）产品特色无所谓，只要你真的改变了使 用者的工作方式，赢的何止千百倍？最重要的是确定真
118
的能改变使用者的工作方式，否则只不过是在产品特色 竞赛中平添一笔罢了。
典型性功能特色是你决胜的一击 下载
法则 12
Behind Ship more often with new stuffs 落后竞争对手？加大投 入，更快推出新版本
120
软件业中没有两个完全相同的失败。产品失败有数不 清个可能因素，但是最常见的莫过于新版本无法跟上对手 的脚步。如果对手领先你一两个版本周期（release cycles）， 那你就非常危险了，而且非得彻底检讨、重新定位不可。
如果上帝对你够仁慈，让你活着， 你还有机会继续奋战。
集中火力强化产品本身需要大量的成本，而且你可能 因为在短时间内要开发这么多新功能，而使得团队乱了脚 步，这个结果的危险更大，绝对足以使任何种类的软件产 品被三振出局。因为落后对手，团队的士气已经痛苦不堪。 但这剂猛药的风险非常高，就像化学治疗一样，治疗可能 比疾病更伤人。发现自己处于下风实在令人沮丧，媒体、上级、同事、 顾客、全世界都知道你的表现不佳。这是非常可怕的感觉， 而且结果也不晓得会如何。如果上帝对你够仁慈，让你活着，你还有机会继续奋 战。但痛苦的煎熬还在后头。特别是你必须向全世界宣示 法则12建落后竞争对手？加大投入，更快推出新版本
121 你打死不退的决心。这一点非常重要，因为没有人会买软 件开发公司可能会放弃的产品。省下和媒体说明的精力，就让他们批评吧！反正无论 如何辩解，他们都是照批不误。不如专心集结所有的资源， 好好准备下一场战役，你只是输了一着，并没有输掉全局。 保留实力，你还是有赢的机会。不要提前宣布计划。虽然你需要宣传，需要挽回面子， 也需要给老顾客一线希望，但是绝对不要在产品完工前放 话出去。这个举动太危险，等于是降低了产品推出时的震 撼效果。对自己和对团队内部都要承认失败的事实，不要粉饰 太平（对别人就不必提了）。确实找出最重要的毛病，把 它实时修正，然后重新出发。如果问题是软件的错虫太严重，当然得在下一版之 前全力大扫荡，至少一定要消灭掉最主要的错虫。这是 非常艰巨耗时的工作，可能会吸干你的资源。即便如此， 也尽量不要向顾客收取除虫版的费用，虫虫危机不是顾 客的错。 我认为取得市场领导地位的要诀只有一个词：残忍 （r e l e n t l e s s）。你必须在追求卓越时残忍，也在展开攻击时
122
残忍。最有效的战术是比对手更快速地推出新产品。这个 观念是：让你的顾客对你有信心，显示你旺盛的企图。如 果软件竞争是一场比赛，顾客就是观众。观众喜欢看精彩 的对决，而且他们有权决定谁输谁赢。所以，站起来吧！ 即使战局不利，向顾客展现你的实力，看你如何扳回一 城。 如果你的团队能够持续地比竞争对手更快推出新产 品，并且将投入的成本大约控制在合理的程度，那你终究 会赢！产品推出是最困难的事情，如果你做得比竞争者好， 那你很有希望在别的地方也表现得比他好。准时地、经常 地推出新产品是软件开发产业中最大的金科玉律。 下载
法则 13
Ahead Don't ever look back 领先竞争对手？不要 回头
124
已经领先竞争对手？恭喜你终于可以称霸群雄，现在 你遇到的困难是继续领导这个产品领域的方向，开拓新的 技术以及伴随而来的新机会。自满是你最大的敌人，请牢 记下面几件事：你无法永远保持领先。随时有人在伺机攻击你，你不 知道敌人是谁？用什么方法？在什么时候？你必须与自己竞争。现在你该把典范性功能特色的投 资增加为原来的三倍，每一次改版的内容要更丰富（虽然 你已经拿下冠军宝座），建立你更高层次的冠军地位。
让每一个人都知道你勇往直前，绝 不回头。
将改变的速度提高到别人无法赶上的程度。身为市 场领袖，你有机会自由决定自己的日程和更新版本的速 度。照理说，你的获利要比别人都高，你应该增加投资 更稳固你的领先地位。打下江山固然困难，守住基业更 不容易。记住，如果让你的竞争者拿下推出速度的控制 权，那你很可能就会丧失领先地位，至少被迫做出相对 法则13建领先竞争对手？不要回头
125 的响应。高科技产品的生命周期是以月来计算，而不是 以年来计算，而产品的世代交替是这么地快速，随时都 可能一夕之间山河变色，所以你一定要保持自己迅捷的 行动能力。要有破釜沉舟的决心。巩固现有的地位之外，你必 须继续朝更高的目标挑战。让每一个人都知道你勇往直 前，绝不回头。你不能被现状限制了向前的脚步，兼容 性是重要的，在你向前直奔的同时，保证产品的兼容性， 让顾客跟着你一起向前走，而不是被顾客或其他人拖 住。 下载
法则 14
Take the Oxygen along 保持新鲜 法则14建保持新鲜
127 当你决定为个人计算机开发软件产品，特别是在微软 的视窗环境之下时，你必须有一种认识：你不只是在开发 软件，你在选择一种生活哲学。它改变的速度快得令人窒 息，就像是科技和社会的变迁一样。快到在你还没有适应 过来时就得再更新。分析、开发、建置、维护的过程再也 不是一套操作化的公式。操作系统的全球化快速改版已经是信息时代的基本特 质，这驱使了软件不停地改变。不只是软件，包括硬件、 外围设备和大众通信的厂商都因为操作系统的版本更迭交 替而受到很大的影响。这种快速变迁的节奏是信息社会的 常态，也是你不能与之对抗的。
快速变迁的节奏是信息社会的常态， 你必须快速前进，否则就落伍了。
对全球化的信息科技作出迅捷的反应是组织健全的基 本条件，而不是特殊功勋。软件包厂商将他们的技术包装 在产品中卖给顾客，而产品本身就是最主要的沟通工具。 为了解决现在的问题，厂商开发下一个版本，这是持续性
128
的购买行为，不是买过一次就算了。 操作系统厂商频频推出新版本，并不是为了自己的好处（虽然这样做对他很有利），最主要的目的还是将新的 科技纳入产品，让顾客都能使用。而如果在 P C上开发应 用软件的厂商跳过一个操作系统版本，顾客就得不到使用 新版操作系统的好处，比如说速度无法提升或是觉得用到 了次级产品等等。不要忽视潮流的力量，不要错过潮流。想想看你对汽 车、时装或是流行音乐的追求和感受，就能明白潮流是不 可抵挡。你的顾客也会喜欢最新、最方便的科技。所以， 将潮流纳入你的产品开发计划中吧！
吸收最新鲜的氧气 下载

返回书籍页