于是本小组中有一位聪明人士，想出了一个聪明点子： 精灵（ wizard）。现在看来它也没什么了不起，它不是什 么仙女棒，只不过是一个可以产生一小段程序代码的按钮 罢了。在概念上来说，精灵差不多是我们所做过的功能特 色中最容易的（虽然它的基础 MFC，相当困难）。但是精 灵却是正中靶心，它让无数的程序设计师只要按一下按钮 就产生出一堆基础程序代码。
我们把精灵放进产品之后， Visual C++的市场占有率 明显窜升了数十个百分点。由 Visual C++的例子可以看出 来，高深的技术应用并不是重点，重点是帮助你的顾客， 找出他们真正的需要，他们的内心在为什么事情挣扎，然 后把所有的注意力转向这里。不必管模板和例外处理，不 必管其他的高科技名词，只要全心全意开发大多数人真正 需要的东西就够了。
顾客需要被了解，虽然他很可能说不出口，你应该体会他真正的需要，并且以软件产品表现出你对顾客的了解。
将技术的轴心放在这里，做出顾客梦寐以求的东西。在 Visual C++ 的例子中，顾客的愿望是：”我想成为C++的程 序设计高手，成为年薪 9万美元的高级工程师。如果你让 我实现这个愿望，而不必学得那么累，我一定花钱买你的 产品，并且叫我的亲朋好友一起用你的产品，我一定要得 到它！如果公司不买我就自掏腰包，如果我的另一半不同 意我就跟她争论到底，我会不惜任何代价买到它。“”我一定要买这个软件！甚至不惜和老婆吵架,我愿意付出一切代价买它。“身为软件厂商，一定要牢牢记住顾客需要安全感，要 能够控制软件，要软件帮助他事半功倍。顾客不愿意承认 他无法跟上新科技，顾客不会说：”你的软件烂毙了。“他 会想：”一定是我太笨了。“一般人除非相信自己聪明到足 以掌握科技，否则对科技都怀有畏惧和逃避。你不能等着 竞争者使顾客聪明。
你和顾客的关系就像是舞伴。你向前一步（推出新产品和传达新信息），然后顾客响应一步，然后你跳下一步；你必须注意整体发展，而不是刚刚那一步。这就是我 在法则 3中提到的多版本计划。如果顾客知道你会按时出 新版，而且在这漫长的科技旅途中你都会忠实地伴随他， 那他就会在下一步时比较能够配合你，跟着你的脚步舞得 更流畅优美。
你和顾客的关系也像情侣。如果你忽略他们太久，或 是表现出兴趣缺乏或者是拒绝，当然你们的关系就没法子 融洽。你的忽视会使顾客觉得受到背叛、伤害，觉得生气， 恨不得给你一点报应。所以，一定要对顾客”一路走来，始终如一“。
我一定是太笨了不久前我在飞机上与一位女士聊天，她问我在哪儿工作。通常人家听到我在微软工作，不外乎两种 反应，一是露出很崇拜的样子，一是直接问我认不认 识比尔?盖茨。
这位女士问过比尔?盖茨的问题之后，开始和 我谈计算机，告诉我她学计算机的计划。她说她要去 一间社区大学上课，要学所有的计算机软件，包括数据库、电子表格和文字处理器。谈到这些，她脸上流露着兴奋的光芒：”计算机实在太棒了，我要学会所 有的东西，Windows啦、RAM啦，反正所有的东西， 要花几年也无所谓。“听到这位女士的梦想，我对她面对计算机革命 的态度有两种感想。我钦佩她的勇气、决心和远见， 她不愿被科技抛在后头，错过这本世纪最重要的文化 与技术核心。她愿意投注大量的时间、金钱和努力去 学习计算机，不怕承认自己不会计算机的事实。
咦？等等，这位女士真的认为计算机很难，计 算机真的那么难吗？她需要回到学校，才能够学会操 作PC 的软件。而事实上这些软件实在非常地容易。 这么说，这位女士一定很笨 口罗 ，还得重新回去做老 学生，忍受数不清的挫折，只为了学计算机。嘿！这 可真不错，这就是我们软件厂商的大生意，把软件弄 得很难表示我们智商高人一等，然后顾客会付我们白 花花的银子来学软件。即使我们的软件很烂，顾客也 只会觉得自己太笨或计算机太难。
既然你是本书的读者，应该已经具备相当程度 的专业知识，而且你的亲朋好友都知道你懂计算机。
请回想一下，你是不是常常遇到有人困窘羞怯地告诉你自己实在是计算机白痴呢？这是相同的现象。大部 分的人都觉得不懂计算机一定是自己太笨的缘故，而 感到极度不安。人们的错觉是：计算机是对的，自己 是错的。
下载法则加速产品推出的周期我们已经谈过了准时推出软件产品，兼顾进度和品质。
除此之外，你还得加快新版本推出的速度，这么做的理由 有几个：第一，无论你做得多快，市场、科技的进步和竞 争者都会比你更快。第二，你与顾客之间的关系是维系在 你多勤快地与他们沟通，沟通的主要媒介就是产品的新版 本。你要告诉顾客的每一件事都包含在软件产品之中：你 对顾客的细心体贴、你的热情、你的信念、你对顾客的看 法，往往都由软件表现，软件是不会说谎的，她是你（和 你的公司）的代言人。
我从来没有听说过有任何的关系会被太多的诚恳沟通 而破坏。借着频频推出新版，不只是使你在市场中的曝光 率增加，也等于是回馈顾客，拉近与顾客之间的距离。钞 票也不会说谎，常常推出新版会使你与顾客的交易机会增 加，也使得双方的关系更密切。
团队具有在短时间内推出产品的丰富经 验，所以我们在这方面做得很成功，以后还要继续。这是 我们强大的竞争武器，也表示我们能与市场维持良好的互 动关系。现在我们甚至能够用预订的方式卖软件，一年推 出三次新版本。我认为这是贩卖软件的最好方式，但是有 两个问题：第一是很少有厂商能够保证自己规律而快速地微软团队成功秘诀推出软件；第二是软件更新往往需要厂商付出大量的成 本，而且很难管理得当。不过我相信现在的软件厂商愈来 愈能够处理这个问题，再加上 PC和网络的进步成熟，我 认为这种方式会逐渐普及的。
站在顾客的立场，他不一定每一个版本都得使用，他 可能已经习惯于旧版本的环境，或是采购预算的限制，或 是已经在旧版本上做了一些投资（比方说开发了一些应用 软件）。不论理由如何，顾客永远有权说要或不要。顾客 需要做自己的技术、预算或时间规划，他需要预估你何时 推出新版本，而届时他就可以使用市面上最先进的技术。 不幸的是，现在的软件大多是非常不定期地推出新版，而 在新版中会有重大的变革或是大幅度的除虫。
经常而准时地推出新版（修改规模比较小），比不定 期的一次出个革命版本效果要好得多，而且利润也比较高。 开发软件最重要的是对市场能够迅速反应，而不见得要有 革命性的突破（responsive but revolutionary）。定期推出新 版让你有机会直接响应顾客的需求，同时很快地扫除令顾 客烦恼的障碍（也许只是个小瑕疵），而顾客会对你心存 感激。我发现消除顾客的烦恼（Annoyance fix）实在是一 本万利，通常不需要太多的技术难度，有时候只不过是一点点使用习惯的问题。这会让顾客相信你会替他解决问题的，大大增加了他的安全感。 我发现顾客比较喜欢新产品摆在他眼前，而不喜欢厂商的承诺，有少部分的顾客是两者都要。但一般来说，持 续推出新产品才是对顾客最好的保证。送顾客纪念品只能 让他高兴一下，不会让他想买你的软件。
完成很多个小成就，比完成一个大计划，还要受人欢 迎。因为这种方式比较容易切合使用者的需要。按时推出 新版软件会让你设定比较小的目标，对这个目标更清楚而 且容易掌握，比起很大而不确定性甚高的目标来说，也比 较好管理。
下载设 计 设计 设计对于一个伟大的软件而言，最重要的是在正确的时机，推出正确的产品。也就是说，你必须知道如何准时推出软 件，而且能够抓住顾客内心深处的需要，这就愈能够体会 到顾客的内心，这个软件就愈伟大。软件的设计─每一 位团队成员都必须参与─这表示团队整体对功能需求的 了解程度。总而言之，软件设计的第一要诀是：将全团队 中最好的想法组织起来，去满足顾客内心最深处的需要。 在设计过程中，最困难的是让每一个人最好的想法 或建议、最棒的创意或灵感表现出来。但是这样做的代 价是绝对值得的。想想看：只有两三个人做产品设计的 话，加起来的智商最高只有 230 ，或是 250，有 10个人的 话，结合的智商也许可以到 1 300 。算一下你的团队有多 少人，你能结合的智商愈高，做出伟大软件的潜力就愈 高。在设计或开发过程中的每一个阶段，让创意充分发 挥是非常重要的。一个伟大的教堂，只需要一位伟大的 建筑师，但是软件的设计却需要上百人或上千人的智能来为它创造价值。 然而，让每个人都充分发挥创意而又不牵绊住其中的天才，是一件相当复杂的工作，也是领导者所面临最大的 挑战，当然这不是软件业中惟一的挑战。教育可说是领导微软团队成功秘诀者或管理者最主要的角色：带领团队做案例研讨，带领大家思考如何解决一切的疑难，让每一件事都在该做的时候 做好。
法则追求卓越如何让组员生活在美的环境中，陶冶他们对美的素养？让组员阅读什么样的书籍或给他们什么挑战，可以加 强他个人的成长？管理者应该培养组员对美学的概念，可 以把千百年来人类的文明当作美学的来源，而重点则放在 软件的设计。人类对美的感受是非常复杂的，几个世纪以 来不断有人研究这个主题。因此，不妨利用前人探索的经 验当作基础，以下我将引用一些前人的理论，来引导本章 的讨论。
除了美学之外，我们也可以利用历史的角度：暂时忘 掉这个信息时代，想想看历史上有什么人物或事迹（时间 较近的排在前面）令你觉得很崇拜或很感动，改变了你的 想法或态度？你团队的工作是什么？两者有没有类似的地 方？这个历史故事能不能激发人们的潜能，而开启另一扇 创意之门？这个创意是不是完全没有人想到过，而且会导 向一个没有人想象过的未来？你可以思考这一类的问题， 用历史的眼光来分析一下你的工作，也许会有意想不到的 结果。
法则设定主题有几件伟大的著作影响了我对伟大软件的观念：乔治?桑塔亚那（ George Santayana ） 1896年的经典名作《美感》（The Sense of Beauty），以及较近的乔治?史汀尼（George Stiny）与詹姆士?吉普（James Gip）于1978年合 著的《美学法则》（Algorithmic Aesthetics，University of California Press出版）。尤其是史汀尼的著作，对于我们现 在所讨论的软件美学有很大的关系。史汀尼对美学的定义 如下：
美学所关心的问题是如何描述、诠释和评价一 件艺术作品(work of art )，以及如何创造一件美的艺 术作品。
在德惠克?帕克（DeWitt H. Parker）于1926年所著的《艺术分析》（The Analysis of Art，Yale University Press出 版）中提到六项美学的准则（ Criteria of esthetic form ）， 很适合作为分析软件设计之用，而我要求我的团队把它们 当作设计时的标准。
德惠克?帕克的六项美学的准则是：统一、主题、变奏、演进、平衡、层级。
根据帕克的看法， 统一性（unity）是伟大艺术作品 最主要的原则。而我也曾经在许多件伟大的软件作品中看到这项特质。如果我们将帕克对统一性的解释套用在软件设计上，我们可以说，一件具有统一性的软件，每一个小 组件对于整体的美感价值都非常重要，而且每一个美感元 素都应该出现在作品中，缺一不可，而且不应该出现的东 西、对美感没有贡献的东西，绝对不要出现。因此，软件 设计应该是把顾客想要的东西全部纳入，而顾客不要的东 西统统排除，由于软件中所有的东西都是需要的，顾客对 于软件的使用不会被干扰，而去注意不必要的东西。所以， 追求软件的统一性，是软件设计的首要目标。也许你在别 的领域（也许是创造一件艺术作品）的工作中，也曾经由 于直觉或别的理论而运用统一性，而我认为帕克的六项原 则对于软件的设计非常有用。
软件的主题（theme）会主宰设计的基础观点，也是软件价值的主要根源。因此，你必须在团队中明确地传播 这个主题，让开发人员和行销人员对主题有非常透彻的了 解才行。软件的主题事实上是目标的同义词。目标愈明确， 造成的的冲击就愈大，因为你可以将模糊降到最低，而目 标在每个人心目中造成的感受与解读会更一致，整个设计 过程就愈平顺。但是主题决定之后，你还得注意与主题无 关的部分都要删除掉，即使开发人员认为这一部分很重要，或者这是你一贯的信念，都还是得忍痛牺牲。
产品的销售信息会由主题衍生。精明的观察家只要看 到主题就能抓住信息。信息只是补充说明主题的意义，如 果主题模糊或是不只一个，再好的销售信息也没用（大家 都明白这个浅显的道理：产品若没有鲜明而惟一的形象， 广告再多也没用）。产品的主题根源于你的对市场的观念， 以我Visual C++的例子来说，我们对市场的观念是：大家 都觉得C++太难学，于是我们设计的主题是：让使用者容 易学习 C++，我们的信息自然就是： Visual C++把C++变 容易了。
重点是产品的功能特色不能像是一袋子随便抓过来的 东西，应该把与主题无关的东西都删掉，而且你的目标也 必须符合统一性（ unity of purpose）才行，这一点是与主 题互为一体的两面。将资金投注在这个目标上，让所有的 人都完全明白这个目标，并且为这个目标努力，做得到这些的话，你的产品就会完全包含这个目标。
专心致力于主题我不知道以下的故事是真是假，但我很喜欢它，而且经常说给我的组员听。
有一家电子表格公司做了一项研究，结果发现到使用者大约每打20个数字就会想用这些数字画张图 表。这项研究发现，大多数的人在用电子表格时都有 这样的行为模式。
所以他们研究再研究，开发再开发，全心全意 地努力让产品有这样的功能：可以利用很少量的数字， 很容易地产生图表。那些用电子表格绘图的使用者看 到这项功能特色都非常高兴，认为只要有这个功能就 值得买下这套软件。
另一个类似的故事（我也不知道是真是假）是 一个做家庭财务软件包的团队。他们研究过市场之后 发现：这项产品一定要让顾客立即得到好处，否则就 卖不出去，而且消费者不会再买升级版。他们决定要 让任何一位完全陌生的使用者，都能够在打开包装后 十分钟之内得到结果，从安装、操作、输入、输出， 一定要又简单又快。
所以他们派人到软件商店去，征得顾客的同意， 跟着他们回家观察他们的使用状况，巨细靡遗地记录 下来：包括他们拆开包装之后会先看什么东西，在安 装和执行软件的过程中会遇到什么困难等等之类的，以提供产品改进的依据。分析研究之后，他们找到了数十种加强顾客满意度的机会，然后他们在往后的几 个版本中逐步实现这个目标─十分钟内的满意。产 品终于成功了！
变奏（variation）是将主题稍加变化润饰后，重新表 现一遍。在主题表现过之后，为了持续吸引使用者的注意 力和兴趣，变奏是以另外一种方式来铨释主题，加强使用者对主题的理解和欣赏，使他对主题留下深刻的印象。
演进（evolution）的意思是用前一部分来决定后一部 分，就像是学习的过程应该是先入门后进阶一般，由浅入 深的变化会让人更容易接受，更喜欢学习。如果软件作品 的前后能够如此呼应，通常会有满意的结果。
平衡（balance）是对软件中各项组件都不偏废或过 度强调。例如，正好相反的两个对象，应该给予相同份量 的说明。
层级（hierarchy）是指软件作品中的各个元素，依照它们的重要性与大小给予合理程度的比重。层级与平衡 的概念很接近，层级可以说是建立与衡量平衡的方法。如 果主题是在层级的最顶端，则以下各层级的同层组件都应 该彼此平衡，同层级的组件对主题的支持力也应该相等，愈近顶端的层级对主题的支持力量愈大，以此类推。
美的特质年，盖?瑟西罗（ Guy Sircello）在他的著作《美学新主张》（A New Theory of Beauty）中，提 出了一个有关于美感认知的学说，相当有趣。我们不 谈他对物体特性的质与量的详细划分，他提到一些有 关美学感受的理论，非常深得我心。瑟西罗认为我们 之所以感受到美，是因为这个物体有一种以上的特质 很美；瑟西罗进一步解释说，惟有一项特质在作品中 被特别强调，才会是有美感的特质，而一个物体惟有 包含一项以上的美感特质，才会被人们感受到它的美。 足够的美感特质不一定保证让整个物体显得美，但是 一个没有美感特质的物体绝对美不起来。
瑟西罗的学说或多或少解释了为什么有一些软 件叫好不叫座，这些失败的软件什么都有，想要大小 通吃，有一大串的功能特色就是没有主题，结果没有 一项特色能够使产品鹤立鸡群，就无法吸引顾客的注 意，当然注定要失败。
法则不要倚赖不确定的事尽 量 减 少 团 队 需 要 而 又 无 法 控 制 的 事 情（dependency）。项目开始的时候，决定允许倚赖的事情愈 少，最后就会愈顺利。一般来说，程序设计的效率是不会 太高的（也许是由于不熟练或是错虫太难抓），即使你努 力加班在时限内完成了自己份内的事，别人也可能无法做 到这样。
因此，在设计时就得考虑这种必要而又不确定的事， 要知道这种依存性有可能会吃掉大量的成本，只有在很重 要或是非不得已的地方才允许这种倚赖，让成员们明白其 严重的后果，尽量配合协助，并事先评估倚赖之事失去控 制的可能性，以及会有什么影响。
法则平息顾客的愠怒在项目进展的过程中，总有一些依存性或外在的不确定性因素可能会拖垮你。你必须在其中找出最有可能 绊住你的因素，事先研究好万一发生问题时你该采取什 么步骤。
先检视一下产品的功能特色，其中有没有不明确的、 或是对顾客满意度没有太大意义的部分，在时间来不及时 可以牺牲掉这些。不错，可能会有顾客不满意你没有做这 项特色，但是只要你能如期推出新版，那顾客就不会放弃 你，并期待在下一版中见到他要的特色。
平息顾客的愠怒法则软件的可移植性对于大部分的软件厂商而言，做到跨平台（）的支持是相当困难的。即使不考虑每增加一种 支持平台所增加的开发成本，在品保方面所增加的工作负 担也是呈指数增长，再优秀的品保管理也无法真正解决这 个问题。最好的办法是要求系统软件厂商提供工具支持， 然后慎重小心地决定你要支持的平台，数目愈少愈好。
但千万别选错了，那会是你的致命伤。
法则在设计时将时间因素 考虑在内在设计时就将时间因素考虑在内，千万不要先设计好再决定要花多少时间才能做出来。时间是你最大的限 制条件。
产品设计的目标一定要完成才能推出，你不能把做到 一半的软件给顾客使用。开发人员和管理者在做产品设计 时很容易忘记考虑时间因素。正确的做法恰好相反，你应 该在设计阶段就把时间当成关键因素，当你在考虑替代方 案时，时间短的加分，时间长的减分。通常只要把时间因 素纳入设计时的考量重点，你就能够缩减开发的时间。
如果你的设计并不一定要产品如期完成？别傻了，还 是如期完成最重要，比什么伟大的理想（可惜实现不了） 重要太多了。
开 发 开发 开发这里所谈的开发，包括的以下的实际行动：执行计划、进度安排、程序撰写以及品质验证，而不是讨论什么人做 什么工作，在团队中每一个人都必须参与开发的活动，因 此，每一位都是开发者。
人们使用软件开发（software development）来表示软 件产生的过程。这一点很有意思，这表示软件的形成是一 种渐渐成熟的过程，经过一组有顺序而相互影响的步骤演 变而成。究竟是什么因素推动软件趋向成熟呢？是团队的 创意凝聚。从众多个人的智能产物，逐渐组成一套结构紧 密而完整的智能财产，那就是将要推出的软件产品。这又 使我想起了本书一再强调的主题：软件开发的基本活动就是将一群个人的智能结合成一项智能财产。
软件开发的终点事实上是开发人员脑力的极限。
脑力的密切结合但软件开发的过程牵涉到很多层面。每一个人、团体互动和科技，三者都在发展，并不是固定不动的。所以， 软件开发没有明显的起点或终点，而是很多人在很多不同 的层面切入，共同创造。虽然每一次的新版，都可以说是 一个里程碑，但是不能把它当成终点，软件开发的终点事 实上是开发人员（脑力的极限）。
很多专家以工程的眼光分析软件开发的问题，而软件 开发的问题也常常被当成是工程问题。但我却常把软件开 发当成社会学或文化现象。和一群人共同创造智能财产， 比起工程上的设计方法论或其他的基本理论要困难得太多 了，在工程上的情况都是有限的，但在软件开发过程中的 问题却是无限的，而且没有绝对的是与非，很多问题都是 要靠沟通和取舍来解决。聪明才智是创造软件的绝对必要 条件，但光有聪明才智并不够。
处于布局时期的”开发“，就像解联立方程组一样， 方程式中的变量有无法预测的时间排序和不明确的产品内 容。要知道，在该说的全说完但还没真正动手之前，大概 没有人知道软件完成时的模样。在这个阶段，所谓的产品 功能特色只是个描述性的名称，和大概期望的功能，而设 计通常是到了新版产品出炉了才算真正结束。换句话说，在这个联立方程组中的变量都是不确定的值，而且还会随着开发阶段的演变而改变，这是个极为复杂的问题。
与其说软件开发是一组结构巧妙的程序，不如说是开发人员脑力的密 切结合。
另一个在布局时期所面临的难解方程式是人的创意， 也就是说你必须在此时就估计出每个组员创造力的效用程 度。我们不仅要在本阶段仔细思考功能特色的内涵，还得 预测它如何能变成具体明确的工作项目，何时能放到组员 的手中加工，并且完成它。
上述的不确定性因素实在是太多太复杂了，以致安排 进度几乎是不可能的任务。当然啦，你还是要设定项目的 整体目标，然后集中精神在第一个里程碑，也许是项目开 始后的一两个月，这大概是你在布局时期时最多所能做到 的了。在第二篇孕育阶段中我们会更详细地谈设定里程碑 的技巧；这是一个让团队练习在短时间内做出具体成果的 好机会。注意每个里程碑的间隔不要超过三个月。
一般而言，软件开发比较像是在赶进度，而不像是在演奏交响乐；交响乐是和谐有序而优雅的，而软件开发却 是一堆排山倒海、蜂拥而至的工作。这个比喻太可怕了， 把它当作是即兴演奏吧！你必须自己知道什么时候该出来 表现，什么时候退后一点，大家都是在动态的情况下，和 很多人密切合作，任何两个音符都不要互相抵触，让整体 表现出的是一段优美的旋律。在一切都不确定的情况下把 整个活动带到最高潮，使其美妙的程度不下于交响乐，而 且事实上，它本身就是一种喜乐。
下载法则拒绝不合理的命令我很惊讶居然有软件开发团队接受非专业人士的指挥，尤其是有关进度的事情。在现代科技领域的世界中竟 然使用典型旧社会的方法，简直是大开倒车。有些公司竟 然让根本不懂软件开发的人来管理最重要的事 ─时间、 特色和资源是软件开发的金三角─简直是疯了。那些在 上位者或是行销人员是假装无所不能的妖魔鬼怪，变个魔 术就能拟定进度了。更糟的是，有些专业人员竟然也接受 这种缺乏见识、亳无逻辑的领导，还把这种事情当作是标 准的作业程序呢。
我曾经接触过数以打计的开发团队，据我私下估计， 大约有三到四成经常为不合理的重大命令所苦。合理的做 法是由负责做事的人来估计时间。当然啦，如果精确不是目标之一的话，任何人都可以随便乱估。
如果在上位者不让真正执行任务的人来估计所需的进度，那就是专制。
有些时候，没有好好估计时间是团队自己的问题，是 开发人员和项目经理没有担负起决定达成目标所需时间的责任。把估时间的责任从执行工作者手上拿走，是最最最反授权的做法。在任何情况下接受这种做法都是极槽糕的， 一开始进度就是假的，团队如何会有工作能力呢？
没错，我们很能同情那些上位者需要感到自己能控制 能预测，但究竟是什么原因使这种荒谬的决策一再上演， 而使软件开发永远是个大灾难？
不管是人或组织，大部分的时候都无法从错误中学习。 人有时候很粗心大意，上次做错的事，我试着再做一次能 不能做好，完全没有细细思量上回弄错的原因，甚至不去 想想看成功软件开发事例给我什么样启示。
这种盲目的现象特别容易发生在进度严重落后的团队 中，很多开发人员再也受不了这种死亡进行曲，只好挂冠 求去。这些离去的人对于工作要求都很高，才会不容许自 己继续和这些官僚大爷们混下去，而且通常都是最重要的 人。而留下来的人在怨声载道中，被弃于险地而无人理会。 魔鬼在办公室的每一个角落出现。行销人员像个傻子，他 们的承诺像是空气，不知不觉流露出愤世嫉俗的态度；高 阶管理者充满困惑、窘困和愤怒；顾客觉得自己被骗了。 灾难于是开始要知道，在疯人院中，头脑清醒的人反而会被当成疯子。
慢慢地，云消雾散，大家又重新燃起一线希望，也加 入新的成员，新的（或是被原谅的）管理者来带领大家， 而新的技术也吸引了开发人员再度投入热情 上过当却 学不了乖的高阶领导者又开始了错误决定，下令软件必须 在某月某日做出来，于是灾难的循环又再度开始如果是你，该如何对付这种荒谬的情况呢？如果你 发现自己身陷在这种组织当中，该如何面对困境？记 住！在这种荒谬的环境中，任何正常人都会失去理智， 而组织中弥漫着不理性的行为，它的未来必定走向不可 理谕，你在这里一点希望都没有，身为惟一头脑清楚的 人，必定会被旁人当成是疯子。也许你可以明哲保身地 在这种自我毁灭的组织中勉强活下去，但你不可能会有 什么像样的作为。
但是无论如何总得解决这个问题。所以你在接受不 合理命令的同时，还是要很技巧地提醒你的昏君，这样做是不对的，无法这样做是因为事实的要求。权力不是万能的，他们的做法行不通，你得帮助你的昏君明白， 大家都在拼命完成皇上的目标，而不是团体的目标，如 果能够多点参与，情况一定会比较好，人们也会因此而 做得更快，更愉快。
开发进度表应该由下而上来拟定，每一个人负责自己 的工作，也负责设定它的时间表，负责准时完成工作。责 任和充分授权是一体的两面，二者兼备才能拟出合理的开 发计划。
下载法则把工作当作游戏吧如果把软件开发当成是一种工作，那实在是一个索然无趣的职业；从另一个角度来看，我建议你把它当成 游戏。
在布局时期，每件事情都按步就班进行并不是成功的保证。
如果你引用我的法则来建立你的团队，虽然软件还是 同一个，但你会发现他们更自动自发、反应更快、更多幽 默、更容易做出令人欣赏的软件。把竞赛当成游戏，你比 较容易赢。计算机其实是个充满趣味和挑战的玩具，而开 发人员呢？当然是大玩家 口罗 。
在健康的团队中，以游戏的方式来做事是很自然的。
管理者不需要做什么特别的举动，只要避免限制组员的发 挥，和注意大家是否乐在工作又自动自发就行了。鼓励组 员快乐，不要怕他们分心，这可能是创意的泉源。
软件开发这场游戏，会自然而然地产生规则，做得好 的人自然会获得奖励，而做得不好的人自然会受到惩罚。 管理者不必操心正义和仲裁，游戏本身的奖惩比你做的奖微软团队成功秘诀惩要更有效果。
用游戏的心情工作并不是罪过这个游戏能给你什么好处？多玩玩它，练习它，感受它的趣味，并且喜欢它。如此一来，软件创造本身的趣味 会使僵硬、骄横和严肃都消失，这样最好。
在布局时期，每件事情都按步就班进行并不是成功的 保证。本篇的目的是告诉你如何在发挥团队最大潜能之前， 准备好你的团队。本篇并不是成功的公式，而是伟大的先 决条件。如果每件事都能在布局时期就照本书的法则进行， 那么以后仍然会如此进行，协助你的团队成长起来。
第二篇中程时期微软团队?成 功 秘 诀中程时期书为了帮助读者建立清楚的观念，将软件开发过程 划分成四个阶段，然而在实际运作上真的很难这样 做，各个阶段彼此都有重复的部分。在本篇中，我不设章节段落，因为这一部分的内容用各项法则来说明比较清楚。 因此请不要以为我在每个阶段所用的法则仅适用于该阶 段。事实上，我所提出的法则都是观念，适用范围是整个 的软件开发过程，好的开发团队应该随时随地注意每一个 法则是否被实践。而在起始阶段所提的各项法则，如果你 有做到的话，你会发现在孕育阶段更容易实践它们，因为 你已经练习过这些方法。
在起始阶段的主要目的是让团队凝聚并建立对团体与 产品的目标，而蕴育阶段则是充满对目标的期望、不确定 和挣扎，所有的事情都是一片混沌，并且充满对可能失败 的恐惧。这时候，毅力是最重要的。暂且不管你的团队是 多成熟，暂且不管你经历过多少次这种场面，或是产品出 炉时会有多伟大，孕育阶段总是可怕而乱糟糟的，你随时 都可能遭遇意外打击或是想象不到的失败，但绝对要坚持 下去。
你很可能会有那种心情：但愿有条路让我逃离这一切， 每个项目都会有这种时候。每件事情都无法确定，于是组员的心情开始恶劣，冷嘲热讽、消极抵抗都来了，几个月下来不见天日的辛勤工作，使得组员好似得了坏血病。这 场灾难似乎永无休止，可怕啊！
深呼吸一下，进入孕育阶段吧！
中程时期下载法则用医生的方法当病人已经药石罔效时，医生通常会对病情有所保留，避免病人太过悲观或恐惧，并且尽量鼓励病人保持希望， 最好能让病人有个期望完成的目标。软件开发在这方面也 很像医学，它不是完全能用科学来解决一切。只是很不幸， 到目前为止，一般人还不了解软件开发是一门艺术─是 必须具有技术专长的艺术。
现在，你得学着用医生的方法。医生绝对不会斩钉截 铁地断言什么医疗行为一定会有什么样的结果，反而是以 一种自在且充满信心的口吻说：”试试看吧，一切都还没 有确定呢。“反观软件项目经理人，常常在还不确定是否 可行时，就率尔对团队保证产品的特色、时间等等。更糟 的是，医生往往是在整体系统大都健全的情况下，对其中 的一部分功能做医疗；而软件开发则常常得面对全新的、从来没有运作过的系统，不确定性更高。
当然，任何情况都是有可能的，即使是再简单的医疗行为，都可能有风险。
另外一件应该向医生学习的事情是，即使是再小再简单的医疗行为，都带着几分风险，所以医生会说：”当然，任何情况都是有可能的，治愈率再高我都不能跟你说百分 之百没问题。“如果这样说都还不能让组员明白任何未来 的事都有不确定性、都有风险，那我也只好束手无策。
我们必须记住，面对软件开发的不确定性，总会有方 法可以试试看。就像医生会试着让病人了解任何医疗行为 都有风险一般，管理者也应该让组员了解，任何项目都有 不确定性和风险。
”一切都还没有确定呢。“下载法则软件开发金三角：特 色、资源和时间作为一位软件开发的领导人，你得集中注意力在三件事情：资源（人和钱）、特色（产品与其品质）和时间。 这三件事是软件开发的核心，其他的都是外围。资源、特 色和时间是三角形的三个边，任何一边的变化，都会影响 到另外一边或两边。所以如果时间落后了，去看你的三角 形，看看对特色和资源的影响；当有人谈到可以增加什么 功能特色时，你得立刻谈起时间和资源，以显得你思虑周 详反应敏捷。所以，管理者的第一要务是把这个三角形放 在心里，随时利用这个模式来思考问题，你会发现答案都 在这个三角形内。”好吧，我的时间落后了，我得利用另 外两个边来弥补，或是三边都得调整，我可以少一点特色， 我也可以加一点资源，或是修改一下时间。“由于人、时 间和特色都是你最关心的，所以你对这个三角形有具体的 概念，很快地，你就会发现这个三角形对你的思考帮助非 常大。
微软团队成功秘诀软件开发的金三角还有一点要记得，时间落后时，你只有四种选择：增加时间、减少特色、增加资源或三者同时进行。但人是不 可以随便增加的。
不可加派人手？
你是否听说过，加派人手是个错误的决策？在佛莱德?布鲁克有关软件开发的经典著作《人力资源 之钥》（The Mythical Man-Month）中，用了很大的篇 幅来阐述他的论点：在软件开发项目中不当地增加人 手，反而会使工作进行更慢。布鲁克的观点被证明是 非常正确的，但我们应该了解的是，布鲁克是在写一 本书，而不是写一部适用的律法。
然而，传统的教育使得人们用太过单纯的理解 方式，使得布鲁克真正的睿智多少被曲解─绝对不 要在进行到一半的开发团队增加人手，重点是”进行 中的团队“。虽然布鲁克十之八九是对的，但却成了 太多管理者的借口，理直气壮地决定不加派人手。是 的，增加人手是很难管理（人员应该在项目开始前就 规划妥当），通常也不是个好办法，只有在非不得已 时才考虑，但不是被禁止的。
下载法则不懂别装懂对于不懂的事情，千万别装懂，或是看起来似乎懂，也不要接受别人不懂却装懂。不懂却装懂一定会造成团队 管理上的困扰，这一点几乎没有例外，你若犯了这种错误， 一定会尝到它的苦果。在每个阶段的每一个人，一定有某 些重要的事情是他不知道的，这应该是被允许的。去掩饰 你不懂的事情只会造成别人在认知上的偏差，结果反而导 致不知道那些事情可以相信，那些不能相信。如果你勇于 承认自己不懂的事情，就不会掉进这个泥淖。
人们会觉得对于重要的事情，我如果不知道就很丢 脸，这是天性。而在软件开发过程中，太多东西是大家 不知道的，因此，管理者或开发人员就很容易有这种不 懂装懂的倾向。好的开发团队应该有一张清单，上面列 着我们目前不知道的事情，这样才比较容易掌握到底什 么事情会不确定。抗拒”我都知道“的骄傲天性，是需 要团队士气和心理上的勇气的。对于管理者而言，称许 承认不懂的勇敢组员更加困难，尤其是这个事实已经被 文饰过的时候。虚假的文饰是面对未知事情的错误防卫 心理。
虚假的文饰是面对未知事情的错误防卫心理。
我非常建议管理者重视组员了解自己什么地方不知 道，而不是被迫或自愿去掩饰。要让你的团队明白他们从 未检视过自己的未知，但要从现在开始练习承认自己不懂 的事情；一般来说，在团队成立的初期或转变阶段会比较 容易做到。我们没有时间拐弯抹角。最后，大家会明白成 功比较重要，牺牲一点点面子或是受到幻灭的打击又有什 么关系呢？
你坚持组员必须面对不确定性，承认自己不知道，最 后会将无知变成知识。领导者的任务是让大家全都明白不 确定性是绝对的事实，必须强迫大家去面对它、适应它。 为了大家好，团队应该学会在不确定的环境中生存，并且 兴旺起来。
既然要写在书里，就让我们说这是正式的规定：当有 一件事是不确定时，就直接说明这个事实，即使不确定的 事情是何时能够推出新版。不必担心，没有项目经理会因为承认自己不知道的事情而被撤换。
知之为知之，不知为不知，是知也不必说大家都晓得，我的属下会因为知道自己不懂什么而获得我的加分，因为知道自己不懂，才会去求知。我 宁愿知道什么不足，这样我才知道什么事情可能会绊倒我， 我的同事和属下最好也明白这些。
软件开发项目的目标并不是事前做好正确的规划，而 是每天都得在事情从未知到已知的时候，做出正确的抉择。 如果你明明不知道某件事却假装知道，你就无法在事情从 未知到已知的时候得到正确的信息，也就可能会做出错误 的决策。当信息证明你错了，你一定觉得非常难过。于是 你会更加害怕信息，而别人就以为你在抗拒事实，最后你 将陷入恶性循环。
只有当你知道不确定性在那里时，你才有可能解决 它；那些没有被发现的确定事情，会把你绊倒。相形之下， 承认你不知道是比被击倒要好得多了。
当你不知道事情该如何完成，当你内心有个声音在 质问你、在困惑你 ─ 面对它吧！不必害怕承认了自己 不懂就显得很笨，你一定会因此而学到某件事情的。在 你内心不断萦回的声音，事实上是团队还没浮现的怀 疑，而你收到了无形的信号。也许当你告诉别人时，得 到的回答是：”对啊，我也在怀疑同样的事情。“当然，偶尔别人会认为你是不理性的空穴来风，没关系，那是你在不确定的环境中必须付出的小代价（如果命中率实 在太低，也许你得看看心理医生，但至少不会令你延误 就医吧）。
