第2章IT项目管理之需求管理课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第2章IT项目管理之需求管理,*,第2章IT项目管理之需求管理,2024/11/24,第2章IT项目管理之需求管理,第2章IT项目管理之需求管理2023/9/29第2章IT项目,1,需求工程,需求获取,需求分析,文档编写,需求状态,需求跟踪,版本控制,需求开发,需求管理,需求验证,需求变更,第2章IT项目管理之需求管理,需求工程需求获取需求分析文档编写需求状态需求跟踪版本控制需求,2,基础认知,需求相关概念剖析,第2章IT项目管理之需求管理,基础认知需求相关概念剖析第2章IT项目管理之需求管理,3,需求的重要性,需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,第2章IT项目管理之需求管理,需求的重要性需求是业务的根源，需求工作的优劣对业务影响最大。,4,需求是缺陷主要来源,错误定位费用分析,错误引入阶段分析,James Martin：,超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,James Martin：,80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误,第2章IT项目管理之需求管理,需求是缺陷主要来源错误定位费用分析错误引入阶段分析James,5,一个小故事,第2章IT项目管理之需求管理,一个小故事第2章IT项目管理之需求管理,6,如何练就需求分析的火眼金晴？,5W + 1H + 8C,5W就是 Who、When、Where、What、Why,Why是关键,1H就是 How 需求本身的流程,8C指的是8个约束和限制，即8个Constraints：,包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility,第2章IT项目管理之需求管理,如何练就需求分析的火眼金晴？ 5W + 1H + 8C 第2,7,如何建立组织级需求工程？,专业的角色做专业的事？,专业的人做专业的事？,第2章IT项目管理之需求管理,如何建立组织级需求工程？专业的角色做专业的事？专业的人做专业,8,需求工程贯穿开发全过程,设计需求,架构设计,系统规格,软件需求,硬件需求,质量属性,DFX,业务需求,用户需求,内部需求,客户要求,功能需求,非功能需求,标准约束,书面标准,事实标准,第2章IT项目管理之需求管理,需求工程贯穿开发全过程设计需求架构设计系统规格软件需求硬件需,9,需求存在什么问题,不是“大而全”，而是“准而精”；,镀金.swf,不是“热点组合”，而是“关键点组合”；,不是“盲目跟风”，而是“为我所用”；,不是“形成报告”，而是“达成共识”。,CRUDL,Create-Read-Update-Delete-List,第2章IT项目管理之需求管理,需求存在什么问题不是“大而全”，而是“准而精”；镀金.swf,10,1.可行性研究,项目的机会选择,初步可行性研究,详细可行性研究,（1）,可行性分析报告模版,（2）,金蝶公司可行性分析报告,2.项目立项,立项管理过程,建设方的立项管理,承建方的立项管理,（1）,某大型集团IT项目实施管理方法,（2）,校务通模型,可研与立项,第2章IT项目管理之需求管理,1.可行性研究2.项目立项可研与立项第2章IT项目管理之需求,11,第2章IT项目管理之需求管理,第2章IT项目管理之需求管理,12,合同项目立项过程,1.甲方过程,招标书定义、乙方选择、合同签署,2.乙方过程,项目分析、竞标、合同签署,3.相关文档,立项报告、可行性分析报告、,标书,第2章IT项目管理之需求管理,合同项目立项过程1.甲方过程第2章IT项目管理之需求管理,13,需求分析在工程中的位置,第2章IT项目管理之需求管理,需求分析在工程中的位置第2章IT项目管理之需求管理,14,用户/系统,业务,管理者,初始需求,变更的需求,获取,分析,定义,验证需求,控制需求变更,需求规格说明,项目环境,需求开发,需求管理,需求工程活动综合关系,第2章IT项目管理之需求管理,用户/系统业务管理者初始需求变更的需求获取,分析,定义,验证,15,包括：需求确认、需求变更控制、需求跟踪,1、需求确认,需求确认是指开发方和用户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,需求管理的最终作用,需求管理的目的是在用户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。,第2章IT项目管理之需求管理,包括：需求确认、需求变更控制、需求跟踪需求管理的最终作用,16,一、需求确认,项目开发面临的实际问题,第2章IT项目管理之需求管理,一、需求确认项目开发面临的实际问题第2章IT项目管理之需求管,17,项目开发面临的实际问题,第2章IT项目管理之需求管理,项目开发面临的实际问题第2章IT项目管理之需求管理,18,项目开发面临的实际问题,第2章IT项目管理之需求管理,项目开发面临的实际问题第2章IT项目管理之需求管理,19,需求验证的目的和任务,需求验证的目的就是要确保软件需求具有良好的特性（如完整性，正确性等）。,需求验证包含的活动,满足性（功能需求是否满足需要）,满意性（非功能需求是否满意）,明确及含蓄的需求(失败),、,(成功),共识行（是否能共同理解）,可行性（技术是否可行）,明晰性（信息是否存在含混性）,第2章IT项目管理之需求管理,需求验证的目的和任务需求验证的目的就是要确保软件需求具有良好,20,1、为需求进行正式评审,正式的审查过程,第2章IT项目管理之需求管理,1、为需求进行正式评审正式的审查过程第2章IT项目管理之需求,21,需求评审做不好的后果：, 需求变更, 需求不明确, 需求不可测, 需求不可实现, 导致后续工作难于开展或经常出现变更,由于需求未能得到有效管理， 在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。,第2章IT项目管理之需求管理,需求评审做不好的后果： 需求变更 第2章IT项目管理之,22,如何进行需求评审, 参与需求分析和评审的人员的管理, 软件需求文档的管理, 需求分析过程的管理, 需求变更的管理,第2章IT项目管理之需求管理,如何进行需求评审 参与需求分析和评审的人员的管理 第2,23,需求规格评审实例,例1：“产品应在不少于每秒的正常周期内提供状态信息。”,分析：这个需求是不完整的：,状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。,第2章IT项目管理之需求管理,需求规格评审实例例1：“产品应在不少于每秒的正常周期内提供状,24,需求规格评审实例,例1需求：,后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息；,如果后台进程处理正常，那么应该显示任务已完成的百分数/比；,任务完成时，应显示相关的信息；,后台任务出错应该显示错误信息；,为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。,第2章IT项目管理之需求管理,需求规格评审实例例1需求：第2章IT项目管理之需求管理,25,需求规格评审实例,例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换”,计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。,第2章IT项目管理之需求管理,需求规格评审实例例2：“产品应瞬间在文本中的显示和隐藏不可打,26,需求规格评审实例,例2需求：,用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。,现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。,第2章IT项目管理之需求管理,需求规格评审实例例2需求：第2章IT项目管理之需求管理,27,需求规格评审实例,例3：“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。,单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？,第2章IT项目管理之需求管理,需求规格评审实例例3：“HTML分析器可以产生HTML标记错,28,需求规格评审实例,例3需求：,“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。,现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。,第2章IT项目管理之需求管理,需求规格评审实例例3需求：第2章IT项目管理之需求管理,29,需求规格评审实例,练习：,以下描述哪些属于不精确的用户需求描述？如果不精确，应如何改正？,1）系统应表现出良好的响应速度。,不精确，应指出具体项目和响应时间。,2）系统必须用菜单驱动。,“必须”不精确，因系统还可以用其他方式驱动。,3）在数据录入界面，应该有10个按钮。,不精确，因过于细致，限制了设计的自由度。,4）系统运行时占用的内存不得超过200M。,仅是一个约束条件。,5）电梯应平稳运行。,不精确，应指出加速、减速、运行速度的大小。,6）即使系统崩溃，也不能损坏用户数据。,不精确，因这是一个难以保证的“用户需求”。,第2章IT项目管理之需求管理,需求规格评审实例 练习：以下描述哪些属于不精确的用户需求描,30,2、为需求写测试用例,目标是识别需求的含混性,以需求为基础，并视其为黑盒子，然后编写测试用例。,要覆盖需求常见的测试点,入口条件,出口条件,主事件流,可选事件流,非功能需求,第2章IT项目管理之需求管理,2、为需求写测试用例目标是识别需求的含混性 第2章IT项目管,31,3、用检查单识别常见问题,第2章IT项目管理之需求管理,3、用检查单识别常见问题第2章IT项目管理之需求管理,32,4、为需求设定优先级,支持项目分期交付,支持需求取舍之道,支持需求的模式化,第2章IT项目管理之需求管理,4、为需求设定优先级支持项目分期交付第2章IT项目管理之需求,33,为什么要设定需求的优先级,软件开发受时间、成本、质量等多种资源的限制，同时软件开发的高不确定性，导致,需求在项目结束时往往难以被全部实现。,因此需要在需求开发阶段，对需求进行分解，,设定优先级,，先实现优先级别较高的需求，,有助于维护项目收益和提高项目成功率。,第2章IT项目管理之需求管理,为什么要设定需求的优先级软件开发受时间、成本、质量等多种资,34,基于价值、费用和风险的优先级设定,费用方法（Cost）：,价值方法（Value）：,风险方法（Risk）：,最小费用优先原则,最高价值优先原则,最低风险优先原则,它们本质上从单一视角探寻适用标准来评价每个需求，并且计算出一个分值用于编排需求的优先级。,如何设定需求的优先级,第2章IT项目管理之需求管理,基于价值、费用和风险的优先级设定费用方法（Cost）：最小费,35,基于价值、费用和风险的优先级设定,XXX,XX%,X,XX%,X,XX%,XX,X,X,n. XXXXX,优先级,风险%,相对风险,费用%,相对费用,价值%,总价值,相对损失,相对利润,需求/特性,XXX,XX%,X,XX%,X,XX%,XX,X,X,1. XXXXX,总计,X,X,X,X,相对权值,在一个平面中列出要设定优先级的所有需求、特性或使用实例；在这个例子中，我们将使用特性来设定优先级。,所有项都必须在同一抽象级别上；不要把个人需求与产品特性混合在一起。如果某些特性有逻辑上的联系（例如，只有包括特性A的情况下才能实现特性B）那么在分析中只要列出驱动特性就可以了。,这种模型在其有效范围内可以容纳几十种特性。如果你有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。如果你需要的话，可以在更详细的级别上进行第二轮分析。,估计每一个特性提供给客户或业务的相关利益，并用1 9划分等级，1代表可忽略的利益，9代表最大的价值。,这些利益等级表明了与产品的业务需求的一致性。客户代表是判断这些利益的最佳人选。,在缺省情况下，利润和损失的权值是相等的，作为一种精化，你可以更改这两个因素的相对权值。,估计出如果没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。,使用1 9划分等级，这里1代表基本无损失， 9代表严重损失。,总价值相对利润相对损失,价值%=总价值/总计价值100,根据需求的复杂度，所需求的用户界面的实现情况、重用当前代码的潜在能力、所需要的测试量和文档等等，开发者可以估算出费用。,估计实现每个特性的相对费用，使用1（低） 9（高）划分等级。,平面图将计算出由每一个特性所构成的总费用的百分比。,开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用1 9划分等级。,1级表示你可以轻而易举地实现编程，而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。,平面图将计算出每个特性所产生的风险百分比。在缺省情况下，利润损失，费用和风险的权值是相等的，但是你可以在平面图中调整其权值。,如果你无需在模型中考虑风险，就把风险的权值设为0。,价值%,优先级,（费用%费用权值）（风险%风险权值）,第2章IT项目管理之需求管理,基于价值、费用和风险的优先级设定XXXXX%XXX%XXX%,36,优先级设定演示,相对权值,2,1,1,0.5,需求/ 特性,相对,利润,相对,损失,总,价值,价值,%,相对,费用,费用,%,相对,风险,风险,%,优先级,UC1,5,3,13,8.4,2,8,1,3.0,1.345,UC2,9,7,25,16.2,5,11.9,3,9.1,0.987,UC3,5,5,15,9.7,3,7.1,2,6.1,0.957,UC4,2,1,5,3.2,1,2.4,1,3.0,0.833,UC5,4,9,17,11.0,4,9.5,4,12.1,0.708,UC6,4,3,11,7.1,3,7.1,2,6.1,0.702,UC7,6,2,14,9.1,4,9.5,3,9.1,0.646,UC8,9,8,26,16.9,7,16.7,8,22,0.586,UC9,3,4,10,6.5,4,9.5,2,6.1,0.517,UC10,7,4,8,11.7,9,21.4,7,21.2,0.365,总计,54,46,154,100,42,100,33,100,迭代1,BaseLine=UC1-3,迭代2,BaseLine=UC4-6,迭代3,BaseLine=UC7-9,第2章IT项目管理之需求管理,优先级设定演示相对权值2110.5 需求/ 特性相对相对总,37,5、最后：形成总体共识,本需求文档建立在双方对需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白，需求的变更将导致双方重新协商成本、资源和进度等。,甲方负责人签字,乙方负责人签字,第2章IT项目管理之需求管理,5、最后：形成总体共识 第2章IT项目管理之需求管理,38,什么是需求变更？,项目实现需求的程度(失败),、,（成功）,初始需求,变更的需求,对问题的,初始理解,对问题的,新理解,时间,二、控制需求变更,第2章IT项目管理之需求管理,什么是需求变更？初始需求变更的需求对问题的对问题的时间二、控,39,受控的需求,需求文档V1,系统实现,V1,系统实现,V2,需求变更,第2章IT项目管理之需求管理,受控的需求需求文档V1系统实现系统实现需求变更第2章IT项目,40,受控的需求变更,需求文档V1,需求文档V2,系统实现,V1,系统实现,V2,需求变更,由CCB委员会裁定,第2章IT项目管理之需求管理,受控的需求变更需求文档V1需求文档V2系统实现系统实现需求变,41,CCB的解释,CCB,变更控制委员会(,Change Control Board,),CCB,是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，不提出变更方案。,第2章IT项目管理之需求管理,CCB的解释CCB 变更控制委员会(Change Contr,42,批准,提出变更请求,变更影响评估,评审评估报告,审批,用户认可,修订项目计划,实施变更,验证,变更结束,拒绝,修正,需求变更控制流程,第2章IT项目管理之需求管理,批准提出变更请求变更影响评估评审评估报告审批用户认可修订项目,43,需求变更申请单（我国）,第2章IT项目管理之需求管理,需求变更申请单（我国）第2章IT项目管理之需求管理,44,变更管理五级成熟度模型,第2章IT项目管理之需求管理,变更管理五级成熟度模型第2章IT项目管理之需求管理,45,需求变更案例分析,面对客户的需求变更，接受还是拒绝？,在某公司的项目管理课堂上，小李，小王、小林等人正在七嘴八舌地议论纷纷。原来，大家正在讨论公司最近遇到的两个颇为有趣的项目。,第2章IT项目管理之需求管理,需求变更案例分析面对客户的需求变更，接受还是拒绝？第2章IT,46,情况1：尽量满足用户需要,据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。,第2章IT项目管理之需求管理,情况1：尽量满足用户需要据小王介绍，这两个项目分别由两个项目,47,情况2：严格执行项目计划,相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。,第2章IT项目管理之需求管理,情况2：严格执行项目计划相比之下，项目经理B显得稍有些“盛气,48,分析1 不太迁就用户,小王：“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”,第2章IT项目管理之需求管理,分析1 不太迁就用户小王：“对项目经理来说，成本、质量和时间,49,分析2 坚持原则，适当调节用户关系,小林：“当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”,第2章IT项目管理之需求管理,分析2 坚持原则，适当调节用户关系小林：“当前，国内的项目一,50,分析3 用户就是上帝,小李：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。”,第2章IT项目管理之需求管理,分析3 用户就是上帝小李：“不管怎样，客户才是第一位的。客户,51,问题：,1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？,2、分析这两种应对需求变更方式的优缺点。,第2章IT项目管理之需求管理,问题：第2章IT项目管理之需求管理,52,指导策略：合理控制,1、根据客户提出需求的实际情况而定,对于客户的需求，如何是合理的，在自己的范围之内，是可以变更的，但是如果在对前面的主体框架是做以否定的话，那就断然拒绝！,第2章IT项目管理之需求管理,指导策略：合理控制1、根据客户提出需求的实际情况而定第2章I,53,指导策略：合理控制,2、把握好度,项目的目的是在规定的时间内完成规定的内容。,项目范围在项目启动阶段就已经确定下来了，绝对不能更改的。,如果经常更改，项目经理需要分析一下原因。,如果是客户原因需要更改，项目经理需要分析工作量，尽量少做改动，但是不能完全拒绝客户。,如果全盘接受，客户会毫无顾及的更改；,如果全然拒绝，就没做好沟通管理。,第2章IT项目管理之需求管理,指导策略：合理控制2、把握好度第2章IT项目管理之需求管理,54,随着开发工作的进展需求将逐步扩展和演化,各个开发阶段的工作业务之间存在的继承关系,使每一项需求均能追溯到,前后继承关系的脉络清晰可见,三、需求跟踪,第2章IT项目管理之需求管理,随着开发工作的进展需求将逐步扩展和演化三、需求跟踪第2章IT,55,开发,阶段,需求,状态,需求,建议,设计,编码,测试,获取,定义,承诺,设计,实现,完成,生存期各阶段需求状态的演变,第2章IT项目管理之需求管理,开发需求需求建议设计编码测试获取定义承诺设计实现完成生存期各,56,需求的类型及其追踪性,问题,解决方案领域,业务领域,业务需求,用户需求,软件需求,测试规约,设计,或代码,用户,手册,所要,构建的,系统,追踪性,第2章IT项目管理之需求管理,需求的类型及其追踪性问题解决方案领域业务领域业务需求用户需求,57,需求跟踪归纳如下：,1、建立和维护需求跟踪矩阵,正向跟踪,逆向跟踪,当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵,2、查找不一致,后续工作成果没有实现需求文档中的某些需求,后续工作成果实现了需求文档中不存在的需求,后续工作成果没有正确实现需求文档中的需求,3、消除不一致,将消除不一致记录到“需求跟踪报告”,消除不一致后，项目经理更新“需求跟踪矩阵”,第2章IT项目管理之需求管理,需求跟踪归纳如下：第2章IT项目管理之需求管理,58,软件需求属性矩阵,属性,需求,需求,状态,优先级,工作量,风险,稳定性,产品,版本,职责,分配,原因,功能需求,非功能需求,设计约束,第2章IT项目管理之需求管理,软件需求属性矩阵 属性需求优先级工作量风险稳定性产品职责,59,第2章IT项目管理之需求管理,第2章IT项目管理之需求管理,60,实现,“需求全生命周期”,的管理,达到,“,需求,-,开发,-,测试,”一体化,第2章IT项目管理之需求管理,实现“需求全生命周期”的管理第2章IT项目管理之需求管理,61,需求生命周期管理平台,第2章IT项目管理之需求管理,需求生命周期管理平台第2章IT项目管理之需求管理,62,一些重要名词解释,管理流程：用于管理的规范流程（例如：需求确认、审批、签署、验收、变更流程等）,OBS：组织分解结构（以树形结构描述项目参与组织与角色的分解）,WBS: 工作分解结构（以树形结构描述工作任务分解）,PBS：产品分解结构（以树形结构描述交付物分解）,RBS: 资源分解结构（以树形结构描述服务于项目的资源）,报表模版：项目执行所需要的报表、报告、文档的模版,活动：Activity（WBS的叶子），也称为工作，作业等,依赖关系：作业(活动)的先后次序,资源：有形资源，为完成工作所用到的人财物,日历：工作日历,关键路径：一系列不得有任何推迟的工作，否则就来不及了,浮时：那些有可能能推迟的工作的浮动时间量,基线：计划的快照，形成比较基准,风险：预计未来可能发生并对项目产生影响的事件,变更：项目进行过程中产生的新需求或原有需求的变化,第2章IT项目管理之需求管理,一些重要名词解释管理流程：用于管理的规范流程（例如：需求确认,63,项目管理基础动画教程,1、,资源分配管理；,2、,个人效能；,3、,资源管理；,4、,风险管理；,5、,承诺；,6、,不懂承诺的管理者；,7、,不明白依赖；,8、,不知后果；,9、,理解承诺事项；,10、,索取承诺的困难；,11、,信口开河；,12、,假装信心；,13、,不切实际的信心；,14、,其实不可能做到；,15、,其实做到是万幸；,16、,没有自知之明；,17、,对任何人都说尽力；,18、,项目缺失了什么,；,19、,现状调查,。,第2章IT项目管理之需求管理,项目管理基础动画教程1、资源分配管理；11、信口开河；第2章,64,演讲完毕，谢谢听讲,!,再见，see you again,3rew,2024/11/24,第2章IT项目管理之需求管理,演讲完毕，谢谢听讲!再见，see you again3rew,65,