论坛首页 综合技术论坛

什么样的项目算是大项目?

浏览 18164 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2006-12-07  
大项目的衡量标准要看客户的需求情况,端到端的业务流程的数量,业务的复杂程度。需求的范围扩大到一定程度后,业务流程和数据本身就要划分成多个域。这样的系统就不再是企业中独立的岛屿,而是关系到多个部门,多个行业。用户范围上至公司的CEO,下至最基层的业务人员。
此外还有用户的接触要求,安全性要求。
简单的讲,有个需求规格说明书,说明书上面记录了功能性和非功能性的需求,这个说明书的厚度标志了项目的大小。
0 请登录后投票
   发表时间:2006-12-07  
项目大小是相对的,看客户,看软件公司,有时候说大就大,说小就小.举个例子:
比如我们现在客户做的最大的一个项目,软件费1800万美元,包括咨询,开发,实施等,开发周期>3年
本来法国一家公司中标的,做了一年半,没做好,谈崩了
现在重新给IBM做.
在这过程中,这个项目中最大最复杂的一部份,作为独立项目给我们公司做,估计工作量至少占整个项目的 1/5
结果只给200万RMB

1800万美金算个超级大项目了
200万RMB * 5 = 1000万RMB只能算个大项目
可做的还是一回事~~

0 请登录后投票
   发表时间:2006-12-07  
kent 写道
项目大小是相对的,看客户,看软件公司,有时候说大就大,说小就小.举个例子:
比如我们现在客户做的最大的一个项目,软件费1800万美元,包括咨询,开发,实施等,开发周期>3年
本来法国一家公司中标的,做了一年半,没做好,谈崩了
现在重新给IBM做.
在这过程中,这个项目中最大最复杂的一部份,作为独立项目给我们公司做,估计工作量至少占整个项目的 1/5
结果只给200万RMB

1800万美金算个超级大项目了
200万RMB * 5 = 1000万RMB只能算个大项目
可做的还是一回事~~



所以说项目规模是不是应该按照项目本身的复杂度来衡量比较准确些呢,从金额来衡量并不准确。

0 请登录后投票
   发表时间:2006-12-07  
robbin 写道
kent 写道
项目大小是相对的,看客户,看软件公司,有时候说大就大,说小就小.举个例子:
比如我们现在客户做的最大的一个项目,软件费1800万美元,包括咨询,开发,实施等,开发周期>3年
本来法国一家公司中标的,做了一年半,没做好,谈崩了
现在重新给IBM做.
在这过程中,这个项目中最大最复杂的一部份,作为独立项目给我们公司做,估计工作量至少占整个项目的 1/5
结果只给200万RMB

1800万美金算个超级大项目了
200万RMB * 5 = 1000万RMB只能算个大项目
可做的还是一回事~~



所以说项目规模是不是应该按照项目本身的复杂度来衡量比较准确些呢,从金额来衡量并不准确。

像下面这位说的....
lane_cn 写道
大项目的衡量标准要看客户的需求情况,端到端的业务流程的数量,业务的复杂程度。需求的范围扩大到一定程度后,业务流程和数据本身就要划分成多个域。这样的系统就不再是企业中独立的岛屿,而是关系到多个部门,多个行业。用户范围上至公司的CEO,下至最基层的业务人员。
此外还有用户的接触要求,安全性要求。
简单的讲,有个需求规格说明书,说明书上面记录了功能性和非功能性的需求,这个说明书的厚度标志了项目的大小。

说明书厚度真的可以用作一个项目的大小的标帜
一个大项目没有足够的说明书一样是拉不到客户的
而一个小项目说明书太厚浪费的人力成本也是惊人的....
0 请登录后投票
   发表时间:2006-12-07  
抛出异常的爱 写道
robbin 写道
kent 写道
项目大小是相对的,看客户,看软件公司,有时候说大就大,说小就小.举个例子:
比如我们现在客户做的最大的一个项目,软件费1800万美元,包括咨询,开发,实施等,开发周期>3年
本来法国一家公司中标的,做了一年半,没做好,谈崩了
现在重新给IBM做.
在这过程中,这个项目中最大最复杂的一部份,作为独立项目给我们公司做,估计工作量至少占整个项目的 1/5
结果只给200万RMB

1800万美金算个超级大项目了
200万RMB * 5 = 1000万RMB只能算个大项目
可做的还是一回事~~



所以说项目规模是不是应该按照项目本身的复杂度来衡量比较准确些呢,从金额来衡量并不准确。

像下面这位说的....
lane_cn 写道
大项目的衡量标准要看客户的需求情况,端到端的业务流程的数量,业务的复杂程度。需求的范围扩大到一定程度后,业务流程和数据本身就要划分成多个域。这样的系统就不再是企业中独立的岛屿,而是关系到多个部门,多个行业。用户范围上至公司的CEO,下至最基层的业务人员。
此外还有用户的接触要求,安全性要求。
简单的讲,有个需求规格说明书,说明书上面记录了功能性和非功能性的需求,这个说明书的厚度标志了项目的大小。

说明书厚度真的可以用作一个项目的大小的标帜
一个大项目没有足够的说明书一样是拉不到客户的
而一个小项目说明书太厚浪费的人力成本也是惊人的....

严重同意!
0 请登录后投票
   发表时间:2006-12-08  
大小本来就是需要参照物的,看你怎么比较了,没有绝对的大,也没有绝对的小,争这个干毛
0 请登录后投票
   发表时间:2006-12-08  
大小之分本来就要有参照物的,看你拿什么比,没有绝对的大,也没有绝对的小,争这个无意义
0 请登录后投票
   发表时间:2006-12-08  
对不同的人来说,“大”的含义是不一样的。比如对销售和财务来说,“大”“小”肯定是要看销售额的。

从软件工程和项目管理的角度来说,我觉得以项目组成员的数量来衡量比较合理。比如XP所说的中小规模的项目基本就是12人以下。

个人意见,20个程序员以上的就可以算是大项目了。
0 请登录后投票
   发表时间:2006-12-08  
<30工作人日 小项目
30~60 中项目
>60 大项目
0 请登录后投票
   发表时间:2006-12-08  
软件项目的核心成本是什么?应该就是人力啊,公司一般也都是给月薪的吧。所以项目的大小按照人月来计算最合适了。200个人月以上应该算大项目。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics