战 争是一个复杂的系统工程，需要多兵种的协同，即便是在冷兵器时代，也不能依靠单一兵种完成某场战役，现代战争更是需要不同专业士兵的配合。我们经常可以在 影视剧中看到这样的情景：两军对垒，最前面是盾牌兵，接下来是弓箭兵、长枪兵、骑兵、朴刀兵。首先弓箭兵在盾牌兵的掩护下放箭，一通乱射之后，然后盾牌兵 和长枪兵冲锋，弓箭兵掩护，快接近敌军时，盾牌兵后撤，弓箭兵停止射箭，骑兵和朴刀兵冲锋。这种配合看似教条，实际是有一定意义的，它是从实践中总结出来 的，从某种程度上反应了冷兵器时代多兵种协同作战的重要性。

软 件开发也是一个复杂的系统工程，需要各种专业的技术人员配合。通常我们简单的把这些技术人员分成需求、开发和测试，相应的也把整个过程分为需求阶段、开发 阶段、测试阶段。这种划分积极的意义是区分了不同专业方向，将整个过程流水化，负面的意义是将各个阶段和各个专业团队割裂开，各自为政，失去了划分专业的 本意，形式替代了目的。结果需求人员的目的变成了写出一份需求，然后封闭意见；开发人员按照需求写出代码，改正bug；测试人员挖掘bug，监督开发人员改正，然后写一份报告。整体的目的荡然无存。当然无法否认这种流水作业的正确性以及必要性，我这里要说的只是它的负面问题。

当 作战室只要指定一份作战计划，作战部队只要冲锋杀敌，后勤部队只要做饭埋尸体；空军只管按线路图投弹，炮兵只要向指定坐标开炮时。如果没有一个正确的、伟 大的、英明的将军，这场战争只能在一个貌似严格符合教科书的方式开始，以一个不可思议的方式失败。因为除了这位将军，所有人都没有带着脑袋去打仗，他想的 对不对，直接影响到结局。

可 惜的是，我们没有这样的将军指挥软件开发，也不存在这样的将军。我们都长着脑袋，都要去思考。从另外一个角度，我们并不严格类似军队，我们更像一个自治的 团体。那么自我协同就成了一个现实问题。需求、开发和测试人员如何协同完成一个产品呢？首先我们要把他们看做一个整体，他们所有人工作的目的只有一个：完 成一个产品。需求阶段、开发阶段和测试阶段只是这个目的的一个阶段，不是某个人工作的终极目的。我们已经认识到这点，但我们做的远远不够。

在 需求阶段，需求人员应该统领全局，向开发和测试人员介绍产品构想，解释需求，辅助开发和测试人员完成后续阶段的计划和方案；在开发阶段，开发人员要重新整 合所有资源，由开发人员冲锋，需求人员提供支持，测试人员监督开发过程，纠正开发失误；而在测试阶段，测试人员才是指挥中心，他们要检查软件，需求人员配 合诊断，开发人员按测试计划解决故障并封闭。不同的阶段只是中心成员不同，决策人员不同，而不是责任不同，目的不同。

可 能说的太隐晦了，举两个例子来说明。一个还是打仗的例子，比如现在我们需要让弓箭兵上马，去追杀敌军。弓箭兵老大可能反对并提出几个原因，第一，并非职责 范围，弓箭兵的职责是远距离造成敌军伤亡，没有追逃的责任，这是骑兵的责任。第二，技术能力不足，弓箭兵都不善于骑马，而且马上射箭难度较大，没法实现。 第三，如果敌人反扑，由于不善近战，可能会造成大量伤亡。的确有道理，可是如果我们真的需要这样做来表现我们的战略意图，怎么办？