IT项目管理教程之五

《IT项目管理教程之五》由会员分享，可在线阅读，更多相关《IT项目管理教程之五（64页珍藏版）》请在金锄头文库上搜索。

1、1 讲座5目标 范围管理与需求工程 2 为什么实施该项目 项目要达到什么样的结果 如何实施该项目 项目工作的具体内容是什么 如何定义该项目完成 3 主要内容 目标管理范围管理需求管理管理需求的目的需求管理的困难性软件需求特性需求工程如何获取需求需求规格说明需求管理工具 4 目标管理的早期发展 一般认为 目标管理的思想是得鲁克在1954年发表的 管理实践 一书中提出来的 在此之前 一些企业也提出了类似的管理思想如通用电气公司1954年为进行改组而拟订的广泛计划中 提出 管理决策的分散进行 要求用客观目标和对目标完成进度的客观测定来代替主观的评价和个人的监督 通过实行一种客观的测定计划 可把主观人

2、员从具体事务中解脱出来 因此 目标管理的思想是管理学家和企业界共同努力的结果 5 目标管理的概念 目标管理是参与管理的一种形式 上下级目标形成 目标 手段 链强调 自我控制 人们应 控制 的是行为的动机而不是行为本身促进下放权力 有助于协调集权与分权的矛盾注重成果第一的方针 目标考核体系 6 项目目标 项目目标就是实施项目要达到的期望结果特点多目标性 时间 成本和性能优先性 不同的目标有不同的优先级 在生命周期的不同时刻 优先级也不同 如性能是初始阶段考虑的重点 实施阶段重点考虑成本 时间在结束阶段显得更紧迫 层次性 总体目标 具体目标 具体计划 如上大学 总体目标 自我实现 为将来获得更高的

3、社会地位 取得更高收入 实现个人追求具体目标 1 在交纳一定学费的基础上 4年取得学位 2 掌握软件工程方面知识和理念 3 结交新朋友具体计划 4年内的课程安排 7 项目目标的描述 应该不应该定量的 可度量的定性的 不可度量的使每个成员都能清楚认识与项目成员无关现实的理想化的简单的复杂的面向结果的面向成本的能够起激励作用无激励作用例子 如一个医疗部门的目标描述可能是 治愈所有的疾病 或 治愈所有的病人 两者表面相同 实质差别很大 8 目标管理的一些建议 目标要分等级层次社会经济方面的总目标使命组织的总目标 长期的 战略的 更详细的总目标分公司目标部门和单位的目标个人的目标成效 个人的培养目标

4、9 目标要形成一个网络如果各具体目标之间互相不关联 彼此不支持 人们就会采用对自己的职能似乎是有益的方法 但对公司整体而说可能是巨大的损失注重目标的多样性可以有多个目标但是目标过多就等于没有目标 10 长期目标和短期目标互为整体选择短期目标的过程也是评定长期目标先后次序的过程培养管理者的素质有效的管理者的共同之处不在于他们拥有什么 也不在于他们是什么样的人 而在于发挥有效性的实践善于利用时间注意贡献善于发现和使用他人的长处 能用人之长 容人之短要善于分清工作的主次先后要善于作出有效的决策目标管理的实践经验对美国500家最大的工业公司调查 在403家中188家实施了目标管理方法 36家认为非常成

5、功 占188家的19 左右 11 目标 范围管理 12 项目范围管理 项目范围是指为了成功达到项目的目标 项目所规定要做的工作 在项目环境中 范围 产品范围 即一个产品或一项服务应该包含哪些特征和功能产品规格 即产品所包含的特征和功能具体是怎样的项目范围 即为了交付具有所指特征和功能的产品所必须要做的工作 13 项目范围的管理过程 启动 指组织正式开始一个项目或继续到项目的下一个阶段 启动过程的一个输出就是项目章程 项目章程正式承认项目的存在并对项目提供一个概览 范围计划 指进一步形成各种文档 为将来项目决策提供基础 包括用以衡量一个项目或项目阶段是否已经顺利完成的标准等 范围定义 指项目主要

6、的可交付成果细分为更小的 更易管理的成分范围核实 指对项目范围的正式认定 项目主要涉及人员 如客户或发起人要在这个过程中正式接受项目可交付成果的定义范围变更控制 指对有关项目范围的变更进行控制 主要的过程输出是范围变更 纠正行动与教训总结 软件项目的范围管理 需求管理 15 为什么要管理需求 系统开发团队之所以管理需求 是因为他们想让项目获得成功 满足项目需求即为成功打下了基础 若无法管理需求 达到目标的几率就会降低 为什么要管理需求 避免失败就是一个很充分的理由 提高项目的成功率和需求管理所带来的其他好处同样也是理由 16 需求管理的重要性 真的很重要吗 例 Ourreal timeexam

7、pleisbasedontheembeddedsoftwareintheAriane 5 aspacerocketbelongingtotheEuropeanSpaceAgency ESA OnJune4 1996 onitsmaidenflight theAriane 5waslaunchedandperformedperfectlyforapproximately40seconds Then itbegantoveeroffcourse AtthedirectionofanArianegroundcontroller therocketwasdestroyedbyremotecontrol

8、 Thedestructionoftheuninsuredrocketwasalossnotonlyoftherocketitself butalsoofthefoursatellitesitcontained thetotalcostofthedisasterwas 500million Newsbyteshomepage1996 Lionsetal 1996 17 需求分析的重要性 Thereason therewasnodiscussionintherequirementsdocumentsofthewaysinwhichtheAriane 5trajectorywouldbediffe

9、rentfromAriane 4 统计资料 In1994 theStandishGroupsurveyedover350companiesabouttheirover8000softwareprojectstofindouthowwelltheywerefaring Theresultsaresobering Thirty onepercentofthesoftwareprojectswerecanceledbeforetheywerecompleted Moreover inlargecompanies only9 oftheprojectsweredeliveredontimeandcos

10、twhattheywerebudgeted and16 metthosecriteriainsmallcompanies Standish1994 18 需求管理的重要性 19 需求分析的重要性 5点事实软件生命周期中 一个错误发现得越晚 修复错误的费用越高 20 需求管理的重要性 许多错误是潜伏的 并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误DeMarco在一份研究报告中指出 被检查出来的错误的56 产生的根源可以追溯到需求阶段 AIRMICS所进行的一项调查发现 在一份美国军方大型管理信息系统的需求现格说明书 SRS 中存在着500多个错误 当然这仅仅是一个软件项目中

11、的一次调查 在需求阶段 代表性的错误为疏忽 不一致和二义性美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究 得出的研究数据表明 A 7E项目中77 的需求错误特点是不明确 疏忽 不一致和二义性 按错误类型对这些错误分布进行分析的结果是 49 不正确的事实 31 疏忽 l3 不一致 5 二义性 21 需求管理的重要性 需求错误是可以被检查出来的 22 需求管理的重要性 在需求过程中会产生很多错误 事实3和4 许多错误并没有在早期被发现 事实2 这样的错误是能够在产生的初期被检查出来的 事实5 如果没有及时检查出来这些错误 软件费用会直线上升 事实1 23 需求管理的困难性 2

12、4 需求管理的困难性 需求不总是显而易见的 而且它可来自各个方面 需求并不总是能容易用文字明白无误地表达 存在不同种类的需求 其详细程度各不相同 如果不加以控制 需求的数量将难以管理 需求之间相互关联 而且需求也和软件工程流程中的其他可交付工件有关 需求有唯一的特征或特征值 例如 它们的重要性和容易满足的程度都各不相同 需求涉及众多相关方面 这意味着需求要由功能交叉的各组人员管理 需求会变更 25 什么是软件需求 需求为用户解决问题或达到目标所需的条件或权能系统或系统部件要满足合同 标准 规范和其它正式规定文档所需具有的条件或权能一种反映上述条件或权能的文档说明 26 需求的层次性 项目视图与

13、范围文档 其它非功能需求 UseCase文档 软件需求规格说明 27 产生不合格需求的原因 产生不合格的需求说明的原因无足够的用户参与 原因感到与用户合作不如编写代码有意思因为开发人员觉得已经明白用户的需求了用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划 28 优秀需求具有的特性 完整性正确性可行性必要性划分优先级无二义性可验证性 29 需求工程的概念 需求工程 需求开发 需求管理 问题获取 分析 编写规格说明 验证 30 需求工程涉及人员 31 需求获取 需求的来源访问并与有潜力的用户探讨把对目前的或竞争产品的描述写成文档系统需求规格说明对当前系统的

14、问题报告和增强要求市场调查和用户问卷调查观察正在工作的用户用户任务内容分析 32 用户分类 用户及其分类各种用户对系统具用不同的要求 如一个没有经验的用户关心系统是否简单易用 对于高级用户则关心产品的易用性和高效性 因而需要对用户进行分类 每一个用户类将有自己的一系列功能和非功能要求在项目中 要尽早为产品确定并描述不同的用户类 这样就能从每一个重要的用户类代表中获取不同的需求 33 寻找用户代表 寻找用户代表每个一个用户类必须有一名和几名用户代表参与软件开发项目周期对于直接面向客户的项目 用户代表相对容易找到 对于商品化软件 用户代表 此时称为产品代表 比较难找到 产品代表者必须是真正的用户

15、而不是用户的代理人 如主办者 产品客户 市场人员必须给产品代表者足够的尊重 否则将挫伤他们的积极性 34 产品代表者 如何寻求产品代表者与大公司建立联系通过产品打折或者免费使用的方式来吸引产品代表者要注意技术泄漏问题真正聘请具有丰富经验的合适的产品代表者 35 谁说了算 谁说了算 问题如果个别用户不能在需求方面达成一致的意见 那么必须由产品代表者作出决策 这种方法的实质是授权给产品代表者 由其解决他们所代表用户的需求冲突问题如果不同的用户类有不一致的需求 那么必须决策出满足哪一类用户的需求更为重要 了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何 将有助于呢决定哪一个用户

16、类所占份额最大 36 谁说了算 不同公司的客户可能都要求产品按照他们各自的喜好来设计 运用项目的业务目标来决定哪些是你最关心的客户 非核心客户的需求可以安排在下一个版本中开发 客户经理与真正用户的需求相冲突 用户需求必须与业务需求一致 因此 必须说服那些没有亲自使用过产品的经理服从代表他们用户的产品代表者提出的详细的用户需求和功能性规格说明 当开发者想像的产品与客户需求冲突时 通常应该由客户作出决策 然而 不要陷入 客户总是对的 的陷阱中去 现实中 客户并不总是对的 37 谁说了算 如果市场部门提出的需求与开发者所想要开发的系统发生冲突时 通常由于市场人员作为客户的代理人 市场需求具有更重的分量 但是 市场人员可能会一味地迁就客户需求 没有简单的正确答案 38 聆听客户的需求 访谈 访谈要点 事先需调查涉众或用户以及公司的背景 访谈前对问题进行复审 在访谈期间要参照一定的格式 以确保提出正确的问题 在访谈结束时总结两 三个最为重要的问题 重复您听到的内容 以确认您的理解是否正确 39 聆听客户的需求 访谈 寻求客户客户是谁 用户是谁 他们的需要是否不同 他们具有什么背景 能力和环境 业