CMMI on line

做中国最专业的CMMI网站! 新网站软件知识原创基地:www.umlonline.cn
欢迎光临 CMMI on line 登录 | 注册 | 帮助
in 搜索
CMMIonline网站升级啦,请访问新网址: 软件知识原创基地 ( www.umlonline.cn ),发帖请到新网站!

很痛苦,换了个新单位,不能上MSN了!请教个问题

本主题共有 6 篇回复,最新回复发表于 07-29-2008, 22:47,作者 zhangcb
帖子排序: 上一主题 下一主题
  •  07-25-2008, 9:12 7783

    很痛苦,换了个新单位,不能上MSN了!请教个问题

    在需求分析时,原型应该是起到什么作用?

    现在公司原型要求非常高,

    这对于需求开发阶段是必须的吗?而每次需求变更时,原型变更就很累,所以基本都不动了,正在想如何解决此类问题,哪位兄弟指教一二吧!

  •  07-28-2008, 0:35 7843 回复至 7783

    回复: 很痛苦,换了个新单位,不能上MSN了!请教个问题

    原型只是需求开发的一种方法,需求开发是很复杂的难度很高的工作,并不会因为用了原型就会一定成功。关于需求开发,请参考最近斑竹主讲的《需求开发挑战之旅》沙龙,可下载PPT:
    http://cmmionline.net/forums/thread/7394.aspx

    关于你的问题,你提到:需求变更时,原型也需要变更?我觉得这个问题有点怪而且是有点无厘头,能不能说具体一点?


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  07-28-2008, 9:24 7847 回复至 7843

    回复: 张总的问题和一些简述

    简述下单位目前的状况:我的职位是QA。

    需求开发阶段需求分析人员得到需求后,将需求告知设计人员,共同设计出一个原型,然后再交由产品部门确定原型的符合度。开发人员依据原型进行开发。现在的问题是:

    1、我原本的理解是,原型是需求分析人员为了更好的表达需求的一种方法,是为了更好的确认需求的途径。所以原型应该是需求分析员自己做,当变更时再变更,而现在的问题是,需求部门变更需求有如下两种情况:a.直接与开发部沟通,跨过了设计部;b.与设计部沟通,然而设计部并不同意再做一种原型,因为这将花费大量的时间。

    2、公司项目对于页面的要求非常高,这在需求开发中如何处理这种关系,很多时候是一个按纽变更很多次,而开发的经常觉得,有些存在“树”中的按纽变更会给他们带来很大的工作量。另外这样的需求需要编写“白雪卡”吗?

    先写这么多,马上开会了!期待回复!

    • 帖子点数:0
  •  07-28-2008, 21:49 7852 回复至 7847

    回复: 张总的问题和一些简述

    对贵公司的情况了解不多,以下意见供参考:

    按照你的描述,目前似乎存在一下问题:
    1.需求分析人员、设计人员、产品部门、开发人员四拨人都参与到需求开发中来,环节比较多。
    2.好像是需求分析人员获得第一手需求的,但原型由产品部门来确认,产品部门是否能接触到第一手需求的?这样的确认环节,看上去有点怪。
    3.几个环节的人似乎都没有能从项目成功的最大利益出发,各环节的人员似乎都带有“本位主义”,希望自己的工作越简单越好。

    一些建议:
    1.你牵头或者让你的直接领导牵头,和这几个环节的负责人讨论工作方法,讨论出最符合公司利益的做法来,最好能让你们的大头参加。
    2.你们有项目组不?项目组是否强势?各环节的部门领导能否强力支持项目经理的工作?你们可以考虑从加强项目组的“势力”角度出发,不同部门的人组成了项目组,一切利益要以项目为重,不要有本位主义。改善这点需要让你们的大头下达明确指示,并且赋予项目建立足够的权力,同时配套有效的项目绩效及管理办法。
    3.原型只是获取需求的一种方式,不太明白你们这样反复“折腾”原型的工作方式,可以考虑简化。

    另外你的问题2中提到的内容,特别是后半句以及“白雪卡”,不是很懂什么意思。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
  •  07-29-2008, 9:14 7856 回复至 7852

    感谢张总回复!

    昨天因为要开会,所以没有仔细检查我的说辞,可能造成了一些误解。我们的需求流程是这样的:

    产品部提出产品愿景(提交可行性分析报告)——需求部开始进行需求分析及开发(提交需求规格说明书)——设计部根据需求设计原型——待产品部确认后,开发部开始开发。

    问题:

    1、需求理解能力。产品部及需求部对需求的理解可能有偏差,导致设计部设计出的原型经常变动。

    2、需求变更管理。经常发生产品部直接跟开发人员交流需求,导致需求说明书和原型的设计成为虚设。

    我一开始的主要问题是想询问:原型不由需求人员写,而由设计部写,这样的步骤是否不合适?不过现在已经探讨的比较深了。

    关于张总的问题:我们是有项目组的,您说的“本位主义”那种问题应该存在,刚到公司时间不长,工作内容及方式还有待磨合与探讨!

    白雪卡:也称需求项框架,需求开发过程中一种个人觉得比较好的方式,相当于便条纸一样的,我觉得公司的需求都比较零散,所以不知道给他们用了这种方式是否可行,以下是白雪卡的简约形式:

    需求编号:       需求类型:     需求来源:

    需求描述:

    需求验证:

    需求人员:

    说明;

    • 帖子点数:0
  •  07-29-2008, 9:16 7857 回复至 7856

    anonymous

    可怜的我怎么回复的时候都是anonymous。。。。。

  •  07-29-2008, 22:47 7861 回复至 7856

    回复: 感谢张总回复!

    你们公司这样的部门设置,可能是有一定原因的,你再多了解一下。

    我们公司以前考虑部门设置的时候,也想过要按专业来分的,类似于你们,我们曾经考虑按照需求、设计、编码、测试来划分部门。按着这样划分的好处就是,各人做自己最专长的事情,并且因为这样的划分,会“强迫”各部门交接用的文档要写得清清楚楚,如需求文档、设计文档。

    但是我们没有采用这样的划分办法,我们认为这样划分部门效率会比较低,难以适应变化。当然每个公司情况不一样,也不能一概而论。

    对于你们当前的需求流程,我有这样的一些疑问:
    1.产品部提出远景,产品部是直接向客户进行需求调研的吗?还是产品部的人员本身就是业务方面的专家?
    2.需求部开始需求分析,那需求部的需求调研对象是谁?是产品部吗?还是直接面对客户?
    3.开发部的工作成果,产品部需要确认,那需求部、设计部要确认吗?

    现在回到你的问题:
    问题1关于需求理解偏差的,我觉得你们的环节还是太多,到最后交给开发部的时候,开发部得到的需求已经是n手的了。
    问题2关于需求变更管理的,产品部直接和开发沟通,这是不是说明产品部都觉得环节太多,不适应变化呢?
    我觉得根本问题可能还是体制的问题,可能要变更。你提到的想法,让需求人员直接写原型其实很好,但要做到这点,要求需求人员会技术,有能力做原型,同时设计部的工作又怎样安排?这些你们可以讨论一下。

    我的总体意见是:
    1.尽量减少环节。
    2.开发人员最好能直接接触到一手需求,甚至直接参与需求调研。
    3.要强化项目组的作用,垂直管理,扁平化管理。

    以上意见供参考,建议你还是和你的领导和相关人员讨论一下,主动出击,提出你的想法。


    CMMIonline 版权所有
    欢迎转载,但请给出指向本网站的链接:
    http://www.cmmionline.net
    版权声明见:
    http://cmmionline.net/forums/thread/1340.aspx
以 XML 格式显示 RSS 新闻频道
CMMI on line 版权所有 ( 粤IC备07073557号)
Powered by Community Server, by Telligent Systems