ITPUB论坛-中国专业的IT技术社区

 找回密码
 注册
查看: 10759|回复: 32

讨论:如何彻底解决需求变化大的问题

[复制链接]
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2009-8-31 20:15 | 显示全部楼层 |阅读模式
过去十多年来,我一直听到人们抱怨一个问题:需求变化大。的确,需求变化大是个老、大、难问题。如何解决这个信息化/系统集成/软件工程的头号难题,值得我们认真深入地进行研讨。当今的软件工程已经超成熟了。解决需求变化大、变化多的难题,其实已经有很多成熟的技术和管理手段可以综合运用。从开发商的需求技术技能角度,应该尽可能地提高需求分析的精度和深度,比客户看得更多、更远。

20 年前诞生于复杂电信软件开发领域的 Use Case(用例)方法是解决需求变化大难题的一项重要技术。简单地说,用例就是利用自然语言用写计算机程序(包括前态、后态、基本流、异常等)的方式来写软件需求,它的最大一个优点就是能够用结构化的文本模板系统、规范地帮助我们挖掘出许多采用其它方法很难发现的隐蔽、复杂需求(扩展流、扩展条件等),从而可以有效地规避需求风险。推广和传播基于用例的统一需求分析和管理技术也是我过去十年来做的一件主要工作。

待续 ...

解决 IT/软件项目需求变化大的难题,不知大家有什么好建议和好办法?

[ 本帖最后由 张恂 于 2009-8-31 20:31 编辑 ]
论坛徽章:
1019
布鲁克
日期:2016-06-25 12:51:02山治
日期:2016-07-02 08:56:29托尼托尼·乔巴
日期:2016-10-05 19:12:50妮可·罗宾
日期:2016-10-06 18:31:042017金鸡报晓
日期:2017-01-10 15:39:05弗兰奇
日期:2017-03-16 20:59:33布鲁克
日期:2017-06-15 19:19:45乌索普
日期:2017-06-15 19:19:45托尼托尼·乔巴
日期:2017-06-15 19:19:45山治
日期:2017-06-15 19:19:45
发表于 2009-8-31 20:36 | 显示全部楼层
学习。

使用道具 举报

回复
论坛徽章:
0
发表于 2009-9-1 09:05 | 显示全部楼层
尽可能正确的需求分析是基础,
1.通过需求评审对需求大方向进行确定,对相关责任人签责任书及需求确认书。
2.商务上需保证,对重大需求变更,需增加相应的合同金额,可按具体需求变更进行人月等估算,以便统计工作量。
这个只能对项目利润率有个基本的保证,但项目期限 等,题目就太大了。。。。

自己的一些理解,跟大家学习了

使用道具 举报

回复
论坛徽章:
0
发表于 2009-9-1 10:21 | 显示全部楼层
我觉得不是需求变化大的问题

根本是需求没有弄清楚

[ 本帖最后由 pmp_sean_huang 于 2009-9-1 10:29 编辑 ]

使用道具 举报

回复
论坛徽章:
16
设计板块每日发贴之星
日期:2009-06-25 01:01:022014年新春福章
日期:2014-02-18 16:41:112012新春纪念徽章
日期:2012-01-04 11:50:44ITPUB十周年纪念徽章
日期:2011-11-01 16:20:282011新春纪念徽章
日期:2011-02-18 11:43:33生肖徽章2007版:兔
日期:2011-01-20 12:58:492011新春纪念徽章
日期:2011-01-04 10:37:102010广州亚运会纪念徽章:棒球
日期:2011-01-03 14:32:202010广州亚运会纪念徽章:游泳
日期:2010-12-06 10:49:53设计板块每日发贴之星
日期:2010-05-27 01:01:02
发表于 2009-9-1 16:52 | 显示全部楼层
原帖由 pmp_sean_huang 于 2009-9-1 10:21 发表
我觉得不是需求变化大的问题

根本是需求没有弄清楚


部分同意,呵呵
我所经手的项目,导致需求变化大的首要原因就是需求获取不全面,分析不到位。
个人认为,要保证如下方面,才能尽可能的了解用户需求:
1、识别项目干系人
很多时候,由于没能识别出来干系人,导致系统到了试运行阶段时,遇到强烈的阻力,干系人以我并没有确认你的需求结果而拒绝使用。
2、用例图和原型法结合来确认需求是否符合用户的真实意愿
我有个项目就是没有使用原型法,只有文字和用例图来描述,结果发现其实双方理解上有很大偏差,但是当时却没能体现出来。
3、干系人共同评审,而不是单独确认
有时候,干系人的需求是相冲突的,如果不是在一起共同评审,总会有一方不能接受你的方案。

之所以部分同意是因为用户的变更很大程度是想简化自己的操作,而不是原方案影响业务的日常运行。这个很令人烦恼,用户总是提出各种各样的要求来方便自己的操作,恨不能只按一个键就完成所有操作,所有的变更要求都沦为一种工具了。

[ 本帖最后由 susan_huangyong 于 2009-9-2 11:07 编辑 ]

使用道具 举报

回复
论坛徽章:
57
秀才
日期:2017-08-18 11:06:452012新春纪念徽章
日期:2012-01-04 11:50:44ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152011新春纪念徽章
日期:2011-02-18 11:43:33ITPUB9周年纪念徽章
日期:2010-10-08 09:28:532010新春纪念徽章
日期:2010-03-01 11:06:132010年世界杯参赛球队:朝鲜
日期:2010-02-22 16:02:522010年世界杯参赛球队:荷兰
日期:2010-02-22 12:53:212010年世界杯参赛球队:瑞士
日期:2010-01-21 17:04:522010年世界杯参赛球队:法国
日期:2010-01-21 12:44:59
发表于 2009-9-2 16:54 | 显示全部楼层
敏捷方式開發,擁抱變化。

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-9-2 20:01 | 显示全部楼层
原帖由 XJ6875 于 2009-9-1 09:05 发表

尽可能正确的需求分析是基础,

1.通过需求评审对需求大方向进行确定,对相关责任人签责任书及需求确认书。

2.商务上需保证,对重大需求变更,需增加相应的合同金额,可按具体需求变更进行人月等估算,以便统计工作量。

这个只能对项目利润率有个基本的保证,但项目期限 等,题目就太大了。。。。

自己的一些理解,跟大家学习了



不错!这几点都管用。当然,最好和迭代结合起来,避免瀑布式。

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-9-2 20:06 | 显示全部楼层
原帖由 susan_huangyong 于 2009-9-1 16:52 发表

我所经手的项目,导致需求变化大的首要原因就是需求获取不全面,分析不到位。

个人认为,要保证如下方面,才能尽可能的了解用户需求:

1、识别项目干系人

很多时候,由于没能识别出来干系人,导致系统到了试运行阶段时,遇到强烈的阻力,干系人以我并没有确认你的需求结果而拒绝使用。

2、用例图和原型法结合来确认需求是否符合用户的真实意愿

我有个项目就是没有使用原型法,只有文字和用例图来描述,结果发现其实双方理解上有很大偏差,但是当时却没能体现出来。


Very good! 都是非常实在的教训和经验啊

如果采用敏捷迭代开发,1-3 的问题就全部解决了。

AID 相当于非抛弃的原型法。

预先全面的分析很重要,用户的及时验证和反馈也很重要。


3、干系人共同评审,而不是单独确认

有时候,干系人的需求是相冲突的,如果不是在一起共同评审,总会有一方不能接受你的方案


即 review meeting

之所以部分同意是因为用户的变更很大程度是想简化自己的操作,而不是原方案影响业务的日常运行。这个很令人烦恼,用户总是提出各种各样的要求来方便自己的操作,恨不能只按一个键就完成所有操作,所有的变更要求都沦为一种工具了。


这点要求很正当,你们 IT 部门好像没有理由拒绝。

[ 本帖最后由 张恂 于 2009-9-2 20:23 编辑 ]

使用道具 举报

回复
论坛徽章:
62
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:522012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
 楼主| 发表于 2009-9-2 20:28 | 显示全部楼层
原帖由 pmp_sean_huang 于 2009-9-1 10:21 发表

我觉得不是需求变化大的问题

根本是需求没有弄清楚



使用道具 举报

回复
论坛徽章:
16
设计板块每日发贴之星
日期:2009-06-25 01:01:022014年新春福章
日期:2014-02-18 16:41:112012新春纪念徽章
日期:2012-01-04 11:50:44ITPUB十周年纪念徽章
日期:2011-11-01 16:20:282011新春纪念徽章
日期:2011-02-18 11:43:33生肖徽章2007版:兔
日期:2011-01-20 12:58:492011新春纪念徽章
日期:2011-01-04 10:37:102010广州亚运会纪念徽章:棒球
日期:2011-01-03 14:32:202010广州亚运会纪念徽章:游泳
日期:2010-12-06 10:49:53设计板块每日发贴之星
日期:2010-05-27 01:01:02
发表于 2009-9-2 22:06 | 显示全部楼层
原帖由 张恂 于 2009-9-2 20:06 发表

这点要求很正当,你们 IT 部门好像没有理由拒绝。


张老师,这点我有不同意见哦

对于产品化的软件,用户一再的提出变更,可能只是为了比另一个报表多了个字段的报表,这完全可以将数据导出来然后自己再加工啊,用户只为了图自己的方便,不但不利于产品日后的升级,而且是一个无底洞,永远没有停止的时候。

对于定制开发的软件,如果仅为简化操作,对业务流程没有任何优化或效率的提高的话,我一般是拒绝的,呵呵

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表