前些天，在工作中遇到一件心塞的事，就是许多人合写了一套方案，结果惨不忍睹。虽然我没有深度参与，但还是忍不住在这儿吐个槽。
多人合写文档的事在工作中并不少见。通常遇到了时间紧、任务重、内容复杂的文案任务，群策群力是最容易想到的解决方案，于是组织常常都会从各个部门抽调人员来搞定这个任务。至少从表面上看起来，这种方式是很合理的，因为：
1．可以快速成型：将一份文档分解为几个部分，分配给项目组员，各个子任务便可以同步进行，这大大缩短了项目时间。
2．有更高的质量：根据每个组员的特点分配给他们最擅长的部分，不仅每个人的压力减轻了，精力也可以更加集中，产出的质量会比较高。
基于这两个理由，大家便风风火火先开个会（或几个会），会议上会确定一个总协调人，明确一个大体规划和思路；然后分配任务，业务描述给业务口的，技术论证给技术口的；各人领了任务就开始埋头苦干；最后在某个时间节点把这些片段合并到一起，修改一番，搞定。
事情要是真有这么顺利就好了！！！
这种做法看起来很合理，但往往在任务后半段的时候大家就会发现一堆问题，通常在deadline之前大部分人都会抓狂。
首先，沟通非常困难。
为了更好的完成工作，人们必须进行沟通。但多人合写的方式，人越多，沟通就越困难。如果采取全通道沟通的方式，那么项目组有n个成员，就有n*(n-1)/2个沟通路径。简单说，沟通的效率和精确性随着成员的增加会迅速下降到一个无法忍受的程度（这还没考虑半途加入进来的不了解情况的人）。
而如果选择通过中心节点——即项目协调人——进行沟通，一样存在效率和准确性的问题。因为中心节点不可能通晓所有细节问题，最终的结果只能是协调人累死，其他人烦死。
建立一个邮件组或聊天群，有问题就发出来，大家一起解决，听起来是个好主意（事实上，现在大多数组织都喜欢这么做），但你会发现，往往有不少问题无人应答，因为大家拿不准这块谁负责（如果有领导在群里，这种现象会更明显），为了避免犯错，人们会更保守。
其次，项目看起来很小，管理却不简单。
上面提到的无人应答问题，一个重要的原因是任务分配没做好。虽然我们都知道合理分配任务的重要性，但出于成本的考虑，我们确实没办法事无巨细的分解所有任务，这就导致会有一些“无人认领的任务”或“边界重叠的任务”。前者会导致合并文档的时候发现少了一部分，后者会导致重复工作。这对一个进度要求很高的项目来说是很麻烦的。
另一个是进度问题。参与人员太多，只要有一个人发生延误，则整体完成时间都会延误。参与的人越多，这个风险越高。甚至在这种情况下，你没法判断和管理关键路径，因为每项任务都在关键路径上。
最后，质量不仅没有想象中的高，甚至更低。
主题不明确：虽然在一开始进行了规划，但一般初期规划很难保证所有人都对项目有深刻的理解（许多人是被当成壮丁拉进来的，连项目背景都不太清楚），这样每个人在写文档的时候都会有不同的假设和预期，单个片段可能和主题偏差不大，但当这些内容拼凑到一起的时候，偏差被放大了，你会发现，虽然每个字都认识，却读不懂这个文档。
风格不统一：每个人有自己的写作风格和习惯，甚至对某个术语的叫法都不同，这会让文档阅读起来极不流畅，甚至包含许多歧义。
质量参差不齐：写东西这事没有一个验收标准，因此你无法统一质量，当你看到一段精彩的论述后面跟了一段不知所谓的文字的时候一定是会抓狂的。
修改困难：以上3点本身都是极难修改的（写过东西的朋友应该有这种经验），再加上沟通的问题，以至于大多数时候，最后一个负责修改的人不得不重写其中的大多数内容（当然，前提是这个人有这么敬业），于是，大家本来期望的进度优势消失了。如果选择集体修改，则等于每个人都要根据别人的内容进行动态调整，这需要大量的沟通、确认，会花费超乎想象的时间和精力，最终才能将主题、风格、质量、内容这些关键因素收敛至统一状态。
要避免上面提到的问题，就必须从整体上看待项目，要明白最终的成果是应该是“一份文档”而不是“几份文档的集合”。
那么这类项目怎么做最好呢？篇幅受限，下回再说。
--------------------------
閱讀更多 學習時間 的文章
