从某国企研究院ERP项目体会文档工程.doc

从某国企研究院ERP项目体会文档工程
软件文档是一些记录的数据和数据媒体，它和计算机程序共同构成了能完成特定功能的计算机软件。但是，软件产品与硬件产品有很大的不同，它的整个生产过程不是有形可见的，而作为软件产品重要组成部分的软件文档，在很大程度上都得不到人们的重视，也没有相关的规范。下面，我以自身经历的一次培训经历说明软件文档管理的一些问题：
2010年，某国企研究院按照集团公司要求，实施ERP项目，包括项目管理（PS）、物料管理（MM）、财务管理（FICO）、设备管理（PM）四个模块，从4月份项目启动开始，制定了完整的计划和进度表，要求11月份系统上线与现有系统并行，并行4个月后正式独立使用。
作为研究院的IT人员与关键用户，我在项目的中后期跟项目组一起完成了培训、单元测试、集成测试、操作手册编写等工作。在这期间，我认识到软件文档的重要性，同时也发现了文档管理的相关问题。
一、 可行性研究报告不够充分
可行性研究报告，是说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理的达到开发目标可供选择的各种可能实施的方案，说明并论证所选定实施方案的理由。
然而，此项目是按照集团公司要求的“必修课”，因此，前期的相关工作做的不是充分，项目可行性分析，就照搬以前生产、销售公司的模式，忽略了一些研究院的实际情况。这样，导致了可行性报告不够深入，对项目今后实施过程的风险和可能遇到的问题考虑不够，可能会在开发过程中产生不必要的矛盾，同时产生一些抵触情绪。
二、 调研沟通程度不够，软件需求说明书与实际应用产生差异
软件需求说明书，也称软件规格说明书，其中对所开发软件的功能、性能、用户界面及运行环境等做出详细的说明。它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。
在调研阶段，项目组通过对一些关键用户的交流和邮件的问答，参照以往在生产和销售公司的实施经验，写了软件需求说明书。但是，四个模块之间缺乏有效的沟通和联系；同时关键用户大部分是使用者，而不是组织者，这样就导致了各个部门的协调性不是很好，相关规定和制度掌握程度不够。同时，生产与销售公司的业务流程与研究院的项目流程相比，在一定程度上有较大的出入。
这样完成的软件需求说明书，不是用户和开发人员双方对软件需求取得共同理解基础之上达成的协议，在今后的开发过程中，项目组发现了问题，再回过头去与用户进行沟通，更改软件需求说明书，不但增加了工作量，还影响了项目的完成时间与进度，得不偿失。
三、 各模块独立为政，沟通时间少，文档格式不一
目前为止，我国还没有一种固定的标准化文档格式，各个软件公司通常都有属于自己的标准，在项目协作完成的时候，就会产生文档格式不一的结果。同时，大的软件公司，有很多项目组，项目组之间可能也有各自的标准和喜好，导致了这一问题的出现。
在项目开发阶段，四个模块都由专门的开发人员独立负责完成，每个模块之间缺乏必要的沟通，导致了同一个模块产生文档的格式相同，而不同的模块之间就有了区别。到最后，不统一的文档格式，用户会有意见，但是，统一文档格式，又需要耗费大量的时间。因此，在项目一开始，就应该制定统一的文档模式，而不是四个模块各自为政，按照自己的标准和想法去修改相关的文档格式，增加今后的工作量。
四、 关键用户自行完成操作手册，无法达到专业水准和实际需求
操作手册，为操作人员提供该软件的各种运行情况的有关知识，特别是操作方法的具体细节。
在ERP系统开发基本完成之后，项目组对关键用户做了一次系统的培训，每个模块都有关键用户参加，我作为研究院IT人员，同时跟进了四个模块的培训。在培训期间，项目组模块负责人对常规操作、流程等进行了讲解和演示，关键用户也实际操作了整套流程，但是没有操作手册，讲解的时候关键用户能完成操作，但是轮到自己使用的时候仍然会出现很多问题，特别是SAP ERP这种界面不友好、死板的操作。
而项目组人员紧张没有人员写操作手册，因此想了一个办法：关键用户自行根据培训情况完成操作手册。美其名曰：能更好的达到培训效果。然而，各个模块的关键用户，完成培训之后，肯定不愿意自己写操作手册，纷纷借口部门工作忙，没有时间之类的托词，完成领导交代了培训了事。这个任务就一推再推，落到了IT人员的头上……最终IT人员根据培训的情况，边操作边截图，完成了软件操作手册的编写。但是，这样的操作手册，只是针对培训中提及到的常规功能，对一些深层次的功能就无法探究了，而且非专业人员完成的文档，无论从深度、格式、叙述等方面都会有所欠缺，从而影响到今后的正常使用。当发生问题时，关键用户还是得找IT人员、开发人员，无形中又增加了不必要的麻烦。
五、 测试人员紧张，深度不够，测试报告从主动测试转变成被动测试
测试分析报告，是测试工作完成以后，提交的测试计划执行情况的说明，并对测试结果加以分析，提出测试的结论意见。
关键用户与IT人员完成操作培训之后，在项目组的指导下，根据测试计划，先后进行了单元测试、集成测试等工作，并完成了测试分析报告。
由于关键用户与IT人员刚完成了操作培训，对系统的把握度还不够，能正常使用就已经达到预期效果了。这种的情况下，在项目组的指导下，进行的单元测试和集成测试，根本就不可能深入的发现存在的问题，给软件今后的正常使用埋下了隐患。测试过程中，测试计划列出的内容、进度、条件、人员、测试用例等，都是操作培训的流程，因此根本就是走一个过场，最终目的就让关键用户在测试结果出签字，实际的效果也就演变成了测试报告从主动的测试，寻找系统的BUG转变为被动的测试，在形式主义之后签字完成任务。
六、 缺乏文档管理体制
目前档案管理部门所做的工作仅仅是提供文档的组卷规则和组织项目的文档检查和验收，而没有真正从文档的生成开始实行全程的监控，缺乏真正行之有效的文档管理体制。
此ERP项目，从项目开始到结束，再到后期的维护，产生了众多的软件文档。这些软件文档在某个时期使用之后，就被抛之脑后，就算能保存下来，也是无人问津。在很多情况下，项目结束时，项目组将这些文档统一交给了某某负责人，而某某负责人可能交给某某技术人员或者让档案室存放，若无人查阅的话，几年后，这些文档可能就无人知晓了。这样会带来以下几点缺陷：1、文档只有一个版本，而往往在开发、测试过程中，文档需要不断的改动，这就使文档变动得不到体现；2、一个个独立的文档，在实际搜索、查阅的过程中非常麻烦，某个功能如果不能准确的定位到某个文档之中，会带来繁琐的搜索过程；3、文档的利用率低，文档交给特定的某些人保管，而真正需要的人却看不到文档，或者借阅文档比较繁琐，不能有效地体现出文档的作用。
因此，一套完整高效的文档管理体制显得尤为重要。可以从如下几个方面考虑文档管理的过程：1、管理文档的编号、格式、入库时间等；2、记录文档的变动情况，并保存文档的各个版本，供今后查阅；3、详细的文档目录，以供查阅；4、文档入库，使文档在线添加、删除、访问都很方便；5、分配严密的文档在线访问权限；6、提高文档存放介质的物理安全性，做好备份工作……
七、 小结
从以上六个方面的问题，可以看出我国文档工程现在还处于发展阶段，很多细节没有落实到位，没有形成相关的标准来进行约束，各个软件公司都有自己的一套行为指南，导致文档没有发挥出它的实际用处，同时也在一定程度上影响了软件的质量。
我认为，甲方对文档工程的重视程度不够，导致了乙方的“偷工减料”，是文档工程没有长足发展的根源所在。因此重视软件开发的各个阶段，完善、规范相应文档，并健全完整的文档管理体制显得尤为重要，这也应该是文档工程的发展方向。