项目调研经验谈_项目管理文章库

用户名密码

联盟服务关于我们联系方式收藏本站

PgMP认证，美国项目管理协会高端项目管理认证！大型项目与项目群管理Program Management全球权威认证

服
务
区

网站登录：会员企业专家服务商
企业服务：PMP培训内训课公开课
工具箱：发表文章提问题发案例

首页：动态 | 文库 | 下载 | 书架 | 访谈 | 专栏 | 专题 | 人才 | 培训 | 软件 | PMC

互动：活动 | 案例 | 问答 | 论坛 | 博客 | 圈子

应用：基础┊工程┊软件┊制造┊活动┊研发认证：PMP┊NPDP┊ACP┊PgMP┊IPMP┊P2┊ISPMP┊IMCP┊建造师┊MPM 特色：热点┊奖项

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

当前位置：文库首页 >> 文章内容

项目调研经验谈

作者：pekingsun 提交人：项目管理者联盟[pekingsun] 属性：提交人转载发布时间：2007/4/2 点击：2658 【收藏本文】

　　调研概要情况：X项目需求调研历时三个月，内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干，编写需求规格说明书字数95.4万。项目经理博客

　　1.把二期项目当作一个新项目来做调研，避免需求细节遗漏。在调研的初期我们曾经有过疑虑，这是一个二期的项目，那么调研的内容是否只针对二期的新需求，对需求内容二期和一期一致的部分就不必调研了? 项目管理者联盟
项目经理圈子
　　经过讨论我们还是决定把二期项目当作一个新项目来做调研，即使二期和一期需求内容一致，我们也在调研会上讨论，并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时，发现有不少地方原来以为是二期不必修改的，经过讨论后发现还是需要修改。（往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”）
项目管理者联盟
　　2.调研团队参加所有子系统的调研会议，可以相互补充避免需求遗漏。这个项目规模比较大，根据业务的类型不同，分成了6个子系统，各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求，但是在调研时，只要可能，我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是，对于子系统之间的业务关系，调研团队都可以有全面的了解，对业务的理解比较透彻全面，并且还可以相互补充遗漏。项目经理博客
转自项目管理者联盟
　　3.多人调研，在会议后应该立刻回顾整理统一的会议笔记，消除歧义，避免遗漏。在开调研会时，全体与会人员都各自记自己的会议笔记，会后没有强调当天整理会议笔记（会议进度很紧，每天开会到晚上8、9点钟）。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容，或者同一份需求在几个笔记上记录的内容细节上有差异，事后难以追溯正确的信息。给编写需求文档带来了一些困难，需要再次讨论需求。项目管理者联盟
项目管理者联盟
　　4.需求文档编写完成后，在开发阶段也应该做检查和更新，避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后，在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误，导致需要重新修改。项目管理者联盟
club.mypm.net
　　建议：项目管理者联盟
项目管理者联盟
　　1、如果在编写需求文档后，开发阶段应该做一边阅读需求文档，一边做需求文档的检查，对于保证需求质量效果会更好。项目管理者联盟
项目管理者联盟
　　2、应该指定人负责需求追踪和更新，在开发阶段、测试阶段要保持和用户的需求沟通，这不是一个可有可无的简单工作，很重要，并且会占用责任人50%的工作时间。项目管理者联盟
项目管理者联盟
　　5.企业业务管理信息系统的需求调研方法：我认为对调研的组织安排是非常重要的，好的调研安排虽然未必产生质量高的需求，但是一个不遵循调研规律的调研活动，必然是低效的。下面是H项目调研组采取的调研流程，供参考：项目管理者联盟
项目管理者联盟
　　1、第一步不是立刻和用户当面讨论需求细节，而是要业务关键用户编写初步的需求报告，提供给开发团队阅读分析。需求报告的内容是，对业务流程的描述，对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系，经常在没有面对面沟通时，关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础，一定要做，有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通，让用户编写。项目经理圈子
项目管理者联盟
　　2、和业务关键用户用开会的方式讨论业务流程细节，并绘制业务流程图。当关键用户和项目团队通过对需求报告的编写、阅读和讨论后，就可以开始对业务流程的细节讨论。这个讨论内容是涉及到每一个细小的业务流程环节，环节之间的关系，和业务流程流转相关的输入输出信息，例如在审核出库单时，出库数量和可用库存数量就是和流程相关的信息。（这时应避免偏离重心，过多讨论系统界面、和流程无关的软件操作方式）。业务流程图是一份正式的文档，需要让用户签字确认，和需求规格说明书一起作为以后的需求文档。占总调研时间的15% 项目管理者联盟
项目管理者联盟
　　3、打通业务流程图后，根据业务流程每个环节，讨论在每个环节上的详细输入输出项和操作。这里的讨论会增加更多的信息项，这些信息项可能和业务流程流转没有必然关系，但对于业务用户方便地获取各种业务信息是必要的描述。这里的讨论也有可能会部分更改前期描绘的业务流程图。我个人认为，此时也不建议过多在操作方便性上做讨论，原因在概要设计里讲。占总调研时间的35%。 bbs.mypm.net
项目经理博客
　　4、编写需求规格说明书，编写过程中会对不少需求细节再讨论，再确认。千万别埋头编写，不和用户做沟通讨论！占总调研时间的50%。最后要让用户签字确认需求规格说明书。项目管理者联盟
项目管理者联盟
　　5、需求规格说明书写的要有多细？其实这个问题没有唯一准确的答案，各个项目未必一样。文档的目的是在整个项目周期中，让项目团队及关键用户所有人对相关需求的理解都是足够细致，没有歧义的，并且可以依据其内容准确工作。系统越大越复杂，信息量就越大，项目周期一般较长，那么对需求文档的质量要求应该更高；对于小系统或简单系统，如果你决定在较短的时间内完成需求规格说明书，那么也一定要和关键用户、项目团队做充分细致的需求沟通（这种需求沟通往往占项目经理一半以上的时间），要做需求变更记录，对容易引起歧义的部分需求要描述详细，并且做好心理准备和时间准备，在软件和用户见面后，会有较多的修改。 service.mypm.net

[发表评论]

[相关评论]

[评论人] 苏	[时间] 2007-04-03
中肯

本站热点

·从《PMBOK指南》第八版看项目经理角色
·国际项目管理奖项PMI(中国)项目管理大
· 华师大CTO学院：科创生态建设与创新项
·宏发电声江玫瑰谈PgMP：“下好一盘棋”
·PgMP：交付能力与创造未来的项目管理方
·开放讲座|《项目组合管理与PfMP认证》
·开放讲座|项目组合管理与PfMP认证
·开放讲座|PgMP：项目管理思维与方法论
·开放讲座|《项目组合管理与PfMP认证》

栏目说明

《文库》栏目为项目管理者联盟网站核心栏目，收录了十大行业项目管理文章5000余篇，囊括了项目管理五个阶段、九个知识领域的相关文章，是广大项目管理爱好者学习的知识库，欢迎大家发表原创文章、转贴文章，或直接发给编辑。须联盟会员且登陆后才能发表文章。

项目管理活动

活动QQ群：531390275
免费积累PDU,仅500人
2022年项目管理活动计划
2021活动精彩回顾

原创排行榜

项目管理评论杂志	311	高扬	106
乔东	100	项目管理	84
高国伟	61	人月神话	60
张为	59	郭致星	52
蒋昕炜	46	肖杨	38
曾伟强	37	潘德有	36

搜索文章

关键词：

行业：

团队成本风险进度
沟通采购质量合同

更多>> 专题集锦

企业项目化管理

PMO实践与应用

如何处理项目客户关系

经理访谈

个人专栏

王树文

赵春明

高国伟

项目管理者联盟特刊

	联盟特刊是对网站会员发行的内部刊物，刊物内容包括：案例及分析等，得到了会员好评。
电子期刊：
特刊下载：
2017合刊 2016合刊 2015合刊 2014合刊 2010合刊 2009合刊 2008合刊 2004合刊 2005合刊 2006合刊 2007合刊

施工企业管理

	《施工企业管理》创刊于1986年1月，中国施工企业管理协会主办，是反映施工企业管理杂志。
浏览往期：

建造师杂志

	《建造师》杂志由清华国际工程项目管理研究院主办，是中国面向建设企业管理人的高端杂志。
浏览往期：

如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者

PMI,Project Management Professional, OPM3, PMBOK, PMP，PgMP，PfMP，PMI-ACP，PMI-PBA
and the PMI Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc.