全面成功

这与过去的，人类一向成王败寇的单一判断观念有些不同。过去的社会关系简单，战争这种纯粹的、一旦失败就意味着国家灭亡的沉重的责任也让个体在群体中泯灭。到了现代，这类竞争关系不再存在。特别是在软件开发领域，你永远有模拟环境实施，犯错误，获得反馈并改进的机会。

奇怪的是，即便在这种情况下面，“交付成功”这一功利的目标，依然成为众多软件开发团队是否运转成功的唯一标准。在这种唯一判断标准之下，有一些行为显得可以理解：

很少的日常质量活动。 最显著的特征就是没有进行持续的测试活动，包括细粒度的单元测试和为业务人员准备的展示。测试本质是一种浪费——如果确定你的代码能够很好的工作，测试的确是增加了工作量。以“交付成功”的唯一目的而言，这些浪费毫无价值。

很少的知识共享和能力提升活动。 在“交付成功”的唯一目的之下，提升个体能力固然从长期看来对组织有利，但对于只有几个月的交付而言，没有项目经理希望这一行为发生在自己的项目之内。什么，需要花点时间学习新的技术？延误交付怎么办？沟通通常被工作环境、分配式的工作内容所隔离，团队中的个体往往只能在开会中聚集到一起，通常好几天、一两周才能偶尔发现一些讨论。

加班。加班显然是所有领导者喜欢的，说不定也是员工喜欢的。在软件行业，大多数人将其与一般的，体力密集型的工作混为一谈，认为工作时间的长度决定了工作内容的产出。就像收割麦子，生产线上的工人，工作时间越长，产出越大。然而智力密集型工作的特点在于思维清楚。很难想象一个人在工作加班十几二十个小时，依然能够保持犀利的想法，对项目进行贡献。当成为一种常态的时候，加班更多的成为一种筹码——一旦交付无法准时，那么就可以说：我们已经加很多班了。

让很多项目管理者感到迷惑的是，即便以“交付成功”或者“客户第一”之类的纯粹的，绝对的目标导向，最终许多项目依然不可避免的走向了无法按期交付、质量低劣、团队士气低落的噩梦。

在这里我不想继续提那些单点的优化策略，例如持续集成、测试驱动开发等等等等。我发现这里面是一个认知的过程。绝大多数的项目领导者，没有意识到在软件开发行业，这种单一的、功利性的目标导向下，只能产生一时的生产力提升，或无法最终产生另所有人满意的交付。在此，作为对“交付成功”唯一目标的对立面，我提出“全面成功”的概念：

全面成功，是指一个软件团队不再以交付成功作为唯一目标，而以团队沟通、个体能力提升、士气、客户沟通、持续的软件质量作为全面的衡量标准，最终获得一个全面成功的团队，交付成功只是必然结果之一。

软件开发事关沟通。写下的每一行晦涩代码，如果存在另外一个人审视，那么也许将不会存在；如果团队以平等尊重为前提，那么所有的错误都被容忍并改进，那么团队将显得更加和谐充满生机。想办法将各种软件交付产物的受众加入到沟通圈来，及早获得反馈，获得信任。

个体只有通过项目才能获得能力提升。这一点在软件行业尤其突出。给予团队成员一定的空间，通过各种活动提升员工的能力，最终这些能力会转化为惊人的生产力。

持续的软件质量，而不是某一刹那的集成。数天的甚至更久的扫缺陷、稳定版本时间不是必然的。通过实时的集成，充分的测试以及良好的测试策略，让软件库任何时刻都处于稳定的状态。这样开发人员才能放心的实现新的功能而不比担心破坏已有的功能。

全面成功并不是一个口号。事实上，我所经历过的成功的项目，都印证了这一论点。我的同事胡凯在InfoQ上分享的团队案例，也印证了全面成功对交付成功的必然性，并且获得了更多的好处。

在此我呼吁，团队停止以“交付成功”作为唯一的目标，将“全面成功”作为追求，不断改进，最终获得令人羡慕的团队，以及理所当然的顺利交付。