资源描述
21.解决方案,执行、监控和评价,1,步骤,1.监控需求 2.解决方案评价,2,监控需求,目的： 控制需求执行和变更情况 输出： 干系人对解决方案交付的信心，信心的前提是对进程心中有数 手段： 跟踪 回溯（向前跟踪）：识别需求的来源（商业需求） 前瞻（向后跟踪）：识别需求如何被测试和实施 需求间跟踪：洞察一组相关需求所交付的价值 监督：实际绩效和基准之间的偏差,3,step 1:跟踪矩阵,需求属性 需求ID 需求简述 目的：商业需要、商业目标、项目目标 产品发展阶段：设计、建立、测试、实施、验证 WBS 状态：生命周期 存在理由 优先级 拥有者 来源 版本 完成日期 稳定性 复杂性 验收标准 干系人满意程度,跟踪矩阵层级 从高层级开始， 渐进明细， 填入越来越多的细节 作用 确保出现的详细需求被链接到已基准化的需求； 保证完整的一组基准化需求具有打造某项功能或一组功能所需的细节； 可以支持为每项基准化需求创建商业分析工作成果； 阶段成果是为每项获批需求创建的， 如设计文档、 测试文档等； 防止范围蔓延,4,需求生命周期,5,优先级,时间盒法（Time-boxing） 时间是固定的，不能谈判的，只能看在这段时间内可以交付什么 配合其他有限排序技术使用 MoSCoW Must haves：项目必须 Should haves：重要，但没有也不影响项目成功 Could haves：不影响项目成功 Wont haves：在这个时间段里不会交付 多票制（Multivoting） 每人三种票（高、中、低），投票统计 加权排序（Weighted ranking） 每个选项都有多个考虑条件，所以要加权算分,6,需求之间的关系和依赖性,子集 一项需求是另一项需求的子集。 实施依赖性 有些需求依赖于其他需求的实施。 收益或价值依赖性 除非先实施另一项需求， 否则某项需求的收益无法获得,7,step 2:基准化已批准需求 （baseline）,需求基准的定义 由所有已获得批准的需求组成的边界， 涵盖了项目中所有已批准的需求 作用 基准提供了比较机制 超出基准的都需要获得批准 需求变更只有通过变更控制流程才能执行 维护基准的职责 维护需求变更的描述 维护发起变更人信息 维护需求变更原因,8,step 3:管理需求变更,影响分析,对需求基准的影响 提出的需求是否与其他需求发生冲突的影响 对商业分析的影响 对项目管理的影响,行动方案推荐,批准变更需求 推迟变更需求 否决变更需求 要求更多信息,9,解决方案评价,验收 长期绩效,10,验收,1.评价计划 2.评价验收标准和解决缺陷 3.促成通过/不通过的决策和签字,11,Step 1：评价计划准备什么？,本次评价活动会监督、 跟踪或确认项目或组织的哪些目的、 目标或风险？ 谁会承担进行评价所需花费的时间和工作量成本？ 解决方案或其基础架构是否具有对评价标准的内置测量能力？ 是否存在已有手段来抽取测量数据用于评价？ 选择的评价方法是否有效且相对经济？ 是否有已存在的方式可以用来汇报和公布评价结果？,12,Step 1：评价计划评价什么？,考虑商业目的和目标 考虑关键绩效指标 KPI是公司高层定义的指标 考虑附加的评价指标和评价验收标准 项目指标：项目成本、挣值偏差、跟踪变更请求 客户指标：满意度 销售和市场营销指标 运营指标和评估 功能：强调测试覆盖率， 而不强调单项测试结果 确认组织可以继续评价 当识别了衡量的事情后，就可以回顾评价所需的成本，并在必要的时候更新之。 必要时，要重新确认正在做评价的部门/组织是否仍然有能力或意愿继续做,13,Step 1:评价计划何时验证？,开发完 发布前 发布后,14,Step 1:评价计划如何验证？,集成测试模拟生产环境测试 对比功能的预期结果和实际结果 对比非功能需求的预期结果和实际结果 成果测量和收益的财务核算,15,Step 2：评价验收标准和解决缺陷,预期结果与实际结果的比较 检查公差范围和确切数字 记录和解决缺陷 发布缺陷后要记录 用额外的需求分析、影响分析、变更请求来解决,16,Step 3:促成通过/不通过的决策和签字,通过/不通过的决策应该开会决定 评价结果要在决策会议上展示 决议选项：完整发布、部分发布、不发布,17,长期绩效评价,1.确定指标 决定用什么指标去衡量绩效 2.获得指标&测量绩效 在解决方案发布前，组织原来并没有衡量这个指标的技术， 可能获得这个指标的成本比较高； 测量长期绩效， 可能要比较多个单项指标和累积指标。 3.分析结果 分析绩效平稳、 上升、 下降、 异常的状态。 4.评估解决方案和组织的局限性 在分析完指标并掌握根本原因后进行。 5.建议提高解决方案绩效的方法,18,谢谢！,19,
展开阅读全文