小说下载尽在http://bbs.txtnovel.com---书香门第【亦安】整理
附：【本作品来自互联网,本人不做任何负责】内容版权归作者所有!
第一篇布局时期
多探讨软件开发的书籍都假设自己存在于理想的状 态下：团队本来就应该非常专心且克尽职责地完成 工作，并完全掌握任务的本质；他们收集得到完整的需求 情报，建立设计规格，并导引软件原型（ prototype）一次 又一次的蜕变；他们请求使用者参与，使用者便会全力配合，而且非常认真地与开发团队共同完成深入的需求分析。 所有的事情都是那么完美顺利。很不幸地，理想状态是不 存在于现实世界的，在真正的软件开发项目中，您可能看 不到一丝一毫属于完美顺利的景象，而且看到的恐怕只有 一堆的问题。
不只是问题，还有可怕的挑战。优秀的开发团队在布 局时期必须做的事情多如牛毛、广如大海，我们大略分为 五个范畴：组织、竞争、顾客、设计、开发。布局时期的 工作是多维的，而且必须在每一个细节中都能综合、兼顾 所有预期的结果。
下载组织开发团队 组织开发团队 组织开发团队我所谓的组织，是指集结适当的人选分别担任下列角色并参与设计：
项目管理（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 Education)─负责以文字表达正确的产品使用方法。
这里所谈到的设计，是指软件产品的设计，不是指 写程序或程序设计。读者耳熟能详的“程序设计师”， 译自Programmer一词，虽然这种工作有相当的设计成 分，但这种设计比较不是艺术性的，而是工程性的。 原 作 者 甚 至 鲜 少 使 用 Programmer 一 词 ， 而 以 Developer表达。概略地说，软件产品设计是厘定目 标，事先定义出软件要做到的功能，本产品预定要满 足什么需求，目标顾客是什么样的，主要的硬件或操作系统环境等等。—译者注您不一定要将自己的团队成员划分成这五种角色（虽 然我认为这是最有效率的做法），但务必要确定这些工作 都有适当的负责人选。请注意每一种角色都有参与设计， 如此每一位成员对项目都有整体性且清楚的认知，使每一 位成员的目标是一致的。
如果您的开发团队无法合作无间，对于目标老是有不 同的意见。那么，首先要做的是找出不团结的真正原因。
品保人员（QA）是少数民族？
如果品保人员认为他的工作是测试程序，而开发人员 认为他的工作是写程序给品保人员测试，那就得小心了， 这是一个警讯。这种情况会造成开发人员和品保人员之间 的疏离，开发人员的优越感会使品保人员感觉自己是被歧 视的少数民族，当然会影响到软件的品质。品保人员的最 主要功能，是不断鉴定和评估产品的现状，是否在品质上 和功能上确实遵行产品目标，而让其他的人员专心投入他 的职务。
品保人员的评估工作是一项整体性、持续性软件开发 活动中的一环，而不是偶尔来点缀一下。好的评估报告在本质上应有客观的分析和衡量标准，如此才能导引软件产品符合现实的需要。这种导引的重要性是不容轻忽的。因 为在开发过程中，开发人员可能因为一些偶发的小事或某 种无关的灵感而不知不觉地偏离了现实的需要，暂时忘记 了什么才是产品最该有的功能。品保人员的职责就是为软 件的品质把关，以现实、客观而市场导向的眼光，不断地 检视软件产品。
谁来设计产品？
如果项目经理、产品经理、开发人员不断争论谁有权 设计产品或是各执一词，这是一个愚蠢的开发团队，只会 关心自己的权威；然而，真正的权威是来自于对现实状况 的精确掌握。产品设计的目的是将最好的想法列为产品的 基础，每一位工作人员都应该为此努力。至于什么是最好 的想法，应该在项目真正开始之前就通过实地检验。市场 调查是很好的方法，不需要太多的时间或成本，就可迅速 平息大家对于产品设计的争论。我们在下文中会讨论如何 增进彼此之间了解，这也是解决方法之一，精确缜密的思 考通常能使问题柳暗花明。
权力争夺战会迫使人们心胸狭窄，互相竞争而不合作。
产品设计的争论是权力的争夺战，会使人们心胸狭窄， 互相竞争而不合作。可能有人主张产品在这项功能上有所 不足，结果焦点变成了功能而不是产品本身。一位有智能 的领导人应该将争论视为组织出现问题的症状，而去发掘 问题的根源，这比仲裁这项争论要有用得多。在这方面我 的经验与传统所谓的智能刚好相反，我认为用职权裁定谁 有产品设计权是毫无用处的，虽然改变正式的产品设计权 或许有点帮助。
老实说，谈这个谁来掌权、谁来负责的主题并不有趣， 而且解决这个问题非常浪费时间。组织健全的团队是适才 适任，各司其职的；此外，每个人的除了各自专司的角色 之外，还担任一般的角色（ generic role），这一点也受到 管理者的肯定，因此角色与能力之间的关系能够取得和谐。 一般角色会使团队更能融为一体，互相支持。团队是一种 平衡的生态，人与人之间的职权界线像是和睦邻人的关系，于是，对每一位单独个体都有足够的尊重，整体的效能也达到最佳化。这种平衡的组织生态是自然生成的，强制性 的外力干预只会造成负面的影响。如果团队成员彼此的关 系无法做到亦邻亦友的和谐，领导人必须分析原因。通常 如果利益分配不公平，或有多人争夺同一项利益，或是提 供的报酬不够齐全，不平衡就会发生；有时候管理方面欠 缺弹性也会造成资源必须用人为的方式重新分配，效果不 一定会好。
在任何项目开始之前，项目经理必须弄清楚团队中有 哪些地方需要特别的注意，尤其是团队的变动性（ team dynamics）。就像团队中的每一份子必须清楚要做什么工 作、有什么资源、目标在哪里，项目经理也必须设计自己 所要带领的团队该有什么样子，自己该如何“激活”这个 团队。因此，我们导出了法则1。
下载法则建立一个共同的目标乍看之下，这何需赘述，但这却是相当困难的事。团队中每一位成员都必须非常清楚我们要做什么、成品会是 什么模样、基本的产品策略是什么、什么时候必须完成。 凡是与共同目标相冲突的看法都必须转化成一致，而不是 把它消音。和谐的共识是绝对必要的，否则软件不可能做 得好，很多事会复杂化而难以收拾。
建立共同目标的方法从独裁式的极端到放羊式的极 端，中间有无数不同的方法，但在我们讨论这些方法之前， 得先说明何谓目标，毕竟目标的建立已是现今衡量领导能 力的指针之一。简单地说，目标是共同的希望，对未来的 事情所描绘出来的景象。
目标一词常被政治家或经济学家使用。任何一位好的 领导者，都有责任为其追随者创造目标。以我的看法，领 导者对其组员心理状态的掌握与认知，是目标的开始，然 后领导者对于组员之间复杂的心理状态认知、修正、建立 共同点，融入领导者的个人特质，使得领导者与组员、组 员彼此之间的防卫界线逐渐消失。有共同的目标才能建立 团队的认同感和归属感，大家会觉得我们是一个整体，这 是团队气氛的心理基础。
微软团队成功秘诀团队的认同感和归属感，能消除个体的自利行为。
通常，共同的经验可以作为领导者的感情移入，领导 者用各种不同的形式告诉追随者：我们过去是那样，我们 现在是这样，而我们将来会是什么样。
不论是否有共同的历史，“成功的领导者”能在团队 中营造共鸣，而“群众煽动者”则不能。当组员对领导者 意见相左时，最常见的反应不是直接反对，而是：“是啊， 我们也是这么认为，但我们该怎么办呢？”这时必要的努 力、鼓励和妥协都可能发生。领导者应该自问：“如果换 他们来领导，他们会怎么做？我该如何将他们复杂的情绪 转化成行动力？”这些问题的答案能帮助领导人解决大部 分的问题。
有远见的领导者会构思一个美好的前景，需要大家共 同努力创造；而群众煽动者则是对现状不满，意欲去之而 后快。有远见的领导者会带领不同心态的人朝共同的目标 努力，有时为了长远之计而放弃近利；而群众煽动者则是逞一时之快、急功近利的人。
领导能力与目标是来自领导者与组员之间的心理共鸣， 若非如此，目标会流于虚幻，也无法带动团队迈向成功。
共同的目标微软程序语言部门的故事年的微软程序语言部门，情况实在不乐观。
那年的四月，微软发表了 C7。C7花了超过两年的时 间开发，经历无数次的进度落后和品质恶化，似乎是 一场永无休止的死亡进行曲。而微软的竞争对手已经 抓住这个机会，在Windows版的C和C++上面获得很好 的评价。C7在很多地方都不足以与之竞争，虽然它有 精美的包装、动人的价格、优异的类函数库( c l a s s library）MFC1.0，和微软素以见长的最佳化执行码编 译器(compiler)。这些优点只能使微软勉强维持不被淘 汰出局，但很显然下一版非得大幅扭转劣势不可。
微软的 C/C++ 开发团队经历了好几年的流年不 利，光是项目经理就换了三次。丹尼斯?吉伯特（Denis Gilbert）是新任的资深开发部经理，而我是新 任的行销兼使用者教育部经理；虽然我们都从未领导 过这么庞大的团队（超过两百人），但我俩都充满斗 志，企图有一番作为。杰夫?赫伯（Jeff Harbers）管 理AFX小组，这个小组集结了微软的精英工程师，负 责为C/C++的产品提供“所见即所得”（）的类函数库工具。他们的经验极为宝贵，虽然两组人马的文化差异刚开始 难免造成点小摩擦。
程序语言部门是微软中最古老的部门，第一个 产品就是比尔?盖茨与保罗?爱伦（ Paul Allen）合 写的 Basic 直译器。当微软进入操作系统与应用软件 领域之后，程序语言的重要性相对降低许多。微软的 重心转移之后，尽管微软的程序语言产品有占先的优 势，但开发者的辅助工具方面则跟不上竞争者了。
在1992年，大部分的微软高层主管都希望重新 振作这个部门，也许是被忽略得太久了吧，我无意批 评他们，但我猜多少也是微软扩张得太快太广所致， 无论如何，这使得我和丹尼斯肩负着更重大的责任， 更强烈地希望把事情做好。
对我们的压力与期望不只来自微软高层，还有 来自专业杂志的负面评价和使用者的责难，甚至微软 内部同仁也轻视这个部门。大家都说我们缺乏目标， 是一群笨蛋，要不然就笑我们 C7品质不良，完成日 期老是拖延。就连比尔?盖茨的电子邮件也会带上一 句─程序语言部门是全微软最笨的一群人。这一切不只是没面子而已，我们实在该做点什么。
回想过去这段时日的发展和本部门堆积如山的 工作，我们（主要是丹尼斯）发现本部门一直被以下 的几个错误所蒙蔽：
我们无法完成任务，因为我们没有足够的能力。
即使我们每件事都如期完成，也一样会失去市场。 我们没办法叫媒体不批评，或叫使用者不要抱怨。
我们的人力素质和数量可以做一个项目，最多两个。
跨出重要的第一步丹尼斯征询过所有的经理人的意见，要求他们 将各项项目作个评比，发现每个人都认为Caviar 是最 重要的项目。Caviar 就是Visual C++ for Windows 3.1 的计划代号。我们的结论是只要将 Caviar做得好，又 能在适当时机推出，就是打赢了一场重要战役，甚至 会带来最后的胜利。第二重要的项目是Barrauda，基 本上就是Caviar 的Windows NT 版。
我们必须立刻加强这两个项目，幸运的话两个 都能完成，但若做不到，至少要集中火力在 Caviar。 我们把所有的资源都集中在 C a v i a r ，期望它赢得 Windows 3.1的市场胜利。
于是我们把手上大大小小的项目逐一列出，要大家票选自己认为最重要的项目，以期形成初步的共 识。但丹尼斯并未加强这个共识，他甚至并未再邀请 组员发表意见，因为他已做了决定。我们明白 Caviar 一定要赢，虽然希望渺茫，大家都愿意尽可能贡献自 己的力量。
丹尼斯召来了全体组员，向大家说明我们要如 何打败竞争对手。我们必须将不重要的项目放弃，并 且重新整编改组。
这是一个好的开始，但只不过是开始而已，其 他重要的条件诸如团体共识、决断能力、清楚的目标、 组员心理上的满足感等都还差得远。丹尼斯注意到整 个团队都为无法打败竞争对手而感到愤怒而沮丧。他 自己也有一股驱动力，想把这一切好好整顿。他感受 到只要有人把胜利的希望带进团队，全体组员都会发 誓：“我们要赢！”
会成为 Windows 3.1 的 Visual C++。 丹尼斯的决心点燃了整个团队，Caviar非赢不可，虽然大家对于部分项目必须牺牲放弃不免情绪反弹。 显然丹尼斯已经创造出成功的必要条件，但他还缺少充分条件。
问题接踵而至这群人从来不曾形成团队。我们也没有跨部门 的协调组织，而且当初所期望的充分授权管理方式（consensus-style management)还处于很幼稚可笑的阶 段。我们没有跨版本的产品计划，也没有详尽的技 术规划，过去也从来没有成功的经验作为开发程序 的参考。几乎每个人都高估了我们如期完成的能力， 即使对于我们刚刚设立的新目标也是如此。但无论 如何，弃车保帅的策略和改组行动确实为部门注入 了新的动力，但结果还未见分晓，我们可不知道是 否能一举奏效。
几个月过去了，事实告诉我Caviar实在不太可能 如期完成，事实也告诉我非得如期完成不可。我们已 决定在 1993年的Software Development '93 West展览 上发布 Visual C++ 1.0，同时铺货在各种通路上，要 让竞争者来不及反应。这是我们成功的关键，也是我 们士气和信心的关键，最后的期限是1993年 2月22日。
然而，这时的开发工作只能说是一团糟。我们 仍不断添加零星的功能；好的一面是我们还在不断提升系统效能，坏的一面是几乎无法将模块建构成完整的产品，甚至无法每天产生一次完整的执行档。开发 人员把软件品保当成是黑箱作业，每天丢一份雏型给 品保就继续埋头苦干了，根本不管品保人员为时数周 的测试。
大约在推出前的四个月，我受到了赫伯的严重 警告，他很坦诚地告诉我，如果我真要做好这个产品， 必须改变一些做法。他使我了解到除了我自己，没有 人能阻碍我做该做的事。我明知道该做些什么，却往 往因为某些因素（大多是个人的因素）而退缩不前。 我现在是行销经理，虽然过去在微软的 R&D部门曾 经领导过15 个项目，但从未加入过 C++ 的团队，如 果我再不好好表现，我大概就是第三个卷铺盖走人的 经理了。
赫伯的忠告使我明白我太消沉了。我可以清楚 看到事情是如何一塌糊涂，我有责任改变它，而不是 逃避它。赫伯向来以毫不遮掩、实话实说闻名，而且 总是能够一语中的。我终于被他的话点醒了。
于是我和丹尼斯讨论了眼前的困境。我们其实 无法确定该怎么做才对，但都明白非得有一番彻底的改变不可。当天下午我们便召开了一次小组会议，这件事本身就极不寻常，抓这么多人过来只为宣布一件 小事？是的，我们要在组员的心理上制造一个转折 点。
我们为了求胜已经尽可能减轻不必要的负担， 而我们仍然在市场上失利，在同类产品评比中输给对 手，我们已经受够了失败的滋味─总是在进度严重 落后的情况之下做出平庸的产品─而我们明明知道 自己可以做得更好。只要我们同心协力，我们一定可 以在期限内做出最优良的产品；没有人能阻挡我们， 只除了我们自己（当然也有些不可知的因素）。我愈 思考眼前的处境，以及它对微软公司、对我们的意义， 就愈觉得斗志高昂。
我们有士气、充满活力，一切成功团队所需的 条件我们都有了，只除了共同的目标。我个人有个想 法：我们不但要追上日程，也要做出最伟大的产品 Visual C++ 1.0 ，要令所有的人都刮目相看，尤其是 那些一向对我们避之惟恐不及的营销人员。我们要扭 转战局，让对手俯首称臣。
我的求胜心很强，但矛盾的是，我却不敢告诉我的同事。没有人阻止我说出心中的想法，倒也没有人要求我说，这种时候个人的感觉似乎已经不重要。 我害怕自己被嘲笑：“他是谁啊？新来的嘛，这搞行 销的家伙想教我们写软件？”
然而我再也无法沉默，再不做点事情我在微软 就混不下去了。那天下午我终于告诉全体组员我的感 受，也问问他们的感受：“我受够了挫败，你们也是 吧？作为全微软最差劲的项目经理，我恨透了，外界 的批评令我觉得丢脸，你们也是吧？Visual C++是最 伟大、最值得骄傲的产品，你们难道不这么认为吗？ 我知道我们可以如期完成它，而且用它来给对手一个 迎头痛击，不只我一个人这么想吧？我们将创造微软 的明日世界，我们会大有作为的，不是吗？”
结果，几乎每个人都有类似的感受，纷纷发言 为我补充。我终于整合了共同的目标：我们要准时完 成 Visual C++ 1.0，没有什么事情比它更重要。所有 的资源都投注在这个清楚明白的目标；不必要的枝节 可以牺牲，其他的项目（即使是NT版的Visual C++） 都可以暂缓，全部的人、钱、机器，都押这一注，而 且得立即行动！
会后我们紧接着要求每一个工作小组至少提出五项具体务实的建议，只要对 2 月2 2 日完成 Vi s u a l C++ 有帮助的想法，请大家务必提出来。我获得了 许多宝贵的建议，本书的第三篇“推出日期”中，就 有许多很棒的观念是来自这次的建议。而此时此刻， 大家的心理上和情绪上都有完成目标的强烈的决心， 因此会主动告诉管理者该做什么，然后确实去做。而 我和丹尼斯则负责提供工作环境，凡是对目标有帮助 的，我们都全力支持，甚至包括一些背离传统却实际 可行的构想，这就是员工领导的管理风格( manage- ment-led style)吧。
我个人觉得，在任何项目的执行过程中总有些 “关键时刻”，使大家在心理上和情绪上因此凝聚成对 目标的共识，对共同的目标产生共鸣，对事情的优先 级形成清楚的认知。我无意夸口Visual C++的团队有 多伟大或领导多卓越，我的目的是指出在大家一片士 气低落时促成大家态度转变的关键因素。
首先，有人察觉到了团队发生问题，并勇敢地 指出来。赫伯以他多年丰富的经验，独特的真知灼见， 看出了我们在胡乱挣扎；虽然我们的做法基本上是正确的，但却不够。赫伯没有任何义务帮助我们，但他仍然不吝直言。 赫伯在这件事情上，完全克服了人性的弱点。
一般人很少会主动帮助并未求助的人，尤其是软件开 发这种智能财产的工作。赫伯首先必须对自己的看法 有足够的信心，并且在心理上要冒着很大的风险；然 后，赫伯确信自己的行动对事情有所助益；最后，他 必须不介意是否失去我的友谊。为了帮助整个团队， 他必须冒着得罪我或整个团队的风险。
他的忠言刺伤了我的自尊心，激起了我的防卫 心理，并且刚开始时不断和他争辩。他说我搞砸了一 切，我应该彻底改变做法。我用尽自己的脑力和心力 反击他的“帮助”。而他则以关怀和冷静的事实击退 我的不理性。直到凌晨四点，我还特别记得他冷冷地 说：“别管我的语气，别管是谁告诉你这些，忘掉你 的骄傲，只要你听得进去我的话。”
渐渐地，我想我可以接受他的劝告了，我的情 绪平息，思考也变得更有建设性。我开始觉得不必因 为接受他的建议就感到自己不如他，我太骄傲了。想 通了这一点，我的创造力和旺盛的活力又恢复了。
这个事件的教训是，我们应该坦诚将事实告诉那些当局者迷的人，我们应该告诉他们问题在哪里、 他们的潜力在哪里。如果你的心胸够开阔，当你犯错 时就会有人及时纠正你，甚至提供更有用的建议。如 果你的忠告被曲解成太骄傲或自以为什么都知道，或 者“你是谁？凭什么批评我?”，别管他们的防卫心态， 直接告诉他们的情绪正在混淆事实。如果他们说： “什么，你以为只有你懂软件?”你只要在被拒绝前简 单告诉他们，你只不过提供一些想法，又没有恶意， 何不试着了解呢？
单纯的沟通的效果可能会昙花一现，你必须真 的以彼此的情谊为赌注（有时甚至冒着失去工作的危 险）来讲出实话，如果不是这样，可能很难突破对方 的心防，而打从心底接受你的建议。
这种实话实说需要高度的技巧与智能，但却是 建立共同目标的基础之一。经过不断发掘出最真实的 情况，才是鼓舞团队士气的金钥匙。
然而，真话也得有人听才行。事实是最残酷， 实话最难听，但不论是你自己发现或别人告诉你，你 终究得接受它；缺乏自信心或安全感的人比较难接受事实，而抗拒事实或情绪反应会使人丧失创造力，或是发生错误的直觉。 这是两个阶段的过程，你不只要学会接受事实，还得学着传达真实的信息。传播事实的最佳媒介是情 感，这是你用之不竭的，多付出你的关怀和好意，让 事实被正面地接受。即使你被拒绝，你也可以达到鼓 舞对方的目的。
我们终能如期完成 C++ 的开发，而且它确实是 一件伟大的作品；微软的行销部门也全力支持我们。 我们终于打败竞争者，虽然压力和威胁还在，但我们 毕竟扭转劣势，赢了这一仗。
往后的日子里，我们逐渐建立了版本控制的规 则，我们可以每隔固定的期间发表新的版本，以及共 享版本（请参阅法则3：建立开发多版本的技术规划）， 但最艰苦又最令人难忘的、团队精神最炽热的，还是 那第1版的经验。
下载法则使大家主动投入如果每个人都在认真思考如何使团队更有效率，这个团队自然就比较容易表现出高效率，反之亦然。听起来又 是老生常谈，但事实上，让每个人的思考都动起来是一项 管理上的重大成就，这需要有人用智能和努力营造出这样 的环境，才能让它发生。
这种全体一致为整体设想的思维，其重要性绝不致被 高估，但其困难性却常常被忽视。在团体思维之外，每一 个人都有自己个人的想法，不能说不对，却常常是问题发 生的根源。
每个人都有自己的思想、价值观、信念，也许不会表 达出来，当然也不是每件事都非得说出来不可，但是团队 中大部分的事都值得花时间沟通，特别是有人的想法非常 敏锐时（请参阅附录）。每个人的想法都值得注意倾听， 而且其所隐含的信念都值得花时间了解，尤其是有流言、 断章取义或误会发生的时候。
人们的行为来自信念，人会为行为改变信念，也会为信念改变行为。
创造力的可贵在一个需要创造力的环境中，好点子是愈多愈微软团队成功秘诀好。你只要鼓励大家有这种共识，很容易造成深远的影响。假设大家在讨论一个问题时遇到瓶颈，没有好 点子，你的做法是，规定每个人至少提出一个或两个 好点子，然后你就会发现气氛动起来了。
有好点子是令人愉快的事，尤其当两个看似无 关的点子，凑在一起突然变成一个崭新的、更复杂更 丰富的好主意时，大脑中的愉悦中枢会受到刺激，所 以创造力总是伴随着喜悦。
有人倾听或了解自己的想法也是令人愉快的事。 最棒的是你的好点子被大家广为使用或接受，这本身 就是心理上的很大的快慰与满足。想出好点子是内在 的脑部活动，但当别人恭贺你或肯定你的点子，你会 禁不住开心地微笑。
好点子是具有感染性的。真正的好点子应该像 病毒般广为散播，每个听到的人都会感受到创造性思 考的快乐。
好点子具有相乘的效果。当好点子打破某些错 误的假设时，会有更多更好的点子被激发出来。
创造性思考能培养你的洞察力和头脑敏锐度， 以及对新想法的成本、价值等的评估能力。
创造性思考只有好处没有坏处。虽然培养某种特殊的创造力不是件容易的事，但“想出好点子”本 身很单纯，你多用它就会磨亮打光，一旦时机到来， 创造力就会像核反应一样，绵延不断地增生扩大。
为什么组员会怠于思考或是不敢说出想法？
因为他们认为没有人会重视他的想法。
因为他们认为该由别人告诉他该做什么事。
因为他们认为这样做没有什么好处，只会使老板皱 眉头罢了。
管理者只管发号施令而已。 如果人们的想法被采纳，他们就会愿意思考和表达想法。如果他们的新点子能够被团体接受，就表示值得实施， 团体的力量会更强化好的想法，这就叫做“授权共决”
（empowered consensus）。或许有更适切的名词表示这个抽 象的观念，我选用这个名词是因为它表达出决策形成的两 个重要过程：主动思考与尝试表达。
下载法则建立开发多版本的技术规划组员如果乐于参与我所谓的“技术规划”（），会对未来更有信心。授权共决是所有信赖的基础， 技术规划是它的结果之一。在民主式的授权共决中每个人 都有投票权，参与技术规划的决策。更重要的是，每个人 的想法都受到重视，被认真地评核。技术规划是团队行为 的基础，在最理想的情况下，它包含了全体组员最好的想 法。
技术规划是组员对团队工作的契约，也是团队的宪章。 一年大约修改一到两次，以适时反映每一位组员的意愿， 这么做会让组员更有安全感，更愿意信赖彼此和未来。技 术规划勾勒出了大家信赖的未来的蓝图，因此，假定有一 位组员对目前分配到的工作觉得不太喜欢，没关系，下一 次改版时他可以挑个比较有兴趣的工作；或者有一位组员 不喜欢现在的产品方向，可以暂时退出，等下次技术规划 修改时再加入。
技术规划对于日程的掌握也有帮助：开发人员总是想 把一些了不起的功能加入，常常和进度不能两全其美。如 果有技术规划，开发人员会信赖未来，他有的是表现机会， 不必急于一时。另一方面，开发人员很清楚该在适当的时 间做适当的事，既不会负荷过重，工作品质也更能掌握。
当每个人都很明白在这个产品中自己该做什么，事情就很容易被精确掌握。其中的关键就在这种“割爱”的艺术。
一个技术规划的实例有一次我受邀担任一个软件开发团队的顾问(不是微软)，协助他们建立技术规划。他们的资深项目 经理出身该公司主要的技术部门，决定集中力量在 一个五年计划(即使两三年的时间对科技来说就已经 是全面改观了，我一般不建议定这么长的计划日 程)。当时，他们正在讨论各种新技术能为工作带来 的好处。
在讨论中有一个主题很有意思，是他们年久失 修的关键程序。这个程序庞大而脆弱，有很多错虫， 跑得很慢，其中有一部分的程序代码甚至已经超过10 年。组员中没有一个喜欢它，很多地方根本不符合现 代的设计原则，他们甚至不愿去碰这个大麻烦。
我想每个公司或多或少都有这类的程序：程序逻 辑纠结交错、缺乏弹性、冥顽不灵，简直令人头疼。 这种程序最后会变得无法维护，更别提加入新的功能了，结果是大大限制了开发团队创造优秀软件的潜力。
我把这种情况称之为“软件开发的恶性循环”， 你不可能在推出下一个版本的同时，彻底翻修旧程序。 谁能承担得起重新经历一次软件开发的整个过程，只 为了将程序改写，而这段期间很可能降低或中断客户 服务，在程序还没有变得更有弹性而能搭配新功能之 前，客户可能得等上好几个版本的时间。
比恶性循环更深一层的问题是：为什么会有这 种怪兽程序？是技术总监失职，没有好好监控软件的 品质？项目经理坐视程序败坏至此，竟不能防微杜 渐？在你没有弄清楚真正的病灶并矫正它以前，就算 重新修缮了现在的麻烦程序，同样的问题还是会一再 发生。不要在损坏的地基上重新修筑倒塌过的房子， 那是白费力气！
在这一组开发人马中有一群新成员，新的资深 经理带着一群新的工程师，负责这段伤脑筋的程序代 码；当然，这也为这个团队和这个程序带来新的活力 和希望。他们打算重新架构这段程序，以便融入更好 的技术，提高产品的使用价值。
这个小组经过一番研究之后，倾向外购一项全新的技术，作为未来开发的基石。当他们向决策当局提出这项建议时，反应是两极化的：赞同的人认为即 使外购也可能有兼容性的风险，但旧程序实在太难清 理不如放弃；反对的人则认为团队有能力重整旧程 序，只要管理当局给他们机会。
项目经理也搞得不知如何是好。这位资深经理 在情感上倾向放手让属下好好努力，去清理他们数年 来不断奋斗的怪兽程序，但她又实在不放心这群属下 是否真的准备好迎接这项重量级挑战，尤其是想到他 们过去不怎么样的记录。她不认为这是原先管理者的 “错”，虽然是他们的疏忽以致程序腐化到这般田地。 一般而言，如果管理当局对技术是压榨而非培 养，优秀的人会离开，苟且的人会留下，最后组织和技术一起走下坡。 在本实例中，有不少的新人（包括那位项目经理）觉得这套旧技术实在活得太久，该被淘汰了。也 许大家所缺乏的只是管理当局的承诺，包括技术生涯 规划、创造力的突破和员工福利等等。这位项目经理 希望她的努力可以改变这种状况。
最后，她决定做一次技术规划，然后冒着被开除的危险充分授权给开发团队，果然不只使得怪兽程序浴火重生，而且只花了一次改版的周期时间，也扫 清了许多地雷暗礁。成功的背后，她也失去了几位主 张使用外购新技术的人员。
下一次她修订技术规划的时候，她不只是让开 发小组参与，还设法训练主管们也能参加并了解这个 决策，让负责准时完工的技术人员梦想和希望有机会 呈现在技术规划之中。她也鼓励其他的主管们参加这 些讨论，这样做事的时候会比较容易沟通，也更不会 错失任何好主意。
有很多方法可以制定技术规划，但最重要的原则只有 一个。优良的技术规划有很多好处，也许“割爱”是最重 要的。技术规划会让您知道将会走到哪里，更容易掌握该 做什么，采取什么方法，如何就会更接近目标。而且，惟有完善的多版本技术规划，才能帮助您准确详估工作量。
修订技术规划另一个我所观察到的技术规划实例也是加强共识的最佳典范。由开发小组和项目经理中派人组成的 技术观察员，花了一两个月的时间起草大致的技术计划（请参考法则5：刺探敌情）；然后这份草案被全组人分别传阅、加注意见、讨论激辩，最后被交给负 责执行的开发人员（大约80位）。
同一时间，这份草案也在高阶主管之间传阅， 他们会参照许多其他的技术规划后，定出多版本的产 品计划。他们通常不会修改技术规划，因为他们知道 这是所有组员的心血结晶，也是得来不易的团队共识。 然而，他们发现了一个问题：这份规划看起来像是一 大串互不相干的产品特色（ feature），这样蔓杂的目 标怎么能激励开发人员呢？怎么可能向全世界描述他 们有这么样的产品─有几十个不显眼特色的产品？
然后经理们归纳出来，这些产品特色分属于五 大类型：策略、竞争、顾客满足、投资，以及他们称 作“典范性”（paradigmatic）的功能诉求。典范性的 功能是指有计划地放在 n个连续版本中的产品特色， 最终目的是改变使用者的工作方式。这套分类当然不 是说典范性的功能不属于竞争或策略，或是策略性产 品特色与顾客满足感无关，这么划分只是为了比较精 确地描述。
“策略性”产品特色与最基本的环境和限制有关。
譬如说是本产品支持什么操作系统？采用何种对象模式（object model)？产品需要什么等级的中央处理器（CPU)？支持哪种程序语言？此外，策略性产品特色 也涵盖了公司发展其他产品线的全面性策略。例如公 司卖的打印机，就必须写驱动程序去支持。“竞争性” 产品特色基本上是为了对抗竞争者而设计的，特别是 竞争者有而我们没有的功能。虽然不必每一项竞争者 的功能都要放进来，但倘若其中有特别巧妙或特别吸 引媒体注意的功能，就值得投资。这一类的产品特色 是数目最少的。
“顾客满足性”产品特色基本上是大家已经耳熟 能详，且顾客大都需要的。多去听听顾客的声音，产 品特色就会更能搔到痒处。这部分的产品特色数目最 多，但开发成本相对较低。
“投资性”产品特色是技术方面的前瞻性投资， 其效益可能在未来的一或数个版本中都未必能明显看 出。毋庸置疑，投资性产品特色是未来大放异彩的潜 力，它能带来未来版本中的典范性产品特色。这个项 目的重点是使开发人员善用每一分钱的投资。
“典范性”产品特色可以改变使用者的工作方式。
基本上这是整体开发人员梦寐以求的目标，在每一次改版中放进刻意设计的巧妙功能，逐渐引导使用者。 通常这是行销部门持续性对外宣传的产品特色，它甚 至能改变整个游戏的竞争规则。我们可以说：如果典 范性产品特色成功的话，没有人能跟你竞争─除非 他也有这项特色。
在本例中，项目经理将技术规划中所有的特色加 以整理，分别归入这五大类，并决定在这五大类中分别 要投入多少的资源、占整体投资的比重，并且做出相对 应的技术需求分析，当然要符合内部资源和技术的分配。 这一部分我就留给读者当成家庭作业，您自己思考一下， 以您的条件、产业竞争型态等因素来看，五大类产品特 色中，其所占资源比例应该如何分配呢？
然后，整个开发团队在接下来连续大约五天的 时间，每天开会约两个小时，逐步讨论出下一版产品 的技术规划的细节，整个计划就此拍板定案。这五天 是大伙儿发表意见的最后机会（当然啦，事实上计划 永远是可以变更的，这样做是为了强化计划的效力）。 因为计划的制定是由下而上，不会有任何人跌破眼 镜；因为管理阶层负责综合各方意见而形成完整的、有系统的产品特色，组织目标会被大家接受；整个过程开放而民主，每位成员都获得充分的授权，最后的 争议也会最小，很能共识凝聚，热忱也会很强烈。没 错，整个团队会深刻感受到共同的目标。
这是我所见过最理想的规划过程。我写本书的时 候，他们的产品已经上市了，真的是很棒的产品呢！ 每个人对技术都应该有一份使命感，都有追求 进步的内在欲望，然而新点子可能因为缺乏适当的分 析或时机不成熟而被排除于计划之外。团队成员必须 明白真正的工作内涵，并且能够理解有时候新点子虽 好，但总得经过慎密的分析并证明实际可行又有足够 的效益才行，而好的想法若能被团队审核过关、形成 共识，最终还是会实现的。如此可以减少未经深思熟虑的提案，对整个产品的稳定性颇有助益。 最后，将产品特色分为策略性、竞争性、顾客满足性、投资性、典范性这五大类的用意是，给经理 人一个管理上的指针，便于监督各项资源的运用以及 诊断问题。比方说，如果失去了技术上的领先地位， 管理者就应该加强典范性的投资，而相对降低其他各 类的投资比重。
下载法则别做笨蛋我再说一次，软件是智能财产。必须运用智能，才能得到软件产品。若能用更快的速度结合更多的智能，软件 的智能财产价值就愈高。这是显而易见的事实。曾经有人 问我：“在软件产业中最重要的事情是什么？”
我毫不犹豫地回答：“让大家思考。” 信不信由你，大部分的人都不愿意思考。他们认为自己乐于思考，但事实上并非如此。保持脑袋空空很容易， 在微软我们把这种人叫作 bozo，意思是笨蛋。永远没有 人会注意笨蛋的所作所为，即使他真的有贡献，他也不会 有任何份量。笨蛋当然是不可信任的，你对笨蛋惟一的期 望是但愿他不要搞砸事情。
然而每个人都有可能是笨蛋。你自己反省看看，是不 是知道自己在做什么，是不是觉得自己一点能力都没有？ 小心，笨蛋可能就是你。
在我的部门里，这种德行是不允许的。我要每一个 人都全心全力地投入，每个人都得有贡献，每一个人都 可以侃侃而谈我们的产品 ─如何在市场上竞争、何时出 新版本等等，而且每个人对产品的看法都一致，不会众 说纷云。
判断一个人是否在思考，最简单的指针是看他是否专微软团队成功秘诀心倾听别人的看法，并且立即给予直指核心的响应。面对优于自己的看法，我们必须平息一开始的那种竞争心理或 防卫反应，别人当然是经过一番智力淬炼才能想得出这些， 我们应该公正地评判这些新的、可能很有价值的信息。
