这次，在实验室开始了新的项目，是老师接的一个项目，也算是我在实验室里面最重要的一个项目把，因为以前的项目要么自己参与了一点，很像是打酱油(但是也会有一定的收获的)，还有一些是自己私下帮同学或者某个老师做的项目，规模不大，技术含量也不是很高（但是也让我对很多东西有熟悉了很多）。另外，这个项目无论是在进度，还是技术难点上很大程度都是由我来把握的，而且，我也很希望在毕业前能够做出一个比较完善的完整的项目，所以，基于这种种原因我还是很重视这个项目的。
原来，自己上课的时候，感觉写文档啊，做需求啊，都没有什么必要的，可是，现在，我发现原来的想法真是错了，而且是大错特错。
首先，一定要明白客户的需求是什么。前一段时间从一个学长手里接了一个项目（一个ERP系统），是他帮老师做的，可是他不想做了，给了我们。可是，至今这个项目我都没有给那个老师交代呢，因为我没做完，并不是由于技术能力不够，我们现在几乎每一个模块都做完了，可是最终发现，一个整体的流程难以走下来，而且，由于需求不是我们做的，是那个老师的研究生做的，最近发现，表里面的字段差的太多了，所以，这个项目就算是死在我的手里了（还不知道怎么跟那个老师交代呢）。然而，在这里，我明白了，项目要想开始，需求必须要做，而且得做好，得完全搞清楚客户想要做什么，想要什么，否则，你做出的自己感觉再好的东西都是一个垃圾。
其次，确定客户的需求，不再改变（完全不变是不可能的，因为项目开发中唯一不变的就是客户的需求一直在变，但是，基本上得确定了）。我原来帮一个老板维护网站（用asp写的，我学的java）的时候，我们拿着自己做的东西，让那个老板看了三次他都还是说挺满意的，可是最终想要交付的时候，他却说不好，不符合他们行业的习惯，没有艺术气息（我勒个去啊），所以，又改了一次，几乎是把前台重新写了一遍。所以，确定客户的需求，是很重要的，否则，有可能出力不讨好。（因为是同学介绍，我又在学校，所以没有合同）
综上所述，汲取教训，这次这个OA系统开始前，做需求就做了好久，而且由于部门较多，现在还有几个部门的需求不太明确，不过，由于进度问题，现在先从一个部门开始做，然后，让更多的人参与进来。
然而，人多必定问题多，你不可能把需求给每个人都讲一遍，所以，这时候就需要知道文档的重要性了。需求不仅要记在脑子里，而且要写成文档----需求说明书。这样子，一来、自己不会忘记；二来、也不用天天给每个人说了，谁不知道直接看文档即可；还有第三、这个也确定了项目的目标；第四：客户审视过，也跟客户达成了一致（签过合同的）。
所以，需求说明书很重要，而且是第一位的。