引言
正如没有人能从田径场直奔马拉松，从爬郊野丘陵挑战珠穆朗玛；「介绍操作技巧」和「编写使用指南」之间也不仅仅是话题和篇幅的量变，而还要求工作流程和方法的质变。
作为长期关注 Apple 生态的科技媒体，我们对自己在报道和讲解 iOS 系统方面的专业性是有信心的。但即使如此，为日益复杂的 iOS 编写一本完整指南，也是我们未敢轻易涉足的领域。虽然早在 iOS 11 和 iOS 13 时代，我们便出版过两份相对成规模和体系的 iOS 付费栏目；但受制于时间和精力，这两份内容还远达不到我们心中的「系统指南」的量级，因此无论从选题还是宣传中，我们还是谨慎地以「技巧手册」相称。
然而，制作一套面向所有人群的 iOS 系统指南，细细分解 iOS 中的每一项设置和功能，始终是悬在我们心中的一个情结。今年，随着团队成员进一步充实、内容规划渐成体系，我们觉得是时候挑战一下自己了。
说干就干。6 月，iOS 15 亮相 WWDC 2021 之后，我们便迅速开始「少数派系统指南 · iOS 15」（下文简称为「系统指南」）的项目策划。当然，笔头未动，规划先行。考虑到可能涉及的章节之多，如果这份指南完全由我们编辑团队内部完成，不仅工作量上不现实，质量上也可能受限于自己的视野和经验中。
因此，即使并无经验和先例，我们没有太多犹豫就决定采用「共创」模式，即在少数派资深作者中公开招募、择优参与，内外分工协作完成创作。经过筛选，最终有十九位作者成为创作团队的成员。
由多位作者参与一部作品的创作并非前无古人，维基百科就是此种创作范式的典范。遍布全球的编写者与编辑，共同完成了体量惊人的百科全书。
然而对于少数派要制作系统指南这件事来说，依然存在不少困难：
- 系统指南并非简单的说明书和百科，要求在保证信息量的前提下，让内容的阅读性也保持少数派付费内容一贯的水准；
- 我们希望系统指南在写作风格上保持一致，不让读者感受到明显的割裂感；
- 从完成作者招募（七月中旬）到 iOS 15 正式上线仅有两个月的时间，到上架前起码要完成所有初稿。
简而言之，我们要在两个月的时间内，让十九位作者像一个人一样去写作。既要保证写作速度，还要追求文字的阅读性和一致性。
正如大家看到的，我们按时交出了答卷，从销售和反馈看，读者对我们的工作也是基本认可的。因此，在这个适合回顾的季节，我们也将借本文，对系统指南的创作过程和方法做一次复盘，或许能对你有所启发。
手册大纲：想清我们「做什么」
在单篇或较小规模项目的约稿流程中，我们编辑一般会和作者进行一次头脑风暴。然后，等作者将大纲整理出来，编辑确认内容结构没有问题后，即可动笔。如果编辑和作者相熟、或者选题特别明确，甚至可以略过这一步。
但在系统指南的项目中，这种方式就行不通了。要是由编辑一一和作者沟通，一定会造成有些选题有多位作者想写，有些选题无人问津被遗漏的局面。这与「全面」介绍 iOS 的目标是相悖的。
因此，我们决定在提纲阶段更多承担主导角色，在一开始就整理了一份系统指南的内容大纲。在梳理这份大纲时，我们重点参考了Apple 官方的 iPhone 使用手册，但还借鉴了国内外已有书籍的目录予以补充。
有了这份大纲，我们起码解决了「系统指南里有什么」的问题，相当于为系统指南画了一条内容的基准线。事实证明，这对后续的进展非常重要：实际工作中，思维活跃、创造力满载的作者们经常提出关于选题的建议和询问；对此，我们都会以大纲为参考系，看新选题是否能有机地融入进去。如果没有这样一份大纲，恐怕我们编辑自己都不知道哪些选题该增加，又应该加在哪些章节之中。
选题卡片：确定作者「写什么」
在以往项目的合作中，我们倾向于采取一种「佛系」态度，通常和作者约定大纲之后，不会过多干涉作者的写作篇幅和时间进度。这是因为我们相信，充分的自由度和尊重感，是高质内容的源泉。
然而，系统指南的时效性和内容量，要求我们更积极地进行项目管理。因为要保证 9 月份的上架时间，如果完全「放羊」，就让项目的进度不可控——作者中途因为个人原因无法按计划参与之类的意外情况是很难避免的。
不仅如此，项目管理要从选题认领阶段这一最初环节就开始。原因在于，就介绍 iOS 系统功能而言，不同功能之间的写作量差距是非常大的。例如，在最终的成稿里，介绍 App Store 的篇幅是介绍语音备忘录的十倍。这说起来顺理成章，但落实到实际操作中，如果我们直接让大家挑选题，就可能出现大家的工作相差巨大的情况。这对于多劳者不够公平，对于少劳者则也有屈才之感。
所以，在大纲的基础上，我们又设计了一项非常规的机制：将多个选题捆绑成一个写作卡片，作者领取写作卡片而非直接选择选题。
写作卡片的制作同样是由我们编辑完成的，基本原则就是每个卡片内选题最终的文字量在三千字左右。三千字，是我们根据经验预估可以在两个星期内完成的写作量。因此，当作者在看板中领取了写作卡片之后，就会明确知道初稿的交稿日是两周后。从编辑的角度，也可以通过对比剩余卡片的数量和制作周期剩余时间，来判断是否能按时完成初稿、是否需要调整细节规划等。
当然，虽然在策划上做了更多引导，但我们希望多给作者选择权，保证大家尽量领到自己感兴趣的选题。因此，我们首先允许作者自主领取选题，但要求同时要写的选题不超过三个，以防写作量积压。之后，对于一些少人问津的冷门选题，则由编辑「上门推销」，同时提供一些思路启发和内容建议。这样，我们成功地实现了每个人的写作量相差不会太大，而且不会漏掉一些选题。
在线协作：引导作者「怎么写」
作者领到写作卡片，便进入到写作初稿的环节。
在之前一篇「幕后」文章《三人三地跨时区，数字工具组如何进行团队协作？ 》中，我们介绍过数字工具组通过滴答清单，进行任务协同管理的经验。
在此经验指导下，在系统指南的编辑责任分工中，我们也在内部做了进行责任制分工，以保证每位作者能及时地与对接编辑保持沟通，确保不会遗漏或重复；为此，我们同样大量使用到滴答清单的「指派」功能。
具体而言，当作者领取写作卡片后，我们就会在滴答清单里创建对应的卡片（关于为什么不直接用飞书多维表格进行编辑团队的任务管理，请见之前文章中的解释，在此不赘），将卡片指派给负责的编辑。随后，被指派的编辑会和作者进行沟通，确定卡片内选题的大致内容、交稿时间，最终将所有信息汇总在滴答清单的任务上。
但在实践中，光靠硬性的分工机制是不够的，还需要更多软性的沟通。
为此，在作者招募完成之后，编辑团队就召集了作者开过一次说明会，提及了系统指南的内容风格、写作建议和注意事项等。例如，在内容风格上，我们提出希望成品包含对功能、应用的完整介绍，具有良好的阅读性和适合各类人群的内容难度，还要让读者可模仿进行操作。在作者领取写作卡片后，我们又在一对一沟通中再次强调内容风格的注意事项，并举出过往改稿经验中的实例，尽可能让在作者写作前就对我们预期的效果有相对具象的了解，避免成稿后再全部返工的不理想情况。
充分沟通是必要的，但也不是万能的。尽管有事先规划，但修改的重头戏还是在拿到初稿之后，根据初稿和作者一起进行调整。在这一阶段，为了避免因编辑对话题的不熟悉发生单点失效，一篇文章也会经过两遍审稿，先由一名编辑确定结构完整，再交给另一位编辑，换一双眼睛确保文章在内容上是合格的。
文稿整合：换位思考「怎么看」
一般的约稿中，经过编辑审稿、定稿，剩下就是排版发布了。但在系统指南项目中，在发布前还有非常关键的一步：文稿整合。
如果你有留意上文中系统指南大纲，会发现它的结构与最终发布的目录差别非常大。这是因为大纲的主要目的是完整，而成品还要考虑到可读性、发布日程、篇幅节奏等其他因素。例如，选题阶段预估的篇幅和最终进入整合阶段的接近定稿篇幅可能出现明显的区别，这就导致需要通过整合、拆分来保证相对均匀的节奏。
因此，根据读者了解 iOS 的顺序，我们重新将所有选题梳理为认识 iOS、系统功能、Apple 生态、生活应用和效率工具五个模块。经过这样的重新规划，读者既可以按照线性顺序，由浅入深地阅读内容；又可以把它当作一本工具书，直接查找自己想看的章节。
除了内容结构上的整合，保证写作风格的连贯也是这一阶段的工作重点。特别是因为整合内容会一定程度上打乱了作者的初稿，就更需要在内容上进行修饰，弥补可能产生的割裂感。
因此，我们又给自己加码，增加了一道「润色」环节。这项工作由编辑内部承担，范围包括但不限于：重新修改开头，确保每一篇的开头是风格统一的；统一各级标题的风格；统一对操作的描述，配上相应的快捷键等等工作。
最后，我们希望系统指南是一本「活」的指南。因此，我们在发布环节引入了「公测」机制，对于在上架早期购买的读者，持续听取其反馈，及时调整和优化。例如，第一周的内容因为涉及基础操作比较多，有读者反馈希望增加一些技巧性强的内容。我们便在后续的更新中，用技巧卡片的形式着重突出一些 iOS 操作技巧。
事实上，截至 11 月 18 日，系统指南 · iOS 15 不仅按计划完成更新，而且增加了包括 4 篇加更内容，使得总篇幅达到 50 篇，共计 17.2 万余字；这是超出我们预期的。
后记
总之，我们将一篇稿件经过多道编审、润色，就是希望能确保它在内容上不会给读者带来割裂感，能让十九位作者的文稿，看上去像一位作者所写的。
当然，正如开头所讲，多人协作文档无论在技术上还是内容上，都不是什么新鲜事，有维基百科这样的珠玉在前，我们也确实瓦石难当。
不过，我仍然为我们所有编辑和作者所共同创作出来的「少数派系统指南 · iOS 15」而自豪。或许它离完美的 iOS 系统指南还有差距，但从内容量、阅读性还是时效看，我们确实达成了立项之初的目标，面对成品，也可以对自己一直怀有的「系统指南」梦想有一个交代——我们没有浪费这个珍贵而有挑战性的题材。
让我们《iOS 蓝皮书》再见！
