满意百分百行动策划new资料教材.pptVIP

满意百分百行动策划 研发体系业务研究院IT中心 约束和假设和潜在故障用新的模板识别。 约束和假设和潜在故障在项目周例会报告上解决情况。 团队组织 团队组织 可用性 应用管理方面 缺乏完善的应用系统运行报告，对于系统运行状况统计分析不足，致使预防能力薄弱 应用系统缺乏实际有效的KPI衡量指标 监控系统覆盖面不足，部分关键应用缺少监控 应用系统例行检查记录缺少监管环节 主机支撑平台方面 主机存储平台资源的规划仍待完善 备份恢复的速度不能满足关键应用要求 设备过保带来的可靠性风险 海外服务器运维缺乏保障 网络方面 关键应用缺乏运行报告（DNS/DHCP/Proxy/Radius） 网络运行需要建立全面的KPI指标体系 对网络的主动预防性管理需要加强 数据中心运营管理需要加强 缺乏系统性的可用性管理流程和机制 维护工作缺乏有效的监管,服务质量依赖于维护人员的个人素质 监控数据分析挖掘不足，难以及时预防运维环境存在的风险 IT系统总是有性能问题，客户抱怨越来越多 为什么老是登录不上去? 页面访问、数据查询，怎么这么久没响应? 系统越来越慢，刚上线时还好好的? 刚录好数据，系统就出错了? 正用着怎么突然就掉线了? 系统突然挂起、无响应，要重启操作系统? 应用开发方面 系统设计时没有建立数字模型，先开发后调优 项目团队重视功能开发，系统性能意识淡薄 开发设计人员能力不足，缺乏相关专业培训 应用测试方面 只测试功能点，不能模拟真实环境 测试人员只能做黑盒测试，不能做白盒测试 应用运维方面 只报告系统故障，无法提供现场系统完整分析数据 缺少系统性能监控能力 IT中心未建立系统性能管理机制 IT中心组织专业的性能专家团队，指导项目 系统需求和设计没有建模”容量规化” 系统测试标准还不完善 运维没有监控系统性能的方法和工具 ，无法建立IT中心系统整体性能数字模型 没有建立性能方案专家知识库，无法提高项目解决问题的高度和效率。 建立IT系统性能管理制度和标准 制定系统性能监控规范和规程 建立IT中心性能问题专家库 系统架构设计，推广”容量规化” 系统测试，引入“现场环境”模拟工具和方法论 引入IT系统性能监控平台，指导项目接入监控平台 建立IT中心系统整体性能分析报告 项目人员方面 以用户为中心的设计理念未能得到项目人员的重视 对易用性认识模糊、重视程度不够 人员技能不足，对工作产品质量影响很大 对已有的标准执行力度不够 规范标准方面 易用性标准较少 易用性标准及改进活动少 应用系统方面 控件不统一，操控模式各异 页面流程设计模式众多，用户学习困难 权限控制与角色未能较好的识别，无效信息很多，用户无所适从 报错信息很不友好，很难理解 向导功能很少，指引信息很少，不能较好的避免用户出错 在线帮助功能很少或干脆没有，少数有的也不能及时更新，一致性差 快捷方式使用较少、不统一，效率影响 用户记忆负担较大，很多操作连续性差 词汇专业，用户难懂 重视程度不够； 宣贯执行方面较弱； 人员技能培训不足； 易用性相关标准缺失较多； 易用性持续改进机制不健全等。 标准制度和工作指南方面 1、易用性改进工作方法的建立（同心圆模式） 2、易用性原则性规范建立 3、易用性评估方法 4、易用性相关标准的新增、改进、修订工作（需求、开发、测试等方面） 重点推进实施工作方面 1、易用性基础理论培训 2、易用性标准培训 3、重点应用系统易用性评估、问题收集分析、改进报告 4、重点应用系统易用性改进版本的落实 5、易用性测试工作推进 6、建立图片、模板、FLASH标准库 7、与DPG共同推进组件级标准库建立 8、与DPG共同推进组件、页面模板、页面流程等三级易用性改进工作 项目人员方面 BA大多数情况下局限于狭窄的项目层次，对业务的理解局限在少数几个接口部门。 BA大多数都是应对式接收用户的需求，对需求的合理性很少能提出异议，需求引导以及需求优化、跨项目、跨平台的数据整合、应用整合不能很深入地把握。 需求人员缺乏走出去学习业界先进理念和成熟技术的机会。 应用系统方面 业务变化很快，由于缺少有效的沟通，紧急开发情况较多。 应用系统的长期演进路线缺乏，最后经常导致或者重复开发，或者产生业务空挡。 应用系统使用后的跟踪和评估做的较少，系统能给用户带来什么收益，功能使用状况不清晰。 应用系统主要针对中兴的特殊流程定制，在业务扩展性方面与业界优秀软件差距较大。 应用系统往往是以岗位、部门定制，而岗位、部门等组织机构变化频繁，系统需要做较大的改动，成本很高。 规范标准方面 规范标准主要都是关于软件开发过程的，对于软件是否满足业务需求，是否符合业界标准等方面相对缺乏。 应用系统需求分析时，业界软件的标准考虑不足。