微软团队成功秘诀

这是完全错误的。（Alpha测 试又名内部测试， Beta测试又名外部测试， Beta测试版是 把即将推出的产品提供给部分顾客试用，另一方面也作 为对市场的试探。）Beta测试的目的是确定产品是否能在 预计的各种硬件平台与操作系统中正常运作。虽然 Beta测 试的反馈意见很有参考价值，但除非 Beta测试中发现产品 有重大问题，否则不应对功能再做修改，顶多只是更正 错误。所有的建议和反馈都留到下一版时再考虑纳入。
  这么做绝不表示忽视顾客的意见，相反地，如果你要 把Beta测试的意见纳入，那你永远没有办法推出产品。你 与顾客之间的关系应该是更亲密、更持续的（请参考本书 第一篇中的顾客关系）。
  法则测试是暖身活动顾客对产品的第一个印象往往决定了他对产品的评价。基本上，Beta测试者的反应，也会是大部分顾客的反 应。行销人员应该把握 Beta测试的机会，了解测试者对产 品的感受，分类并记录测试者的反应，以便在产品的包装、 信息传达等方面抓对方向。即使在这时候主要的信息已经 发布给媒体，敏锐的行销人员仍然能够从Beta测试的结果， 得知那些应该强化或淡化的信息。行销人员应该建立一套 顾客心理学的模型，用来了解顾客在使用产品时的心理状 态及其变化，以及产品信息应该如何根据试用顾客的心理 反应来做调整。
  毫无疑问，你一定会在 Beta测试中得到一些负面的评 价，这很正常，而且应该在你的意料之中。如果负面反应 很强烈的话，你得设法找出其他的产品优点去平衡它；如 果负面反应很普遍，每个测试者都有，那你得让大众降低 对产品期望的水准，让这个负面反应在消费者的意料之中， 而不致产生吃惊受骗的感觉，这样负面的反应就不会那么 强烈；最后，你得设法让这个产品的缺点看起来不那么严 重，比方说提供解决的操作方式等等。
  就算Beta测试活动不是由行销人员所主导，也应该让 行销人员密切参与。在这个时候，与外界的沟通就可说是经不是用开发活动来创造产品的形象。
  下载法则急救术的缺点。欠缺完美是所有智能财产的必然性质。世上所有的事物都不完美，所以问题不在于判断这个产品好或不好， 而是决定应该修改那一部分，使它比较能被顾客接受或喜 爱。我们把这个判断并修改的过程称之为”急救术“（triage）。 急救术，当然是个医学名词，在急诊室中医生必须非常迅速地查看所有的问题，采取最急迫必要的急救医疗措 施，然后再依优先级分别施救。软件急救术是非常类似的 观念，先分析各项错误与瑕疵，以及它的严重性，以下是 判断是否施救的准则：
  错误的严重性：如果错误严重到必须回收所有已推出的产品时，那么就必须立即改正这项错误。
  明显程度：错误会很明显而立刻被使用者发现吗？ 会不会影响到产品的品质？会影响到产品的形象， 而成为竞争者攻击或嘲笑的把柄吗？
  影响范围：有多少比例的使用时间，会遇到这个错误？这个错误是大部分的使用者都会遇上的吗？
  修正错误的风险：如果要修正这个错误，会不会造 成软件的不稳定？这需要非常资深又对产品了如指下载掌的开发人员来判断。
  错虫满天飞微软团队?成 功 秘 诀法则51     急救术团队动态：为了修改这项错误是否需要动用大批的人力，抑或是一小部分人员投入即可？会不会使已 经忙碌不堪的开发人员更加人仰马翻？
  修正错误后所需要的测试成本：为了任何理由修改任何部分都需要测试，团队有没有足够的人力来执 行测试工作？时间上允不允许测试？
  一般而言，急救小组的任务是选择和修改产品中最重 要的错误，尽量让大部分的使用者在大部分的时间都能使 用愉快。对使用者而言，这项不完美的产品是帮助还是灾 难？他是用这个不完美的产品比较好，还是宁愿不用比较 快乐？这个复杂且严肃的问题，需要工作人员不断设身处 地去设想使用者的情况，揣摩使用者的心情，与使用者双 向沟通，才能探得正确的答案。
  下载法则小心保持软件的稳定处于完成阶段，你必须灌输组员一个观念：修改软件是一件危险的事。软件马上要推出，这时候稳定绝对是第 一要务。错误修改的成本或风险如果太高，宁愿不要修 改；不必要的修改必须极力避免。
  产品的推出，就像一盘特大号的、结构脆弱的果冻， 你一摇动盘子，果冻必定会颤动、摇晃，然后逐渐静止。 你摇动愈用力，果冻晃得愈厉害，需要变回静止的时间就 愈长。同样地，你修改任何一个错误，都不可避免地影响 到整个软件的稳定性，等到你的软件像果冻一样恢复静止， 恭喜你，那就是你推出产品的时机了！
  然后，它会再度震动。
  第四篇发布时期书的主要目的虽然在阐述如何以团队方式开发伟大 的软件，然而，我们无论如何都不能忽略与大众的 沟通。软件如果无法让一般大众很容易感受它的伟大、它 独特的优点，又有什么用呢？我的看法是，软件的伟大必 须要经过与大众沟通的过程，让世人都认识它，既然是伟大的软件，当然要让它在历史上记下一笔，让它永垂不朽。 因此，软件产品完成后，必须要有一个产品发布会。
  产品发布会就是让产品留名青史的时刻，顾客、产业 记者和评论家都在发布会上睁大眼睛看你的软件作品，这 是他们了解产品的开始。即使你的软件不是商业性的，也 不打算特别包装，但仍得利用产品发布会来强调它的技术 性，至少是在一个研讨会之类有很多重要人物聚集的场所 发布你的新技术。无论采用什么方式或强调什么重点，你 的目的是昭告世人新软件产品出炉了，希望大家对它有正 确而清楚的认识。这是软件首次登台亮相，你得让它吸引 众人的目光，尽可能使它的信息清楚地传递给所有的人， 这是你的开发团队和顾客建立关系的大好时机，也是对组 员很大的鼓励。
  产品发布会是一个充满成功气氛的活动。
  已发布的信息是无法收回的。信息虽然可以重新发 布，但结果大都不理想，人们心中对产品的印象不是新 的信息，而是一片混淆，所以第一次信息发布格外重要。 一个规划妥善的产品发布会，所有信息与气氛的设计都 应该以产品为中心，一切安排都是为了抓住人们的注意 力，让产品在明确的信息烘托之下，漂亮登场，配合精 心设计的各种沟通媒介，务必让每个人都对产品有鲜明 而正确的认识。把产品发布会做成功的好处是说不尽的， 此处择要概述如下：
  确定的产品发布会，能够促使团队为确定的目标同心协力。如果每个人都认为并期待某一件事应该在 某一天发生，就像是一个共同的目标，无形中促使 开发团队把它当作一项有意义的挑战而同心协力。 我建议每一组参与产品发布活动的人，都有详细的 战略规划，因为发布会和产品本身，就像一场战役。
  产品发布团队（launch team ）应该与开发团队一样，应用本书的 54条法则，应该有共同的目标、懂得运 用策略、有团队精神，发布团队必须把任务当成一 种全心全意的承诺。全体工作人员会感受到产品发 布那种成功的气氛，辛辛苦苦孕育的产品，如今捧 在自己手中，那是非常令人振奋的感觉，这种心情 会感染给会场上的每一位来宾，使产品发布会更加 热烈。
  成功的产品发布会能够提高产品的接受度。有些意见领袖对产品发布会特别敏感。很多人参加产品发 布会纯粹是为了对科技的狂热，或是产品对他个人 有重大的影响，再加上产品发布会本身多少带有戏 剧性，所以，会有很多人带着热情而来，他们会希 望认识你、你的团队和你们的努力、你的软件和你 对这个软件的感情，因为使用你的软件，他们开始 认识你，你和团队的言行气度所表达出来的形象， 也会是他们对新产品的印象之一。事先应该和行销 人员研究好，如何确切地表达这个产品在历史和技 术上的重要性，这和如何发挥产品发布会的戏剧效 果是同样重要。
  发布会是产品与大众见面的最重要的活动 。就像电影的首映会一样，发布会是产品问世时的第一次 见面；发布会的前置作业与后续的活动都有逻辑上 的顺序，应该事前安排妥当。在 Beta测试时，你就 应该邀请媒体、重要的顾客、相关领域的权威人士、 你的朋友，试用 Beta测试版，这样的话，他们会对 产品有清晰的概念，也会比较乐意提供自己的感 想，为产品做见证。而在发布会前夕，你私下寄给 这些重要试用者一段小小的摘要，稍微提醒一下产 品的特点，免得他们太忙而不记得产品试用时的感 受。在产品发布会上，这些人就会很自然、很清楚 地向记者宣布他们对产品的看法，等于是为产品背 书一样的效果。发布会后接踵而至的是一大堆的广 告活动，包括传单、电子邮件、产品目录、现场展 示等等。你必须密切注意与会者的现场反应，尽可 能给予足够的支持和服务。