项目结束后总结--

xiangzhao

项目结束了，会议总结出些问题。例如：需求如何获取，软件如何与管理制度、管理流程、管理理念靠上边，我一直认为做管理软件你不能在制度上、流程上有自己的标

准，你只能被别人牵着鼻子走。在原来的一家公司就是这样，程序是东一块西一块的拼凑起来，程序与程序相互之间是网状的联系，我一直提议要从大的方向去计划这些系统，奈

何位低人言轻，别人的理念跟你不一样，你也没办法。      
       第一点：需求如何去细化把握，首先需求是要以层次去划分的，最简单就是上中下即管理层的关注管理理念及方向

、中间管理层关注的整体流程以及各个模块的之间的依赖关系，最后是操作人员的操作细节，整个过程是由上而下去细化的，管理层提出的理念基本上就是这次项目的目标，这个

很重要，基本上是项目的大的方向，中间层的管理流程是最复杂也是最容易出问题，一般在这方面出现的问题最多。到了操作人员基本上就是界面上的东西，就是这里应该多一个

字段，那里改个什么标识的，但是不能够end user 影响key user,最后把整个方向都改变了。

        第二点：一个项目做完后，要升华一些知识和方法论以及资料，简单来说是取完水要架根管子，每个项目做完会有一些测试案例、安装文档、会议记录、流程图等，这些

是项目资产，不要每做一个项目，所有的东西都要从头来过，例如测试案例，只要整理一下，下一个项目还是可以继续使用的，只要把修改点加上去，节省很多时间。

        第三点：这次项目的需求一直无法落地，除来一些业务原因外，应该说在获取需求的过程中我们缺乏一些好的工具，我们的业务场景（包括正向的流程与逆向的流程）整

理不够完善，这些可以测试案例一同整理，很多讨论都停留在文字的叙述方面，其实多做一些流程图、用例图、系统集成架构图会，更直观，业务员看了后更容易看清楚自己所在

的位置。

        第四点：ODS和数据仓库的方案解决网状程序间数据关系。现在很多程序之间数据交换是用db_link来连接的，相互间的形状的网状的很混乱，ODS及DW就是把各个系统的数

据都集中到数据仓库中，统一规划，一些综合性分析报表直接在DW出，减少了很多问题。

        第五点：程序是持续优化的过程，只要系统存在，优化的需求就不会中断，但是，这种需求的修改是要按版本来规划的，绝对不能够东一个补丁西一个补丁去做，这样做

程序缺乏稳定性，并且测试和考虑也不充分，风险很大。

Scott.Pan

写的很实在，确实是这样，总结和积累很有必要，不过业务经验性的东西基本只能做参考，像文档等一些资料那要是借鉴起来会节省不少时间。希望楼主能加精该帖！THS

jiuyingzi

新来的，学习下

enjoylifedass

刚做完一下，为了赶时间点，做的很累：（，说说自己的感受吧
1.明确项目主导人或发起人的项目目标，并且在项目的整个过程中反复的强调，并且一定要和项目的执行人（项目经理）达成一致。
2.一定要按里程碑节点去推动项目的进程，一鼓作气，再而衰，三而竭，要给整个参与项目的人一个信心
3.关键用户，也就是具体做业务的骨干必须投入精力，不然在上线前的测试中肯定会存在不少的偏差，而导致抵触的情绪
4.刚上线的半年到一年，企业要持续的投入，不管是人力还是物力，还是公司的政策，上线时开始，而这半年到一年是一个考验期，只要这段时间处理的好，那么基本上系统的操作就会变成业务人员的习惯了，而这时才能发挥出系统的优势。

sulker

楼主太无私了

环境美

楼主太无私了

radium

留个标记