微软团队成功秘诀

  在激活阶段的团队工作效率会达到巅峰状态，因为大 势已定，不需要再揣摩或协商。这时候的团队心理有以下 几项特点：
  大势已定产品的功能特色、团队中每个人的角色几乎是完全定型了。所有犹豫不决的特色不能早点 定案到现在都得删除，组员之间的工作负荷很平均， 产品架构完全确定而且趋向成熟，测试计划正在进 行，文件撰写原本只有纲要，现在要加入细节。此 时一切都没啥好争论的，没有任何疑惑，每个人都 知道产品就要诞生，剩下来该做的事也很清楚，去 做就是了。艰辛的开发工作终会过去，此时，赶紧 把它完工是最重要的。
  共同一致的信念每个人都有一致的信念，我们即将完成产品，时间一到产品就能推出。现在所有的 痛苦抉择或权衡都已经过去，大家只要专注于眼前 产品的状态就好。产品的催生时期就代表着所有的争议结束。如果现在还有怀疑或争论（到现在还没解决的话），也只有暂时搁置，到下一版时再说， 否则永远没完没了。此时若是还有人对项目有严重 的怀疑，产品是永远无法进入催生时期的。
  每个人都明白每个人都明白自己该做什么事，也明白整个团队该做什么事，才能使产品顺利推出。 现在已经没有什么事是不确定的了。所以，只要继 续把手上的工作做出来即可。延误或是对延误的恐 惧，只单纯地和自己的工作有关，不再和别人的工 作有太多的依存。在组员心里曾有的焦虑、飘浮无 依的不安，现在都可以放掉。我常把这个阶段称作 ”工作清单“阶段，每个小组都把自己的一大串的 工作逐条列在清单上，现在要把清单上的工作逐项 完成，打个勾勾，清单上每一项工作都做完时，产 品就完全推出了。 开发团队的最高领导人必须身先士卒，率先进入产品推出时该有的心理状态，并且信守一切的承诺，才可能带 动所有组员进入这个紧张的时期。对于细节的认知会愈来 愈清楚，在工作步调上也许会有点凌乱的危机，但这时候 领导人最重要的工作就是带领大家专注于产品的推出，凡是不太相干的事情尽量排除；在团队中的每一个成员都渴望推出，看到自己辛勤耕耘的结晶是多么欣慰，领导人必 须将大家对于推出的渴望，转化成完美的推出工作。
  产品的推出：推移推移阶段（ship mode: transition ），在时间上可以跨过 一个以上的里程碑，视产品性质的需要与产品的推出而定。 基本上，产品推出的推移阶段是产品从开发迈向完成的逐 渐稳定阶段。开发工作仍在进行，直到最后一个里程碑为 止；如果开发工作的重心是增加功能，势必很难同时追求 产品的稳定，自然严重影响产品的推出；由于同时追求增 长和稳定实在太耗费心力，这时候主要的开发活动是除虫， 凡是无法完成的功能特色都暂时放弃。要放弃任何的功能 特色，都难免引起组员的不安情绪，所以，下决定之前必 须审慎地分析评估。
  如果我们把产品推出当成一条数学上的连续曲线，你 会发现当产品愈来愈成熟，所需的开发人力愈来愈少，产 品推出就进入了完成阶段（我们稍后再详细讨论）。现在， 产品推出的推移阶段即将结束，而将进入早期的完成阶段 时，会有下列的迹象：
  组员的思考更加保守而小心谨慎，避免掉入开发的泥淖。
  程序置入的动作审慎再审慎，通常会成立一个临时 的特勤小组，检查每一个程序置入的动作，务求事 先防范大幅的不利影响。
  增进执行速度和改善使用者接口成为工作的重点， 把产品磨亮打光，以期带给外界深刻的印象。收尾 成为最重要的方向。
  修饰的工作完成后，接下来加强产品的稳定度，以 达到推出的要求水准，所有的开发工作已经结束， 清除错虫的工作也已接近尾声。
  产品的推出：完成在产品推出（激活、推移和完成）的三个阶段中，工 作重心发生移转，从准备进入催生时期的心理变化，产品 逐渐稳定下来，直到产品推出的完成阶段（）时，只剩下一个里程碑了，就是”推出“（shipping）。在概念上，这个阶段的工作相当单纯，就是 一张工作清单，当上面所列的项目逐一完成，产品就推出 了。工作清单上有几百项，甚至几千项，也不过只是一张清单罢了，很多但不会太困难，你没有时间想或做这张清单以外的事情，每个人只有心思专注在自己该做的事情上。 也许会发生一些状况，使得工作清单上必须增加一些项目， 团队会在一阵”适度抗拒“（appropriate resistance）之后 接受工作项目的增加；这种适度的抗拒，我把它称之为 ”谦逊的抗拒“（profound resistance）。
  这时候每天召开例行的检讨会是个很不错的方式，如 果能常常邀集决策者参与更好。会中的议程不拘泥于惯例 或任何形式，但必须是能立即决断的问题，凡是长期性的 目标或一时无法解决的问题，都暂时撇开不谈，下次改版 时再说。管理者参加这个会议的作用之一就是将议题引导 在这个方向上。现在，团队的主要目的是在推出日期时， 产品的品质水准要够好。已经进入倒计时阶段，开发人员 主要的工作是错虫的更正，而且是重要的错虫──这会影 响很多的使用者，或是造成严重具毁灭性的错虫，都必须 优先清除。至于使用者界面的美化、执行速度加快、或是 新的功能，都不宜在完成阶段讨论。 Beta测试版的测试结 果，以及外界的反馈，都以”追求产品的稳定性与避免严 重错误“为大前提，作小幅度的修改。而其他的建议案， 都只是预警相关人员在销售上可能遇到的困难或不利影响，或是下一版的改进时的建议，但基本上，目前不打算在产品上响应这些项目。
  有多少无伤大雅的错虫，存在于你推出去的产品中？
  你必须了解，顾客对于软件品质的要求程度，或是说 对错虫的忍受程度。在你推出的产品中，有多少错虫因为 优先顺位较低，而未及修正就随着产品出门？这些较次要 的错虫会不会造成问题？使用者会不会因此而在操作上遇 到麻烦？由于在产品的推出阶段，稳定是第一优先考量， 所以在决定是否要更正一个错误以前，必须先考虑会不会 因此而造成更大更多的错误；有些错误的修正太冒险，错 误本身的危害并不大，把它列在产品的读我（readme.doc） 档中说明，会比较好。
  有时候，就像有些人的阵痛期特别长一样，产品的推 出工作如果不太顺利，也可能使上市的日期受到延误，以 下有几个法则提供软件开发团队的领导人参考，以期能避 免在产品推出时发生延误的情形。
  下载法则关怀多于要求身为团队的领导人，你可能巴不得所有的属下都拼命工作。但事实上，虽然在产品推出阶段所面临的挑战可能 真的需要大家拼命工作，你却不可能”命令“大家为工作 牺牲奉献自己的一切。我曾经见过一些没有人性也不懂人 性的管理者，要求他的组员晚上加班、周末来上班，结果 组员要不是他的命令理都不理，就是在背后嘲弄这位可恨 的管理者。
  事实上在产品推出的阶段，管理者的作用并未消失， 有些仪式性的动作，虽然很小或很简单，却是意义非凡。 此时领导人应该用实际的行动来表达他对组员的关怀，肯 定他们对组织的贡献，让每一位组员都感受到自己的每一 个角色都是那么的重要，领导者的关怀，可以增强组员的 向心力，对产品的顺利推出有莫大的影响。
  领导者对组员的沟通应该是具有鼓励性，不是强迫加 班，而是提供方便的加班环境。例如，写一张小卡片给某 位组员（不能用虚假的客套话、公式话，要真诚的关心）、 走廊上餐厅里不期而遇时的几句赞美、提供加班时的托婴 托儿服务、自掏腰包来个点心宵夜，或是让组员可以很方 便地在家工作（简单的远距办公室通信设备）；这些小动 作花费极少，却让组员体会你的关心与诚意，而感到自己的加倍付出是值得的。还有，这些小动作似乎都是与传统规矩背道而驰，你为了他们而打破这些传统的规矩，也让 组员们觉得你对他们的肯定超过公司给你的规定。一般来 说，优秀的开发人员多少都有点叛逆心理，喜欢对传统的 权威挑战，你用别出心裁的方式鼓舞他们，比用传统的方 式要来得有效。
  优秀的开发人员多少都喜欢违抗传统。
  以行动表示的关怀，同时还告诉组员产品推出是件值 得纪念的大事。大家合拍一张照片，写一篇小故事，收集 一些开发过程中辛苦的笑料，送个电子邮件恭贺大家产品 终于要推出，或是表扬一下杰出的组员或事迹。这些都是 领导人在这时候可以做的事情，让大家留下难忘的回忆。 好好享受这欢笑的收割吧！因为大家都曾经流泪播 种。产品推出是大家形成一个团队的目的，也是大家同甘 共苦情绪的最高点。这时候团队士气是最高昂的，所有曾经犯下的愚蠢行为和几近干戈的争议，现在一律抛诸脑后。 大家已经完成任务，产品推出了。
  法则测试版不是修改 功能的时候几乎全世界的人都有这种误解，以为Beta测试版就是邀集外界对产品提出设计方面的改进建议，然后让软件 公司对功能做加强或修改。