软件工程当中的文档化是整个工程脱离强耦合人员进入标准化的过程，在没有文档化的时候，项目是严重依赖于人员的，文档化之后项目才会走入正轨，进入铁打的营盘流水的兵。整个软件工程当中，有许多文档需要记录，例如需求文档，详细需求文档，设计文档，详细设计文档，测试用例文档等等。整个项目业务在转化成实际代码过程中最需要注意的是需求当代码的过程，这个过程也是项目工期的主要时间窗口。现在的文档化基本上都有一些模板使用，大体上主要改一下就好了。最近我看书过程中遇到了一些问题，例如真个项目的某个部分经历了很多人，很多是超过6人，以致于最后接手的人根本不知道开发了半截的代码到底是什么，业务需求是什么，这种快速的人员更迭的情况下，怎么去保证项目的一致性？
第一个原因是人的问题。每一具体的项目都需要人去执行的，每一个制度和任务也是需要人去执行的。没有制度或者是要求标准的时候，大家基本上做的五花八门。如果有制度或者要求标准就会好很多，可是已经到具体职位的任务时，这个就非常难以确定了。一方面是执行标准一定有些弹性的地方，一方面是执行人可能没有相关方面的培训，总之文档及时更新或者记录变更便成为了一种从上到下的任务。有没有想过，如果有足够的文档或者最新的项目情况，这种条件下会对项目的维护效率提升多少？
第二个原因是需要有足够的软件工程知识，对文档化有足够的认识和了解，这样可以设计或者规划出良好的文档设计和更新的标准。这些标准必须满足可以让不懂得这些工程知识的人可以进行容易地编制、容易地更新、容易地使用。编制标准的人不仅仅要懂软件工程，还要考虑在具体执行这些情况下的人的心理等等这些要素。我想能做出这些标准的人一定非常的牛。
第三个原因项目工程这种团体性工作的情况的主旨应该是“我为人人，人人为我”，在整个项目的情况下，每个任务都是保证整体利益最大化的，但是对局部可能就不是这样的。我们工作过程中站在更高层次看待问题总是容易解决现有问题的。系统论在解决问题的时候就是先在小系统中解决，出现解决不了的问题就将系统的层级提升到高一层。项目中也是一样的。
这是关于项目规范化部分的一些思考，不喜欢软件工程的可以放过。