有关项目管理,欢迎大家来讨论

zilang 2004-08-28 01:04:54
我没有项目管理的经验,但作为一个程序员对于项目管理一点都不了解也是不可能;作为一个程序员,看到由于并不是客户需求更改,而是当初就没有完全了解客户的需求,告诉你,你做的模块基本不符合需求需要动大手术,或者是你做的项目拿去客户Demo的时候,客户说跟他们的需求相差很大,你会是什么感觉;而且由于分工,需求并不是由你做,所以数据库设计也不是你,但是考虑到需求分析的人不可能考虑的那么细,经常在编码的过程中增减字段,这给编码工作带来很大麻烦,不知道大家在遇到这些问题的时候怎么解决的。
我想谈些个人项目管理的方法,希望得到大家的看法,比如哪些不对
主要是针对一个全新的项目,也就是说业务逻辑方面是以前没有做过的,技术都是掌握中的一些东西,我会这么安排:
1.前期用两三个人去了解需求,半天去实际了解需求,半天将业务逻辑用visio或者rose画出来,当然这只是需求文档和客户组织机构、业务逻辑方面的文档,写好后要经过调研的部门级主管签字,主要是保证需求的正确性,和为以后的开发保留最原始的需求文档,为设计打基础
2.研究完整个业务逻辑后,就是设计数据库,我建议在设计之前先对名词进行管理,对一些专有名词一定要有注释,和英文翻译,每个人在设计模块的时候将自己遇到的新名词都加进去,以免到时候出现同一字段在不同的模块中名字相差很大,或者词不达意,最好按一种规则进行字段命名
3.写代码前,先确定开发过程的一些技术和需要达到什么功能和样式,变量命名规则、抽出公用部分,能共用的一定要共用,等等太多了我就不想说了
有人做过统计,一个项目的失败50%是因为需求没有作好,因为技术差损失的是性能,而需求差损失的是全部,30%是因为数据库设计不合理,一个先天性不合理的数据库要用前端来弥补是吃力不讨好的工作,20%是由于编码;各位的需求分析和数据库设计是怎么做的,然后我的想法有什么不合理,希望大家都说说自己的经验,以上只是我个人作为一个程序员的一些想法,望指教。
...全文
291 15 点赞 打赏 收藏 举报
写回复
15 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
yanwei100 2004-09-29
需求和设计的变动是不可避免的,随然有各种方法控制需求变化,如前面很多人说到的原形法.但也只能做到把需求的变化幅度减小一些,变化的次数较少一些.用户在需求上出尔反尔的事情还是会不断发生的.传统的瀑布模型的软件开发过程在实际的工作中几乎是不存在的,除非需求就是你自己来定.既然变化不可避免,开发人员就要从心态上做一个转变,不是拒绝变化,而是拥抱变化.
当然,并不是说需求变化就不要控制了,XP,RUP这些软件工程的方法都是有用的,应该学习并加以实践的。而且需求和设计的基本功也要扎实,如怎样做需求分析,怎样做设计。这些已经超出这个帖子所能覆盖的了。
  • 打赏
  • 举报
回复
jinhongze 2004-09-21
除了一些科学的方法外,还需要分析人员的严谨作风,逻辑分析能力和抽象能力,这些都需要培养
而理解能力和表达能力更需要锻炼!总之,做一个好的需求分析员是很不容易的。
  • 打赏
  • 举报
回复
liunathan 2004-09-18
看看http://www.01591.com
  • 打赏
  • 举报
回复
hnsoso 2004-09-16
我也同意先做demo,给客户看,看后再改,客户再看....,差不多了,再开发!
如果是WEB,那DEMO就直接用静态页面做就行了
  • 打赏
  • 举报
回复
pc01 2004-09-16
我觉得应做好前期的规划和分析。
首先我们将拿到用户方(或其它部门)提出的原始需求,这时我们就要根据这些需求以及我们对业务处理的了解(不管是对还是不对)往下走,在往下走的过程中肯定会遇到好多走不下去的地方,或出现一些假设。这时对这些问题就应该及时和用户方进行交流,当获得新的需求后又如此反复,当处理流程已走的很顺了的时候才可以进入分析设计了。
  • 打赏
  • 举报
回复
lw1103 2004-09-15
比较同意张伟的见解。在正式编码前最好做一个DEMO,既给客户一个粗框架,也检验开发团队的开发能力。
  • 打赏
  • 举报
回复
火电 2004-09-15

现在的客户很是不好应付,所以就得采用敏捷软件的开发模式

先整理前期需求,做好原型给用户演示,看看是否符合标准,那个时候的程序可以是个空架子,

里面不用写什么重要的,详细的代码,如果用户满意了,敲定了在大规模的进行开发

要不就是浪费人力物力阿

如果不满意,将修改整理后再作出原型和大致的实现方式,给用户再看,通过交互直到他们通过

那个时候就是开发的事情了

总之,要不断的适应用户的需求变动,
建议写一些面向对象的公用函数\类
可以减少一些工作量和开发周期
  • 打赏
  • 举报
回复
silent1 2004-09-03
最简单就是把最后的软件拿文字、图形、图像画出来。
  • 打赏
  • 举报
回复
pllli 2004-08-30
我做了一年多的项目,感觉最重要的就是需求,对于需求的正确与否直接影响到了你的项目是否合老板的“胃口”。但是最麻烦的事就是当你当初和老板拍板了,他认可了的需求,最后常常做出的东西(说文明一点)是他意想不到的,呵呵……汗ing,为什么会这样,还是缺乏了必要沟通,在国外或者大型的软件企业,需求并不是由程序开发人员直接去做的,而是专门的一批系统设计人员+实施顾问去和老板打交道拿来的,他们比程序开发人员更好的去和老板沟通,将老板的想法变成需求文档和概要设计,然后再由程序开发人员去实现。
  • 打赏
  • 举报
回复
Shires 2004-08-30
up
  • 打赏
  • 举报
回复
yelang771 2004-08-30
up
  • 打赏
  • 举报
回复
zilang 2004-08-30
具体的用什么方式来描述用户的需求让大家都知道,毕竟前期做需求的人比较少,还有涉及到资料的保存不能总是放在需求人员的记忆里,就是用一种什么好的方法来精确定义现在客户的需求
  • 打赏
  • 举报
回复
silent1 2004-08-30
需求需要不断地和客户进行沟通,把自己的理解说给客户,得到顾客的确认。
想得比客户更多,客户可能不专业,提出来的需求不完整,这就需要对顾客的需求进行分析,挖掘出其他的需求。
需要考虑到顾客将来的需求,保证现在的系统不会不能适应将来的变化。
  • 打赏
  • 举报
回复
相关推荐
发帖
研发管理
创建于2007-08-27

1221

社区成员

软件工程/管理 管理版
申请成为版主
帖子事件
创建了帖子
2004-08-28 01:04
社区公告
暂无公告