如何把握不存在的需求_项目管理文章库

用户名密码

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

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

服
务
区

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

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

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

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

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

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

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

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

北京 | 直播 | 录播

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

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

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

计划 | 报名 | 经验

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

如何把握不存在的需求

作者：黄绍良提交人：黄绍良[黄绍良] 属性：提交人原创发布时间：2008/5/19 点击：14922 【收藏本文】

　　任何从事IT行业的人员都清楚，软件开发项目失败的其中一个主要原因是项目在启动的时候功能需求模糊，导致开发过程的不断修改，让项目不断延误，功能不断扩张，资源越来越吃紧，最终影响交付的质量和客户的满意度。网上有很多文章介绍如何去把握需求，很多业内人士也常在网上分享他们把握客户需求的方法，可惜效果并不太理想。因为我们绝对不能够把握基本上不存在的“客户需求”。项目管理者联盟
项目管理者联盟文章
　　作为一个软件工程的专业人员，如何能够从客户所提供的模糊需求建立一个明确的范围，然后从这个范围中建立整个系统的功能需求，让我们可以控制软件开发的过程，减少项目的范围变动，降低开发过程中的修改需求，让我们能够按预算、按工期，提交符合质量要求的交付物，达到客户的预期目标，我们便需要理解问题的根源，打破过去的工作习惯，寻找一套可行的方法。项目经理博客
项目管理者联盟
　　在项目管理知识体系(PMBOK)中我们学习范围变动管理，而不是需求变动管理，范围变动才是需求变动的主要原因。其实在这里PMBOK做了一个假设，就是有了明确的范围便可以建立明确的功能需求，如果能够控制范围，便能够控制功能需求。项目管理者联盟文章
blog.mypm.net
　　功能需求变动是导致软件工程在开发过程中进行修改的主要原因，那是说我们在软件工程项目启动的时候没有把握好项目的范围，才会发生我们面对的问题。所以，我们首先需要理解范围与功能需求的关系，什么是范围?什么原因导致需求模糊?能够明确理解两者的异同，才能够找出解决的方法，建立明确的项目范围，转换成功能需求。让我们能够从模糊的需求转变成为明确的需求。项目管理者联盟
项目管理者联盟
　　建立明确的项目范围代替不明确的范围，才能够减少开发过程中的修改。本人最近一直从过去30多年的科技项目开发和管理经验中，结合近年回国后对国内IT企业运营模式的理解，我国技术人员的工作习惯，客户的思维、心态和期盼，总结出一套建立明确项目范围的方法，特在此与读者分享，共同改善我国软件企业的困境。 training.mypm.net
training.mypm.net
　　70年代的项目范围与需求
项目管理者联盟
　　项目范围与项目需求是两个完全不同的概念，但两者却不能单独处理。让我们回到上世纪70年代的时候，国外企业正进行自动化的过程。项目基本上是把人工作业流程转变成计算机程序。那时候并没有项目范围这个名称，我们用Terms of Reference (ToR)来界定项目的边界，采用文字描述的方法说明这个项目要做什么。例如，要为希赛公司建立一个库存管理系统，这个项目的ToR会说明货品从进入仓库开始，到货品因应生产或销售申领要求离开仓库为止，其中包括货品存入量的统计，存放位置记录，总库存量统计、申领数目、检货、提取货品、准备出仓，最后更新货品存量统计等工作过程。这个项目的Term of Reference只说明这个项目的范围，包括一些需要执行的工作和记录等。转自项目管理者联盟
项目管理者联盟
　　在项目实施过程中，系统分析员会对库存管理全过程进行调查或调研，采用访谈或观察等方法，记录上述范围中的整个工序的过程，每一个数据的更新，参考记录数据的报告格式和任何有关的工作单据。这些工序，数据更新时间和地点，报告打印等工作最后便成为系统的功能需求。这些需求能够让最终用户明确开发人员已经把握了整个工作流程，明确每一个工作的内容，保证完成的系统能够提供库存管理的功能。项目管理者联盟
项目管理培训

项目管理者联盟
项目经理圈子
　　这段时间软件工程的焦点是在范围确认后的信息搜集(Facts Finding)和需求分析(Requirement Analysis)中。依据PMBOK的论述，我们在20世纪70年代，的确可以从范围的建立带出明确的功能需求，减少开发过程中的修改，降低项目延误的风险。这个模式在我国软件产业发展初期采用，大概是20世纪80年代后期至90年代中期的时间进行自动化过程。项目管理者联盟

　　80年代的项目范围与需求 talent.mypm.net
转自项目管理者联盟
　　到上世纪80年代中后期，国外企业的自动化过程已经接近尾声，企业开始整合部门的计算机系统，加上个人电脑开始取代终端，项目多数包括跨部门或跨地区的系统集成、综合数据库应用、远程计算(Remote Access)、网络连接等为项目主体。在这种情况下，传统的ToR已经不能够明确说明项目属于哪个部门，从哪里开始，如何才是项目完结。ToR已经不能够有效地界定项目的范围，所以，我们利用多个工作描述来说明，成为我们知道的工作说明“Statement of Works (SOW)”，其中包括项目开发过程中需要处理(inclusive)的工作说明和开发过程中不需要(NOT-inclusive)处理的工作说明，整合这些SOWs 后成为我们今天所认识的项目范围，利用工作说明以明确的语句来说明项目中包含的每一个工作内容。例如，在一个项目范围中包括的工作说明可能是:“连接A市及B市两地办公室的主机，通过A市数据中心的中央货品库存数据库，为A市工场和B市销售中心提供即时货品存量查询及货品预订功能”。项目管理培训
blog.mypm.net
　　这些工作说明便成为这个工程需要提交的最终成果。利用项目范围中的SOW替代ToR，一个项目可以容许多个SOW来描述系统建设的内容，所有的SOW描述的建设内容都包含在这个项目的范围中。但实际上每一个SOW的结果如何实现，还是需要技术人员透过调查和进行分析后才能够清楚具体的操作该如何实现。每一个SOW的具体操作过程都成为这个SOW的功能需求。整合全部SOW的个别操作过程，才是项目的最终功能需求。 club.mypm.net
项目管理者联盟
　　简明的说，每一个SOW都是一个小范围，它本身也不是一个需求。我们还是需要通过理解SOW的内容才能够把握这个SOW的需求。每一个SOW可以成为一个独立的项目，“子项目”的名称也是在这个时候诞生。项目管理者联盟
training.mypm.net
　　从上述的历程中可以看到，用户或客户告诉我们的永远都不是需求，是客户或用户希望在最后交付物中看到的部分成果，永远不会完整，只是客户或用户的部分期盼、愿景和目标。如果把这些期盼、愿景和目标当作了需求，那么我们永远不能在项目初期建立满足用户对交付物的期盼。需求从来不是用户或客户提供，需求是技术人员依据范围中需要实施的工作过程进行分析后寻找出来可以提交项目最终交付物的结果，然后才能够把这些需求转变成一个软件工程，在项目指定的范围中利用科技达到用户的最终目的。项目管理者联盟
项目管理者联盟

项目管理者联盟

　　系统集成项目在PMBOK论述的范围管理仍然有效，但在软件工程中能否包含全部SOW是影响范围变动的主要因素，遗漏了一个SOW便会带来范围变动，所以当时的软件工程多以SOW为主，需要客户方确认，只要客户确认SOW后，任何不包括在SOW中的功能便成为范围变动，也是PMBOK中范围变动管理的主要意义。改变范围便需要改变项目基线，增加工作量和项目成本，延长项目工期。我国的软件产业发展从2O世纪90年代中期到本世纪初期才开始进行系统集成的过程。 www.mypm.net
pmp.mypm.net
　　自动化到信息化的年代项目管理者联盟
项目管理者联盟
　　IT在上世纪70、80年代的项目是流程自动化与系统集成年代，基本上是先确认范围后才开始把握功能需求，大部份项目所采用的开发体系也是依据这个构思对软件开发进行管理。但到了90年代进入信息化年代，范围的意识开始模糊，范围开始被误解成为需求，最主要的原因是技术人员仍然采用过去流程自动化的开发思维，希望客户能够明确说明范围，但在范围建立的过程中，每当客户提出“我需要这个系统能够提供 …… ”，技术人员便把客户的说明演绎成为系统需求。项目管理者联盟
bbs.mypm.net
　　故此从90年代中期开始到现在，很多软件工程师对需求的定义非常模糊，系统需求与功能需求把握不准，把范围建设的过程与功能需求混在一起，导致今天大部份软件在开发过程中不断修改，让项目不断延误。 www.mypm.net
项目管理者联盟
　　90年代的项目范围与需求项目管理者联盟
转自项目管理者联盟
　　自上世纪90年代中期开始，企业从流程自动化的“科技应用方法”开始转型到信息化的“科技应用价值”为最终目标。项目的目标也渐渐地从明确的技术应用过程转变成为如何利用科技来完成虚拟的理想及模糊的愿景。例如，建立一个系统为企业提供业务方向决策，让管理层能够判断产品在市场上哪个地域的市场需要和进行产品调整或改善，属于哪类消费群，如何开拓一个新市场等，又或者希望利用因特网为企业提供一个产品推广和销售渠道。项目管理者联盟
项目管理者联盟

项目管理者联盟
项目管理者联盟
　　这些项目可能包含现有市场的地域或推进到新的地域环境，包含一个或多个部门的分工与协调，也可能包含现有数据库的组合、信息分享或需要成立新的数据来提供所需的信息，但大多数需要包含现有系统和建立新系统的集成体。如何实现项目的人工或系统操作流程等等多是客户在项目启动前没有考虑过的内容。在这张情况下，范围的建设依据是一个相当困难去完成的子项目。客户在项目调研过程中能够提供的只能是一部份的愿景和期盼，需要技术人员透过这些信息建立项目的范围，才能够降低后期的变动。 pmp.mypm.net
talent.mypm.net
　　大部分技术人员在软件开发过程中对开发体系的应用未能融合信息化项目的特色。盲目依从开发体系的过程，忘记开发体系应用前的一些先决条件：建立项目的范围。所以从90年代开始，项目管理开始扮演重要的角色，在项目章程(Project Charter)中建立范围、预算、资源和投资回报等内容，让技术人员依据项目章程的指导，更能有效地发挥技术应用的能力。 talent.mypm.net
项目管理者联盟

本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！

[相关文章]

[网友互动]

·四招提高项目需求准确性及完整性 (1773)	项目管理者联盟	06-22
·应对需求变更，基实就跟谈恋爱一. (2426)	项目管理者联盟	04-08
·需求分析师和产品经理都有哪些不. (1418)	项目管理者联盟	03-28
·如何避免需求遗漏？ (4522)	项目管理者联盟	03-04
·产品经理如何评估需求？ (2889)	项目管理者联盟	12-01
·很多团队的问题都可以从分析需求. (1687)	项目管理者联盟	11-24
·需求频繁变更，感觉痛不欲生！怎. (4335)	项目管理者联盟	10-25
·产品经理怎么做，才能在需求评审. (1723)	项目管理者联盟	09-28

06-04[帖子] 被需求变更拖垮的项目，终于有救了 (140)
05-19[帖子] 易趋赋能智能家电：从需求到交付的全链. (151)
12-30[帖子] 需求跟踪矩阵指南：让每一个需求都具有. (1781)
11-15[帖子] 轻量型协同管理软件无法满足日益增加的. (1343)
11-14[帖子] 产品经理必看：需求跟踪矩阵指南，让每. (440)
11-14[日志] 产品经理必看：需求跟踪矩阵指南，让每. (41)
06-07[帖子] 产品经理：做好有效的客户需求分析 (1650)
01-31[帖子] 项目管理中，项目经理如何预防需求蔓延. (1509)

[发表评论]

[相关评论]

[评论人] 唐旭东	[时间] 2009-04-22
把握不存在的需求，我就得就是隐性需求，对于需求初步接触的人来说，难度较大，因为它与软件行业经验有关，同时也与业务知识有关，只有深入分析和探讨，才会逐步发现并把握！

本站热点

栏目说明

《文库》栏目为项目管理者联盟网站核心栏目，收录了十大行业项目管理文章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.