| 作者 |
内容 |
| freeman770 |
 项目已经开发了近一年了，需求还没签字怎么办
当时客户很急，所以我们就快速上马！可到现在需求还没签字，而且经常加新需求，变更以前的需求。合同的范围又太模糊 |
| 02/04/01 10:29 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| freeman770 |
 大家为我指点一条路吧，
五个人一直在干活，这样下去我看再过一年也做不完 |
| 02/04/01 10:35 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| heyongbin |
 当机立断进行需求管理，否则后果比你想象的还坏
|
| 02/04/01 11:25 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 自己的问题！
需求变更是常有的事，所以你应该用平常心去接受它。
现在主要的问题是，你的项目范围是否能确定下来，把项目范围确定下来之后，在这个范围你变的需求应该还是比较好应付的，当然这跟你的设计有直接的关系，如果设计的不好，那么谁也救不了你。
我想你现在应该做的主要有下面几件事：
1、把项目范围先真正的确定下来
2、区分那些是经常变动的部分，那些是比较稳定的部分。如：商店中销售行为一般是稳定的，但销售信息、商品信息可能会经常发生改变等等。在建立模型时要注意区分。
3、是否能把经常变动的部分通过适当的接口封装起来，注意系统体系设计。如：销售信息、商品信息可以通过entitybean封装起来。增加的一些功能、流程信息可以通过一些模式，如facade等，建立一些控制类，把所有相关的流程、功能通过控制类进行分发，这样变化的时候你只要调整控制类就可以了，等等。
所以，最重要的还是你的管理和设计。把需求管理好，进行良好的设计。 |
| 02/04/01 16:08 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
 管理只是一个侧面哟！
|
| 02/04/01 16:35 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| uml_fan |
这可真是犯了一大忌!需求是一个项目的灵魂，魂魄不定，项目安有宁日乎？
|
| 02/04/01 17:09 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| 风雪漫天 |
有道理，给朵花
有一个问题，还在需求阶段就想到设计如何如何实现，用什么样的设计模式，这是不是犯了大忌？ |
| 02/04/02 09:05 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| xue_zhong |
最好不要这样做！
我刚在“如何在Rose中管理各分析阶段的use case? ”做了一下解释，基本意思差不多，从business到system的分析过程是相当重要的，最好不要跳过。 |
| 02/04/02 09:25 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| smitha |
回复:
项目已经开发了近一年了，需求还没签字怎么办
需求签字了又有何用？到时候客户说改你还得改，老板在乎地是钱，只要有钱赚，在海外需要一年地项目他一个月地期限也感拿，到时候受苦地是技术人员，
你说这样地项目质量能好到哪里去？需求签不签字有啥意义，我们终验了还大量改需求地项目不是一个两个，感觉中国地客户是霸道地爷，老板是媚膝地鸡婆，程序员是受苦地妓。说什么两年赶超印度，唉。。。。。。 |
| 02/04/02 09:35 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| jjman |
 回复:
项目已经开发了近一年了，需求还没签字怎么办
现在主要关心接下来如何做的问题 |
| 02/04/02 11:06 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| smitha |
回复:
项目已经开发了近一年了，需求还没签字怎么办
弄清楚客户地要求是否在本项目范畴之内，还是是本项目地扩展，如，很多mis系统我们在需求完成后进行设计开发阶段用户提出一些新的需求，有的是我们没有考虑周全的地方，有的是属于决策支持与数据挖掘，前者是系统构架不够完善，灵活度不高，若不是急功近利的话，可再次对系统构架进行新的认识，这大概就是rup中提到的对系统进行在认识，进行优化，如何项目潜力大，考虑新的构架与技术；若是后者则让老板与客户清楚这是系统的延伸或再期工程，本系统坚决不予实现，如果本着对客户负责的态度，则应在构造上要有所考虑。所以出现了你所说的情况，要冷静分析，也许这正是你系统再上一个台阶的锲机。 |
| 02/04/02 11:57 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| fqnewman |
你小子不适合做生意，先要别人把钱定下来再问人家要多少货，你至少也先和他约定一个大概的范围嘛，在这个框架内随便他怎么变，钱要定下来，数量要定下来....,至于货刷什么颜色，好说
|
| 02/04/02 12:29 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| gzsamlee |
 回复:
项目已经开发了近一年了，需求还没签字怎么办
一个典型的没有项目管理概念的例子。 |
| 02/04/02 15:27 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| bomb_hero |
 酷！！当务之急是想出解决方法，而不是检讨以前错在哪里。
酷哥！ |
| 02/04/02 16:09 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| bomb_hero |
 回复:
大家为我指点一条路吧，
当客户提出一个需求时，你提出N反对意见说明这项需求的不合理的地方。
或者把客户提出的需求写在纸上，注明由这项需求带来的负面影响由他负责并让他签字。
这个方法不是最后的解决方法，但可以让客户提要求时理性一点，不是拍拍脑袋就想出来。最好能让他把需求签了。 |
| 02/04/02 16:18 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| hhhxxx |
频繁的版本发布
在很多时候，需求都是模糊而且易变的。客户有没有能力在动手开发之前提出完整、正确而且具有足够细节的需求，这个问题存在很大的疑问。开发商要求客户在开发之前确认需求，把所有这个巨大的责任推卸给客户，我认为不是一种好的做法。当然，需求的范围还是有必要确认的。
那么在项目过程中，我们如何获取模糊的需求，不断满足变化的需求呢？一个比较可行的方法是提高开发商的生产力，尽可能快速地进行版本发布，通过产品和客户沟通，并获得反馈。高效的生产力是每个开发商梦寐以求的，但只有很少数的公司能够做得到。我想对于一个小型的开发队伍，xp方法应该可以提高他们的效率。 |
| 02/04/03 10:07 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| jjman |
 客户到了这个阶段甚至想去外面参观以后回来再提需求
惨了!
对了是不是该做做全面思想工作(从领导到业务人员),说明一下需求的重要性. |
| 02/04/03 21:05 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
