微软团队成功秘诀

倘若没有 人决定好最适合的路线，你的开发过程就会像在沙漠中迷 失了方向，版本与版本之间毫无组织和明确的方向，注定 了悲惨的命运。虽然有好的侦察员不能保证情报够充分，至少“侦察员”会让你不致盲目乱走。
  侦察员的重要性最近我与一家大公司的 MIS部门有接触的机会。
  他们在过去三年内成功地将原本在大型主机上的终端 机全部（有上千部之多）换成 PC及Windows的作业 系统与网络环境。可想而知这是非常艰巨的任务，需 要大量的人力与金钱，和一段很长时间，整个公司在 这个转换的过程中，受尽各种煎熬。
  完成了Windows 和 PC的转换之后，MIS部门开 始发展一套分布式的应用软件，以期充分发挥新科技的效用，这是他们第一个重大的投资回收项目，预计降低的成本和增加的利润可达每年数百万美元。 这个工作团队大约由100个人所组成，主要是软件工程师与品保工程师，大部分都是公司的新人，或 对技术还不是很熟悉，再加上对公司而言也是第一次 开发这种关键性任务（ mission-critical）软件，可想 而知他们一定得克服无数的困难。在我与他们接触之 初，这个项目的进度已经严重落后，并且大大超出预 算，更糟的是眼看期限就要到了。
  这项 PC 软件的项目自开始至今已经有三年了， 当初他们开发软件时规划的硬件、网络协议等环境早 就已经过时，目前所使用的软件开发工具和操作系统 竟然落后了两个版本！这三年来，硬件价格大幅滑落， PC效能大幅提升，所要求的硬件运算能力也提高了 几倍，他们使用的 PC已经在市场上绝迹，但运行在 上面的应用软件却无法淘汰。
  我实在无法帮助他们解决这个难题，只能说这个 实例证明了“侦察员”的重要性。当年他们几乎是凭 着直觉和谨慎保守的作风来决定软硬件环境和工具策 略：“我们尽量不要改变任何东西，反正它能用就好。”
  倘若他们曾经好好调查一下计算机的发展趋势，倘若他们曾经考虑过兼容性的问题，他们就会知道必须使 用最新的工具和最新版的操作系统，并且尽可能将未 来的发展也估算在内，多花一点钱也是值得的，也不 会因为当年决策错误而造成今日难以挽回的局面。
  不过还好，这支勇敢的 MIS 团队毕竟最后还是 圆满达成了任务，成功地完成了新的软件。这次他们 学乖了，事先派了两位最优秀的组员担任“侦察员”， 做了一次彻底的技术调查和完善的规划，终于在危机 爆发之前将之化解。
  老实说，对于类似上例的公司，我只能感到同情。计 算机科技进步太快太剧烈，冲击着组织不够健全的公司， 旧的系统难以割舍，新的技术又逼着你不得不进步。是的， 使用第0版的软件也许会让你惶恐，但从第 7 版升级到第版可能意味着重大的进步。如果你做决策之前，好好做 过“侦察员”和完善的规划，而且知道这些对系统的重要 性，你就会乐于接受科技带来的改变。
  本书强调的基本观念是，我们并不企图减缓科技进步 的速度，也不是要建立僵化的系统，而是要在改变中获得 益处，将不断变化的科技管理得宜。行动总比停滞好，行动力高的组织会有较高的适应环境能力。“侦察员”就是为科技的改变而准备的，如果你决定永远停着不动，那你 不需要“侦察员”。
  当然“侦察员”也可能带来问题。如果他对多版本计 划没有非常清楚的认识，他可能不知道要侦察什么；他们 也可能不懂这项任务的重要性而随便做做。“侦察员”必 须要非常了解自己肩上所担负的责任：一旦选错了一个操 作系统或开发工具，可能会害死整个组织。
  另一方面，“侦察员”本身也可能因为这项任务的重 要性而过度膨胀自我，看不起其他的人，自以为是“定 义未来的人”。团队中的其余成员会因此而觉得沮丧，对 未来的方向完全没办法掌握，觉得自己不受重视；甚至 以为事情已经多得做不完，管理者竟然把人调出去研究 无关的技术：“我每周工作  70 小时，而那个家伙悠闲地 在看书!”这种抱怨在派最顶尖的人去当“侦察员”时尤 其会发生。
  团队成员对“侦察员”的工作不免嫉妒。当“侦察员” 比当开发者好─比较光鲜亮眼、比较先进、比较酷。当 几个月的“侦察员”似乎真是不错，你可以观摩别人的公 司、跟厂商谈谈、玩玩软件原型、趁机多充实自己的技术能力、有权力影响未来的方向。但是“侦察员”不参与软件开发，只负责做初步的规划、培养团队对于目标的共识。 如果“侦察员”能够让团队信任，并凝聚出真正的共识， 开发人员就比较能够自在工作，相信这些担任“侦察员” 的优秀同事是在为大家的未来披荆斩棘地开路。
  对开发团队来说，“侦察员”能够运用得愈成功，代 表他们愈相信项目经理的领导，团队的共识愈强；不论 是否处于技术转换的过程，对团体和个人都是一种很好 的现象。
  下载法则注意人员的组成比例项目经理经常犯的错误之一，是以为只要雇用软件工程师就好，其他的人都不必要，或是让软件工程师占整个 团队很高的比例。也许是认为开发人员愈多，写出来的程 序就愈多，这是错误的观念，项目的目的是完成软件，不 是完成很多程序代码。在开发团队中，事实上有一些工作 是不适宜交给软件工程师的。
  在我的小组中，比例通常是 6位开发人员， 2～3位品 保人员，一位项目经理，以及两位技术文件撰写人。在微 软的各个部门中，这个比例会稍有不同，也许和您的人员 比例也不同；但基本原则是开发人员和品保人员的比例不 超过2:1。其实真正负责软件如期完成的是品保人员。当 进度落后时，我们第一个要看的是品保人员：人数够不 够？有没有充分授权？有没有确实参与设计？进度上能不 能跟开发人员配合良好？能不能一有问题出现就立刻提出 警告？品保人员和开发人员的理念一致吗？是不是跟开发 人员过度亲密而放水？
  对于人员的组成比例应该着重于有效的人数比，而不 是实际人数比。一个健全的软件开发团队一定要符合上述 的人数比例原则，平均每一位品保人员所支援的开发人员 不超过两位：前者是思考并监督软件的状况是否达到预期水准，后者专心写程序和抓错虫。注意人员的组成比例，可以帮助（但不保证）团队的运作取得平衡，记住，平衡 才是你真正的目的。
  下载法则运用特色监督小组在微软的C++开发小组中，我们就用过特色监督小组（feature team）的横向组织。我觉得这是非常好的做法， 对整个团队的工作品质产生了绝佳的影响。
  如果你问一个品保人员他的工作是什么，他会回答： “监督软件开发的进度，确保如期完成，并且确保品质达 到预定的目标。”他绝不会说：“测试程序。”那是肤浅的 答案。品保人员的工作是如期完成软件，是开发“产品”， 是去了解顾客，而且还知道技术规划中每一件大大小小的 事情进行得如何；可以说，品保人员必须要管我们的产品、 我们的市场和我们的整个事业。
  我们的团队组织像一个二维矩阵，传统的组织模式为 经，特色监督小组为纬。以经理、品保、开发、文件四种 角色，虽然是一个传统的阶层式组织，但还算相当扁平化 的；除此之外，这四种角色必须各派代表参加特色监督小 组，每一项产品特色都有专属的特色监督小组，以确保每 项特色都能照日程做出来，这个小组必要时可自行开会。
  特色(feature)一词，也有人为了听起来较大众化而译为功能，这是因为中文里的功能一词，意义非常广的 缘故。事实上特色是指完成某项功能的独特方法，特 别是与竞争者不同的地方，它适用的范围很广，您可以说，采用Control-C.Control-X.Control-V来操作“剪贴簿”是微软产品一贯的特色，您也可以说，某软件 具有随插即用的特色。―译者注）特色监督小组运作模式有几个重要因素：分别是充分 授权、赋予责任、融入任务、建立共识和地位平等。特色 监督小组是我所经历过最神效的组织方法，我将它的五项 重要因素讨论如下：
  充分授权（Empowerment） 像特色监督小组这样的编制似乎比较非正式，无法像阶层式的组织那样容易管理， 但它需要被充分授权才能发挥作用。譬如像开发人员，他 们是“专才”，几乎专职负责某一特定的技术领域，若是 让他们完全主导一项产品的设计显然太不智，如果加进一 些别的角色，形成“通才”的局面，就平衡多了。单靠经 理人的决定，恐怕不够全面，我看过太多好的（或坏的） 决策，一下子就被另一位经理完全推翻，我倒是没见过特 色监督小组把事情搞砸过。也就是说，只要特色监督小组 能被充分授权，并且发挥它的作用，就可以确保决策的品 质。（当然特色监督小组的必须挑选适合的人参加，本书 附录中将说明这一点。