微软团队成功秘诀

  任何项目都有可能碰到进度落后和觉醒，但有些觉醒 不一定是跟随进度落后而来，这很有可能，但有点危险， 并且不是好事。以下是你对进度落后应有的正确观念：
  进度落后与道德无关，请切记！这并不是失败或做 错事，应该受到责罚，这是创造智能财产过程中无 法避免的。千万不要有道德上的罪恶感或良心上的 负担，并且要求你的团队也要这么想。因为组员们 最怕被威权形象责备，他们会因此而陷入一种很微 妙的精神压力中，在讨论时拖拖拉拉不着边际，在 恐惧犯错和渴望荣耀之间挣扎，在责难和赞誉之间 游移，结果会尽全力摆脱这种压力，会胡思乱想， 因此而消耗所有的心力。所以，千万不要让任何人 对进度落后有道德上的联想，认为这是不应该或不 对的事情。
  不要隐瞒事实。人在遭遇冲突或危险时，一定但愿 没这回事，而有逃避的倾向。在进度落后时，你和组员们都难免会不想谈它，但这时候特别要克服这种天性，发挥你卓越的领导力，把事情变得不一样。 不要瑟缩在你的办公室中。喃喃自语：”我不敢去 看，进度迟延了，??不，我不相信有这种事??“ 勇敢地走出去面对问题，你要打败问题，而不是逃 避问题。
  化阻力为助力，利用进度落后来激发效率。对于进 度落后的认知是一种醒悟，组员们开始有重新振作 的精神，有最新的信息，有最新的看法，创意和想 象力也可能有新的境界，领导者必须得把这些新兴 的朝气导向最有效用的地方，不要管传统规矩的包 袱，进度落后是考验团队弹性的最佳时机。
  进度落后不是问题，被进度落后吓倒才是问题。进度 落后并不代表产品的难度太高而无法开发。但是如果进度 已经落后却未被察觉，那表示组员们不思考、不观察、不 讨论，此时组织可说是濒临瓦解了。
  善用你的迟延，这是最能看出你领导能力的时候，此 时也是组员最脆弱也最需要你的时候，在这个时候组员最 能把你的话听进去，此时组员的学习能力最强。如果你在 办公室内激动得大喊大叫，指天骂地，那就错失了赢得组员的心的大好机会。你必须说：”OK，进度落后了，让我们来看看问题出在那里？??今天下午五点在会议室，我 们要检讨每一个细节，问题一定要设法解决！“当组员了 解到你不是企图卸责或算帐，而是真诚地想解决问题，就 会乐意把一切开诚布公地摊开来谈，大家一起研究问题， 从各种角度去设法克服问题。”进度落后“反而变成大家 宝贵的成长经验。
  进度落后里程碑达到了吗？其实这个问题很难有完全客观的衡量标准。由于产品设计可能会变，而品质本身 就是无形的，所以里程碑的到期日也可能会变，因此， 里程碑到达与否，变成了一种人为的判断：当需要回 头修改的项目愈来愈少、里程碑的宗旨达成、组员对 于下一个里程碑跃跃欲试时，你差不多可以宣布里程 碑成功。当然这一刻是很难决定的。对于这个问题， 我只能举个反面的例子来说明这个观念：比方说你去 问路，人家的回答是：”你一直往前走，若是看到尖 塔教堂，就表示走过头了。“如果你已经接近里程碑， 但开发活动还在进行，就表示已经走过头了。身为领导者，你必须时时掌握软件的一切状态，必须知道在每一个阶段应该进行那些活动，又该停止那些活动。 曾经有一次（也许不只是曾经），我们接近M1了，但一切工作都陷入混乱，我们只剩下两星期，而软件 的情况却糟得难以想象：错虫数（ bugs count ）实在 太高了，虽然每个程序设计师的错虫率还在合理范围， 但加起来的错误率却高得惊人，从我们每天的错虫增 加数目显示出软件距离稳定还差得很远。
  我们没有办法每天做软件建构（请参考法则32）， 虽然主要的产品组件多半都能建构成功，但就是有那 么几个不成的，表面上都能编译和连结（ compile & link），但就是建构不起来。这个问题大大地妨碍了 下一步骤工作：”猎犬测试“（sniff test）和程序代码 分析。当其中的一个定点问题好不容易被找出来解决， 这至少又花掉了一天的时间（请记得，在里程碑的后 期，一天就可能耗用是百分之十的资源）。
  组员和领导者并没有感到特别紧张，通常在接 近里程碑的时候，组员们都知道自己已经尽力，但 不知怎地，就是觉得不对劲，里程碑的精神似乎不 见了。
  事实上，这个问题的主要原因（也是一般常见的状况）是出在沟通和协调不良，起于至微而酿成巨 祸。当一只程序置入时，就改变了另一只程序的假设 前提，结果另一只程序就遇到了意料之外的状况。 A 小组依赖B小组的公用程序， A小组改好也测试过了 自己的程序，但前提是 B小组维持在第 n版，然而Ｂ 小组却改到了第n＋1版，虽然改得很少，但恰好是悠 关A小组的部分， B小组误以为不会影响 A小组的程 序，所以没有告知 A小组，结果A小组的程序就建构 不起来，因为它应该与B小组的第n版搭配，结果B小 组已经置入了第n＋1版的程序。 领导人应该制止这种情况吗？
  绝大多数的项目经理一旦发现这种情况，第一 个反应是采取补救行动─ 成立特别小组来接管事 务。但是这么做可能会造成一些问题：最严重的是， 这种行动的代价甚高，虽然这么做一定会使组员非常 注意软件的状态和风险─我把这种活动称作”强烈 焦点“（radical focus）─你等于是用领导者的职权 来使组员就范，这种敲响警钟的方法不能太常用，否 则团队就会发生”狼嚎症状“（cry wolf syndrome ），懒得对老板太认真，老板只是叫得凄厉而已。
  如果进度落后的情况太频繁，是很危险的。进 度落后变成正常的事，此时运用领导者的威严来提 高团队的危机感，这种手段只有在士气低落时才适 用，这时团队需要一点刺激，就是”强烈焦点“活 动：让小组在同一时间内担负几个小项目（大概不 超过两个），但是这几个项目的目标是南辕北辙、毫 不相干的。
  而当”强烈焦点“展开时，即使是健康的团队也 多少会反弹，觉得领导人在”反授权“（disempower- ment），于是一切不顺利的牢骚都算在”当权官员“ 的帐上，把这项措施解释成不尊重团队和团队的决定。 防卫心理升起，而且开始情绪不平，甚至可能因此怨 恨起来。即使是最优秀的领导者在采取”强烈焦点“ 措施时都会遭遇一段抗拒期。在违反对方的意愿之下 教育他，虽然做得到，但要辛苦很久。
  同时，你要和团队中最优秀开发人员的反抗权 威心理作战，他们可能不会很好沟通，而直接把你当 成笨蛋（请参考法则4）。在另一方面，你也有可能误 判士气的低落程度，这时候麻烦就大了，健康的团队会对你反弹，如果你死不认错就会丧失组员对你的尊敬和忠诚，要不就是你的自大使你愈走愈远；而团队 如果不是那么健康，不敢对你谏言，那你绝对会陷入 万劫不复的失败。
  在你决定采用”强烈焦点“时，以上所谈的故 事都是你的成本和风险。你的”固定成本“至少是几 个工作天（大概一星期左右），而你必须抓住组员的 注意力，保持他们的兴趣，让组员明白你是玩真的， 让他们愿意告诉你心里的感受，让他们开始做点实际 的事情。在这个起步阶段所需的时间视团队的大小、 沟通的意愿与能力而定。
  现在我们回到接近第一个里程碑时的原地踏步， 领导者要团队有什么样清楚的认识（ awareness）？ 如何做到这一点？然后会引起什么行为？
  在我们的案例中，要团队清楚认知的是 M1迫在 眉睫，而且除非过了 M1这一关，否则我们不可能完 成产品；我们也希望让团队练习使软件”整装待发“、 完工交货；最后，我们希望团队经历一下不成熟的 团队合作所带来的可怕后果，而从中学到我们每一 个人都有等量的责任，也是全部的责任 -就是达成里程碑。
  在我们的案例中，”强烈焦点“的施行是不合适 的，因为团队的问题不在士气低落，而且事后发现， 团队的反弹非常强烈。我们应该为真正的紧急情况保 留子弹。
  那该怎么办？
  很明显地，我们不可能让整个投资都押 M1这个 岌岌可危的一注，我们知道一定不能让问题持续下去。 我们现在正处于瓶颈，无法建构软件的不良效应正扩 散开来，这一点可以从超高的错虫率可以证明。大家 对程序的置入动作更谨慎，必须得仔细检查是否会妨 碍到别人的程序，也就是速度慢了很多。错虫数仍然 居高不下，为了除虫而做的修改仍然会发生前述版本 不同步的问题。当软件无法建构的状态持续太久，会 使得更多的程序搭配到别人的旧版本，结果使得软件 建构更加成功无望。我们很关心这种情况，组员对危 机的感受度似乎无法和工作的进度成正比。
  团队合作是相互影响的。为了完成整体的工作， 你必须划分出局部的工作。