1,265
社区成员
发帖
与我相关
我的任务
分享有关项目管理，欢迎大家来讨论
我没有项目管理的经验，但作为一个程序员对于项目管理一点都不了解也是不可能；作为一个程序员，看到由于并不是客户需求更改，而是当初就没有完全了解客户的需求，告诉你，你做的模块基本不符合需求需要动大手术，或者是你做的项目拿去客户Demo的时候，客户说跟他们的需求相差很大，你会是什么感觉；而且由于分工，需求并不是由你做，所以数据库设计也不是你，但是考虑到需求分析的人不可能考虑的那么细，经常在编码的过程中增减字段，这给编码工作带来很大麻烦，不知道大家在遇到这些问题的时候怎么解决的。
我想谈些个人项目管理的方法，希望得到大家的看法，比如哪些不对
主要是针对一个全新的项目，也就是说业务逻辑方面是以前没有做过的，技术都是掌握中的一些东西，我会这么安排：
1.前期用两三个人去了解需求，半天去实际了解需求，半天将业务逻辑用visio或者rose画出来，当然这只是需求文档和客户组织机构、业务逻辑方面的文档，写好后要经过调研的部门级主管签字，主要是保证需求的正确性，和为以后的开发保留最原始的需求文档，为设计打基础
2.研究完整个业务逻辑后，就是设计数据库，我建议在设计之前先对名词进行管理，对一些专有名词一定要有注释，和英文翻译，每个人在设计模块的时候将自己遇到的新名词都加进去，以免到时候出现同一字段在不同的模块中名字相差很大，或者词不达意，最好按一种规则进行字段命名
3.写代码前，先确定开发过程的一些技术和需要达到什么功能和样式，变量命名规则、抽出公用部分，能共用的一定要共用，等等太多了我就不想说了
有人做过统计，一个项目的失败50%是因为需求没有作好，因为技术差损失的是性能，而需求差损失的是全部，30%是因为数据库设计不合理，一个先天性不合理的数据库要用前端来弥补是吃力不讨好的工作，20%是由于编码；各位的需求分析和数据库设计是怎么做的，然后我的想法有什么不合理，希望大家都说说自己的经验，以上只是我个人作为一个程序员的一些想法，望指教。
我想谈些个人项目管理的方法，希望得到大家的看法，比如哪些不对
主要是针对一个全新的项目，也就是说业务逻辑方面是以前没有做过的，技术都是掌握中的一些东西，我会这么安排：
1.前期用两三个人去了解需求，半天去实际了解需求，半天将业务逻辑用visio或者rose画出来，当然这只是需求文档和客户组织机构、业务逻辑方面的文档，写好后要经过调研的部门级主管签字，主要是保证需求的正确性，和为以后的开发保留最原始的需求文档，为设计打基础
2.研究完整个业务逻辑后，就是设计数据库，我建议在设计之前先对名词进行管理，对一些专有名词一定要有注释，和英文翻译，每个人在设计模块的时候将自己遇到的新名词都加进去，以免到时候出现同一字段在不同的模块中名字相差很大，或者词不达意，最好按一种规则进行字段命名
3.写代码前，先确定开发过程的一些技术和需要达到什么功能和样式，变量命名规则、抽出公用部分，能共用的一定要共用，等等太多了我就不想说了
有人做过统计，一个项目的失败50%是因为需求没有作好，因为技术差损失的是性能，而需求差损失的是全部，30%是因为数据库设计不合理，一个先天性不合理的数据库要用前端来弥补是吃力不讨好的工作，20%是由于编码；各位的需求分析和数据库设计是怎么做的，然后我的想法有什么不合理，希望大家都说说自己的经验，以上只是我个人作为一个程序员的一些想法，望指教。
...全文
请发表友善的回复…
发表回复
yanwei100 2004-09-29
- 打赏
- 举报
需求和设计的变动是不可避免的,随然有各种方法控制需求变化,如前面很多人说到的原形法.但也只能做到把需求的变化幅度减小一些,变化的次数较少一些.用户在需求上出尔反尔的事情还是会不断发生的.传统的瀑布模型的软件开发过程在实际的工作中几乎是不存在的,除非需求就是你自己来定.既然变化不可避免,开发人员就要从心态上做一个转变,不是拒绝变化,而是拥抱变化.
当然,并不是说需求变化就不要控制了,XP，RUP这些软件工程的方法都是有用的，应该学习并加以实践的。而且需求和设计的基本功也要扎实，如怎样做需求分析，怎样做设计。这些已经超出这个帖子所能覆盖的了。
当然,并不是说需求变化就不要控制了,XP，RUP这些软件工程的方法都是有用的，应该学习并加以实践的。而且需求和设计的基本功也要扎实，如怎样做需求分析，怎样做设计。这些已经超出这个帖子所能覆盖的了。
jinhongze 2004-09-21
- 打赏
- 举报
除了一些科学的方法外，还需要分析人员的严谨作风，逻辑分析能力和抽象能力，这些都需要培养
而理解能力和表达能力更需要锻炼！总之，做一个好的需求分析员是很不容易的。
而理解能力和表达能力更需要锻炼！总之，做一个好的需求分析员是很不容易的。
liunathan 2004-09-18
- 打赏
- 举报
看看http://www.01591.com
hnsoso 2004-09-16
- 打赏
- 举报
我也同意先做demo,给客户看,看后再改,客户再看....,差不多了,再开发!
如果是WEB,那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
- 打赏
- 举报
需求需要不断地和客户进行沟通，把自己的理解说给客户，得到顾客的确认。
想得比客户更多，客户可能不专业，提出来的需求不完整，这就需要对顾客的需求进行分析，挖掘出其他的需求。
需要考虑到顾客将来的需求，保证现在的系统不会不能适应将来的变化。
想得比客户更多，客户可能不专业，提出来的需求不完整，这就需要对顾客的需求进行分析，挖掘出其他的需求。
需要考虑到顾客将来的需求，保证现在的系统不会不能适应将来的变化。
