微软团队成功秘诀

  法则把延误当作宝贵的学 习机会把进度落后当成一种宝贵的学习经验：你曾经不明白的事情，现在明白了，此时正是分析、了解、思考和消化 的最佳时机。这时候学到的心得是最深刻的，也许很难用 言语描述。如果你只是用刻板的印象去看待进度落后，把 它当作是一件坏事，那这个进度落后的事实不能让你进步， 进度落后会成为你深怀恐惧却时常发生的事。
  虽然有这么多不确定的因素会造成进度落后，延误几 乎是必然发生，甚至已经被视为正常。有很多软件开发工 作本质上是具有实验性的，新的平台、新的操作系统、新 的程序技术，往往使得每一个新项目都充满不确定性。
  延误既然不可避免，为了防止酿成大祸，你必须衡量 各种可能造成延误的因素。最理想的情况是，你事先已经 知道一个以上的不确定因素，并且让所有的工作人员明白 进度本身必须包括这些风险，让大家知道我们如何评估这 些不确定因素对进度的影响，如何估算风险所占的时间， 这项预估能力是团队的知识与技巧，对未来大有帮助的。 你同时必须懂得判断人们是不是在做”对“的事情，进度 的落后经常的原因是，人们花太多时间在研究一些比较外 围或衍生出来的特色，事实上这些工作对产品的核心信息 没有什么帮助。
  如果延误是你突然的发现，那就表示沟通的渠道不畅通，你必须加强团队的沟通能力，你必须搬出一大堆 详细的信息给团队成员看，让他们对这个问题有具体而 真实的体会，延误暴露了团队的弱点，但也提供了毫无 保留的检讨机会。你必须确定每个人的每个角色都得到 了需要的指点。
  延误也是重新评估未来相对于什么目标该有什么资源 的好机会，日后对该有的产品功能特色，会更加务实地捡 选，对于不利于团队工作效率的特色将尽量不予纳入目标， 对于资源与特色相互的作用也能更准确估算。
  总之，能够让团队学习的延误，绝对是件好事。
  法则见树亦见林如果本项目有六个模块，各有 90%的部分已经完成，那么你已经完成了 54%。每个模块完成了九成，听起来是 个挺不错的成绩，但不能当成整个项目完成了百分之九十， 它们之间不是相加的关系。你必须”见树亦见林“。如果 任何一个模块完成比率是零，那么整个项目的完成率也是 零。
  用这种数学运算去计算整个项目的完成率是非常正确 的，因为每一个组件对产品都是相等的重要性，假定你的 团队是平均分配工作，那么任何一位失败就是团队全体的 失败。
  必须注意的是，没有一件事情是能够有百分之百把握 的，如果是，那很可能发生”骄兵必败“的后果。今天的 英雄可能明天会惨遭滑铁卢，我每每对曾经跃升的明星和 它坠落的速度震惊不已。你必须设法让组员了解声誉得来 如此不易，却是如此脆弱易碎，不堪一击。团队必须时时 刻刻惕励自己，不要任意把别人当作笨蛋，不要狂妄自大， 不要自我膨胀，不要让自己心中的魔鬼打败自己。
  法则世界在变，所以你也 得跟着改变成功的软件开发工作有一项重要的特质，就是能够从每天涌进的新信息中，做出正确的决策。你不必过度拘泥 于计划和进度，那是人造的事实，难免有失真的时候。改 变是机会之母，如果你对学校课堂中教你的知识不能活用， 你会失去许多机会，会很难适应这个迅速变迁的环境，你 会把改变或机会当成是障碍，当成计划和进度的干扰，而 不是充满潜力的转机。
  软件开发也是一个不断改变的有机体，通常一个大得 不得了的困难，事实上代表着团队对于开发出好软件的强 烈欲望。在你作出直觉反应之前，在你把它当成问题去消 灭之前，花点时间挖掘这种心理状态背后的玄机，试着把 这股能量导入正确的方向。问题本身可能表达着许多意义， 你必须运用你的观察力、想象力、第六感，决定如何将软 件开发的过程导引顺畅。绝对记住你是在领导一群人的心， 共同进行创造性的工作。如果可预测性愈高，代表创造性 愈低，所以，每件事情都得保持弹性。
  当然，你不会希望轻率改变，任何改变都不可导致你 偏离方向，过度的改变会使人无所适从。弹性不代表随便（randomness），弹性是延展性、适应性，是自然地改变， 而随便则是突然地、毫无关连的胡乱改变。如果外界没有微软团队?成 功 秘 诀法则47    世界在变，所以你也得跟着改变变化，随机的改变一下也许会有点灵光乍现的好处，但维持原状则更加保险。只有在改变能够加强整体效率时才能 接受它，改变的目的是让团队的工作最佳化，而不是导入 更多的复杂性。
  我们这样举例说吧，也许有一天，你想增加一个里程 碑，没有明显的理由非得这么做不可，但是有确定的迹象 显示这是目前的发展方向所趋，这时候增加里程碑可能增 加了进度落后的风险，但也可能增加产品推出后的机会。 我特别提出这个例子，是因为我的团队最近经常遇到类似 的困扰，虽然我们一直以准时推出产品为荣，但是环境的 变化使我们愈来愈觉得必须与众不同，必须有所突破，在 原定计划中加入一个新的里程碑，做一点特别的东西。每 一个项目都像是新生的孩子，每个项目都是独特的，你必 须顺应项目独有的特质，配合它定出最适当的里程碑，并 且充分支持它，用它的语言去表达它，而不是像切蛋糕般，切成你想要的样子。
  虽然你想做些改变，你未必有勇气实行。
  伟大的软件必定只有一个中心思想，至于品质能够实现到什么程度，依赖领导者能否带领团队融合无数个小而 重要的改变。如果你能在混乱中辨识出对项目最有意义的 改变，并且引导团队去适应它，将它融入团队的精神中， 将来就会在产品中表现出这项改变，呈现在顾客眼前。
  抗拒变化是失败的策略，你必须学习找出无法抗拒或 是对产品有利的改变，拥抱它、适应它，最后这项改变会 带给你丰富的收获。这是困难的心路历程，你需要刚铁般 的意志，因为你得依赖自己独有的远见，你所看见的没有 任何人能看见，你会很寂寞，每每在深夜被怀疑缠绕而不 得安眠。虽然你实在很想做些改变，你未必有足够的勇气 付诸行动，你等于是在挑战着人们的期望，而且你自己的 感觉也会因此而被左右，你不敢确信这些改变是好的。你 会面临艰难的抉择，在改变与不改变之间饱受折磨。
  然而，不论改变有多大的阻力，只要是必须的改变， 你就得排除万难接受它，否则你会被它摧毁。
  对我而言，即使只是把这些想法写下来，都令我感到 惊慌害怕，但这实在是我在软件开发的过程中，确确实实 的经验体会啊！
  第三篇推出时期于软件开发团队来说，没有什么比产品准备推出（Ship Mode ）更令人兴奋的了。大多数人认为产品 在经过这个阶段后，就可说是诞生了，但我还是倾向于将 此一时期细分为三个小阶段：激活、推移和完成（ onset, transition, endgame）。这三个小阶段没有明确的间隔，彼 此也有重叠的部分，但三者的工作重点却不相同，而每个 团队必定都会一一经历，才能将产品推出。每个人对这三 个小阶段的区分方式也可能不尽相同，但对于将整个产品 推出的催生阶段，每个人都会有类似的看法或感受。
  产品的推出：激活激活产品推出（ship mode: onset）是一段漫长而渐进 的过程，就好像婴儿出生前的阵痛。这时候团队开始为产 品的推出做一切繁杂的准备工作，就好像分娩前产妇要练 习呼吸，身体的机能也会为出生的那一刻作准备一般。在 产品推出的那一刻，团队必须全神贯注、倾全力使它顺利 出门，实在是个紧张而痛苦的时刻。
  假定我们有四或五个里程碑，大概到 M3时产品就应 该大致成形，M3的到达就是产品推出的第一次”模拟考“。 往后的第四个和第五个里程碑，应该更强调产品推出时的练习，不但是产品本身愈来愈接近推出时该有的模样，里程碑的到达也应该更像是产品的真正推出。 通常进入激活阶段的第一个征兆是，一部分认真思考的组员开始焦虑：”我们真的能做到吗？“这并不表示团 队害怕自己做不来，而是一些先知先觉者开始思考许多该 做的事、可能降临的困难，想到那么多那么杂的事情要做， 觉得千头万绪，简直不知如何是好，尤其是开始焦虑的人 还是少数时。逐渐地，恐惧甚至惊慌，像是野火般蔓延到 整个团队，也许领导者在公开场合也流露出这种内心的情 绪。在整个团队都染上这种紧张的情绪时，领导者反而可 以松一口气，因为现在每个人的心里都关心着同一件事， 产品的推出是每个人现在强烈的心愿，大家有一种携手同 心的感觉，我们正在共同为一个伟大的产品而努力的感觉，经过了那么辛苦的开发终于要有成果的感觉。
  有些组员会怀疑，领导者大概是乐观过了头。
  现在，领导者要做的事是为大家加油打气，为大家灌输自信和热忱，有些组员可能会觉得领导者大约是乐观过了头，但大部分的人都会受到鼓舞，理解在这时候焦虑是 正常的，是可以被接受的自然反应，而且是创造智能财产 过程中必经的压力。