前些天，在工作中遇到一件心塞的事，就是許多人合寫了一套方案，結果慘不忍睹。雖然我沒有深度參與，但還是忍不住在這兒吐個槽。
多人合寫文檔的事在工作中並不少見。通常遇到了時間緊、任務重、內容複雜的文案任務，群策群力是最容易想到的解決方案，於是組織常常都會從各個部門抽調人員來搞定這個任務。至少從表面上看起來，這種方式是很合理的，因為：
1．可以快速成型：將一份文檔分解為幾個部分，分配給項目組員，各個子任務便可以同步進行，這大大縮短了項目時間。
2．有更高的質量：根據每個組員的特點分配給他們最擅長的部分，不僅每個人的壓力減輕了，精力也可以更加集中，產出的質量會比較高。
基於這兩個理由，大家便風風火火先開個會（或幾個會），會議上會確定一個總協調人，明確一個大體規劃和思路；然後分配任務，業務描述給業務口的，技術論證給技術口的；各人領了任務就開始埋頭苦幹；最後在某個時間節點把這些片段合併到一起，修改一番，搞定。
事情要是真有這麼順利就好了！！！
這種做法看起來很合理，但往往在任務後半段的時候大家就會發現一堆問題，通常在deadline之前大部分人都會抓狂。
首先，溝通非常困難。
為了更好的完成工作，人們必須進行溝通。但多人合寫的方式，人越多，溝通就越困難。如果採取全通道溝通的方式，那麼項目組有n個成員，就有n*(n-1)/2個溝通路徑。簡單說，溝通的效率和精確性隨著成員的增加會迅速下降到一個無法忍受的程度（這還沒考慮半途加入進來的不瞭解情況的人）。
而如果選擇通過中心節點——即項目協調人——進行溝通，一樣存在效率和準確性的問題。因為中心節點不可能通曉所有細節問題，最終的結果只能是協調人累死，其他人煩死。
建立一個郵件組或聊天群，有問題就發出來，大家一起解決，聽起來是個好主意（事實上，現在大多數組織都喜歡這麼做），但你會發現，往往有不少問題無人應答，因為大家拿不準這塊誰負責（如果有領導在群裡，這種現象會更明顯），為了避免犯錯，人們會更保守。
其次，項目看起來很小，管理卻不簡單。
上面提到的無人應答問題，一個重要的原因是任務分配沒做好。雖然我們都知道合理分配任務的重要性，但出於成本的考慮，我們確實沒辦法事無鉅細的分解所有任務，這就導致會有一些“無人認領的任務”或“邊界重疊的任務”。前者會導致合併文檔的時候發現少了一部分，後者會導致重複工作。這對一個進度要求很高的項目來說是很麻煩的。
另一個是進度問題。參與人員太多，只要有一個人發生延誤，則整體完成時間都會延誤。參與的人越多，這個風險越高。甚至在這種情況下，你沒法判斷和管理關鍵路徑，因為每項任務都在關鍵路徑上。
最後，質量不僅沒有想象中的高，甚至更低。
主題不明確：雖然在一開始進行了規劃，但一般初期規劃很難保證所有人都對項目有深刻的理解（許多人是被當成壯丁拉進來的，連項目背景都不太清楚），這樣每個人在寫文檔的時候都會有不同的假設和預期，單個片段可能和主題偏差不大，但當這些內容拼湊到一起的時候，偏差被放大了，你會發現，雖然每個字都認識，卻讀不懂這個文檔。
風格不統一：每個人有自己的寫作風格和習慣，甚至對某個術語的叫法都不同，這會讓文檔閱讀起來極不流暢，甚至包含許多歧義。
質量參差不齊：寫東西這事沒有一個驗收標準，因此你無法統一質量，當你看到一段精彩的論述後面跟了一段不知所謂的文字的時候一定是會抓狂的。
修改困難：以上3點本身都是極難修改的（寫過東西的朋友應該有這種經驗），再加上溝通的問題，以至於大多數時候，最後一個負責修改的人不得不重寫其中的大多數內容（當然，前提是這個人有這麼敬業），於是，大家本來期望的進度優勢消失了。如果選擇集體修改，則等於每個人都要根據別人的內容進行動態調整，這需要大量的溝通、確認，會花費超乎想象的時間和精力，最終才能將主題、風格、質量、內容這些關鍵因素收斂至統一狀態。
要避免上面提到的問題，就必須從整體上看待項目，要明白最終的成果是應該是“一份文檔”而不是“幾份文檔的集合”。
那麼這類項目怎麼做最好呢？篇幅受限，下回再說。
--------------------------
閱讀更多 學習時間 的文章
