项目调研经验谈

发表于:2007-04-24来源:作者:点击数: 标签:项目调研概要情况经验谈
调研概要情况:X项目 需求 调研开始于2006-3-23结束于2006-6-15,内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个 开发 骨干,编写需求规格说明书字数95.4万。 1.把二期项目当作一个新项目来做调研,避免
调研概要情况:X项目需求调研开始于2006-3-23结束于2006-6-15,内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干,编写需求规格说明书字数95.4万。
 
  1.把二期项目当作一个新项目来做调研,避免需求细节遗漏。在调研的初期我们曾经有过疑虑,这是一个二期的项目,那么调研的内容是否只针对二期的新需求,对需求内容二期和一期一致的部分就不必调研了?

  经过讨论我们还是决定把二期项目当作一个新项目来做调研,即使二期和一期需求内容一致,我们也在调研会上讨论,并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时,发现有不少地方原来以为是二期不必修改的,经过讨论后发现还是需要修改。(往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”)
 
  2.调研团队参加所有子系统的调研会议,可以相互补充避免需求遗漏。这个项目规模比较大,根据业务的类型不同,分成了6个子系统,各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求,但是在调研时,只要可能,我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是,对于子系统之间的业务关系,调研团队都可以有全面的了解,对业务的理解比较透彻全面,并且还可以相互补充遗漏。
 
  3.多人调研,在会议后应该立刻回顾整理统一的会议笔记,消除歧义,避免遗漏。在开调研会时,全体与会人员都各自记自己的会议笔记,会后没有强调当天整理会议笔记(会议进度很紧,每天开会到晚上8、9点钟)。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容,或者同一份需求在几个笔记上记录的内容细节上有差异,事后难以追溯正确的信息。给编写需求文档带来了一些困难,需要再次讨论需求。
 
  4.需求文档编写完成后,在开发阶段也应该做检查和更新,避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后,在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误,导致需要重新修改。

  建议:
  1、如果在编写需求文档后,开发阶段应该做一边阅读需求文档,一边做需求文档的检查,对于保证需求质量效果会更好。

  2、应该指定人负责需求追踪和更新,在开发阶段、测试阶段要保持和用户的需求沟通,这不是一个可有可无的简单工作,很重要,并且会占用责任人50%的工作时间。
 
  5.企业业务管理信息系统的需求调研方法:我认为对调研的组织安排是非常重要的,好的调研安排虽然未必产生质量高的需求,但是一个不遵循调研规律的调研活动,必然是低效的。下面是H项目调研组采取的调研流程,供参考:

  1、第一步不是立刻和用户当面讨论需求细节,而是要业务关键用户编写初步的需求报告,提供给开发团队阅读分析。需求报告的内容是,对业务流程的描述,对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系,经常在没有面对面沟通时,关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础,一定要做,有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通,让用户编写。

调研概要情况:X项目需求调研开始于2006-3-23结束于2006-6-15,内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干,编写需求规格说明书字数95.4万。
 
  1.把二期项目当作一个新项目来做调研,避免需求细节遗漏。在调研的初期我们曾经有过疑虑,这是一个二期的项目,那么调研的内容是否只针对二期的新需求,对需求内容二期和一期一致的部分就不必调研了?

  经过讨论我们还是决定把二期项目当作一个新项目来做调研,即使二期和一期需求内容一致,我们也在调研会上讨论,并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时,发现有不少地方原来以为是二期不必修改的,经过讨论后发现还是需要修改。(往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”)
 
  2.调研团队参加所有子系统的调研会议,可以相互补充避免需求遗漏。这个项目规模比较大,根据业务的类型不同,分成了6个子系统,各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求,但是在调研时,只要可能,我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是,对于子系统之间的业务关系,调研团队都可以有全面的了解,对业务的理解比较透彻全面,并且还可以相互补充遗漏。
 
  3.多人调研,在会议后应该立刻回顾整理统一的会议笔记,消除歧义,避免遗漏。在开调研会时,全体与会人员都各自记自己的会议笔记,会后没有强调当天整理会议笔记(会议进度很紧,每天开会到晚上8、9点钟)。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容,或者同一份需求在几个笔记上记录的内容细节上有差异,事后难以追溯正确的信息。给编写需求文档带来了一些困难,需要再次讨论需求。
 
  4.需求文档编写完成后,在开发阶段也应该做检查和更新,避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后,在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误,导致需要重新修改。

  建议:
  1、如果在编写需求文档后,开发阶段应该做一边阅读需求文档,一边做需求文档的检查,对于保证需求质量效果会更好。

  2、应该指定人负责需求追踪和更新,在开发阶段、测试阶段要保持和用户的需求沟通,这不是一个可有可无的简单工作,很重要,并且会占用责任人50%的工作时间。
 
  5.企业业务管理信息系统的需求调研方法:我认为对调研的组织安排是非常重要的,好的调研安排虽然未必产生质量高的需求,但是一个不遵循调研规律的调研活动,必然是低效的。下面是H项目调研组采取的调研流程,供参考:

  1、第一步不是立刻和用户当面讨论需求细节,而是要业务关键用户编写初步的需求报告,提供给开发团队阅读分析。需求报告的内容是,对业务流程的描述,对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系,经常在没有面对面沟通时,关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础,一定要做,有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通,让用户编写。

原文转自:http://www.ltesting.net