上回咱們聊了那麼多，總結下來就是，多人合寫文檔的時候，溝通和協調是個躲不掉的大問題。團隊成員越多、關係越複雜，這個問題就越嚴重。
這麼看來，最好的方法當然是不採取眾包的模式，而是由一個人完成。這樣就完全規避了溝通協調的風險，只要這個人有能力完成，出來的東西一定是思路清晰、主題明確的，修改起來也很容易。特別是當這份文檔需要配合演講的時候，理解不一致的情況會更嚴重，那麼“誰講誰寫，誰寫誰講”顯然是最理想的選擇。
然而事實上，確實有許多工作是靠個人難以完成的，所以我們只能選擇一個相對合理的合作方式來搞定。我的建議有別於上一篇中提到的“人人平等”的合作方式，而是“一人主筆，旁人補充”。來看看怎麼做。
我們先將這份工作簡單劃分為3個階段：規劃階段、執行階段和收尾階段。
規劃階段
確定一個項目負責人：項目負責人對整個事務負責，也是總協調人。所以，無論是否熟悉業務，他至少應該是一個有極強協調能力的人（靠一個小角色來協調是不靠譜的偷懶做法，原因是沒人想負這個責任）。
明確交付物的需求：需求當然是首先要明確下來的，內部討論也好，跟需求方確認也好，都要確保它是清晰的、可實現的。需求決定了文檔的內容是什麼。
找一個主筆：主筆應該是既熟悉業務文筆又不錯的人。他是執行團隊的核心，由他來整理文檔的整體思路和內容劃分，並對這份文檔的質量負責。這樣就避免了主題模糊、內容混亂、修改困難的情況。
找幾個核心成員：這個階段不需要將所有的團隊成員都加進來，只找幾個最好的即可，他們需要參與前期的溝通，也是後續執行的主力。這些人應該具有相似的背景，如工作能力、寫作水平等，這樣才能確保文檔的整體風格和質量是統一的。
花盡量多的時間討論文檔本身：簡單的說，就是統一思想達成共識。這一步是相當重要的，許多團隊都傾向於儘快開始著手寫，結果在後面修改的時候苦不堪言，反而搭進了更多的時間和精力。之前的文章裡也不止一次的提過，前期準備做足，後面就是無腦寫寫寫而已，最後甚至都不用怎麼修改。
把合適的任務分配給合適的人：當主題確定了，邏輯討論清楚了，內容就可以被分成一個一個的任務包了。主筆應該對每個任務包做一個簡單但清晰的描述，說明自己想要哪些內容，以什麼方式呈現，這樣，收到任務包的人就不需要理會什麼邏輯線故事線，只需要付出體力就可以了。
做好計劃：明確交付的時間、對象和方式。
當規劃階段完成的時候，我們會發現文檔的框架已經非常清楚了，剩下的只是往裡面加料而已。
執行階段
把控進度：項目負責人需要隨時掌握進度，動用一切力量消滅不確定性和拖延症。
使用快速迭代的方式：快速迭代的方法我們之前提過，這裡就不多說了。在規劃階段也要明確每次迭代的時間點。
成員僅和主筆溝通：主筆已經將內容的側重點描述清楚了，寫手們只需要將自己熟知的專業內容按照要求添加進去即可。如果出現了某人不知道需要放哪些材料進去的情況，那就說明規劃沒有做好，這時，需要與主筆儘早溝通並明確要求。
驗證第一次迭代：如果規劃合理，除非需求有變動，否則不會出現內容偏離主題太多的情況，那麼第一次迭代之後，文檔幾乎已經成型了，後面的迭代只不過是查漏補缺而已。而如果第一次迭代之後仍然很爛，主筆有必要召集核心成員，重新明確要求。
不要迭代次數太多：通常，文檔會發給很多人審核，收集意見，但有時候反饋的建議越來越少，這並不是因為文檔已經完美了，更有可能的是，因為每天都收到新的版本，參與者們對這項工作感到乏味了，根本懶得去看。又或者，版本之間的差異非常小，人們把關注點放到了修改的細節上，難以提出有效建議。
還是那句話，只要規劃階段做好，執行會容易和順暢許多。典型的分工合作型工作，如軟件開發、工程建設等，都具有這個特點。
收尾階段
減少參與成員：為了減少溝通和協調的成本，也為了避免更多的妥協，只需要核心人員參與最後階段的修改就可以了。如果最後一個版本質量不錯的話，甚至主筆一個人修改就夠了，因為這時候需要修改的幾乎已經無關內容，而僅僅是一些語句、標點、統一術語等細節問題。
面對面溝通：確實需要一起修改的話，為了高效，首選面對面溝通，其次是電話會議，實在沒辦法才用郵件。
檢查最後一版：大問題應該在規劃階段就解決，至少在第一次迭代之後就發現，所以最後一版，就算質量不算太高，至少也是個四平八穩的版本。所以，再最後檢查一遍錯別字、排版和客戶名稱，沒問題的話就交貨吧。
------------------------------------
OK，最後簡單總結一下：
找靠譜的人
重視前期工作
充分溝通
快速迭代
只要這幾個點把握好了，大家就放心寫寫寫吧。
以上是我的一些建議，希望對大家有用。
閱讀更多 學習時間 的文章
