兵者，国之大事，不可不察也。——孙武
战
争是一个复杂的系统工程，需要多兵种的协同，即便是在冷兵器时代，也不能依靠单一兵种完成某场战役，现代战争更是需要不同专业士兵的配合。我们经常可以在
影视剧中看到这样的情景：两军对垒，最前面是盾牌兵，接下来是弓箭兵、长枪兵、骑兵、朴刀兵。首先弓箭兵在盾牌兵的掩护下放箭，一通乱射之后，然后盾牌兵
和长枪兵冲锋，弓箭兵掩护，快接近敌军时，盾牌兵后撤，弓箭兵停止射箭，骑兵和朴刀兵冲锋。这种配合看似教条，实际是有一定意义的，它是从实践中总结出来
的，从某种程度上反应了冷兵器时代多兵种协同作战的重要性。
软
件开发也是一个复杂的系统工程，需要各种专业的技术人员配合。通常我们简单的把这些技术人员分成需求、开发和测试，相应的也把整个过程分为需求阶段、开发
阶段、测试阶段。这种划分积极的意义是区分了不同专业方向，将整个过程流水化，负面的意义是将各个阶段和各个专业团队割裂开，各自为政，失去了划分专业的
本意，形式替代了目的。结果需求人员的目的变成了写出一份需求，然后封闭意见；开发人员按照需求写出代码，改正bug；测试人员挖掘bug，监督开发人员改正，然后写一份报告。整体的目的荡然无存。当然无法否认这种流水作业的正确性以及必要性，我这里要说的只是它的负面问题。
当
作战室只要指定一份作战计划，作战部队只要冲锋杀敌，后勤部队只要做饭埋尸体；空军只管按线路图投弹，炮兵只要向指定坐标开炮时。如果没有一个正确的、伟
大的、英明的将军，这场战争只能在一个貌似严格符合教科书的方式开始，以一个不可思议的方式失败。因为除了这位将军，所有人都没有带着脑袋去打仗，他想的
对不对，直接影响到结局。
可
惜的是，我们没有这样的将军指挥软件开发，也不存在这样的将军。我们都长着脑袋，都要去思考。从另外一个角度，我们并不严格类似军队，我们更像一个自治的
团体。那么自我协同就成了一个现实问题。需求、开发和测试人员如何协同完成一个产品呢？首先我们要把他们看做一个整体，他们所有人工作的目的只有一个：完
成一个产品。需求阶段、开发阶段和测试阶段只是这个目的的一个阶段，不是某个人工作的终极目的。我们已经认识到这点，但我们做的远远不够。
在
需求阶段，需求人员应该统领全局，向开发和测试人员介绍产品构想，解释需求，辅助开发和测试人员完成后续阶段的计划和方案；在开发阶段，开发人员要重新整
合所有资源，由开发人员冲锋，需求人员提供支持，测试人员监督开发过程，纠正开发失误；而在测试阶段，测试人员才是指挥中心，他们要检查软件，需求人员配
合诊断，开发人员按测试计划解决故障并封闭。不同的阶段只是中心成员不同，决策人员不同，而不是责任不同，目的不同。
可
能说的太隐晦了，举两个例子来说明。一个还是打仗的例子，比如现在我们需要让弓箭兵上马，去追杀敌军。弓箭兵老大可能反对并提出几个原因，第一，并非职责
范围，弓箭兵的职责是远距离造成敌军伤亡，没有追逃的责任，这是骑兵的责任。第二，技术能力不足，弓箭兵都不善于骑马，而且马上射箭难度较大，没法实现。
第三，如果敌人反扑，由于不善近战，可能会造成大量伤亡。的确有道理，可是如果我们真的需要这样做来表现我们的战略意图，怎么办？
再
举一个身边的例子来说明，前几天有这样的争执，关于需求应不应该明确界面限制导致选项不生效，然后切换界面取消限制，选项应如何的问题。需求人员的意见是
这样的，第一，选项最终是什么不重要。第二，强行限制，会使需求工作量变大，同时开发和测试的工作量也增大（因为不同的地方，自然结果必然不同，强行一致
会导致不自然的处理，同时测试需要关注测试）。第三，不利于平台化建设，这种限制会导致需求过分依赖于产品，无法在不同产品间共用。都很有道理。但是我认
为，提出这个问题是无可厚非的，需求的意见也是中肯的，解决的办法是，我们要看看我们的终极目标，以此来判断是否需要这样做。首先，如果不限制造成不一
致，对我们的产品有没有影响，其次，如果不一致，会不会造成后续工作的阻滞。对于这个问题的本身，我觉的对于无关紧要的选项，需求可以不写，开发可以顺其
自然，测试不必关注。而对于比较重要的选项，需求必须明确，开发必须处理，测试要注意关注。不可一概而论，非左即右。