关于项目文档和wiki页面

（这里说的是不是产品文档，不是使用手册，而是干活的人用到的设计文档）

最近为项目忙得焦头烂额，根本没时间维护先前写的项目文档和wiki页面。放假了，利用空闲时间重新审视了一下那些文档，有以下发现：

1. 先前写文档的自己和现在忙的焦头烂额的自己，判若两人。它写得未必多专业，但看着不像自己写的，那么多详细的表格、流程图、流程分析、相关模块的说明，以及对某个问题的多个解决方案的利弊分析，根本不像一个疲于奔命的人写出来的！
2. 写wiki页面真的是有必要。先前项目刚接手的时候，US leader让我为项目创建一个wiki，心想这是形式主义，但不得不照着Boss的精神创建一个项目wiki页面。随着项目的进行，发生了很多事情，包括新增功能、security fix、knowledge transfer、bug fix等，这些都需要在一个统一的地方做记录，要不然以后会一盘散沙。每个改动我都放到了wiki页面上，现在看来，没有发生一盘散沙的情况，整体还算可控；真心感谢US leader当初的建议。

关于写文档的一些个人感想，总结如下：

1. 写code之前先写点文档，非常必要，磨刀不耽误砍柴工夫。文档帮助自己整理思路，帮助别人更好地理解项目。也为以后的自己做备忘录，好记性不如烂笔头。
2. 和项目相关的任何信息都可以而且建议加入文档（相关性小的放在文档末尾都没关系，但最好不要漏掉）
3. 文档要认真写。文档是写给别人看的，也是写给自己看的，要写得简洁、清楚、明白。排版要层次脉络清晰，不要杂乱堆砌，否则不好阅读，也不好维护。
4. 能用表格、流程图描述的，就不要用文字描述。表格、流程图比文字更清晰明了，更具直观性，当然也节省阅读者的时间。
5. 工作中对项目、业务流程或code的理解，尽量都写进文档。比如之前对项目code某个复杂的流程或算法费了不少力气看懂了，这时就要及时在文档中记录下来：保存自己的劳动成果，以后会事半功倍；否则，时间一长忘记了，回过头来再看，那就后悔去吧，撞墙去吧！
6. 文档要及时更新。工作中会很忙，忙得没时间更新文档，这是很糟糕的，个人觉得这是项目失控的前兆。所以，一旦项目的需求或功能有改动，再忙都要抽时间更新文档，将最新的改动反映到文档中，更新相关章节，也可以增加changelist。长时间没更新的文档，我真心不想去阅读它，怕被它误导，怕浪费时间……

不大会写wiki页面，将现有wiki页面纲要罗列如下：

1. Milestones（里程碑起始结束日期，里程碑状态）
2. Owners（相关模块负责人）
3. References（相关的其他wiki页面，knowledge transfer链接）
4. Design specs（设计文档链接）
5. Tasks（任务编号、描述、状态、位于哪个里程碑中、工作量）
6. Code/file change list（改动日期、改动原因、bug号、code review链接）
7. Meeting minutes（会议记录链接、会议回放链接）
8. Other information（注意事项、todo list、对项目的顾虑等）