第13节

受它，改变的目的是让团队的工作最佳化，而不是导入 更多的复杂性。我们这样举例说吧，也许有一天，你想增加一个里程 碑，没有明显的理由非得这么做不可，但是有确定的迹象 显示这是目前的发展方向所趋，这时候增加里程碑可能增 加了进度落后的风险，但也可能增加产品推出后的机会。 我特别提出这个例子，是因为我的团队最近经常遇到类似 的困扰，虽然我们一直以准时推出产品为荣，但是环境的 变化使我们愈来愈觉得必须与众不同，必须有所突破，在 原定计划中加入一个新的里程碑，做一点特别的东西。每 一个项目都像是新生的孩子，每个项目都是独特的，你必 须顺应项目独有的特质，配合它定出最适当的里程碑，并 且充分支持它，用它的语言去表达它，而不是像切蛋糕般， 切成你想要的样子。

虽然你想做些改变，你未必有勇气实行。

伟大的软件必定只有一个中心思想，至于品质能够实 现到什么程度，依赖领导者能否带领团队融合无数个小而 重要的改变。如果你能在混乱中辨识出对项目最有意义的 改变，并且引导团队去适应它，将它融入团队的精神中， 将来就会在产品中表现出这项改变，呈现在顾客眼前。抗拒变化是失败的策略，你必须学习找出无法抗拒或 是对产品有利的改变，拥抱它、适应它，最后这项改变会 带给你丰富的收获。这是困难的心路历程，你需要刚铁般 的意志，因为你得依赖自己独有的远见，你所看见的没有 任何人能看见，你会很寂寞，每每在深夜被怀疑缠绕而不 得安眠。虽然你实在很想做些改变，你未必有足够的勇气 付诸行动，你等于是在挑战着人们的期望，而且你自己的 感觉也会因此而被左右，你不敢确信这些改变是好的。你 会面临艰难的抉择，在改变与不改变之间饱受折磨。然而，不论改变有多大的阻力，只要是必须的改变， 你就得排除万难接受它，否则你会被它摧毁。对我而言，即使只是把这些想法写下来，都令我感到 惊慌害怕，但这实在是我在软件开发的过程中，确确实实 的经验体会啊！

Part 第三篇 推出时期

Three

推出时期

315对于软件开发团队来说，没有什么比产品准备推出（Ship Mode）更令人兴奋的了。大多数人认为产品 在经过这个阶段后，就可说是诞生了，但我还是倾向于将 此一时期细分为三个小阶段：激活、推移和完成（ o n s e t , transition, endgame）。这三个小阶段没有明确的间隔，彼 此也有重叠的部分，但三者的工作重点却不相同，而每个 团队必定都会一一经历，才能将产品推出。每个人对这三 个小阶段的区分方式也可能不尽相同，但对于将整个产品 推出的催生阶段，每个人都会有类似的看法或感受。

产品的推出：激活激活产品推出（ship mode: onset）是一段漫长而渐进 的过程，就好像婴儿出生前的阵痛。这时候团队开始为产 品的推出做一切繁杂的准备工作，就好像分娩前产妇要练 习呼吸，身体的机能也会为出生的那一刻作准备一般。在 产品推出的那一刻，团队必须全神贯注、倾全力使它顺利 出门，实在是个紧张而痛苦的时刻。假定我们有四或五个里程碑，大概到 M 3时产品就应 该大致成形，M3的到达就是产品推出的第一次“模拟考”。 往后的第四个和第五个里程碑，应该更强调产品推出时的

练习，不但是产品本身愈来愈接近推出时该有的模样，里 程碑的到达也应该更像是产品的真正推出。通常进入激活阶段的第一个征兆是，一部分认真思考 的组员开始焦虑：“我们真的能做到吗？”这并不表示团 队害怕自己做不来，而是一些先知先觉者开始思考许多该 做的事、可能降临的困难，想到那么多那么杂的事情要做， 觉得千头万绪，简直不知如何是好，尤其是开始焦虑的人 还是少数时。逐渐地，恐惧甚至惊慌，像是野火般蔓延到 整个团队，也许领导者在公开场合也流露出这种内心的情 绪。在整个团队都染上这种紧张的情绪时，领导者反而可 以松一口气，因为现在每个人的心里都关心着同一件事， 产品的推出是每个人现在强烈的心愿，大家有一种携手同 心的感觉，我们正在共同为一个伟大的产品而努力的感觉， 经过了那么辛苦的开发终于要有成果的感觉。

有些组员会怀疑，领导者大概是乐观过了头。

现在，领导者要做的事是为大家加油打气，为大家灌推出时期

317输自信和热忱，有些组员可能会觉得领导者大约是乐观过 了头，但大部分的人都会受到鼓舞，理解在这时候焦虑是 正常的，是可以被接受的自然反应，而且是创造智能财产 过程中必经的压力。在激活阶段的团队工作效率会达到巅峰状态，因为大 势已定，不需要再揣摩或协商。这时候的团队心理有以下 几项特点： 大势已定 产品的功能特色、团队中每个人的角色 几乎是完全定型了。所有犹豫不决的特色不能早点 定案到现在都得删除，组员之间的工作负荷很平均， 产品架构完全确定而且趋向成熟，测试计划正在进 行，文件撰写原本只有纲要，现在要加入细节。此 时一切都没啥好争论的，没有任何疑惑，每个人都 知道产品就要诞生，剩下来该做的事也很清楚，去 做就是了。艰辛的开发工作终会过去，此时，赶紧 把它完工是最重要的。 共同一致的信念 每个人都有一致的信念，我们即 将完成产品，时间一到产品就能推出。现在所有的 痛苦抉择或权衡都已经过去，大家只要专注于眼前 产品的状态就好。产品的催生时期就代表着所有的

争议结束。如果现在还有怀疑或争论（到现在还没 解决的话），也只有暂时搁置，到下一版时再说， 否则永远没完没了。此时若是还有人对项目有严重 的怀疑，产品是永远无法进入催生时期的。 每个人都明白 每个人都明白自己该做什么事，也 明白整个团队该做什么事，才能使产品顺利推出。 现在已经没有什么事是不确定的了。所以，只要继 续把手上的工作做出来即可。延误或是对延误的恐 惧，只单纯地和自己的工作有关，不再和别人的工 作有太多的依存。在组员心里曾有的焦虑、飘浮无 依的不安，现在都可以放掉。我常把这个阶段称作“工作清单”阶段，每个小组都把自己的一大串的 工作逐条列在清单上，现在要把清单上的工作逐项 完成，打个勾勾，清单上每一项工作都做完时，产 品就完全推出了。 开发团队的最高领导人必须身先士卒，率先进入产品推出时该有的心理状态，并且信守一切的承诺，才可能带 动所有组员进入这个紧张的时期。对于细节的认知会愈来 愈清楚，在工作步调上也许会有点凌乱的危机，但这时候 领导人最重要的工作就是带领大家专注于产品的推出，凡推出时期

319是不太相干的事情尽量排除；在团队中的每一个成员都渴 望推出，看到自己辛勤耕耘的结晶是多么欣慰，领导人必 须将大家对于推出的渴望，转化成完美的推出工作。

产品的推出：推移推移阶段（ship mode: transition），在时间上可以跨过 一个以上的里程碑，视产品性质的需要与产品的推出而定。 基本上，产品推出的推移阶段是产品从开发迈向完成的逐 渐稳定阶段。开发工作仍在进行，直到最后一个里程碑为 止；如果开发工作的重心是增加功能，势必很难同时追求 产品的稳定，自然严重影响产品的推出；由于同时追求增 长和稳定实在太耗费心力，这时候主要的开发活动是除虫， 凡是无法完成的功能特色都暂时放弃。要放弃任何的功能 特色，都难免引起组员的不安情绪，所以，下决定之前必 须审慎地分析评估。如果我们把产品推出当成一条数学上的连续曲线，你 会发现当产品愈来愈成熟，所需的开发人力愈来愈少，产 品推出就进入了完成阶段（我们稍后再详细讨论）。现在， 产品推出的推移阶段即将结束，而将进入早期的完成阶段 时，会有下列的迹象：

组员的思考更加保守而小心谨慎，避免掉入开发的 泥淖。 程序置入的动作审慎再审慎，通常会成立一个临时 的特勤小组，检查每一个程序置入的动作，务求事 先防范大幅的不利影响。 增进执行速度和改善使用者接口成为工作的重点， 把产品磨亮打光，以期带给外界深刻的印象。收尾 成为最重要的方向。 修饰的工作完成后，接下来加强产品的稳定度，以 达到推出的要求水准，所有的开发工作已经结束， 清除错虫的工作也已接近尾声。

产品的推出：完成在产品推出（激活、推移和完成）的三个阶段中，工 作重心发生移转，从准备进入催生时期的心理变化，产品 逐渐稳定下来，直到产品推出的完成阶段（ ship mode: e n d g a m e）时，只剩下一个里程碑了，就是“推出”（s h i p p i n g）。在概念上，这个阶段的工作相当单纯，就是 一张工作清单，当上面所列的项目逐一完成，产品就推出 了。工作清单上有几百项，甚至几千项，也不过只是一张推出时期

321清单罢了，很多但不会太困难，你没有时间想或做这张清 单以外的事情，每个人只有心思专注在自己该做的事情上。 也许会发生一些状况，使得工作清单上必须增加一些项目， 团队会在一阵“适度抗拒”（appropriate resistance）之后 接受工作项目的增加；这种适度的抗拒，我把它称之为“谦逊的抗拒”（profound resistance）。 这时候每天召开例行的检讨会是个很不错的方式，如果能常常邀集决策者参与更好。会中的议程不拘泥于惯例 或任何形式，但必须是能立即决断的问题，凡是长期性的 目标或一时无法解决的问题，都暂时撇开不谈，下次改版 时再说。管理者参加这个会议的作用之一就是将议题引导 在这个方向上。现在，团队的主要目的是在推出日期时， 产品的品质水准要够好。已经进入倒计时阶段，开发人员 主要的工作是错虫的更正，而且是重要的错虫──这会影 响很多的使用者，或是造成严重具毁灭性的错虫，都必须 优先清除。至于使用者界面的美化、执行速度加快、或是 新的功能，都不宜在完成阶段讨论。B e t a测试版的测试结 果，以及外界的反馈，都以“追求产品的稳定性与避免严 重错误”为大前提，作小幅度的修改。而其他的建议案， 都只是预警相关人员在销售上可能遇到的困难或不利影

响，或是下一版的改进时的建议，但基本上，目前不打算 在产品上响应这些项目。

有多少无伤大雅的错虫，存在于你推出去的产品中？

你必须了解，顾客对于软件品质的要求程度，或是说 对错虫的忍受程度。在你推出的产品中，有多少错虫因为 优先顺位较低，而未及修正就随着产品出门？这些较次要 的错虫会不会造成问题？使用者会不会因此而在操作上遇 到麻烦？由于在产品的推出阶段，稳定是第一优先考量， 所以在决定是否要更正一个错误以前，必须先考虑会不会 因此而造成更大更多的错误；有些错误的修正太冒险，错 误本身的危害并不大，把它列在产品的读我（readme.doc） 档中说明，会比较好。有时候，就像有些人的阵痛期特别长一样，产品的推 出工作如果不太顺利，也可能使上市的日期受到延误，以 下有几个法则提供软件开发团队的领导人参考，以期能避 免在产品推出时发生延误的情形。

法则 48

Violate at least one sacred cow关怀多于要求

身为团队的领导人，你可能巴不得所有的属下都拼命 工作。但事实上，虽然在产品推出阶段所面临的挑战可能 真的需要大家拼命工作，你却不可能“命令”大家为工作 牺牲奉献自己的一切。我曾经见过一些没有人性也不懂人 性的管理者，要求他的组员晚上加班、周末来上班，结果 组员要不是他的命令理都不理，就是在背后嘲弄这位可恨 的管理者。事实上在产品推出的阶段，管理者的作用并未消失， 有些仪式性的动作，虽然很小或很简单，却是意义非凡。 此时领导人应该用实际的行动来表达他对组员的关怀，肯 定他们对组织的贡献，让每一位组员都感受到自己的每一 个角色都是那么的重要，领导者的关怀，可以增强组员的 向心力，对产品的顺利推出有莫大的影响。领导者对组员的沟通应该是具有鼓励性，不是强迫加 班，而是提供方便的加班环境。例如，写一张小卡片给某 位组员（不能用虚假的客套话、公式话，要真诚的关心）、 走廊上餐厅里不期而遇时的几句赞美、提供加班时的托婴 托儿服务、自掏腰包来个点心宵夜，或是让组员可以很方 便地在家工作（简单的远距办公室通信设备）；这些小动 作花费极少，却让组员体会你的关心与诚意，而感到自己法则48建关怀多于要求