关于我

最近来访

留言簿(0)

文章分类

文章档案


最新评论

1. re: EHR系统规划之以沟通为基础,促进全员参与的个人绩效管理模块
  很多企业上了eHR管理系统,第一期就完成了组织机构管理和职位管理这两个基础模块的建设,尤其是在组织机构管理中实现了部门职责描述、在职位管理模块中实现了职位说明书。但为什么企业的员工在使用这个系统时,仍然不能明确地知道自己的部门和职位到底该做些什么具体工作、该如何做?
可以参考下这篇文章:
http://www.ehr100.com/showtopic-211.aspx--【匿名用户】:E-works热心网友
2. re: EHR系统规划之以流程为核心的组织机构和职位管理模块
对我来说很有帮助,谢谢!--zhuqifeng
3. re: EHR系统规划之以流程为核心的组织机构和职位管理模块
对我来说很有帮助,谢谢!--zhuqifeng
4. re: EHR系统规划之以流程为核心的组织机构和职位管理模块
对我来说很有帮助,谢谢!--zhuqifeng
5. re: 经营客户,从“交往、交流”做起
一个好的销售的基本功,交往、交流、交心还要小舍,才能有得到单子的大得!--wcc
6. re: 项目管理-精确制导式项目管控模型
已选录入文库项目管理栏目,请与我联系,谢谢.
zm@e-works.net.cn--张敏

阅读排行榜

评论排行榜

软件项目中,软件需求的准确性、稳定性直接决定项目的成败。这一点,所有从业人员都坚信。各种项目管理书籍与知识体系,尤其是PMPCMMI等知识体系,都无不强调需求工程的重要性,而且也都给出了非常好的过程实践。

此文,仅限于需求分析过程,其他过程暂时不涉及。

比如,CMMI模型对需求分析过程域提出明确的过程目标与实践指导:

过程域:需求开发

SG1 开发客户需求 收集相关人员的需求、期望、限制及接口,并转换成客户需求。

  SP1.1 引导需求 引导相关人员提出有关产品生命周期各阶段的需求、期望、限制及接口

  SP1.2 开发客户需求 转换相关人员的需求、期望、限制及接口为客户需求。

SG2 开发产品需求 细化病详细说明客户需求,以开发产品及产品组件需求。

  SP2.1 建立产品与产品组件需求 以客户需求为基础,建立和维护产品与产品组件的需求。

  SP2.2 配置产品组建需求

  SP2.3 标识接口需求

SG3 分析并确认需求

  SP3.1 建立操作概念及场景 建立和维护操作概念及其相关场景。

  SP3.2 建立必要的功能定义 建立和维护必要的功能定义。

  SP3.3 分析需求,以确保其必要性和充分性。

  SP3.4 分析需求一取得平衡 分析需求,并在相关人员的需要和限制间取得平衡。

  SP3.5 用广泛的方法确认需求 使用多种适用的技术来确认需求,以确保在用户环境下,最终产品能如期运行。

过程术语:SG 特定目标; SP 特定过程

这类知识体系,为我们过程实践提供了非常有益的指导,但在项目实践中,怎么做才能高效高质地遵从这些SP,达到SG规定的目标呢?

现实中,各组织、各个体的做法各异,无所谓优劣,唯有看效果。软件需求规格说明书(SRS)是体现项目需求最关键的工件之一。根据个人的实践经验,我们从SRS开始,总结了一套“循环修正法”,能够较有效地拉动客户参与,提高需求的准确性和稳定性。

循环修正法:

依据目标软件项目业务关联关系,把软件项目拆分为多个子系统或模块,每部分单独或者分组形成需求描述文档,以此作为与客户达成共识的唯一媒介。

与客户进行多轮循环沟通,每次沟通结论都记录在此文档中,以不同颜色或标记来标识修正过程。比如,红色表示疑问部分,蓝色表示已去除疑问、达成一致后待再次确认的部分,黑色表示已经达成共鸣并已确认的部分。

循环沟通多轮后,所有疑问都达成共识,即可进入评审阶段,并形成需求基线。

下面介绍循环修正法使用的前提条件、操作过程要点以及输出成果的应用与跟踪。

如果希望顺利使用“循环修正法”,必须搞清如下几个条件:

1-项目已经立项。

项目已经完成立项工作,项目立项的标志为“项目经理已经正式任命,再项目经理的组织策划下,已经召开项目启动会”。

2-需求阶段的详细计划已经形成。

项目策划阶段最主要的输出成果之一是项目进度计划。项目初期阶段,至少做到需求阶段计划非常明确且详尽。此计划必须与客户达成共识,是需求分析工作高效高质的前提条件。没有明确的计划,就会导致阶段工作盲目而无效率,无法充分拉动客户参与。

3-项目范围定义说明书已经熟读。

商务阶段或可行性研究阶段形成的项目范围定义说明书已经提交项目组,需求分析人员已经熟读范围定义,并且做到范围明确。

在实施“循环修正法”过程中,需要注意如下要点:

1-项目分割

依据目标软件项目的业务以及技术关联关系,把项目需求分割为多个子系统或模块。没有分割的量化标准,旨在便于后续需求分析的沟通工作,人们往往喜欢阅读一定篇幅的文档,而厌恶巨篇文档。

当然,如果项目需求量很小或者关联度超高,则未必非要分割。

2-需求文档初稿编写

在阅读项目范围定义说明书和客户提供的其他相关资料的基础上,着手编写文档初稿。文档具体格式有很多参考资料,比如各大公司的通用样本、本公司或本人的经验范本,甚至客户原始文本的再加工。各有各的优点,只要效果好即可。例如,使用客户原始文本,可能与公司规范或个人经验范本有差异,但他便于客户沟通,也是不错的选择。

无论如何,需要注意两点:1)图文并茂,文本旨在准确描述,图片旨在形象而便于交流;2)标识所有疑问内容,甚至加上你的疑问问题。

3-多轮循环沟通

需求文档承载项目干系人的要求,是否准确、全面,必须经过多轮沟通。每轮沟通都要做到去伪存真、去疑存真。循环中,包括去掉疑问,更要包括上轮达成共识的问题的再次确认。

4-唯一共鸣媒介

务必要找到唯一共鸣的媒介,来记载共识。我觉得循环修正的目标文档就是最理想的选择。切勿东记一下,西记一下;更不要你记一下,我记一下。这都会导致一团糟。

会议记录和邮件确认都是某次任务结果的记录,但不要把它们分别藏着,毕竟人们都是健忘的,把他们统统都放到整个唯一媒介中。

5-修正标记应用

循环修正的最大外在表现形式就是准确使用修正标记。建议,红色表示疑问部分,蓝色表示已去除疑问、达成一致后待再次确认的部分,黑色表示已经达成共鸣并已确认的部分。红色部分必须达成共识才能变成蓝色,蓝色部分只有经过再次确认才能变成黑色,只有所有部分都变成黑色,才能说明我们沟通有成效。

记住今天偷的懒,明天需要你用百倍的代价来补偿。千万不要为了偷懒而改变颜色。

另外,也不要忽略蓝色和黑色部分重新变为红色的可能性,因为人的理解是一个渐进的过程,这是修正过程的正常表现。

“循环修正法”输出的成果必须得到正确的应用,否则就无法发挥其效力,反倒成为白忙一场。最重要的输出成果往往是软件需求规格说明书,它的应用与跟踪包含如下几个方面:

1-内部评审

项目组内部,也可能包括部分客户,必须认真仔细地阅读两遍,内部评审一轮。既是内部学习,又是内部修正的过程。

2-同行评审

我们称其为PV,即PeerReview。根据项目规模和范围要求,需要外部同行来共同参与评审,必须做到所有关键干系人共同参与。

评审必须由结论,通常有3种结论:1)完全通过,2)有条件通过,3)不通过。无论什么结论,都必须有明确说服力的解释,对于有条件通过的,必须详细定义和说明条件。

3-评审修正跟踪

依据评审决策,再次修正文档,及时提交给验证负责人,完成最终评审归档。

非常感谢你与我一起走过循环修正需求分析全过程,但不要忘记最后的基线化,完成配置管理工作。希望上述内容对于我们的项目经理和需求分析人员有些借鉴意义。

本该再加些图文和样本,人都有惰性呀,我也如此,见谅。或者感兴趣的话,给我留言。

发表于: 2008-11-16 21:05 魏 阅读(1891) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

网站相关博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册