文档的管理

一、立案的流程

1、  策划负责人、技术负责人、项目经理协同进行功能执行案的拆分。

2、  根据技术的进度安排功能执行案的撰写（功能执行案因提前于技术的功能实现）。

3、  策划完成功能执行案的撰写；提交策划负责人、技术负责人、项目经理审核。

4、  提交顺序：策划负责人→技术负责人→项目经理

5、  反馈修改，直到通过。

6、  文档必须有纸质的保存和签名；或开发文档只有一人有权放置在开发文件夹中。

7、  提交文档至《开发文档》文件夹，以群发消息的形式通知开发组所有成员。

8、  版本冻结：冻结已通过审核的文档；没有正式的修改请求，不得进行修改。

9、  正式修改的流程见：三、立案后的修改。

流程图：

二、文档管理

文档的管理分两部分：对于技术美术而言文档的可阅读性；在开发过程做出易于查找的历史记录管理方式。

1、文档的可阅读性

“颜色的含义”

文字颜色的管理：文档一般采用黑色字体；黑色加粗表示醒目，需要特别留意的部分；灰色字体表示暂不开发的部分；红色字体表示审核时发现问题，需要调整的部分；文档定案后做出的文档修正部分，采用蓝色字体。

“保持文档的唯一性”

对于与技术美术接口的文档而言；同一份文档的前后内容不得出入、重叠；文档之间的内容不得有出入和重叠。该部分工作由策划主管负责。

   “文档结构表”

   必须有一份表格，记录放置对技术美术接口的文件夹和文件；修改人必须唯一。在文件夹结构内容修改、增加、减少的情况下，调整《文档结构表》。

2、文档的历史记录

    在同一个项目中，需要根据文档的当前状态和处理结果分为四类：未审核、未通过、已通过、修改记录。

未审核：由策划撰写完成未审核，但还未经相关人员审核的第一个版本；这个版本是对所有开发成员公开的，所有开发成员都有知情和建议权。未通过：已经撰写了文档，但最终没有通过审核，而不能用于开发的文档；该类型的文档需在文档附录追加“取消开发原因”，作为今后开发的参考。已通过：提交审核，最终通过的文档；该类型文档是技术美术进行开发的唯一接口。修改记录：文档的未审核版本至已通过版本之间的修改记录，需要为其中每一项修改及修改原因做出完整记录；在接下来的开发中，如果出现同样的争执，可以作为判断的依据，减少团队在同一个问题不同时间点上的争执。

三、立案后的修改

1、  项目组所有成员都有修改建议权，交由策划完整文档草案。

2、  立案后的修改，必须以全新的功能模块的格式撰写。

3、  策划必须根据该修改，调整相关的已通过文档。

4、  必须在修改记录中就修改原因做出完整的记录。

5、  三位负责人进行审核，通过则对“已通过”的文档进行修改。