程序员与架构师的差别之文档的思维方式（老开发感悟）

最近带一个毕业生，他让我对文档的撰写有了一些新的领悟，跟以前的结合起来一起说一下：
首先，我个人在写文档方面有2个特点：简洁，清晰
简洁：能用一句话说清楚的绝不用第二句，用最简单的句子
清晰：结构清晰，让人一目了然；逻辑清晰，尽量减少读者的理解成本；重点清晰。
对内的文档
对上级：由于上级的时间都很宝贵，所以对上级的文档建议使用“金字塔原理”（《金字塔原理》是一本很不错的书，推荐阅读）。先用简练的开头让老大知道整个文档的核心内容（分析结果、方案概述…），然后再阐述细节，说明理由。
对下级：大部分都是执行层面，所以文档要强调执行的目的，完成时间，谁来做，做到什么程度，需要注意什么…
跨部门：大部分都是需求类文档，要强调制作需求目的，需求实现的各种细节，测试时间，更新时间…
对外的文档
对于活动策划来说，对外的文档主要就是活动公告了，这也是今天想说的重点。
【结构】
活动标题、活动引言、活动时间、活动范围、活动奖励、活动内容、活动说明。
这几个部分缺一不可，顺序没有定式，始终如一即可。由于大部分活动文档都是用这种结构，所以制作一个活动文档的模板是十分有必要的，能够节省很多时间。
【重点】
语言简洁，不说废话，同时要突出重点跟。跟玩家参与活动有关的都是重点（5W1H），这些重点尽量用颜色区分，但是不同的颜色不要过多，多于3种以上的颜色就很难看。
我一般在奖励（红色）和NPC（蓝色）上用颜色区分，时间由于是独立的一部分所以不用颜色。
【逻辑】
大部分活动都没有很复杂的逻辑（如果大部分活动的逻辑都很复杂，那么这个活动策划就是失败的，他的活动方案“拦住了”很多玩家参与活动），我们可以是用上面的结构。
但 是有时候因为某些功能无法实现，或者为了增加乐趣性，我们选择了较复杂的活动逻辑和流程。这个时候，使用上面的结构就不是明智之选了。当你按照上面的结构 写完，让一个不了解活动的同事来瞅瞅，发肯定会告诉你：第一他不愿意看，因为字太多，第二他不容易看懂，因为活动内容和活动说明这2个部分的逻辑会错综复 杂。
面对较复杂的活动，我建议使用玩家的行为逻辑。目的都是为了让玩家知道“我要做什么”！
活动概述：
最简洁的语言说明活动的核心内容，活动奖励，活动范围。（同样是金字塔原理）
流程图：
图形化的手段降低理解成本。流程图中的内容为玩家行为（如果活动流程中存在官方人员的工作内容，去掉它，只保留玩家必须要知道的内容）
流程详情：
每一步流程都包括时间，内容，其他说明。

【修饰】
加入活动奖励图片：把奖励的文字标红，远不如加入奖励图片来的好。
加入跟活动主题贴切的图片：这个图片是用来传递情感的，比如在母亲节活动的公告中加入一张体现关爱母亲的图片能更有感染力。
活动引言：以前我最不爱写这部分，但是现在觉得这个引言也很重要，因为他体现了一种风格，就跟人的个性一样，这部分文字能让突出游戏的风格特点。比如你是一个三国背景的游戏，引言就可以加入一些典故。
不要觉得图片一定比文字好：以前我曾迷信图片一定优于文字，所以有一阵尝试了在所有的活动公告中都加入一些流程图（包括逻辑简单的活动），但是发现图片无法精确的表达细节，容易误导玩家。所以简单的活动不要用图片，加入图片反而变得复杂化，复杂的活动再加入流程图。
【当局者迷】
由于活动方案都是我们想出来的，整个活动都是我们自己的逻辑，所以我们不存在理解问题。
另外，做方案时，我们会设计好玩家的行为方式，其他行为方式可能会被我们所疏忽。
基于以上2点原因，我们写出来的文档可能会让玩家难以理解。所以我们在写好文档后，最好找一个对活动方案不了解的同事，让他看一遍，是否存在理解困难问题，或者哪些地方玩家可能钻空子。
听取局外人的意见，对文档进行最终修改，这样的文档才能成为玩家喜欢的文档，而不是我们自己喜欢的文档！