文章图片

系统指南最初的大纲
有了这份大纲 ， 我们起码解决了「系统指南里有什么」的问题 ， 相当于为系统指南画了一条内容的基准线 。 事实证明 ， 这对后续的进展非常重要：实际工作中 ， 思维活跃、创造力满载的作者们经常提出关于选题的建议和询问；对此 ， 我们都会以大纲为参考系 ， 看新选题是否能有机地融入进去 。 如果没有这样一份大纲 ， 恐怕我们编辑自己都不知道哪些选题该增加 ， 又应该加在哪些章节之中 。
选题卡片：确定作者「写什么」
在以往项目的合作中 ， 我们倾向于采取一种「佛系」态度 ， 通常和作者约定大纲之后 ， 不会过多干涉作者的写作篇幅和时间进度 。 这是因为我们相信 ， 充分的自由度和尊重感 ， 是高质内容的源泉 。
然而 ， 系统指南的时效性和内容量 ， 要求我们更积极地进行项目管理 。 因为要保证 9 月份的上架时间 ， 如果完全「放羊」 ， 就让项目的进度不可控——作者中途因为个人原因无法按计划参与之类的意外情况是很难避免的 。
不仅如此 ， 项目管理要从选题认领阶段这一最初环节就开始 。 原因在于 ， 就介绍 iOS 系统功能而言 ， 不同功能之间的写作量差距是非常大的 。 例如 ， 在最终的成稿里 ， 介绍 App Store 的篇幅是介绍语音备忘录的十倍 。 这说起来顺理成章 ， 但落实到实际操作中 ， 如果我们直接让大家挑选题 ， 就可能出现大家的工作相差巨大的情况 。 这对于多劳者不够公平 ， 对于少劳者则也有屈才之感 。
所以 ， 在大纲的基础上 ， 我们又设计了一项非常规的机制：将多个选题捆绑成一个写作卡片 ， 作者领取写作卡片而非直接选择选题 。

文章图片

领取卡片的看板
写作卡片的制作同样是由我们编辑完成的 ， 基本原则就是每个卡片内选题最终的文字量在三千字左右 。 三千字 ， 是我们根据经验预估可以在两个星期内完成的写作量 。 因此 ， 当作者在看板中领取了写作卡片之后 ， 就会明确知道初稿的交稿日是两周后 。 从编辑的角度 ， 也可以通过对比剩余卡片的数量和制作周期剩余时间 ， 来判断是否能按时完成初稿、是否需要调整细节规划等 。
当然 ， 虽然在策划上做了更多引导 ， 但我们希望多给作者选择权 ， 保证大家尽量领到自己感兴趣的选题 。 因此 ， 我们首先允许作者自主领取选题 ， 但要求同时要写的选题不超过三个 ， 以防写作量积压 。 之后 ， 对于一些少人问津的冷门选题 ， 则由编辑「上门推销」 ， 同时提供一些思路启发和内容建议 。 这样 ， 我们成功地实现了每个人的写作量相差不会太大 ， 而且不会漏掉一些选题 。
在线协作：引导作者「怎么写」
作者领到写作卡片 ， 便进入到写作初稿的环节 。
在之前一篇「幕后」问斩《三人三地跨时区 ， 数字工具组如何进行团队协作？ 》中 ， 我们介绍过数字工具组通过滴答清单 ， 进行任务协同管理的经验 。
在此经验指导下 ， 在系统指南的编辑责任分工中 ， 我们也在内部做了进行责任制分工 ， 以保证每位作者能及时地与对接编辑保持沟通 ， 确保不会遗漏或重复；为此 ， 我们同样大量使用到滴答清单的「指派」功能 。

文章图片

滴答清单中的任务卡片
具体而言 ， 当作者领取写作卡片后 ， 我们就会在滴答清单里创建对应的卡片（关于为什么不直接用飞书多维表格进行编辑团队的任务管理 ， 请见之前文章中的解释 ， 在此不赘） ， 将卡片指派给负责的编辑 。 随后 ， 被指派的编辑会和作者进行沟通 ， 确定卡片内选题的大致内容、交稿时间 ， 最终将所有信息汇总在滴答清单的任务上 。