（收藏）某人的博客，置身事外：能力与勇气

置身事外：能力与勇气

一 台完美的晚会，演员为了观众而投入的表演，观众被表演而吸引，或捧腹或感动，而主持人一定是不温不火的那一个。他看起来不属于舞台：既不需要投入的表演， 也不能忘我的欣赏节目，他最需要做的，就是按照既定的节奏，引导整台晚会逐步完成。观众笑，他可以笑但不能毫无顾忌；演员演得不尽人意，他通常也不能冲上 去救场。他只能冷静的（无论从外表看起来他与观众、演员、嘉宾交流多么投入）按照时间规划，客观、严格的完成节目。

看起来，好像主持人是置身事外的。作为一台晚会，他没有参与其中最重要的部分。但从没有人质疑主持人的重要性，同时人们对这种分工也觉得很自然。但 如果场面变一下：主持人跟观众一样感动得没了分寸，又或者觉得演员表演欠佳，他冲上去临时换着扮演，破坏演员节奏，恐怕最终结果不会那么乐观。劳动分工的 精确含义在于，充分相信那个角色在当时场景下所做的努力，并尽最大努力帮助你的伙伴，不受干扰，节奏平稳的完成他的工作。

我现在依然看到，很多软件项目中，项目经理往往是一个悲情角色。他往往需要对整个项目负责，技术很强（开发背景），同时还要把握需求，控制需求，还 需要跟客户（或者业务部门）交流，以及汇报。早些年参加软件工作的时候，我一直很羡慕项目经理的职位，呼风唤雨，加班（那时一直认为加班是一件很光荣的事 情），随意抽调人，出差。后来有机会做了一些类似的工作，才发现这个职位几乎不能由人来胜任。项目经理要日常管理的同时，还需要是一个技术领袖，能够审核 开发人员的代码。在这种情况下，项目经理一人之力撑起了一把伞，其他角色心安理得的躺在伞下，不用担心任何问题。

敏捷项目中，程序员更希望项目经理是一个看不见的角色。项目最终看起来是什么样子？由BA/QA决定。项目最终质量如何？由那帮写代码的决定。项目 经理要做的，是置身事外。这里的事，就是具体的开发。冷眼旁观，但不评价，不插手，充分信任。置身事外需要勇气，即便在客户的高压下，也能够不加班的勇 气；需要能力，需要辨别风险需求的能力。作为项目交付这台大的晚会，作为主持人，要做的就是保护你的程序员，是他们在任何情况下，能够持续稳定的产出可工 作的、高质量代码。

勇气

作为极限编程中的原则（或者价值观）之一，在其他方面同样有效。项目经理要面对的最大的风险往往是需求的变更。作为一个正常的项目，大部分来自客户 的变更都是有意义的。客户至上的理念在这里并不通用。在敏捷叠帽子游戏中，大部分的参与者都认识到时间与质量之间有一个平衡，总得拿些东西来换的。然而面 对真正的客户，我们是否有勇气对一个看似合理的需求变更说不？说不很可能意味着客户不高兴，或者永久失去了一个客户。我们永远需要记住的是，客户需要 100%，我们在规定时间内交付合格的哪怕50%都比交付不合格的99%要有意义得多。

能力

劝说客户是需要技巧的。与客户交流是需要技巧的。这些技巧程序员天生不具备。缜密的逻辑思维让他们不能在若干种模棱两可的商业外交语中如同编程代码 一样游刃有余。这需要一个真正逻辑清楚并且沟通较好的人来完成。不要期待这样的人也能够写出比hello world级别更高的代码。通常情况下，他们只需要了解三层架构等等概念性的东西。与客户沟通，项目管理，分析项目开发进度，找到影响开发速度的地方并持 续改进开发过程，适当激励才是项目经理需要做的事情。这些事情可以通过个人魅力，但也是需要技巧的。

置身事外

置身事外不是放纵。最大意味着，信任。一个团队中一定有一两个编程方面突出的人。保护这些激情并引导成为成就感，而不是架起一座大伞他们可以躺在伞下睡觉。不断强调整体团队与荣辱与共，这样项目的成功才能成为所有人的成功，而不是一个人的成功。

作为管理者或者推动者，是一个相当不能进入状态的角色，很多时候他们需要警惕破坏团队的因素并不断改进。上面的每一点都可以展开说去，每一点都是知 易行难。我逐渐发现构建一个新的团队的过程远比引入新技术复杂的多。但不怕慢只怕站，持续改进，你的团队将成为最可怕、效率最高的团队。