在会议的讨论过程中做出决策，比较容易得到高明的决策，执行起来也会有效得多。通常是有人发现重大 问题，而且已经想了又想，询问过专家的意见，也许 已经有了初步的行动方针，在会议中邀集众人的看 法；通常与会者已经在会前对这个问题有某种程度的 了解，甚至已经思考过一些解决方案，即使不在事先 排定的议程内，也可以提案讨论无妨。通常在这类会 议中，提出的意见或建议都是经过深思熟虑，初步的 行动方针被补充、被改良，共识在这种过程和气氛中 凝聚。与会者有意见的话，应该让别人都了解，然后 在大家都能认同这个解决方案的情况之下，齐心解决 问题。
下载法则不要因为进度落后而 更改最后期限将来有一天我退休了，真希望能到学术界研究出有关进度落后的数学公式。目前我能确定的是，第一次的进度 落后往往是最严重的一次，之后因为经验的积累会使你更 能掌握进度，所以，当你第一次遇到进度落后时，千万得 有耐心。
进度落后的程度是与计划的不确定性成正比。就好像 你在翻阅一本名叫未来的书，你无法预料未来是什么，直 到你走到那一步；随着时间过去，本来不确定的事会变成 已知，于是整个计划的不确定性会随着时间而降低，进度 就愈来愈能准确掌握。理论上，进度落后的程度相对于计 划的不确定程度，并不是数学上的趋近于零而永不等于零， 而是，如果不确定的程度为零，就不会发生落后。
我相信应该有这么一个算法，用时间轴（ X）和不确 定性（ Y），给定有任两点进度落后的值，就可以投射出 理论上的项目完成日期。我相信这种算法，因为我没有 一次不用到它，虽然我无法提出精确的公式或证明。但 请你睁大眼睛注意，你所经历的进度落后是否一次比一 次轻微，如果是，表示你渐入佳境，如果不是，那你离 目标渐行渐远。
微软团队成功秘诀在你知道自己什么时候能够完成以前，你往往会经历自己即将落后的煎熬。
但是，千万不要为了减轻进度的延误，而将最后期限 向后挪，这种交易不划算，你会因此而信用扫地。一般来 说，早在你知道确切的可完成日期之前，你会知道项目已 经延误，这时候，整个团队乃至于全公司所有的人，包括 外界的新闻探子（如果他们知道的话），都会问你：”既然 每个人都知道延迟势难避免，何不干脆将到期日延后？“ 仅管有庞大的压力逼你延期，但原来正式的到期日仍然是 项目正式的最后期限，如果轻言更改，团队成员会因此隐 约觉得原来的日期设定不妥当，造成人心浮动。项目的正 式到期日并不是不能改变，但不可因为进度赶不上而将它 延后。
在进度落后时，最最糟糕的办法是估计落后的时间差， 而将到期日向后顺延。这等于是将一件你确定已经做错的 事情（进度落后），往后再背负下去（进度还会再次落 后）；这个方法似乎是很方便的权宜之计（我们再也不必去想它），却是最极致的愚蠢。这时候你最确定的事情就是必须思考为什么会发生进度落后。 即使你现在已知的信息，比起你在项目初期设定期限时要丰富许多，但大概依然不足以让你决定新的时程表。 不过话又说回来，要说明在什么情况之下可以重设新期限 本来就是极困难的事。比较好的一般性原则是，除非你已 经很确定各个组件产生多少程度的落后，还欠缺什么样的 内容，发生落后的原因已经确实找出来，并且问题已经在 克服中，否则绝对不要轻言更改最后期限。当然，要做到 这个前提，必须全体团队的合作，正确的领导，以及全心 的投入，在能够精算出期限的数学公式（我预备退休后要 研究的）发表之前，你实在无法估算出正确的期限。你应 该很务实地将目标放在最近一次的里程碑上，并且你必须 做好心理准备，往后的里程还是充满不确定的因素。
珍惜你的时间，把它善用在找出发生进度落后的原因 上，而不是计算我们该延期多久，你不会因为花时间解决 问题而耽误更多的时间，相反地，你会使团队以后走得更 快更稳，早一点达到目的。
法则延误了这个里程碑， 就一定要如期到达下 一个里程碑我们必须明白，每一次的延误，就是你和团队信心的一次受挫，所以，延误这个里程碑时，最好的补救办法就 是无论如何绝不延误下一个里程碑。团队必须挽回对自己 的信心和对理想的承诺；因此，下一个任务必须准时完成 的意义更重大，团队需要重建信心。
你知道进度落后的情形有多严重，也知道是什么原因 造成，你知道该如何改正问题，然后你建立一个比较近程 的、保守估算的下一个里程碑，这次绝不能再失误，然后 重新发布这个消息。如果你的时程表是以下三周内不做任 何事，那也很好，喔，实在太过头了，是不是？我的意思 是你一定得定下一个能够完成的里程碑，哪怕这个里程碑 在内容上没什么了不起，并且绝不失误地达成这个目标， 这个动作必须铿锵有力才行。绝不能再次延误，因为团队 需要藉这个机会重建自信。如期达成里程碑，这个目标的 成功，会带给团队鼓舞的力量，重新充满活力，相信自己 有能力达到对时程的承诺。这种心情是非常重要的，如果 团队相信自己能够如期达成里程碑，他们就会尽一切努力 去达成，这似乎是人类应有的工作方式。
法则把延误当作宝贵的学 习机会把进度落后当成一种宝贵的学习经验：你曾经不明白的事情，现在明白了，此时正是分析、了解、思考和消化 的最佳时机。这时候学到的心得是最深刻的，也许很难用 言语描述。如果你只是用刻板的印象去看待进度落后，把 它当作是一件坏事，那这个进度落后的事实不能让你进步， 进度落后会成为你深怀恐惧却时常发生的事。
虽然有这么多不确定的因素会造成进度落后，延误几 乎是必然发生，甚至已经被视为正常。有很多软件开发工 作本质上是具有实验性的，新的平台、新的操作系统、新 的程序技术，往往使得每一个新项目都充满不确定性。
延误既然不可避免，为了防止酿成大祸，你必须衡量 各种可能造成延误的因素。最理想的情况是，你事先已经 知道一个以上的不确定因素，并且让所有的工作人员明白 进度本身必须包括这些风险，让大家知道我们如何评估这 些不确定因素对进度的影响，如何估算风险所占的时间， 这项预估能力是团队的知识与技巧，对未来大有帮助的。 你同时必须懂得判断人们是不是在做”对“的事情，进度 的落后经常的原因是，人们花太多时间在研究一些比较外 围或衍生出来的特色，事实上这些工作对产品的核心信息 没有什么帮助。
如果延误是你突然的发现，那就表示沟通的渠道不畅通，你必须加强团队的沟通能力，你必须搬出一大堆 详细的信息给团队成员看，让他们对这个问题有具体而 真实的体会，延误暴露了团队的弱点，但也提供了毫无 保留的检讨机会。你必须确定每个人的每个角色都得到 了需要的指点。
延误也是重新评估未来相对于什么目标该有什么资源 的好机会，日后对该有的产品功能特色，会更加务实地捡 选，对于不利于团队工作效率的特色将尽量不予纳入目标， 对于资源与特色相互的作用也能更准确估算。
总之，能够让团队学习的延误，绝对是件好事。
法则见树亦见林如果本项目有六个模块，各有 90%的部分已经完成，那么你已经完成了 54%。每个模块完成了九成，听起来是 个挺不错的成绩，但不能当成整个项目完成了百分之九十， 它们之间不是相加的关系。你必须”见树亦见林“。如果 任何一个模块完成比率是零，那么整个项目的完成率也是 零。
用这种数学运算去计算整个项目的完成率是非常正确 的，因为每一个组件对产品都是相等的重要性，假定你的 团队是平均分配工作，那么任何一位失败就是团队全体的 失败。
必须注意的是，没有一件事情是能够有百分之百把握 的，如果是，那很可能发生”骄兵必败“的后果。今天的 英雄可能明天会惨遭滑铁卢，我每每对曾经跃升的明星和 它坠落的速度震惊不已。你必须设法让组员了解声誉得来 如此不易，却是如此脆弱易碎，不堪一击。团队必须时时 刻刻惕励自己，不要任意把别人当作笨蛋，不要狂妄自大， 不要自我膨胀，不要让自己心中的魔鬼打败自己。
法则世界在变，所以你也 得跟着改变成功的软件开发工作有一项重要的特质，就是能够从每天涌进的新信息中，做出正确的决策。你不必过度拘泥 于计划和进度，那是人造的事实，难免有失真的时候。改 变是机会之母，如果你对学校课堂中教你的知识不能活用， 你会失去许多机会，会很难适应这个迅速变迁的环境，你 会把改变或机会当成是障碍，当成计划和进度的干扰，而 不是充满潜力的转机。
软件开发也是一个不断改变的有机体，通常一个大得 不得了的困难，事实上代表着团队对于开发出好软件的强 烈欲望。在你作出直觉反应之前，在你把它当成问题去消 灭之前，花点时间挖掘这种心理状态背后的玄机，试着把 这股能量导入正确的方向。问题本身可能表达着许多意义， 你必须运用你的观察力、想象力、第六感，决定如何将软 件开发的过程导引顺畅。绝对记住你是在领导一群人的心， 共同进行创造性的工作。如果可预测性愈高，代表创造性 愈低，所以，每件事情都得保持弹性。
当然，你不会希望轻率改变，任何改变都不可导致你 偏离方向，过度的改变会使人无所适从。弹性不代表随便（randomness），弹性是延展性、适应性，是自然地改变， 而随便则是突然地、毫无关连的胡乱改变。如果外界没有微软团队?成 功 秘 诀法则47 世界在变，所以你也得跟着改变变化，随机的改变一下也许会有点灵光乍现的好处，但维持原状则更加保险。只有在改变能够加强整体效率时才能 接受它，改变的目的是让团队的工作最佳化，而不是导入 更多的复杂性。
我们这样举例说吧，也许有一天，你想增加一个里程 碑，没有明显的理由非得这么做不可，但是有确定的迹象 显示这是目前的发展方向所趋，这时候增加里程碑可能增 加了进度落后的风险，但也可能增加产品推出后的机会。 我特别提出这个例子，是因为我的团队最近经常遇到类似 的困扰，虽然我们一直以准时推出产品为荣，但是环境的 变化使我们愈来愈觉得必须与众不同，必须有所突破，在 原定计划中加入一个新的里程碑，做一点特别的东西。每 一个项目都像是新生的孩子，每个项目都是独特的，你必 须顺应项目独有的特质，配合它定出最适当的里程碑，并 且充分支持它，用它的语言去表达它，而不是像切蛋糕般，切成你想要的样子。
虽然你想做些改变，你未必有勇气实行。
伟大的软件必定只有一个中心思想，至于品质能够实现到什么程度，依赖领导者能否带领团队融合无数个小而 重要的改变。如果你能在混乱中辨识出对项目最有意义的 改变，并且引导团队去适应它，将它融入团队的精神中， 将来就会在产品中表现出这项改变，呈现在顾客眼前。
抗拒变化是失败的策略，你必须学习找出无法抗拒或 是对产品有利的改变，拥抱它、适应它，最后这项改变会 带给你丰富的收获。这是困难的心路历程，你需要刚铁般 的意志，因为你得依赖自己独有的远见，你所看见的没有 任何人能看见，你会很寂寞，每每在深夜被怀疑缠绕而不 得安眠。虽然你实在很想做些改变，你未必有足够的勇气 付诸行动，你等于是在挑战着人们的期望，而且你自己的 感觉也会因此而被左右，你不敢确信这些改变是好的。你 会面临艰难的抉择，在改变与不改变之间饱受折磨。
然而，不论改变有多大的阻力，只要是必须的改变， 你就得排除万难接受它，否则你会被它摧毁。
对我而言，即使只是把这些想法写下来，都令我感到 惊慌害怕，但这实在是我在软件开发的过程中，确确实实 的经验体会啊！
第三篇推出时期于软件开发团队来说，没有什么比产品准备推出（Ship Mode ）更令人兴奋的了。大多数人认为产品 在经过这个阶段后，就可说是诞生了，但我还是倾向于将 此一时期细分为三个小阶段：激活、推移和完成（ onset, transition, endgame）。这三个小阶段没有明确的间隔，彼 此也有重叠的部分，但三者的工作重点却不相同，而每个 团队必定都会一一经历，才能将产品推出。每个人对这三 个小阶段的区分方式也可能不尽相同，但对于将整个产品 推出的催生阶段，每个人都会有类似的看法或感受。
产品的推出：激活激活产品推出（ship mode: onset）是一段漫长而渐进 的过程，就好像婴儿出生前的阵痛。这时候团队开始为产 品的推出做一切繁杂的准备工作，就好像分娩前产妇要练 习呼吸，身体的机能也会为出生的那一刻作准备一般。在 产品推出的那一刻，团队必须全神贯注、倾全力使它顺利 出门，实在是个紧张而痛苦的时刻。
假定我们有四或五个里程碑，大概到 M3时产品就应 该大致成形，M3的到达就是产品推出的第一次”模拟考“。 往后的第四个和第五个里程碑，应该更强调产品推出时的练习，不但是产品本身愈来愈接近推出时该有的模样，里程碑的到达也应该更像是产品的真正推出。 通常进入激活阶段的第一个征兆是，一部分认真思考的组员开始焦虑：”我们真的能做到吗？“这并不表示团 队害怕自己做不来，而是一些先知先觉者开始思考许多该 做的事、可能降临的困难，想到那么多那么杂的事情要做， 觉得千头万绪，简直不知如何是好，尤其是开始焦虑的人 还是少数时。逐渐地，恐惧甚至惊慌，像是野火般蔓延到 整个团队，也许领导者在公开场合也流露出这种内心的情 绪。在整个团队都染上这种紧张的情绪时，领导者反而可 以松一口气，因为现在每个人的心里都关心着同一件事， 产品的推出是每个人现在强烈的心愿，大家有一种携手同 心的感觉，我们正在共同为一个伟大的产品而努力的感觉，经过了那么辛苦的开发终于要有成果的感觉。
有些组员会怀疑，领导者大概是乐观过了头。
现在，领导者要做的事是为大家加油打气，为大家灌输自信和热忱，有些组员可能会觉得领导者大约是乐观过了头，但大部分的人都会受到鼓舞，理解在这时候焦虑是 正常的，是可以被接受的自然反应，而且是创造智能财产 过程中必经的压力。
在激活阶段的团队工作效率会达到巅峰状态，因为大 势已定，不需要再揣摩或协商。这时候的团队心理有以下 几项特点：
大势已定产品的功能特色、团队中每个人的角色几乎是完全定型了。所有犹豫不决的特色不能早点 定案到现在都得删除，组员之间的工作负荷很平均， 产品架构完全确定而且趋向成熟，测试计划正在进 行，文件撰写原本只有纲要，现在要加入细节。此 时一切都没啥好争论的，没有任何疑惑，每个人都 知道产品就要诞生，剩下来该做的事也很清楚，去 做就是了。艰辛的开发工作终会过去，此时，赶紧 把它完工是最重要的。
共同一致的信念每个人都有一致的信念，我们即将完成产品，时间一到产品就能推出。现在所有的 痛苦抉择或权衡都已经过去，大家只要专注于眼前 产品的状态就好。产品的催生时期就代表着所有的争议结束。如果现在还有怀疑或争论（到现在还没解决的话），也只有暂时搁置，到下一版时再说， 否则永远没完没了。此时若是还有人对项目有严重 的怀疑，产品是永远无法进入催生时期的。
每个人都明白每个人都明白自己该做什么事，也明白整个团队该做什么事，才能使产品顺利推出。 现在已经没有什么事是不确定的了。所以，只要继 续把手上的工作做出来即可。延误或是对延误的恐 惧，只单纯地和自己的工作有关，不再和别人的工 作有太多的依存。在组员心里曾有的焦虑、飘浮无 依的不安，现在都可以放掉。我常把这个阶段称作 ”工作清单“阶段，每个小组都把自己的一大串的 工作逐条列在清单上，现在要把清单上的工作逐项 完成，打个勾勾，清单上每一项工作都做完时，产 品就完全推出了。 开发团队的最高领导人必须身先士卒，率先进入产品推出时该有的心理状态，并且信守一切的承诺，才可能带 动所有组员进入这个紧张的时期。对于细节的认知会愈来 愈清楚，在工作步调上也许会有点凌乱的危机，但这时候 领导人最重要的工作就是带领大家专注于产品的推出，凡是不太相干的事情尽量排除；在团队中的每一个成员都渴望推出，看到自己辛勤耕耘的结晶是多么欣慰，领导人必 须将大家对于推出的渴望，转化成完美的推出工作。
产品的推出：推移推移阶段（ship mode: transition ），在时间上可以跨过 一个以上的里程碑，视产品性质的需要与产品的推出而定。 基本上，产品推出的推移阶段是产品从开发迈向完成的逐 渐稳定阶段。开发工作仍在进行，直到最后一个里程碑为 止；如果开发工作的重心是增加功能，势必很难同时追求 产品的稳定，自然严重影响产品的推出；由于同时追求增 长和稳定实在太耗费心力，这时候主要的开发活动是除虫， 凡是无法完成的功能特色都暂时放弃。要放弃任何的功能 特色，都难免引起组员的不安情绪，所以，下决定之前必 须审慎地分析评估。
如果我们把产品推出当成一条数学上的连续曲线，你 会发现当产品愈来愈成熟，所需的开发人力愈来愈少，产 品推出就进入了完成阶段（我们稍后再详细讨论）。现在， 产品推出的推移阶段即将结束，而将进入早期的完成阶段 时，会有下列的迹象：
组员的思考更加保守而小心谨慎，避免掉入开发的泥淖。
程序置入的动作审慎再审慎，通常会成立一个临时 的特勤小组，检查每一个程序置入的动作，务求事 先防范大幅的不利影响。
增进执行速度和改善使用者接口成为工作的重点， 把产品磨亮打光，以期带给外界深刻的印象。收尾 成为最重要的方向。
修饰的工作完成后，接下来加强产品的稳定度，以 达到推出的要求水准，所有的开发工作已经结束， 清除错虫的工作也已接近尾声。
产品的推出：完成在产品推出（激活、推移和完成）的三个阶段中，工 作重心发生移转，从准备进入催生时期的心理变化，产品 逐渐稳定下来，直到产品推出的完成阶段（）时，只剩下一个里程碑了，就是”推出“（shipping）。在概念上，这个阶段的工作相当单纯，就是 一张工作清单，当上面所列的项目逐一完成，产品就推出 了。工作清单上有几百项，甚至几千项，也不过只是一张清单罢了，很多但不会太困难，你没有时间想或做这张清单以外的事情，每个人只有心思专注在自己该做的事情上。 也许会发生一些状况，使得工作清单上必须增加一些项目， 团队会在一阵”适度抗拒“（appropriate resistance）之后 接受工作项目的增加；这种适度的抗拒，我把它称之为 ”谦逊的抗拒“（profound resistance）。
这时候每天召开例行的检讨会是个很不错的方式，如 果能常常邀集决策者参与更好。会中的议程不拘泥于惯例 或任何形式，但必须是能立即决断的问题，凡是长期性的 目标或一时无法解决的问题，都暂时撇开不谈，下次改版 时再说。管理者参加这个会议的作用之一就是将议题引导 在这个方向上。现在，团队的主要目的是在推出日期时， 产品的品质水准要够好。已经进入倒计时阶段，开发人员 主要的工作是错虫的更正，而且是重要的错虫──这会影 响很多的使用者，或是造成严重具毁灭性的错虫，都必须 优先清除。至于使用者界面的美化、执行速度加快、或是 新的功能，都不宜在完成阶段讨论。 Beta测试版的测试结 果，以及外界的反馈，都以”追求产品的稳定性与避免严 重错误“为大前提，作小幅度的修改。而其他的建议案， 都只是预警相关人员在销售上可能遇到的困难或不利影响，或是下一版的改进时的建议，但基本上，目前不打算在产品上响应这些项目。
有多少无伤大雅的错虫，存在于你推出去的产品中？
你必须了解，顾客对于软件品质的要求程度，或是说 对错虫的忍受程度。在你推出的产品中，有多少错虫因为 优先顺位较低，而未及修正就随着产品出门？这些较次要 的错虫会不会造成问题？使用者会不会因此而在操作上遇 到麻烦？由于在产品的推出阶段，稳定是第一优先考量， 所以在决定是否要更正一个错误以前，必须先考虑会不会 因此而造成更大更多的错误；有些错误的修正太冒险，错 误本身的危害并不大，把它列在产品的读我（readme.doc） 档中说明，会比较好。
有时候，就像有些人的阵痛期特别长一样，产品的推 出工作如果不太顺利，也可能使上市的日期受到延误，以 下有几个法则提供软件开发团队的领导人参考，以期能避 免在产品推出时发生延误的情形。
下载法则关怀多于要求身为团队的领导人，你可能巴不得所有的属下都拼命工作。但事实上，虽然在产品推出阶段所面临的挑战可能 真的需要大家拼命工作，你却不可能”命令“大家为工作 牺牲奉献自己的一切。我曾经见过一些没有人性也不懂人 性的管理者，要求他的组员晚上加班、周末来上班，结果 组员要不是他的命令理都不理，就是在背后嘲弄这位可恨 的管理者。
事实上在产品推出的阶段，管理者的作用并未消失， 有些仪式性的动作，虽然很小或很简单，却是意义非凡。 此时领导人应该用实际的行动来表达他对组员的关怀，肯 定他们对组织的贡献，让每一位组员都感受到自己的每一 个角色都是那么的重要，领导者的关怀，可以增强组员的 向心力，对产品的顺利推出有莫大的影响。
领导者对组员的沟通应该是具有鼓励性，不是强迫加 班，而是提供方便的加班环境。例如，写一张小卡片给某 位组员（不能用虚假的客套话、公式话，要真诚的关心）、 走廊上餐厅里不期而遇时的几句赞美、提供加班时的托婴 托儿服务、自掏腰包来个点心宵夜，或是让组员可以很方 便地在家工作（简单的远距办公室通信设备）；这些小动 作花费极少，却让组员体会你的关心与诚意，而感到自己的加倍付出是值得的。还有，这些小动作似乎都是与传统规矩背道而驰，你为了他们而打破这些传统的规矩，也让 组员们觉得你对他们的肯定超过公司给你的规定。一般来 说，优秀的开发人员多少都有点叛逆心理，喜欢对传统的 权威挑战，你用别出心裁的方式鼓舞他们，比用传统的方 式要来得有效。
优秀的开发人员多少都喜欢违抗传统。
以行动表示的关怀，同时还告诉组员产品推出是件值 得纪念的大事。大家合拍一张照片，写一篇小故事，收集 一些开发过程中辛苦的笑料，送个电子邮件恭贺大家产品 终于要推出，或是表扬一下杰出的组员或事迹。这些都是 领导人在这时候可以做的事情，让大家留下难忘的回忆。 好好享受这欢笑的收割吧！因为大家都曾经流泪播 种。产品推出是大家形成一个团队的目的，也是大家同甘 共苦情绪的最高点。这时候团队士气是最高昂的，所有曾经犯下的愚蠢行为和几近干戈的争议，现在一律抛诸脑后。 大家已经完成任务，产品推出了。
法则测试版不是修改 功能的时候几乎全世界的人都有这种误解，以为Beta测试版就是邀集外界对产品提出设计方面的改进建议，然后让软件 公司对功能做加强或修改。这是完全错误的。（Alpha测 试又名内部测试， Beta测试又名外部测试， Beta测试版是 把即将推出的产品提供给部分顾客试用，另一方面也作 为对市场的试探。）Beta测试的目的是确定产品是否能在 预计的各种硬件平台与操作系统中正常运作。虽然 Beta测 试的反馈意见很有参考价值，但除非 Beta测试中发现产品 有重大问题，否则不应对功能再做修改，顶多只是更正 错误。所有的建议和反馈都留到下一版时再考虑纳入。
这么做绝不表示忽视顾客的意见，相反地，如果你要 把Beta测试的意见纳入，那你永远没有办法推出产品。你 与顾客之间的关系应该是更亲密、更持续的（请参考本书 第一篇中的顾客关系）。
法则测试是暖身活动顾客对产品的第一个印象往往决定了他对产品的评价。基本上，Beta测试者的反应，也会是大部分顾客的反 应。行销人员应该把握 Beta测试的机会，了解测试者对产 品的感受，分类并记录测试者的反应，以便在产品的包装、 信息传达等方面抓对方向。即使在这时候主要的信息已经 发布给媒体，敏锐的行销人员仍然能够从Beta测试的结果， 得知那些应该强化或淡化的信息。行销人员应该建立一套 顾客心理学的模型，用来了解顾客在使用产品时的心理状 态及其变化，以及产品信息应该如何根据试用顾客的心理 反应来做调整。
毫无疑问，你一定会在 Beta测试中得到一些负面的评 价，这很正常，而且应该在你的意料之中。如果负面反应 很强烈的话，你得设法找出其他的产品优点去平衡它；如 果负面反应很普遍，每个测试者都有，那你得让大众降低 对产品期望的水准，让这个负面反应在消费者的意料之中， 而不致产生吃惊受骗的感觉，这样负面的反应就不会那么 强烈；最后，你得设法让这个产品的缺点看起来不那么严 重，比方说提供解决的操作方式等等。
就算Beta测试活动不是由行销人员所主导，也应该让 行销人员密切参与。在这个时候，与外界的沟通就可说是经不是用开发活动来创造产品的形象。
下载法则急救术的缺点。欠缺完美是所有智能财产的必然性质。世上所有的事物都不完美，所以问题不在于判断这个产品好或不好， 而是决定应该修改那一部分，使它比较能被顾客接受或喜 爱。我们把这个判断并修改的过程称之为”急救术“（triage）。 急救术，当然是个医学名词，在急诊室中医生必须非常迅速地查看所有的问题，采取最急迫必要的急救医疗措 施，然后再依优先级分别施救。软件急救术是非常类似的 观念，先分析各项错误与瑕疵，以及它的严重性，以下是 判断是否施救的准则：
错误的严重性：如果错误严重到必须回收所有已推出的产品时，那么就必须立即改正这项错误。
明显程度：错误会很明显而立刻被使用者发现吗？ 会不会影响到产品的品质？会影响到产品的形象， 而成为竞争者攻击或嘲笑的把柄吗？
影响范围：有多少比例的使用时间，会遇到这个错误？这个错误是大部分的使用者都会遇上的吗？
修正错误的风险：如果要修正这个错误，会不会造 成软件的不稳定？这需要非常资深又对产品了如指下载掌的开发人员来判断。
错虫满天飞微软团队?成 功 秘 诀法则51 急救术团队动态：为了修改这项错误是否需要动用大批的人力，抑或是一小部分人员投入即可？会不会使已 经忙碌不堪的开发人员更加人仰马翻？
修正错误后所需要的测试成本：为了任何理由修改任何部分都需要测试，团队有没有足够的人力来执 行测试工作？时间上允不允许测试？
一般而言，急救小组的任务是选择和修改产品中最重 要的错误，尽量让大部分的使用者在大部分的时间都能使 用愉快。对使用者而言，这项不完美的产品是帮助还是灾 难？他是用这个不完美的产品比较好，还是宁愿不用比较 快乐？这个复杂且严肃的问题，需要工作人员不断设身处 地去设想使用者的情况，揣摩使用者的心情，与使用者双 向沟通，才能探得正确的答案。
下载法则小心保持软件的稳定处于完成阶段，你必须灌输组员一个观念：修改软件是一件危险的事。软件马上要推出，这时候稳定绝对是第 一要务。错误修改的成本或风险如果太高，宁愿不要修 改；不必要的修改必须极力避免。
产品的推出，就像一盘特大号的、结构脆弱的果冻， 你一摇动盘子，果冻必定会颤动、摇晃，然后逐渐静止。 你摇动愈用力，果冻晃得愈厉害，需要变回静止的时间就 愈长。同样地，你修改任何一个错误，都不可避免地影响 到整个软件的稳定性，等到你的软件像果冻一样恢复静止， 恭喜你，那就是你推出产品的时机了！
然后，它会再度震动。
第四篇发布时期书的主要目的虽然在阐述如何以团队方式开发伟大 的软件，然而，我们无论如何都不能忽略与大众的 沟通。软件如果无法让一般大众很容易感受它的伟大、它 独特的优点，又有什么用呢？我的看法是，软件的伟大必 须要经过与大众沟通的过程，让世人都认识它，既然是伟大的软件，当然要让它在历史上记下一笔，让它永垂不朽。 因此，软件产品完成后，必须要有一个产品发布会。
产品发布会就是让产品留名青史的时刻，顾客、产业 记者和评论家都在发布会上睁大眼睛看你的软件作品，这 是他们了解产品的开始。即使你的软件不是商业性的，也 不打算特别包装，但仍得利用产品发布会来强调它的技术 性，至少是在一个研讨会之类有很多重要人物聚集的场所 发布你的新技术。无论采用什么方式或强调什么重点，你 的目的是昭告世人新软件产品出炉了，希望大家对它有正 确而清楚的认识。这是软件首次登台亮相，你得让它吸引 众人的目光，尽可能使它的信息清楚地传递给所有的人， 这是你的开发团队和顾客建立关系的大好时机，也是对组 员很大的鼓励。
产品发布会是一个充满成功气氛的活动。
已发布的信息是无法收回的。信息虽然可以重新发 布，但结果大都不理想，人们心中对产品的印象不是新 的信息，而是一片混淆，所以第一次信息发布格外重要。 一个规划妥善的产品发布会，所有信息与气氛的设计都 应该以产品为中心，一切安排都是为了抓住人们的注意 力，让产品在明确的信息烘托之下，漂亮登场，配合精 心设计的各种沟通媒介，务必让每个人都对产品有鲜明 而正确的认识。把产品发布会做成功的好处是说不尽的， 此处择要概述如下：
确定的产品发布会，能够促使团队为确定的目标同心协力。如果每个人都认为并期待某一件事应该在 某一天发生，就像是一个共同的目标，无形中促使 开发团队把它当作一项有意义的挑战而同心协力。 我建议每一组参与产品发布活动的人，都有详细的 战略规划，因为发布会和产品本身，就像一场战役。
产品发布团队（launch team ）应该与开发团队一样，应用本书的 54条法则，应该有共同的目标、懂得运 用策略、有团队精神，发布团队必须把任务当成一 种全心全意的承诺。全体工作人员会感受到产品发 布那种成功的气氛，辛辛苦苦孕育的产品，如今捧 在自己手中，那是非常令人振奋的感觉，这种心情 会感染给会场上的每一位来宾，使产品发布会更加 热烈。
成功的产品发布会能够提高产品的接受度。有些意见领袖对产品发布会特别敏感。很多人参加产品发 布会纯粹是为了对科技的狂热，或是产品对他个人 有重大的影响，再加上产品发布会本身多少带有戏 剧性，所以，会有很多人带着热情而来，他们会希 望认识你、你的团队和你们的努力、你的软件和你 对这个软件的感情，因为使用你的软件，他们开始 认识你，你和团队的言行气度所表达出来的形象， 也会是他们对新产品的印象之一。事先应该和行销 人员研究好，如何确切地表达这个产品在历史和技 术上的重要性，这和如何发挥产品发布会的戏剧效 果是同样重要。
发布会是产品与大众见面的最重要的活动 。就像电影的首映会一样，发布会是产品问世时的第一次 见面；发布会的前置作业与后续的活动都有逻辑上 的顺序，应该事前安排妥当。在 Beta测试时，你就 应该邀请媒体、重要的顾客、相关领域的权威人士、 你的朋友，试用 Beta测试版，这样的话，他们会对 产品有清晰的概念，也会比较乐意提供自己的感 想，为产品做见证。而在发布会前夕，你私下寄给 这些重要试用者一段小小的摘要，稍微提醒一下产 品的特点，免得他们太忙而不记得产品试用时的感 受。在产品发布会上，这些人就会很自然、很清楚 地向记者宣布他们对产品的看法，等于是为产品背 书一样的效果。发布会后接踵而至的是一大堆的广 告活动，包括传单、电子邮件、产品目录、现场展 示等等。你必须密切注意与会者的现场反应，尽可 能给予足够的支持和服务。这一切细节都是发布会 的一部分，也是产品信息的一部分，不论这些事情 要花你多少功夫，无论你和顾客熟到什么程度，你 都必须将这一切细节都照顾好，确定产品发布会尽 善尽美。
下载法则伟大的软件应该有一 个伟大的故事软件的故事每一个伟大的软件，背后都有一个伟大的故事（平庸 的产品当然只有平庸的故事）。信息架构就像软件中的位 元一样复杂交错，因为信息必须以不同的层次传达给不同的对象，信息必须和接受者发生情感上的共鸣，必须随着时间和环境而演变修正，信息必须够简单，这样才能强而 有力，但又必须够复杂，这样才能引发接受者更大的兴趣。 很显然地，信息所达到的沟通品质，与产品销售成功与否 有莫大的关系。请切记，你应该有适当的投资放在信息传 递上，就像开发工作一样重要，因为信息和产品是密不可 分，二者都是团队所创造出来的智慧财产。
传统智慧经过许多年的传颂，容易让人很快接受。
你必须事先仔细思量，以产品的沟通策略来设计的信 息结构应该是什么样子？如何传递出去？应该如何引导人 们的思路，帮助他们开始懂得欣赏产品？你的信息应该包 括这些，才能让无形的智能财产被世人看见。
当你站在听众面前，别只顾着示范产品特色，先表达 一下产品所赋予的内涵，把产品的故事说给团队、高级主 管、记者、产业分析师、顾客或投资人听，这个故事必须 具有传统智能的色彩。凡是带着传统智能色彩的东西，都会被自然地传颂，而且在任何专业领域都是共通的语言。
传统智能必定是个小故事大道理。你的故事必须至少 有一条主轴是与科技趋势或市场情况(或是二者)有关，这 样才能让听众觉得你的故事有价值，乐意倾听。故事的内 容必须简明扼要，同时又能引发听众更深入的思考，让头 脑灵活的听众觉得其中有些内涵正是我所想过的(共鸣!）， 太玄的言论无法引起在座专家的兴趣，而且绝不能落于俗 套。请注意故事要既简单又有内涵，不要太过简化而流于 空洞，你的内涵一定要让听众觉得非常有价值才行。
要让听众深有同感：”对！这正是我过去一直在思考的。“要把产品信息用一个简明、有见地的故事表达出来， 本来就是一个很大的挑战。你必须能够打动听众的心弦， 要让他们深有同感：”对！这正是我过去一直在思考的。“ 这不是在宣传你的观念，而是在无形中与听众的思想交流， 引发他去想你提示的问题，让听众用自己的心去体会你的 信息，而不是被你灌输信息。这些信息必须听起来像是常识，被你说出来，又在他心中产生了共鸣，就会让听众觉得这是真理。 让我们举个例子来说明信息的内涵，你可以这样开场：
”使用者不爱用footbar，因为它就是这么难用。“这好像是 直说国王没穿衣服一样的反传统─但绝不激进。用一个 大家都知道或愿意相信的事实（也许大家都不好意思宣之 于口），从这个事实紧密地引申出另一个与产品有关的事 实（你要表达的重点，也许直接说会不容易被人接受）， 而且记住不要陈述已经被别人提过的事实（人们会混淆这 话到底是谁讲的）。
当我们发布 Visual C++ 1.0的时候，我们强调的事实 是大部分的程序设计师还没有从 C换到C++。我们调查结 果的数据资料显示，有 80%的C语言程序设计师打算、即 将或是希望能从 C换到C++，但只有10%的人真正能做到。 媒体和产业分析报告都表示C++的时代已经来临，但我们 的资料却显示着相反的情形，这是我们要直言说破的皇帝 新衣。
直接说出产品信息，未必是最有效的表达方式。
我们的直言不讳很快打动了人们的心坎，因为这是千 真万确的事实，而且大部分的人都有同感。就算我们不说， 也许大家终究会知道事实的真相，只不过要花多一点时间 和疑惑吧。
然后，第二步是紧密地引申出另一个事实，也就是产 品信息，非常简单：即使是对于精通C语言的程序设计师， C++还是太难了 ─直到Visual C++的出现为止；我们不 追究为什么 C++那么难，我们只知道 Visual C++把它变容 易了。
传统智慧通常都以俗谚表达，用一两句简单又响亮 的词句，让人朗朗上口、易颂难忘。政治家都是精于发 明口号的高手，例如：”我们需要的是五分钱的雪茄“、 ”除了畏惧本身，没有什么好畏惧的“、”不要问国家为你 做了什么，要问自己为国家做了什么“。这些口号之所以 深入人心，因为它们包含了传统智慧，简明响亮，又提供了指导的功能，没有冗长复杂的理论。尽管喊出这些口号的人早已故去，但这些口号如今依然存在，而且已 经变成了智慧的明灯，因为世人迷惑时它们提供指引， 如果这些口号没有智慧的内涵，流行过后必定会消失无 形，被人淡忘。
好的故事会让人终生难忘，因为它有内涵、有见地， 会让听的人感受到其中的睿智。好故事必须让人们容易联 想，一旦它触动了听众内心的共鸣（因为是很简单的事实）， 人们会很自然地打开心扉准备接受下一个联想或引申出来 的事实，而且接受程度和你打动他们的程度成正比。例如， ”某教练的球队总是无法赢得重要比赛“这是第一个事实， 但人们听到之后在自己的内心会这样重述：”这教练不好“ 或是”要不是他输掉了关键球赛，可能还是个不错的教练“ 这是一般人必然的反应，就是把接收到的信息加上自己的观感，用自己的话重述一遍。
