项目管理之需求分析.ppt

项目管理 ProjectManagement 需求管理 InternalTrainingMaterials CONFIDENTIALINFORMATION Donotdisclose I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 2 从一个典型的失败项目说起 需求和功能设计 现实一个小项目 感觉需求也简单 再加上时间紧 如果从需求开始一步步来 时间肯定来不及 在这种情况下 项目就匆匆的开始了 为了节省时间 需求分析 架构设计等等都不去考虑了 想到哪写到哪 完全瀑布式开发 直接结果是 完工时间一拖再拖 最后不得不决定下一版本整个推倒重来 No 3 从一个典型的失败项目说起 需求和功能设计以上示例失败的原因需求分析不到位 架构设计不合理 Do 需求分析做的好 架构设计合理 灵活的适应变化的需求 Don t 需求分析做的好 架构设计不合理 项目也可以实现 只是以后的维护会有困难 架构好了 需求没有做好 随着需求的进一步完善 项目也会完成 如果都没有做好 象这个项目一样 就只能有两种选择 尽早重来 下一个版本重新开始好的需求 会加快项目的进度 也可以给开发人员的设计提供帮助 项目开始前一定要做好需求和设计 至少要有明确的思路 匆忙开始的项目很可能会失败 至少也会走弯路 而走弯路花的时间很可能会超过在需求和设计上省下来的时间 更不用说失败的项目所造成的后果 No 4 需求内容 业务需求 反映了组织机构或客户对网站 产品高层次的目标要求 通常在项目定义与范围文档中予以说明 例如 电子商务网站中 关于客户在线业务流程实现 在线产品展示 订单与支付等 整个过程都要符合客户企业自身的业务运作流程 为客户服务 用户需求 描述了用户使用网站必须要完成的任务 这在使用实例或方案中予以说明 例如 描述 招聘系统 功能 用户可分部门浏览职位招聘情况 可在线填写简历 用户填写的简历字段可定制 后台可分类检索简历 No 5 需求内容 功能需求 定义了开发人员必须实现的系统功能 使用户利用系统能够完成他们的任务 从而满足了业务需求 例如 系统需要具有网站统计分析功能 需要统计出每日 每月 每年的点击量 PV值 用户来源 非功能性的需求 描述了系统展现给用户的行为和执行的操作等 它包括系统必须遵从的标准 规范和约束 操作界面的具体细节和构造上的限制 例如 系统是按照W3C标准进行开发制作 首页BANNER区以FLASH形式展现 首页新闻区域采用JAVASCRIPT效果以标签形式展现 需求分析报告 报告所说明的功能需求充分描述了系统所应具有的外部行为 需求分析报告 在开发 测试 质量保证 项目管理以及相关项目功能中起着重要作用 No 6 什么是好需求 需求要从客户的角度去寻找需求是客户要求的抽象 而不是具体的表现 这样做的需求才能对以后的设计产生积极的影响 而一些具体的要求可能都是易变的 这些可能是商业政策 而不是真正的需求 需求总是易变的这就要求架构要有灵活性 灵活性不是靠提前设计实现 你认为将来会有的需求 而是靠抽象 这样可以在需求变化时 架构做最少的修改 从开发者角度说 需求是架构必须要实现的要求要把抽象的需求再扩展到具体 这样需求就经历了从具体 客户的描绘 到抽象 架构 好的需求 再到具体 实现 的一个过程都是自己的理解 No 7 I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 8 如何寻找客户的需求如果你赞成客户的参与是发布一个优秀软件的关键因素 在项目的开始阶段就会努力致力于为你的项目征求各个客户的意见 为了征求客户的意见 必须采取以下几步 明确项目用户需求的来源 访问并与有潜力的用户探讨 把对目前的或竞争产品的描述写成文档 系统需求规格说明 对当前系统的问题报告和增强要求指导用户和提供技术支持的工作人员是最有价值的需求来源 市场调查和用户问卷调查 用户任务的内容分析 明确使用该产品的不同类型的用户 与产品不同用户类的代表进行沟通 遵从项目的最终决策者的意见 No 9 I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 10 项目需求分析难在哪里有几种原因使需求分析变得困难 客户说不清楚需求有些客户对需求只有朦胧的感觉 当然说不清楚具体的需求 例如全国各地的很多政府机构在搞网络建设 这些单位的领导和办公人员大多不清楚计算机网络有什么用 反而要系统分析人员替他们设想需求 有些客户心里非常清楚想要什么 但却说不明白 如果客户本身就懂开发 能把需求说得清清楚楚 这样的需求分析将会非常轻松 愉快 如果客户全不懂开发 但信任开发方 事情也比较简单 分析人员可以引导客户 先阐述常规的需求 再由客户否定不需要的 最终确定客户真正的需求 最怕的就是 不懂装懂 或者 半懂充内行 的客户 他们会提出不切实际的需求 如果这些客户甚至觉得自己是上帝的爸爸 那么沟通和协商都会很困难 No 11 项目需求分析难在哪里有几种原因使需求分析变得困难 需求自身经常变动网站开发的需求会变化吗 据统计 没有一个软件的需求改动少于三次 让我们先接受 需求会变动 这个事实吧 免得在需求变动时惊慌失措 明白 需求会变动 这个道理后 在进行需求分析时就要留点神 1 尽可能地分析清楚哪些是稳定的需求 哪些是易变的需求 以便在进行系统设计时 将网站的核心建筑在稳定的需求上 否则将会吃尽苦头 2 在合同中一定要说清楚 做什么 和 不做什么 如果合同含含糊糊 日后扯皮的事情就多 要防止开始时什么都点头 事后就宣布刚才答应的事都不算数 No 12 项目需求分析难在哪里有几种原因使需求分析变得困难 分析人员或客户理解有误有个外星人间谍潜伏到地球刺探情报 它给上司写了一份报告 主宰地球的是车 它们喝汽油 靠四个轮子滚动前进 嗓门极大 在夜里双眼能射出强光 有趣的是 车里住着一种叫作 人 的寄生虫 这些寄生虫完全控制了车 网站需求分析人员不可能都是全才 客户表达的需求 不同的分析人员可能有不同的理解 如果分析人员理解错了 可能会导致开发人员白干活 吃力不讨好 所以分析人员写好需求说明书后 要请客户方的各个代表验证 由于客户大多不懂网站建设 他们可能觉得网站是万能的 会提出一些无法实现的需求 有时客户还会把需求分析人员的建议或答复给想歪了 有一个软件人员滔滔不绝地向客户讲解在 信息高速公路上做广告 的种种好处 客户听得津津有味 最后 心动的客户对软件人员说 好得很 就让我们马上行动起来吧 请您决定广告牌的尺寸和放在哪条高速公路上 我立即派人去做 No 13 I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 14 1 2 3 项目需求分析20条法则客户与开发人员交流需要好的方法 下面建议20条法则 客户和开发人员可以通过评审以下内容并达成共识 如果遇到分歧 将通过协商达成对各自义务的相互理解 以便减少以后的磨擦 如一方要求而另一方不愿意或不能够满足要求 分析人员要使用符合客户语言习惯的表达 需求讨论集中于业务需求和任务 因此要使用术语 客户应将有关术语解释给分析人员 而客户不一定要懂得计算机行业的术语 分析人员要了解客户的业务及目标 为帮助开发和分析人员 客户可以考虑邀请他们观察自己的工作流程 如果是切换新系统 那么开发和分析人员应使用一下目前的旧系统 有利于他们明白目前系统是怎样工作的 其流程情况以及可供改进之处 分析人员必须编写软件需求报告 分析人员应将从客户那里获得的所有信息进行整理 以区分业务需求及规范 功能需求 质量目标 解决方法和其他信息 需求分析报告 使开发人员和客户之间针对要开发的产品内容达成协议 客户要评审此报告 以确保报告内容准确完整地表达其需求 No 15 4 5 6 项目需求分析20条法则要求得到需求工作结果的解释说明 分析人员可能采用了多种图表作为文字性 需求分析报告 的补充说明 因为工作图表能很清晰地描述出系统行为的某些方面 客户可能对此并不熟悉 因此客户可以要求分析人员解释说明每个图表的作用 符号的意义和需求开发工作的结果开发人员要尊重客户的意见 如果用户与开发人员之间不能相互理解 那关于需求的讨论将会有障碍 共同合作能使大家 兼听则明 参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间 同样 客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重 开发人员对需求及产品实施提出建议和解决方案 通常客户所说的 需求 已经是一种实际可行的实施方案 分析人员应尽力从这些解决方法中了解真正的业务需求 同时还应找出已有系统与当前业务不符之处 以确保产品不会无效或低效 分析人员应提出相当好的改进方法 有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性 No 16 7 8 项目需求分析20条法则描述产品使用特性 客户可以要求分析人员在实现功能需求的同时还注意网站的易用性 因为这些易用特性或质量属性能使客户更准确 高效地完成任务 例如 客户有时要求产品要 界面友好 或 健壮 或 高效率 但对于开发人员来讲 太主观了并无实用价值 正确的做法是 分析人员通过询问和调查了解客户所要的 友好 健壮 高效所包含的具体特性 具体分析哪些特性对哪些特性有负面影响 在性能代价和所提出解决方案的预期利益之间做出权衡 以确保做出合理的取舍 以已有的模块进行需求示例 需求通常有一定灵活性 分析人员可能发现已有的某个模块与客户描述的需求很相符 在这种情况下 分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间 而不必严格按原有的需求说明开发 所以说 如果想在产品中使用一些已有的常用模块 而它们并不完全适合您所需的特性 这时一定程度上的需求灵活性就显得极为重要了 No 17 9 10 项目需求分析20条法则要求对变更的代价提供真实可靠的评估 有时 人们面临更好 也更昂贵的方案时 会做出不同的选择 而这时 对需求变更的影响进行评估从而对业务决策提供帮助 是十分必要的 所以 客户有权利要求开发人员通过分析给出一个真实可信的评估 包括影响 成本和得失等 开发人员不能由于不想实施变更而随意夸大评估成本 获得满足客户功能和质量要求的系统 每个人都希望项目成功 但这不仅要求客户要清晰地告知开发人员关于系统 做什么 所需的所有信息 而且还要求开发人员能通过交流了解清楚取舍与限制 一定要明确说明您的假设和潜在的期望 否则 开发人员开发出的产品很可能无法让您满意 11给分析人员讲解业务 分析人员要依靠客户讲解业务概念及术语 但客户不能指望分析人员会成为该领域的专家 而只能让他们明白您的问题和目标 不要期望分析人员能把握客户业务的细微潜在之处 他们可能不知道那些对于客户来说理所当然的 常识 No 18 14 No 19 项目需求分析20条法则12抽出时间清楚地说明并完善需求 客户很忙 但无论如何客户有必要抽出时间参与 头脑高峰会议 的讨论 接受采访或其他获取需求的活动 有些分析人员可能先明白了客户的观点 而过后发现还需要客户的讲解 这时请耐心对待一些需求和需求的精化工作过程中的反复 13 准确而详细地说明需求 由于处理细节问题不但烦人而且耗时 因此很容易留下模糊不清的需求 但是在开发过程中 必须解决这种模糊性和不准确性 而客户恰恰是为解决这些问题作出决定的最佳人选 客户要尽量将每项需求的内容都阐述清楚 以便分析人员能准确地将它们写进 软件需求报告 中去 如果客户一时不能准确表达 通常就要求用原型技术 通过原型开发 客户可以同开发人员一起反复修改 不断完善需求定义 及时作出决定 分析人员会要求客户作出一些选择和决定 这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等 有权作出决定的客户必须积极地对待这一切 尽快做处理 做决定 因为开发人员通常只有等客户做出决定才能行动 而这种等待会延误项目的进展 15 项目需求分析20条法则尊重开发人员的需求可行性及成本评估 所有的软件功能都有其成本 客户所希望的某些产品特性可能在技术上行不通 或者实现它要付出极高的代价 而某些需求试图达到在操作环境中不可能达到的性能 或试图得到一些根本得不到的数据 开发人员会对此作出负面的评价 客户应该尊重他们的意见 16划分需求的优先级 绝大多数项目没有足够的时间或资源实现功能性的每个细节 决定哪些特性是必要的 哪些是重要的 是需求开发的主要部分 这只能由客户负责设定需求优先级 因为开发者不可能按照客户的观点决定需求优先级 开发人员将为客户确定优先级提供有关每个需求的花费和风险的信息 在时间和资源限制下 关于所需特性能否完成或完成多少应尊重开发人员的意见 业务决策有时不得不依据优先级来缩小项目范围或延长工期 或增加资源 或在质量上寻找折衷 No 20 项目需求分析20条法则 1718 评审需求文档 客户评审需求文档 是给分析人员带来反馈信息的一个机会 如果客户认为编写的 需求分析报告 不够准确 就有必要尽早告知分析人员并为改进提供建议 需求变更要立即联系 不断的需求变更 会给在预定计划内完成的质量产品带来严重的不利影响 变更是不可避免的 但在开发周期中 变更越在晚期出现 其影响越大 变更不仅会导致代价极高的返工 而且工期将被延误 特别是在大体结构已完成后又需要增加新特性时 所以 一旦客户发现需要变更需求时 请立即通知分析人员 19遵照开发小组处理需求变更的过程 为将变更带来的负面影响减少到最低限度 所有参与者必须遵照项目变更控制过程 这要求不放弃所有提出的变更 对每项要求的变更进行分析 综合考虑 最后做出合适的决策 以确定应将哪些变更引入项目中 No 21 20 项目需求分析20条法则尊重并积极地开展需求分析过程 软件开发中最具挑战性的莫过于收集需求并确定其正确性 分析人员采用的方法有其合理性 也许客户认为收集需求的过程不太划算 但请相信花在需求开发上的时间是非常有价值的 如果理解并支持分析人员为收集 编写需求文档和确保其质量所采用的技术 那么整个过程将会更为顺利 No 22 I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 23 需求确认 意味着什么 现象在 需求分析报告 上签字确认 通常被认为是客户同意需求分析的标志行为 然而实际操作中 客户往往把 签字 看作是毫无意义的事情 他们要我在需求文档的最后一行下面签名 于是我就签了 否则这些开发人员不开始编码 这种态度将带来麻烦 譬如客户想更改需求或对产品不满时就会说 不错 我是在需求分析报告上签了字 但我并没有时间去读完所有的内容 我是相信你们的 是你们非让我签字的 同样问题也会发生在仅把 签字确认 看作是完成任务的分析人员身上 一旦有需求变更出现 他便指着 需求分析报告 说 您已经在需求上签字了 所以这些就是我们所开发的 如果您想要别的什么 您应早些告诉我们 No 24 需求确认 意味着什么 本质这两种态度都是不对的 在 需求分析报告 上签字确认是终止需求分析过程的正确方法 所以我们必须明白签字意味着什么 对 需求分析报告 的签名是建立在一个需求协议的基线上 因此我们对签名应该这样理解 我同意这份需求文档表述了我们对项目需求的了解 进一步的变更可在此基线上通过项目定义的变更过程来进行 我知道变更可能会使我们重新协商成本 资源和项目阶段任务等事宜 对需求分析达成一定的共识会使双方易于忍受将来的摩擦 这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等 需求确认将迷雾拨散 显现需求的真面目 给初步的需求开发工作画上了双方都明确的句号 并有助于形成一个持续良好的客户与开发人员的关系 为项目的成功奠定了坚实的基础 No 25 I C ontent 什么是需求 II III IV V VI 如何寻找需求分析需求的难点需求分析20条准则需求确认案例讨论 No 26 案例A 客户需求不清楚公司有专门的项目管理部门 作为开发与外部的接口 在销售人员的协助下完成与客户的需求沟通 这天 从销售方面提交过来一个信息 客户 A 要求对X1项目的Y模块进行更换另外的模块进行技术评估 项目经理接到此要求后 发出正式通知让开发部门修改产品并进行了测试 出了测试版给客户试用 但结果客户非常不满的答复说 他们的意图并不是要单一改网站中的这个Y模块 而是在考虑要使用Y模块的模板用到网站中的方案 这个评估只是这个方案的一部分 销售部门其实知道客户的目的 但也未能向项目经理说明详细背景情况 经了解 他们只是认为Y模块的评估是最关键的 所以只向项目经理提到这个要求 请分析一下 这整件事的关键问题出在哪 我们要如何规避这样的风险 No 27 案例 客户需求不清楚 Discuss No 28 No 29 案例 客户需求不清楚 项目组作为具体的功能实现者 产品交付者 不能仅仅依靠销售提供的信息 还应有自己对功能 产品的判断 在与客户交流中 需要明确到非常细节的东西 否则产品成型后 客户会说这些东西和他们要求的不一致 如果顾客提供的要求没有形成文件 则信息的接受方必须对收到的信息书面化 然后要求顾客确认 在与客户沟通的过程中 应当严格的进行记录 而不是项目经理理解就可以的 记录的东西还需要客户再次签字确认 如果签字后 客户仍有修改 我们作为乙方的也可以有凭据讲理 如果客户不肯签字那就坚决不做 这应当作为一种制度进行 而不是随机性的 确认后的文档经过公司评审无异议后 发送给项目干系人 确保干系人知道变更的要求 这些工作 应当由项目管理部负责 案例中 项目管理部在以上工作没有先行的情况下 就变更设计 当然不能达到相关要求 另外对于销售提出的东西 在项目启动会时 售前和售后人员也应当相互沟通 最好有文字记录 这样 一旦项目出现因为需求不一致导致的项目延期等问题 双方都有一个依据 也可以以此请销售人员避免再次犯错 案例B 客户需求变更导致延期公司接手的一个中型MIS项目 在该项目进行期间 客户不断的更改需求 考虑到与客户的关系 要求项目经理服从客户的要求 结果 虽然项目经理对项目其它方面的控制都没有问题 但由于客户需求的频繁变更 项目最终还是被延期了3个月 质量也不尽如人意 问 如此情况 项目经理该对项目结果承担什么责任 如果你是项目经理 遇到这种情况你该怎么办 No 30 案例 客户需求不清楚 Discuss No 31 案例 客户需求变更导致延期 关于控制需求变更的一些意见1 站在客户的角度 分析该变更带来的影响2 找出客户在乎的几个关键因素 告知变更将对其带来的影响3 拿出以前需求变更的次数 内容 让客户知道这其中带来的危害4 站在技术权威的角度说明利弊5 即便是很容易接受的变更 也不要轻易答应客户 不能 宠坏了 客户 作为项目经理应该确定好需求范围 如果客户对本身需求比较模糊 应该主动引导客户 尽可能多的获得需求 需求确定后应该找客户确认签字 依据客户确认的需求 制定严格的进度计划 并要求客户给予书面确认 一旦发生需求变更 可以通过分析进度计划确定工期的顺延 制定严格的变更管理流程 客户的需求变更应通过项目经理签发 项目经理在签发变更前应向客户提供工期和费用的增加额 这样可以给客户提供更准确的决策依据 也可以降低变更的随意性 如果项目出现问题自己的权责要明确 必要时向上级确认 No 32 案例C 客户需求变更导致延期Z是一家规模不大的软件公司 2个月前Z公司参加一个大型企业的信息化建设项目的招标 在给客户的项目建议书中Z公司提及了一些比较超前的功能 当然实现起来相当困难 结果Z公司顺利中标 合同签订后 A担任此项目的项目经理 A接手此项目后 很快发现了项