【问题标题】:folder structure for project documentation项目文档的文件夹结构
【发布时间】:2011-01-31 15:03:46
【问题描述】:

我看到一些关于源代码文件夹结构的问题,但我从来没有看到关于项目文档的文件夹结构的问题。我用谷歌搜索了它,仍然没有看到很多文章谈论。 这是一个http://www.projectperfect.com.au/downloads/Info/info_project_folder_structure.pdf

引用其中的一些话:

“有两种广泛的方法:

  1. 按阶段组织,以便每个顶部 目录是一个阶段。例如, 你可能有目录 可行性业务分析设计等或任何你的阶段 被调用。
  2. 按功能组织,以便顶部 目录级别是函数。为了 例如,风险要求范围变更控制开发

大多数时候两者都混合使用..."

所以有想过吗?我相信这也是一个重要的问题!

【问题讨论】:

    标签: project document


    【解决方案1】:

    恕我直言,根据您的文档管理系统,您的文档结构的选择可能不是问题。在查看与项目相关的文档试图解决的问题时,您通常会得出这样的结论:文档是关于沟通的。

    不同的文档试图传达不同的事物(或上下文);测试计划讨论应该/已经执行测试,需求规范讨论应该如何应用业务规则,架构文档讨论技术组件等等。这些文档中的每一个都可能需要自己独特的结构。例如,您为测试计划选择的结构可能与您为架构文档所需的结构大不相同。

    在记住沟通问题和文档上下文时,我通常会回到这两个关键方面。

    1. 可搜索性 - 找到我要查找的文档的最简单方法是什么?
    2. 版本控制 – 我如何知道我要查找的文档是最新的?

    我觉得可搜索性是最重要的要记住的事情,因为不同的人用不同的名字称呼同一个文档。例如,有些人将业务需求文档称为功能规范。有些人将功能规范称为用例文档。由于您不能总是控制文档的命名约定,因此我觉得找到正确的文档比存储它的文件夹或位置重要得多。

    因此,要回答您的问题,我会简单地回答您使用哪种结构并不重要,只是您应该使用某种形式的文档管理系统(SharePoint、Documentum、Trim 等)。没有它的好处实在是太大了:)

    【讨论】:

    • 如果您有工具可以将元数据添加到您的文档并在此基础上构建可搜索性,这将是一个巨大的优势。但我认为你仍然需要组织你的文档。将状态报告、设计文档和测试计划放在同一个文件夹中确实不是一个好主意。
    猜你喜欢
    • 2014-07-09
    • 2018-03-11
    • 2020-09-11
    • 1970-01-01
    • 2011-07-07
    • 1970-01-01
    • 2015-12-05
    • 2016-08-05
    • 1970-01-01
    相关资源
    最近更新 更多