微软团队成功秘诀

因此，软件 设计应该是把顾客想要的东西全部纳入，而顾客不要的东 西统统排除，由于软件中所有的东西都是需要的，顾客对 于软件的使用不会被干扰，而去注意不必要的东西。所以， 追求软件的统一性，是软件设计的首要目标。也许你在别 的领域（也许是创造一件艺术作品）的工作中，也曾经由 于直觉或别的理论而运用统一性，而我认为帕克的六项原 则对于软件的设计非常有用。
  软件的主题（theme）会主宰设计的基础观点，也是软件价值的主要根源。因此，你必须在团队中明确地传播 这个主题，让开发人员和行销人员对主题有非常透彻的了 解才行。软件的主题事实上是目标的同义词。目标愈明确， 造成的的冲击就愈大，因为你可以将模糊降到最低，而目 标在每个人心目中造成的感受与解读会更一致，整个设计 过程就愈平顺。但是主题决定之后，你还得注意与主题无 关的部分都要删除掉，即使开发人员认为这一部分很重要，或者这是你一贯的信念，都还是得忍痛牺牲。
  产品的销售信息会由主题衍生。精明的观察家只要看 到主题就能抓住信息。信息只是补充说明主题的意义，如 果主题模糊或是不只一个，再好的销售信息也没用（大家 都明白这个浅显的道理：产品若没有鲜明而惟一的形象， 广告再多也没用）。产品的主题根源于你的对市场的观念， 以我Visual C++的例子来说，我们对市场的观念是：大家 都觉得C++太难学，于是我们设计的主题是：让使用者容 易学习 C++，我们的信息自然就是： Visual C++把C++变 容易了。
  重点是产品的功能特色不能像是一袋子随便抓过来的 东西，应该把与主题无关的东西都删掉，而且你的目标也 必须符合统一性（ unity of purpose）才行，这一点是与主 题互为一体的两面。将资金投注在这个目标上，让所有的 人都完全明白这个目标，并且为这个目标努力，做得到这些的话，你的产品就会完全包含这个目标。
  专心致力于主题我不知道以下的故事是真是假，但我很喜欢它，而且经常说给我的组员听。
  有一家电子表格公司做了一项研究，结果发现到使用者大约每打20个数字就会想用这些数字画张图 表。这项研究发现，大多数的人在用电子表格时都有 这样的行为模式。
  所以他们研究再研究，开发再开发，全心全意 地努力让产品有这样的功能：可以利用很少量的数字， 很容易地产生图表。那些用电子表格绘图的使用者看 到这项功能特色都非常高兴，认为只要有这个功能就 值得买下这套软件。
  另一个类似的故事（我也不知道是真是假）是 一个做家庭财务软件包的团队。他们研究过市场之后 发现：这项产品一定要让顾客立即得到好处，否则就 卖不出去，而且消费者不会再买升级版。他们决定要 让任何一位完全陌生的使用者，都能够在打开包装后 十分钟之内得到结果，从安装、操作、输入、输出， 一定要又简单又快。
  所以他们派人到软件商店去，征得顾客的同意， 跟着他们回家观察他们的使用状况，巨细靡遗地记录 下来：包括他们拆开包装之后会先看什么东西，在安 装和执行软件的过程中会遇到什么困难等等之类的，以提供产品改进的依据。分析研究之后，他们找到了数十种加强顾客满意度的机会，然后他们在往后的几 个版本中逐步实现这个目标─十分钟内的满意。产 品终于成功了！
  变奏（variation）是将主题稍加变化润饰后，重新表 现一遍。在主题表现过之后，为了持续吸引使用者的注意 力和兴趣，变奏是以另外一种方式来铨释主题，加强使用者对主题的理解和欣赏，使他对主题留下深刻的印象。
  演进（evolution）的意思是用前一部分来决定后一部 分，就像是学习的过程应该是先入门后进阶一般，由浅入 深的变化会让人更容易接受，更喜欢学习。如果软件作品 的前后能够如此呼应，通常会有满意的结果。
  平衡（balance）是对软件中各项组件都不偏废或过 度强调。例如，正好相反的两个对象，应该给予相同份量 的说明。
  层级（hierarchy）是指软件作品中的各个元素，依照它们的重要性与大小给予合理程度的比重。层级与平衡 的概念很接近，层级可以说是建立与衡量平衡的方法。如 果主题是在层级的最顶端，则以下各层级的同层组件都应 该彼此平衡，同层级的组件对主题的支持力也应该相等，愈近顶端的层级对主题的支持力量愈大，以此类推。
  美的特质年，盖?瑟西罗（ Guy Sircello）在他的著作《美学新主张》（A New Theory of Beauty）中，提 出了一个有关于美感认知的学说，相当有趣。我们不 谈他对物体特性的质与量的详细划分，他提到一些有 关美学感受的理论，非常深得我心。瑟西罗认为我们 之所以感受到美，是因为这个物体有一种以上的特质 很美；瑟西罗进一步解释说，惟有一项特质在作品中 被特别强调，才会是有美感的特质，而一个物体惟有 包含一项以上的美感特质，才会被人们感受到它的美。 足够的美感特质不一定保证让整个物体显得美，但是 一个没有美感特质的物体绝对美不起来。
  瑟西罗的学说或多或少解释了为什么有一些软 件叫好不叫座，这些失败的软件什么都有，想要大小 通吃，有一大串的功能特色就是没有主题，结果没有 一项特色能够使产品鹤立鸡群，就无法吸引顾客的注 意，当然注定要失败。
  法则不要倚赖不确定的事尽 量 减 少 团 队 需 要 而 又 无 法 控 制 的 事 情（dependency）。项目开始的时候，决定允许倚赖的事情愈 少，最后就会愈顺利。一般来说，程序设计的效率是不会 太高的（也许是由于不熟练或是错虫太难抓），即使你努 力加班在时限内完成了自己份内的事，别人也可能无法做 到这样。
  因此，在设计时就得考虑这种必要而又不确定的事， 要知道这种依存性有可能会吃掉大量的成本，只有在很重 要或是非不得已的地方才允许这种倚赖，让成员们明白其 严重的后果，尽量配合协助，并事先评估倚赖之事失去控 制的可能性，以及会有什么影响。
  法则平息顾客的愠怒在项目进展的过程中，总有一些依存性或外在的不确定性因素可能会拖垮你。你必须在其中找出最有可能 绊住你的因素，事先研究好万一发生问题时你该采取什 么步骤。
  先检视一下产品的功能特色，其中有没有不明确的、 或是对顾客满意度没有太大意义的部分，在时间来不及时 可以牺牲掉这些。不错，可能会有顾客不满意你没有做这 项特色，但是只要你能如期推出新版，那顾客就不会放弃 你，并期待在下一版中见到他要的特色。
  平息顾客的愠怒法则软件的可移植性对于大部分的软件厂商而言，做到跨平台（）的支持是相当困难的。即使不考虑每增加一种 支持平台所增加的开发成本，在品保方面所增加的工作负 担也是呈指数增长，再优秀的品保管理也无法真正解决这 个问题。最好的办法是要求系统软件厂商提供工具支持， 然后慎重小心地决定你要支持的平台，数目愈少愈好。
  但千万别选错了，那会是你的致命伤。
  法则在设计时将时间因素 考虑在内在设计时就将时间因素考虑在内，千万不要先设计好再决定要花多少时间才能做出来。时间是你最大的限 制条件。
  产品设计的目标一定要完成才能推出，你不能把做到 一半的软件给顾客使用。开发人员和管理者在做产品设计 时很容易忘记考虑时间因素。正确的做法恰好相反，你应 该在设计阶段就把时间当成关键因素，当你在考虑替代方 案时，时间短的加分，时间长的减分。通常只要把时间因 素纳入设计时的考量重点，你就能够缩减开发的时间。
  如果你的设计并不一定要产品如期完成？别傻了，还 是如期完成最重要，比什么伟大的理想（可惜实现不了） 重要太多了。
  开 发 开发 开发这里所谈的开发，包括的以下的实际行动：执行计划、进度安排、程序撰写以及品质验证，而不是讨论什么人做 什么工作，在团队中每一个人都必须参与开发的活动，因 此，每一位都是开发者。
  人们使用软件开发（software development）来表示软 件产生的过程。这一点很有意思，这表示软件的形成是一 种渐渐成熟的过程，经过一组有顺序而相互影响的步骤演 变而成。究竟是什么因素推动软件趋向成熟呢？是团队的 创意凝聚。从众多个人的智能产物，逐渐组成一套结构紧 密而完整的智能财产，那就是将要推出的软件产品。这又 使我想起了本书一再强调的主题：软件开发的基本活动就是将一群个人的智能结合成一项智能财产。
  软件开发的终点事实上是开发人员脑力的极限。
  脑力的密切结合但软件开发的过程牵涉到很多层面。