项目结束后总结--

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

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

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

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

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

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

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

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

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

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

的位置。

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

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

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

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

有什么认识问题，不对的大家提出来

very good

多做总结多分享啊
感谢ING

我感觉项目管理好，一方面要靠制度，另外还是要靠项目经理

很好的总结，受精！
加入项目管理圈子吧 [url]http://space.itpub.net/mygroup-77[/url]

这次项目的需求一直无法落地
->
需求没有落地会直接影响中后期的开发和维护，项目如何验收了？

好






__________________________________________
项目管理专家 免费的项目管理系统 据易网络（[url]www.jvyee.com[/url]）

初入项目管理
值得学习啊
感谢达人们

呵呵，楼主也是做数据仓库的啊

好文章！

写得很有深度，向楼主学习！

[quote]原帖由 [i]husthxd[/i] 于 2008-6-4 09:38 发表 [url=http://www.itpub.net/redirect.php?goto=findpost&pid=10566131&ptid=993236][img]http://www.itpub.net/images/common/back.gif[/img][/url]
这次项目的需求一直无法落地
->
需求没有落地会直接影响中后期的开发和维护，项目如何验收了？ [/quote]


有时是大家满意就可以了

“我一直认为做管理软件你不能在制度上、流程上有自己的标

准，你只能被别人牵着鼻子走”，这绝对是必须的，只要理念好，客户很乖的，这个时候你只要让他自己跳就行，而你做的可能是让他觉得这都是他提出来的就好！

好文章！往往项目总结会都没有考虑过这么仔细

Good Job

非常感谢楼主的分亨。很受用

挺好