兵者，國之大事，不可不察也。——孫武
戰
爭是一個復雜的系統工程，需要多兵種的協同，即便是在冷兵器時代，也不能依靠單一兵種完成某場戰役，現代戰爭更是需要不同專業士兵的配合。我們經常可以在
影視劇中看到這樣的情景：兩軍對壘，最前面是盾牌兵，接下來是弓箭兵、長槍兵、騎兵、樸刀兵。首先弓箭兵在盾牌兵的掩護下放箭，一通亂射之后，然后盾牌兵
和長槍兵沖鋒，弓箭兵掩護，快接近敵軍時，盾牌兵后撤，弓箭兵停止射箭，騎兵和樸刀兵沖鋒。這種配合看似教條，實際是有一定意義的，它是從實踐中總結出來
的，從某種程度上反應了冷兵器時代多兵種協同作戰的重要性。
軟
件開發也是一個復雜的系統工程，需要各種專業的技術人員配合。通常我們簡單的把這些技術人員分成需求、開發和測試，相應的也把整個過程分為需求階段、開發
階段、測試階段。這種劃分積極的意義是區分了不同專業方向，將整個過程流水化，負面的意義是將各個階段和各個專業團隊割裂開，各自為政，失去了劃分專業的
本意，形式替代了目的。結果需求人員的目的變成了寫出一份需求，然后封閉意見；開發人員按照需求寫出代碼，改正bug；測試人員挖掘bug，監督開發人員改正，然后寫一份報告。整體的目的蕩然無存。當然無法否認這種流水作業的正確性以及必要性，我這里要說的只是它的負面問題。
當
作戰室只要指定一份作戰計劃，作戰部隊只要沖鋒殺敵，后勤部隊只要做飯埋尸體；空軍只管按線路圖投彈，炮兵只要向指定坐標開炮時。如果沒有一個正確的、偉
大的、英明的將軍，這場戰爭只能在一個貌似嚴格符合教科書的方式開始，以一個不可思議的方式失敗。因為除了這位將軍，所有人都沒有帶著腦袋去打仗，他想的
對不對，直接影響到結局。
可
惜的是，我們沒有這樣的將軍指揮軟件開發，也不存在這樣的將軍。我們都長著腦袋，都要去思考。從另外一個角度，我們并不嚴格類似軍隊，我們更像一個自治的
團體。那么自我協同就成了一個現實問題。需求、開發和測試人員如何協同完成一個產品呢？首先我們要把他們看做一個整體，他們所有人工作的目的只有一個：完
成一個產品。需求階段、開發階段和測試階段只是這個目的的一個階段，不是某個人工作的終極目的。我們已經認識到這點，但我們做的遠遠不夠。
在
需求階段，需求人員應該統領全局，向開發和測試人員介紹產品構想，解釋需求，輔助開發和測試人員完成后續階段的計劃和方案；在開發階段，開發人員要重新整
合所有資源，由開發人員沖鋒，需求人員提供支持，測試人員監督開發過程，糾正開發失誤；而在測試階段，測試人員才是指揮中心，他們要檢查軟件，需求人員配
合診斷，開發人員按測試計劃解決故障并封閉。不同的階段只是中心成員不同，決策人員不同，而不是責任不同，目的不同。
可
能說的太隱晦了，舉兩個例子來說明。一個還是打仗的例子，比如現在我們需要讓弓箭兵上馬，去追殺敵軍。弓箭兵老大可能反對并提出幾個原因，第一，并非職責
范圍，弓箭兵的職責是遠距離造成敵軍傷亡，沒有追逃的責任，這是騎兵的責任。第二，技術能力不足，弓箭兵都不善于騎馬，而且馬上射箭難度較大，沒法實現。
第三，如果敵人反撲，由于不善近戰，可能會造成大量傷亡。的確有道理，可是如果我們真的需要這樣做來表現我們的戰略意圖，怎么辦？
再
舉一個身邊的例子來說明，前幾天有這樣的爭執，關于需求應不應該明確界面限制導致選項不生效，然后切換界面取消限制，選項應如何的問題。需求人員的意見是
這樣的，第一，選項最終是什么不重要。第二，強行限制，會使需求工作量變大，同時開發和測試的工作量也增大（因為不同的地方，自然結果必然不同，強行一致
會導致不自然的處理，同時測試需要關注測試）。第三，不利于平臺化建設，這種限制會導致需求過分依賴于產品，無法在不同產品間共用。都很有道理。但是我認
為，提出這個問題是無可厚非的，需求的意見也是中肯的，解決的辦法是，我們要看看我們的終極目標，以此來判斷是否需要這樣做。首先，如果不限制造成不一
致，對我們的產品有沒有影響，其次，如果不一致，會不會造成后續工作的阻滯。對于這個問題的本身，我覺的對于無關緊要的選項，需求可以不寫，開發可以順其
自然，測試不必關注。而對于比較重要的選項，需求必須明確，開發必須處理，測試要注意關注。不可一概而論，非左即右。