兵者，國之大事，不可不察也。——孫武

戰 爭是一個復雜的系統工程，需要多兵種的協同，即便是在冷兵器時代，也不能依靠單一兵種完成某場戰役，現代戰爭更是需要不同專業士兵的配合。我們經常可以在 影視劇中看到這樣的情景：兩軍對壘，最前面是盾牌兵，接下來是弓箭兵、長槍兵、騎兵、樸刀兵。首先弓箭兵在盾牌兵的掩護下放箭，一通亂射之后，然后盾牌兵 和長槍兵沖鋒，弓箭兵掩護，快接近敵軍時，盾牌兵后撤，弓箭兵停止射箭，騎兵和樸刀兵沖鋒。這種配合看似教條，實際是有一定意義的，它是從實踐中總結出來 的，從某種程度上反應了冷兵器時代多兵種協同作戰的重要性。

軟 件開發也是一個復雜的系統工程，需要各種專業的技術人員配合。通常我們簡單的把這些技術人員分成需求、開發和測試，相應的也把整個過程分為需求階段、開發 階段、測試階段。這種劃分積極的意義是區分了不同專業方向，將整個過程流水化，負面的意義是將各個階段和各個專業團隊割裂開，各自為政，失去了劃分專業的 本意，形式替代了目的。結果需求人員的目的變成了寫出一份需求，然后封閉意見；開發人員按照需求寫出代碼，改正bug；測試人員挖掘bug，監督開發人員改正，然后寫一份報告。整體的目的蕩然無存。當然無法否認這種流水作業的正確性以及必要性，我這里要說的只是它的負面問題。

當 作戰室只要指定一份作戰計劃，作戰部隊只要沖鋒殺敵，后勤部隊只要做飯埋尸體；空軍只管按線路圖投彈，炮兵只要向指定坐標開炮時。如果沒有一個正確的、偉 大的、英明的將軍，這場戰爭只能在一個貌似嚴格符合教科書的方式開始，以一個不可思議的方式失敗。因為除了這位將軍，所有人都沒有帶著腦袋去打仗，他想的 對不對，直接影響到結局。

可 惜的是，我們沒有這樣的將軍指揮軟件開發，也不存在這樣的將軍。我們都長著腦袋，都要去思考。從另外一個角度，我們并不嚴格類似軍隊，我們更像一個自治的 團體。那么自我協同就成了一個現實問題。需求、開發和測試人員如何協同完成一個產品呢？首先我們要把他們看做一個整體，他們所有人工作的目的只有一個：完 成一個產品。需求階段、開發階段和測試階段只是這個目的的一個階段，不是某個人工作的終極目的。我們已經認識到這點，但我們做的遠遠不夠。

在 需求階段，需求人員應該統領全局，向開發和測試人員介紹產品構想，解釋需求，輔助開發和測試人員完成后續階段的計劃和方案；在開發階段，開發人員要重新整 合所有資源，由開發人員沖鋒，需求人員提供支持，測試人員監督開發過程，糾正開發失誤；而在測試階段，測試人員才是指揮中心，他們要檢查軟件，需求人員配 合診斷，開發人員按測試計劃解決故障并封閉。不同的階段只是中心成員不同，決策人員不同，而不是責任不同，目的不同。

可 能說的太隱晦了，舉兩個例子來說明。一個還是打仗的例子，比如現在我們需要讓弓箭兵上馬，去追殺敵軍。弓箭兵老大可能反對并提出幾個原因，第一，并非職責 范圍，弓箭兵的職責是遠距離造成敵軍傷亡，沒有追逃的責任，這是騎兵的責任。第二，技術能力不足，弓箭兵都不善于騎馬，而且馬上射箭難度較大，沒法實現。 第三，如果敵人反撲，由于不善近戰，可能會造成大量傷亡。的確有道理，可是如果我們真的需要這樣做來表現我們的戰略意圖，怎么辦？