项目收尾结束后要做哪些工作
一般来说，公司程序是东一块西一块的拼凑起来，程序与程序相互之间是网状的联系。项目结束了，会议总结出些问题。例如：软件如何与管理制度、管理流程、管理理念靠上边?需求如何获取?我一直认为做管理软件，不能在制度上、流程上有自己的标准，你只能被别人牵着鼻子走。
1.需求如何去细化把握?
首先需求是要以层次去划分的，最简单就是上中下即管理层的关注管理理念及方向、中间项目管理层关注的整体流程以及各个模块的之间的依赖关系，最后是操作人员的操作细节，整个过程是由上而下去细化的，管理层提出的理念基本上就是这次项目的目标，这个很重要，基本上是项目的大方向，中间层的管理流程是最复杂也是最容易出问题，一般在这方面出现的问题最多。到了操作人员基本上就是界面上的东西，就是这里应该多一个字段，那里改个什么标识的，但是不能够end user影响key user,最后把整个方向都改变了。
2.这次项目的需求一直无法落地，除来一些业务原因外，应该说在获取需求的过程中我们缺乏一些好的工具，我们的业务场景(包括正向的流程与逆向的流程)整理不够完善，这些可以测试案例一同整理，很多讨论都停留在文字的叙述方面，其实多做一些流程图、用例图、系统集成架构图会，更直观，业务员看了后更容易看清楚自己所在的位置。
3.ODS和数据仓库的方案解决网状程序间数据关系。
现在很多程序之间数据交换是用db_link来连接的，相互间的形状的网状的很混乱，ODS及DW就是把各个系统的数据都集中到数据仓库中，统一规划，一些综合性分析报表直接在DW出，减少了很多问题。
4.程序是持续优化的过程，只要系统存在，优化的需求就不会中断。但是，这种需求的修改是要按版本来规划的，绝对不能够东一个补丁西一个补丁去做，这样做程序缺乏稳定性，并且测试和考虑也不充分，风险很大。
5.一个项目做完后，要升华一些知识和方法论以及资料。简单来说是取完水要架根管子，每个项目做完会有一些测试案例、安装文档、会议记录、流程图等，这些是项目资产，不要每做一个项目，所有的东西都要从头来过，例如测试案例，只要整理一下，下一个项目还是可以继续使用的，只要把修改点加上去，节省很多时间。
