软件项目什会失败——浅谈需求驱动项目理
IT行业世纪70年代蓬勃发展直现理软件项目直家讨话题软件项目失败太项目彻底取消项目工期拖延等等 中国目前软件开发团队实际情况某种程度说错误赖两软件理项目项目失败重理两软件MicrosoftProjectMicrosoftWord钉钉子总斧子 工程项目vs软件项目 MicrosoftProject身错项目理工具够做务分配PetriNETGannt图资源分析等等Project理工程项目造房子修桥等等工程类项目般务驱动理方法软件项目传统工程项目质差务确定性举例子目前房产火造什样房子资金位保质保量造造10层楼1层少天天做什容易计划分配务力资源需求会变没见造房子盖3层改意拆重新盖 软件需求变化避免做项目知道需求变化实际挺频繁样容易造成计划赶变化Project定义务计划工期通常耗费项目理量时间没意义 问什需求固定呢？定许变通常工程师会问样问题果变成客户会问问题需求总会变第：出钱总更话语权（然改需求应该付费）第二：市场情况变竞争手突然发布新产品功必须做出应变更需求第三：写需求神仙犯错误犯错误允许改正（犯错误惩罚需求变更付费）传统纯瀑布式开发方式已成历史愈愈开发团队采极限编程迭代开发应付需求变更 软件项目种特点需相应项目理工具斧子钉钉子做法点合时宜 传统项目工程项目拖工期加手工期赶回软件简单新熟悉项目容花时间工期难完全赶IT老总体会问题总加手加班搞定真正效项目理效理体系支撑 需求描述 软件项目类型目前说软件项目数指应类(Application)软件项目系统类(System)项目数库文件系统开发工具系统类软件项目应类项目系统类项目花长时间研究体系架构（Architecture）设计系统框架模块间关系等等应类软件基会现成框架J2EEMicrosoft台等等精力放需求实现中国目前应系统数客户做定制开发项目企业政府机构国防等做系统做产品中企业财务系统通办公软件等等针应类项目Word写类需求什问题什问题 般Word写需隐含想法需求写定然开发部门实现般Word文档写需求庞应系统开发建议迭代方法开发面提瀑布式开发已成历史需求次性写难软件慢慢成长起（见MicrosoftSecrets）milestonemilestone发展象孩子长样中间会走弯路错路需短调整指引成难开始描绘生详细场景蓝图走（工程项目做样） 建议先想会milestonemilestone发布功然描述需求框架性需求先确定然先写实现功需求说明面需求开发行样产品较快面世客户会时出反馈减项目风险里建议写需求时候UIPrototypeUserScenario方法户越早实际界面方法越 目前项目需求MicrosoftWord写动辄十页百页样文档面讲项目理方法问题存面问题： １规模巨方便查阅中型应系统需求文档达数百页甚更分卷方便查阅 ２利更新需求文档活文档断增长更新难免Word中做更新修订模式容易出更改部分样导致开发功设计两环节沟通畅通常变成需求第版变更发邮件口头说３利时协修改 ４需求没条目化Word文档中通常描述功实际需求分成项项设置需求优先级难易程度功点（functionpoint）发布中应该做完需求源等等种类似数库特性Word难体现 ５利建立需求开发控制元素关系写需求业务员体会项目理实现需求员说非常重开发程中户需求软件需求关系软件需求开发务关系测试例需求间关系等需求变更控制质量控制非常重参考信息体化需求文档（MSWord）难做点 需求驱动项目理(RDPM) 针应软件项目汉星天公司提出传统基务项目理方法需求中心软件项目理方法理中MicrosoftProjectWord处次位 户需求软件开发源泉宿需求代表户期解决问题软件项目开发活动目标服务众软件开发实施案例中项目旦开始户言项目进入隧道列车：难需求实现状况然众形形色色项目进展报表难回答简单问题：需求究竟实现样？RDPM(RequirementDrivenProjectManagement)核心需求务 需求开发 首先需求条目化放Word文档中条目化需求设置属性通属性决定需求实现序工期查前状态等等包括里程碑制定针具体需求项时处理变更记录需求间赖关系追踪需求续开发工件（计划务测试例实现代码等）关系关系称需求追踪矩阵旦需求发生变化影响面广评估实施需求变更首先确认需求变化带击面工作赖需求追踪矩阵体系什需求条目化重原 条目化需求MSWord难理般需存放数库中 条目化解决古老问题需求描述清楚需求必须写清晰明确完整确保开发员需模糊需求做决定尤行发挥推荐wiki描述需求细节加UIprototype形象描述需求wiki处协修改方便 外实践够帮助需求开发工程师提高需求编写质量： １记录条需求原研究成果表明通记录条需求原（什实现功）删达半数谓需求然记录工作投入定工作量效避免必需求完成续工作显著降低系统规模缩短系统开发周期正谓事半功倍 ２考虑采适形式化方法然语言存歧义二义性描述导致需求解释采形式化表示方法编写需求够更加准确户开发团队间进行沟通常形式化需求表示方法包括：实体关系图数字典数流程图USECASE等然UIprototype直接简单效 ３专业工具编写需求理需求类工具没成熟理指导客户求市场相应工具汉星天公司直致力方面研究推出相应需求描述需求变更理解决方案中国百家企业非常效果 户需求vs软件需求 需求谁写呢？先两定义需求名词：户需求户需解决问题期软件力描述通常户语言描述作开发团队户系统解决问题进行沟通桥梁 软件需求建立户需求开发团队理解方式描述系统应具功开发团队进行设计实现 解般客户写word文档发封email电话需求甩开发团队写结构完整容严谨需求客户少美国基户会写需求RFP（RequestforProposal）国时候项目理做需求分析工程师会帮助户整理户需求户需求较粗户需求细化写出软件需求应系统说软件需求写开发工作简单 两种需求分记录里程碑般户需求目标户需关联软件需求 项目规划进度监控 需求作项目规划实施目标RDPM核心切需求中心 通版发布逐步实现需求 项目计划进度控制方面采迭代方法 项目目标分解较易理子目标减少项目失败风险帮助项目目标分解角度进行采版发布分阶段实现项目需求目前越越认种尤现流行敏捷开发方法更提倡迭代开发普遍误解敏捷开发方法适规模开发团队实团队样适开发团队实现模块分成项目组项目组实团队般56合适团队合作沟通成间衡 版发布针前瀑布式开发缺点提出开发方式前模式中项目漫长需求开发设计编码测试阶段够客户见面客户时间段进入盲区直开发团队隆重推出开发成果恰恰时候项目风险时候程中缺乏交流机会客户会发现产品想象样导致项目拖延者失败 版发布系统实现分解连续版实现部分系统功版结束会邀请客户评估版实现状况根户反馈制定调整版目标样做处显易见：客户越早产品越早发现开发团队间户需求方面理解差异早调整需求避免项目期调整需求带巨额代价潜处部分产品功验收投入早户提供价值然版发布会避免面较需求变更请求需仔细理需求变更 需求实现单位规划项目实施 版发布需版制定实施目标确定次版中需实现功计划修改前版缺陷户需求功表达方式户需求作版理成章然根粒度软件需求做版发布容 定版计划目标需规划实施户需求描述客户业务系统期直接采户需求作开发务安排起点合适户需求导出软件需求开发团队够理解语言结构描述适合作安排需求实现基础需求追踪矩阵帮助找版目标中户需求相关软件需求项目理找软件需求实现制定开发务形成开发务集线辅集成测试缺陷追踪形成完整开发计划样分解方式然清晰易手项目进度监控 前文说户需求客户开发团队间契约户需求然成客户参项目时候关心重点实际项目程中客户真正参项目试图解项目进展状况时发现户文档外找需求影子取代堆花花绿绿项目务进展报告甘特图统计报告等报表许准确反映现项目中务分布实现状况户关心需求实现状态没什直接联系缺少语言 问题源传统项目理程中务中心理念实践种理念项目认务集合工作务分解（WBS：WorkBreakdownStructure）分派实现审核项目组部确工作容现代软件开发程强调户参项目进展仅仅务视角展现合适客户言熟悉问题描述户需求已分解成十甚百务难出间联系客户然会感迷茫更说中出需求实现状态 RDPM中提供需求实现状态图需求变化趋势需求数量完成率需求规模完成率工时消耗率等指标指标客户说更意义 需求变更 需求变更业界公认项目理重挑战尤项目期产生需求变更项目影响非常需求开发做完美瑕着客户项目系统解提出新需求者原需求作出修正需求变化避免 应需求变更思路两条：首先源头做起提高需求质量减少变更性前文已提赘述建立流程严格控制需求变更 做变更前考虑果(consequence)需求开发中处中心位旦需求发生变化影响面广通建立需求追踪矩阵分析需求击面需求果变更导致需求测试例设计编码进行变更客观信息项目理提供做出合理判断力 效理需求变更需特注意环节： 1建立正式申请处理流程 然众项目理员变更带巨影响深刻理解令解常常变更提出讨执行常常停留口头样做两弊端：首先时间长事开发团队成员说清楚变更发生结果样显然提高项目理质量改进开发程利次缺乏形式约束变更击定量化分析变更会非常意提出草率执行影响项目进展开发质量建立正式变更处理流程真正实施非常重 2定量化变更击分析 变更作计划外风险素项目肯定存击差果够定量化评估变更带影响帮助开发团队作出正确应决策变更理中击分析环节面谈分析基础追踪矩阵记录项目理素间联系关系关联关系中找潜会受影响素评估影响组合出变更整项目造成击
面例子加似关系需求会造成系列潜影响更说需求众关系复杂型应系统开发项目中3组成变更控制理委员（CCB） 作变更理核心控制环节变更控制委员会（简称CCB）起决策理作通常客户代表开发团队代表组成负责评估变更击决定否实施样变更种综合需求方（客户）开发方（开发团队）力量委员会够较权衡变更代价减少单方面考虑变更带利影响 4忽视变更执行理 实践中开发团队然组成CCB定处理流程忽视变更执行理变更实施坏完整性项目身影响样巨方面根击分析变更评审结果建立变更务列表追踪执行实践 总结 软件项目传统工程项目着种导致描述需求方式实现需求进行项目计划监控项目进度方式种传统基务项目理方法应类软件项目适里提出需求中心软件项目理通提高需求描述质量采版发布策略户需求作版目标组织计划项目开发积极应需求变更提供户需求中心项目进展视图客户起保证项目成功
文档香网(httpswwwxiangdangnet)户传
《香当网》用户分享的内容，不代表《香当网》观点或立场，请自行判断内容的真实性和可靠性！
该内容是文档的文本内容，更好的格式请下载文档
IT行业世纪70年代蓬勃发展直现理软件项目直家讨话题软件项目失败太项目彻底取消项目工期拖延等等 中国目前软件开发团队实际情况某种程度说错误赖两软件理项目项目失败重理两软件MicrosoftProjectMicrosoftWord钉钉子总斧子 工程项目vs软件项目 MicrosoftProject身错项目理工具够做务分配PetriNETGannt图资源分析等等Project理工程项目造房子修桥等等工程类项目般务驱动理方法软件项目传统工程项目质差务确定性举例子目前房产火造什样房子资金位保质保量造造10层楼1层少天天做什容易计划分配务力资源需求会变没见造房子盖3层改意拆重新盖 软件需求变化避免做项目知道需求变化实际挺频繁样容易造成计划赶变化Project定义务计划工期通常耗费项目理量时间没意义 问什需求固定呢？定许变通常工程师会问样问题果变成客户会问问题需求总会变第：出钱总更话语权（然改需求应该付费）第二：市场情况变竞争手突然发布新产品功必须做出应变更需求第三：写需求神仙犯错误犯错误允许改正（犯错误惩罚需求变更付费）传统纯瀑布式开发方式已成历史愈愈开发团队采极限编程迭代开发应付需求变更 软件项目种特点需相应项目理工具斧子钉钉子做法点合时宜 传统项目工程项目拖工期加手工期赶回软件简单新熟悉项目容花时间工期难完全赶IT老总体会问题总加手加班搞定真正效项目理效理体系支撑 需求描述 软件项目类型目前说软件项目数指应类(Application)软件项目系统类(System)项目数库文件系统开发工具系统类软件项目应类项目系统类项目花长时间研究体系架构（Architecture）设计系统框架模块间关系等等应类软件基会现成框架J2EEMicrosoft台等等精力放需求实现中国目前应系统数客户做定制开发项目企业政府机构国防等做系统做产品中企业财务系统通办公软件等等针应类项目Word写类需求什问题什问题 般Word写需隐含想法需求写定然开发部门实现般Word文档写需求庞应系统开发建议迭代方法开发面提瀑布式开发已成历史需求次性写难软件慢慢成长起（见MicrosoftSecrets）milestonemilestone发展象孩子长样中间会走弯路错路需短调整指引成难开始描绘生详细场景蓝图走（工程项目做样） 建议先想会milestonemilestone发布功然描述需求框架性需求先确定然先写实现功需求说明面需求开发行样产品较快面世客户会时出反馈减项目风险里建议写需求时候UIPrototypeUserScenario方法户越早实际界面方法越 目前项目需求MicrosoftWord写动辄十页百页样文档面讲项目理方法问题存面问题： １规模巨方便查阅中型应系统需求文档达数百页甚更分卷方便查阅 ２利更新需求文档活文档断增长更新难免Word中做更新修订模式容易出更改部分样导致开发功设计两环节沟通畅通常变成需求第版变更发邮件口头说３利时协修改 ４需求没条目化Word文档中通常描述功实际需求分成项项设置需求优先级难易程度功点（functionpoint）发布中应该做完需求源等等种类似数库特性Word难体现 ５利建立需求开发控制元素关系写需求业务员体会项目理实现需求员说非常重开发程中户需求软件需求关系软件需求开发务关系测试例需求间关系等需求变更控制质量控制非常重参考信息体化需求文档（MSWord）难做点 需求驱动项目理(RDPM) 针应软件项目汉星天公司提出传统基务项目理方法需求中心软件项目理方法理中MicrosoftProjectWord处次位 户需求软件开发源泉宿需求代表户期解决问题软件项目开发活动目标服务众软件开发实施案例中项目旦开始户言项目进入隧道列车：难需求实现状况然众形形色色项目进展报表难回答简单问题：需求究竟实现样？RDPM(RequirementDrivenProjectManagement)核心需求务 需求开发 首先需求条目化放Word文档中条目化需求设置属性通属性决定需求实现序工期查前状态等等包括里程碑制定针具体需求项时处理变更记录需求间赖关系追踪需求续开发工件（计划务测试例实现代码等）关系关系称需求追踪矩阵旦需求发生变化影响面广评估实施需求变更首先确认需求变化带击面工作赖需求追踪矩阵体系什需求条目化重原 条目化需求MSWord难理般需存放数库中 条目化解决古老问题需求描述清楚需求必须写清晰明确完整确保开发员需模糊需求做决定尤行发挥推荐wiki描述需求细节加UIprototype形象描述需求wiki处协修改方便 外实践够帮助需求开发工程师提高需求编写质量： １记录条需求原研究成果表明通记录条需求原（什实现功）删达半数谓需求然记录工作投入定工作量效避免必需求完成续工作显著降低系统规模缩短系统开发周期正谓事半功倍 ２考虑采适形式化方法然语言存歧义二义性描述导致需求解释采形式化表示方法编写需求够更加准确户开发团队间进行沟通常形式化需求表示方法包括：实体关系图数字典数流程图USECASE等然UIprototype直接简单效 ３专业工具编写需求理需求类工具没成熟理指导客户求市场相应工具汉星天公司直致力方面研究推出相应需求描述需求变更理解决方案中国百家企业非常效果 户需求vs软件需求 需求谁写呢？先两定义需求名词：户需求户需解决问题期软件力描述通常户语言描述作开发团队户系统解决问题进行沟通桥梁 软件需求建立户需求开发团队理解方式描述系统应具功开发团队进行设计实现 解般客户写word文档发封email电话需求甩开发团队写结构完整容严谨需求客户少美国基户会写需求RFP（RequestforProposal）国时候项目理做需求分析工程师会帮助户整理户需求户需求较粗户需求细化写出软件需求应系统说软件需求写开发工作简单 两种需求分记录里程碑般户需求目标户需关联软件需求 项目规划进度监控 需求作项目规划实施目标RDPM核心切需求中心 通版发布逐步实现需求 项目计划进度控制方面采迭代方法 项目目标分解较易理子目标减少项目失败风险帮助项目目标分解角度进行采版发布分阶段实现项目需求目前越越认种尤现流行敏捷开发方法更提倡迭代开发普遍误解敏捷开发方法适规模开发团队实团队样适开发团队实现模块分成项目组项目组实团队般56合适团队合作沟通成间衡 版发布针前瀑布式开发缺点提出开发方式前模式中项目漫长需求开发设计编码测试阶段够客户见面客户时间段进入盲区直开发团队隆重推出开发成果恰恰时候项目风险时候程中缺乏交流机会客户会发现产品想象样导致项目拖延者失败 版发布系统实现分解连续版实现部分系统功版结束会邀请客户评估版实现状况根户反馈制定调整版目标样做处显易见：客户越早产品越早发现开发团队间户需求方面理解差异早调整需求避免项目期调整需求带巨额代价潜处部分产品功验收投入早户提供价值然版发布会避免面较需求变更请求需仔细理需求变更 需求实现单位规划项目实施 版发布需版制定实施目标确定次版中需实现功计划修改前版缺陷户需求功表达方式户需求作版理成章然根粒度软件需求做版发布容 定版计划目标需规划实施户需求描述客户业务系统期直接采户需求作开发务安排起点合适户需求导出软件需求开发团队够理解语言结构描述适合作安排需求实现基础需求追踪矩阵帮助找版目标中户需求相关软件需求项目理找软件需求实现制定开发务形成开发务集线辅集成测试缺陷追踪形成完整开发计划样分解方式然清晰易手项目进度监控 前文说户需求客户开发团队间契约户需求然成客户参项目时候关心重点实际项目程中客户真正参项目试图解项目进展状况时发现户文档外找需求影子取代堆花花绿绿项目务进展报告甘特图统计报告等报表许准确反映现项目中务分布实现状况户关心需求实现状态没什直接联系缺少语言 问题源传统项目理程中务中心理念实践种理念项目认务集合工作务分解（WBS：WorkBreakdownStructure）分派实现审核项目组部确工作容现代软件开发程强调户参项目进展仅仅务视角展现合适客户言熟悉问题描述户需求已分解成十甚百务难出间联系客户然会感迷茫更说中出需求实现状态 RDPM中提供需求实现状态图需求变化趋势需求数量完成率需求规模完成率工时消耗率等指标指标客户说更意义 需求变更 需求变更业界公认项目理重挑战尤项目期产生需求变更项目影响非常需求开发做完美瑕着客户项目系统解提出新需求者原需求作出修正需求变化避免 应需求变更思路两条：首先源头做起提高需求质量减少变更性前文已提赘述建立流程严格控制需求变更 做变更前考虑果(consequence)需求开发中处中心位旦需求发生变化影响面广通建立需求追踪矩阵分析需求击面需求果变更导致需求测试例设计编码进行变更客观信息项目理提供做出合理判断力 效理需求变更需特注意环节： 1建立正式申请处理流程 然众项目理员变更带巨影响深刻理解令解常常变更提出讨执行常常停留口头样做两弊端：首先时间长事开发团队成员说清楚变更发生结果样显然提高项目理质量改进开发程利次缺乏形式约束变更击定量化分析变更会非常意提出草率执行影响项目进展开发质量建立正式变更处理流程真正实施非常重 2定量化变更击分析 变更作计划外风险素项目肯定存击差果够定量化评估变更带影响帮助开发团队作出正确应决策变更理中击分析环节面谈分析基础追踪矩阵记录项目理素间联系关系关联关系中找潜会受影响素评估影响组合出变更整项目造成击
面例子加似关系需求会造成系列潜影响更说需求众关系复杂型应系统开发项目中3组成变更控制理委员（CCB） 作变更理核心控制环节变更控制委员会（简称CCB）起决策理作通常客户代表开发团队代表组成负责评估变更击决定否实施样变更种综合需求方（客户）开发方（开发团队）力量委员会够较权衡变更代价减少单方面考虑变更带利影响 4忽视变更执行理 实践中开发团队然组成CCB定处理流程忽视变更执行理变更实施坏完整性项目身影响样巨方面根击分析变更评审结果建立变更务列表追踪执行实践 总结 软件项目传统工程项目着种导致描述需求方式实现需求进行项目计划监控项目进度方式种传统基务项目理方法应类软件项目适里提出需求中心软件项目理通提高需求描述质量采版发布策略户需求作版目标组织计划项目开发积极应需求变更提供户需求中心项目进展视图客户起保证项目成功
文档香网(httpswwwxiangdangnet)户传
《香当网》用户分享的内容，不代表《香当网》观点或立场，请自行判断内容的真实性和可靠性！
该内容是文档的文本内容，更好的格式请下载文档
