软件项目文档及其必要性



在许多软件项目中，开发人员从商讨结构的会议开始，然后开始书写代码。不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。接着，他会和其他管理人员一样要求各种文档。

做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。

做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。

时间：进度表

资金：预算

地点：工作空间分配

人员：组织图。它与接口说明是相互依存的，如同Conway的规律所述：“设计系统的组织架构受到产品的约束限制，生产出的系统是这些组织机构沟通结构的映射。”Conway接着指出，一开始反映系统设计的组织架构图，肯定不会是正确的。如果系统设计能自由地变化，则项目组织架构必须为变化做准备。

为什么要有正式的文档？

首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。书写这项活动需要上百次的细小决定，正是由于它们的存在， 人们才能从令人迷惑的现象中得到清晰、确定的策略。

第二，文档能够作为同其他人的沟通渠道。项目经理常常会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知。 正因为项目经理的基本职责是使每个人都向着相同的方向前进， 所以他的主要工作是沟通， 而不是做出决定。 这些文档能极大地减轻他的负担。

最后，项目经理的文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整。

我并不是很同意销售人员所吹捧的“完备信息管理系统”——管理人员只需在计算机上输入查询， 显示屏上就会显示出结果。有许多基本原因决定了上述系统是行不通的。 一个原因是只有一小部分管理人员的时间——可能只有 20%——用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。不过，对于基于数据的部分，少数关键的文档是至关重要的，它们可以满足绝大多数需要。

项目经理的任务是制订计划，并根据计划实现。但是只有书面计划是精确和可以沟通的。计划中包括了时间、 地点、 人物、 做什么、 资金。 这些少量的关键文档封装了一些项目经理的工作。 如果一开始就认识到它们的普遍性和重要性， 那么就可以将文档作为工具友好地利用起来，而不会让它成为令人厌烦的繁重任务。 通过遵循文档开展工作， 项目经理能更清晰和快速地设定自己的方向。