微软团队成功秘诀

如 果有技术规划，开发人员会信赖未来，他有的是表现机会， 不必急于一时。另一方面，开发人员很清楚该在适当的时 间做适当的事，既不会负荷过重，工作品质也更能掌握。
  当每个人都很明白在这个产品中自己该做什么，事情就很容易被精确掌握。其中的关键就在这种“割爱”的艺术。
  一个技术规划的实例有一次我受邀担任一个软件开发团队的顾问(不是微软)，协助他们建立技术规划。他们的资深项目 经理出身该公司主要的技术部门，决定集中力量在 一个五年计划(即使两三年的时间对科技来说就已经 是全面改观了，我一般不建议定这么长的计划日 程)。当时，他们正在讨论各种新技术能为工作带来 的好处。
  在讨论中有一个主题很有意思，是他们年久失 修的关键程序。这个程序庞大而脆弱，有很多错虫， 跑得很慢，其中有一部分的程序代码甚至已经超过10 年。组员中没有一个喜欢它，很多地方根本不符合现 代的设计原则，他们甚至不愿去碰这个大麻烦。
  我想每个公司或多或少都有这类的程序：程序逻 辑纠结交错、缺乏弹性、冥顽不灵，简直令人头疼。 这种程序最后会变得无法维护，更别提加入新的功能了，结果是大大限制了开发团队创造优秀软件的潜力。
  我把这种情况称之为“软件开发的恶性循环”， 你不可能在推出下一个版本的同时，彻底翻修旧程序。 谁能承担得起重新经历一次软件开发的整个过程，只 为了将程序改写，而这段期间很可能降低或中断客户 服务，在程序还没有变得更有弹性而能搭配新功能之 前，客户可能得等上好几个版本的时间。
  比恶性循环更深一层的问题是：为什么会有这 种怪兽程序？是技术总监失职，没有好好监控软件的 品质？项目经理坐视程序败坏至此，竟不能防微杜 渐？在你没有弄清楚真正的病灶并矫正它以前，就算 重新修缮了现在的麻烦程序，同样的问题还是会一再 发生。不要在损坏的地基上重新修筑倒塌过的房子， 那是白费力气！
  在这一组开发人马中有一群新成员，新的资深 经理带着一群新的工程师，负责这段伤脑筋的程序代 码；当然，这也为这个团队和这个程序带来新的活力 和希望。他们打算重新架构这段程序，以便融入更好 的技术，提高产品的使用价值。
  这个小组经过一番研究之后，倾向外购一项全新的技术，作为未来开发的基石。当他们向决策当局提出这项建议时，反应是两极化的：赞同的人认为即 使外购也可能有兼容性的风险，但旧程序实在太难清 理不如放弃；反对的人则认为团队有能力重整旧程 序，只要管理当局给他们机会。
  项目经理也搞得不知如何是好。这位资深经理 在情感上倾向放手让属下好好努力，去清理他们数年 来不断奋斗的怪兽程序，但她又实在不放心这群属下 是否真的准备好迎接这项重量级挑战，尤其是想到他 们过去不怎么样的记录。她不认为这是原先管理者的 “错”，虽然是他们的疏忽以致程序腐化到这般田地。 一般而言，如果管理当局对技术是压榨而非培 养，优秀的人会离开，苟且的人会留下，最后组织和技术一起走下坡。 在本实例中，有不少的新人（包括那位项目经理）觉得这套旧技术实在活得太久，该被淘汰了。也 许大家所缺乏的只是管理当局的承诺，包括技术生涯 规划、创造力的突破和员工福利等等。这位项目经理 希望她的努力可以改变这种状况。
  最后，她决定做一次技术规划，然后冒着被开除的危险充分授权给开发团队，果然不只使得怪兽程序浴火重生，而且只花了一次改版的周期时间，也扫 清了许多地雷暗礁。成功的背后，她也失去了几位主 张使用外购新技术的人员。
  下一次她修订技术规划的时候，她不只是让开 发小组参与，还设法训练主管们也能参加并了解这个 决策，让负责准时完工的技术人员梦想和希望有机会 呈现在技术规划之中。她也鼓励其他的主管们参加这 些讨论，这样做事的时候会比较容易沟通，也更不会 错失任何好主意。
  有很多方法可以制定技术规划，但最重要的原则只有 一个。优良的技术规划有很多好处，也许“割爱”是最重 要的。技术规划会让您知道将会走到哪里，更容易掌握该 做什么，采取什么方法，如何就会更接近目标。而且，惟有完善的多版本技术规划，才能帮助您准确详估工作量。
  修订技术规划另一个我所观察到的技术规划实例也是加强共识的最佳典范。由开发小组和项目经理中派人组成的 技术观察员，花了一两个月的时间起草大致的技术计划（请参考法则5：刺探敌情）；然后这份草案被全组人分别传阅、加注意见、讨论激辩，最后被交给负 责执行的开发人员（大约80位）。
  同一时间，这份草案也在高阶主管之间传阅， 他们会参照许多其他的技术规划后，定出多版本的产 品计划。他们通常不会修改技术规划，因为他们知道 这是所有组员的心血结晶，也是得来不易的团队共识。 然而，他们发现了一个问题：这份规划看起来像是一 大串互不相干的产品特色（ feature），这样蔓杂的目 标怎么能激励开发人员呢？怎么可能向全世界描述他 们有这么样的产品─有几十个不显眼特色的产品？
  然后经理们归纳出来，这些产品特色分属于五 大类型：策略、竞争、顾客满足、投资，以及他们称 作“典范性”（paradigmatic）的功能诉求。典范性的 功能是指有计划地放在 n个连续版本中的产品特色， 最终目的是改变使用者的工作方式。这套分类当然不 是说典范性的功能不属于竞争或策略，或是策略性产 品特色与顾客满足感无关，这么划分只是为了比较精 确地描述。
  “策略性”产品特色与最基本的环境和限制有关。
  譬如说是本产品支持什么操作系统？采用何种对象模式（object model)？产品需要什么等级的中央处理器（CPU)？支持哪种程序语言？此外，策略性产品特色 也涵盖了公司发展其他产品线的全面性策略。例如公 司卖的打印机，就必须写驱动程序去支持。“竞争性” 产品特色基本上是为了对抗竞争者而设计的，特别是 竞争者有而我们没有的功能。虽然不必每一项竞争者 的功能都要放进来，但倘若其中有特别巧妙或特别吸 引媒体注意的功能，就值得投资。这一类的产品特色 是数目最少的。
  “顾客满足性”产品特色基本上是大家已经耳熟 能详，且顾客大都需要的。多去听听顾客的声音，产 品特色就会更能搔到痒处。这部分的产品特色数目最 多，但开发成本相对较低。
  “投资性”产品特色是技术方面的前瞻性投资， 其效益可能在未来的一或数个版本中都未必能明显看 出。毋庸置疑，投资性产品特色是未来大放异彩的潜 力，它能带来未来版本中的典范性产品特色。这个项 目的重点是使开发人员善用每一分钱的投资。
  “典范性”产品特色可以改变使用者的工作方式。
  基本上这是整体开发人员梦寐以求的目标，在每一次改版中放进刻意设计的巧妙功能，逐渐引导使用者。 通常这是行销部门持续性对外宣传的产品特色，它甚 至能改变整个游戏的竞争规则。我们可以说：如果典 范性产品特色成功的话，没有人能跟你竞争─除非 他也有这项特色。
  在本例中，项目经理将技术规划中所有的特色加 以整理，分别归入这五大类，并决定在这五大类中分别 要投入多少的资源、占整体投资的比重，并且做出相对 应的技术需求分析，当然要符合内部资源和技术的分配。 这一部分我就留给读者当成家庭作业，您自己思考一下， 以您的条件、产业竞争型态等因素来看，五大类产品特 色中，其所占资源比例应该如何分配呢？
  然后，整个开发团队在接下来连续大约五天的 时间，每天开会约两个小时，逐步讨论出下一版产品 的技术规划的细节，整个计划就此拍板定案。这五天 是大伙儿发表意见的最后机会（当然啦，事实上计划 永远是可以变更的，这样做是为了强化计划的效力）。 因为计划的制定是由下而上，不会有任何人跌破眼 镜；因为管理阶层负责综合各方意见而形成完整的、有系统的产品特色，组织目标会被大家接受；整个过程开放而民主，每位成员都获得充分的授权，最后的 争议也会最小，很能共识凝聚，热忱也会很强烈。没 错，整个团队会深刻感受到共同的目标。
  这是我所见过最理想的规划过程。我写本书的时 候，他们的产品已经上市了，真的是很棒的产品呢！ 每个人对技术都应该有一份使命感，都有追求 进步的内在欲望，然而新点子可能因为缺乏适当的分 析或时机不成熟而被排除于计划之外。团队成员必须 明白真正的工作内涵，并且能够理解有时候新点子虽 好，但总得经过慎密的分析并证明实际可行又有足够 的效益才行，而好的想法若能被团队审核过关、形成 共识，最终还是会实现的。如此可以减少未经深思熟虑的提案，对整个产品的稳定性颇有助益。