文章目录
- 一、前言
- 二、需求管理
-
- [2.1 需求管理是什么？](#2.1 需求管理是什么？)
- [2.2 为什么需要需求管理？](#2.2 为什么需要需求管理？)
- [2.3 需求管理的关键流程](#2.3 需求管理的关键流程)
- [2.4 需求管理与其他流程的关系](#2.4 需求管理与其他流程的关系)
- [2.5 实际案例](#2.5 实际案例)
- [2.6 ISO 20000对需求管理的要求](#2.6 ISO 20000对需求管理的要求)
- 2.7小结
- 三、容量管理
-
- [3.1 容量管理是什么？](#3.1 容量管理是什么？)
- [3.2 为什么需要容量管理？](#3.2 为什么需要容量管理？)
- [3.3 容量管理的核心流程](#3.3 容量管理的核心流程)
- [3.4 容量管理与其他流程的关系](#3.4 容量管理与其他流程的关系)
- [3.5 实际案例](#3.5 实际案例)
- [3.6 ISO 20000对容量管理的要求](#3.6 ISO 20000对容量管理的要求)
- [3.7 小结](#3.7 小结)
- [四、 参考文档](#四、 参考文档)
一、前言
需求管理和容量管理是ISO 20000体系8.4供应与需求章节中的重要内容，本文将针对这两部分的内容浅析含义和解释，并提供案例用于辅助理解。
二、需求管理
需求管理（Requirement Management） 是 ISO 20000 IT服务管理体系 中的核心流程之一，其核心目标是准确捕捉、记录、跟踪和实现用户与业务的需求，确保IT服务的设计、交付和改进始终围绕业务目标展开。它的本质是在用户期望与IT能力之间建立桥梁，避免"开发出来的功能不是用户想要的"或"业务需求被技术实现带偏"。
2.1 需求管理是什么？
定义：
需求管理是通过系统化的方法，从业务方或用户处收集、分析、优先级排序、记录和验证需求，并确保这些需求在服务设计、开发、交付和维护过程中被完整实现和跟踪。
核心输出：需求文档（如《用户需求说明书》《功能规格书》）。
类比 ： 就像建筑施工前的"设计蓝图"------明确房子要建几层、房间布局、材料标准等，施工时按图作业，避免返工。
关键要素：
- 需求收集：通过访谈、问卷、工作坊等方式获取用户需求。
- 需求分析：筛选合理需求，排除冲突或不可行的部分（如用户要求"系统响应时间≤1秒"，但现有技术无法实现）。
- 需求优先级：按业务价值、紧急程度排序（如核心功能优先于优化项）。
- 需求跟踪：确保需求在开发、测试、上线各阶段被落实。
2.2 为什么需要需求管理？
对齐业务与IT目标：
避免IT部门"自娱自乐"，确保服务真正解决业务痛点（例如业务方需要提升订单处理效率，而非仅仅开发一个复杂报表）。
减少资源浪费：
避免开发错误功能或重复功能（如用户需要A功能，IT误开发了功能B）。
控制变更风险：
需求变更是引发项目延期或失败的常见原因，需求管理通过流程化变更控制降低风险。
提升用户满意度：
通过透明化需求实现过程，增强用户信任（如定期向用户汇报需求进展）。
2.3 需求管理的关键流程
（1）. 需求收集与分析
常用方法：
- 用户访谈：直接与业务方沟通，挖掘真实需求（例如用户抱怨"系统慢"，实际可能是网络延迟而非代码问题）。
- 原型设计：用低保真原型（如线框图）快速验证需求理解是否一致。
示例： 业务方提出"需要移动端报表功能"，需求分析发现真实需求是"随时随地查看实时数据"，进而设计为数据同步功能而非单纯报表。
（2）. 需求优先级排序
常用方法：
- MoSCoW法则：Must have（必须实现）、Should have（应该实现）、Could have（可以实现）、Won't have（暂不实现）。
- 成本收益比：评估需求开发成本与预期收益（如修复高危漏洞优先级高于界面美化）。
示例： 某电商平台在版本规划中，将"支付系统安全加固"列为Must have，"商品推荐算法优化"列为Should have。
（3）. 需求跟踪与验证
工具：使用需求管理工具（如JIRA、TFS）跟踪需求状态（待办、开发中、已测试、已上线）。验证方法：- 用户验收测试（UAT）：由业务方代表参与测试，确认需求是否满足。
- 需求追溯矩阵：建立需求与设计、代码、测试用例的映射关系，确保无遗漏。
示例： 某系统上线前，业务方通过UAT确认"批量导入数据"功能符合需求文档中的格式要求。
2.4 需求管理与其他流程的关系
| 关联流程 | 协同作用 |
|---|---|
| 服务设计 | 需求管理为服务设计提供输入，确保设计方案覆盖所有需求。 |
| 变更管理 | 需求变更需通过变更管理流程评估风险并批准（如新增功能需走变更审批）。 |
| 服务验证与测试 | 测试用例需基于需求文档编写，验证服务是否满足需求。 |
| 持续改进 | 通过需求回顾（如用户反馈）发现服务改进点，驱动下一轮需求收集。 |
2.5 实际案例
案例1：银行系统需求管理
背景 ：某银行要求升级网上银行系统，业务方提出"支持指纹登录"。
需求管理过程：
- 收集：访谈发现用户真实需求是"提升登录安全性"，指纹登录只是候选方案。
- 分析：技术团队评估指纹登录需硬件支持，成本过高，建议改用动态口令。
- 优先级：动态口令列为Must have，指纹登录列为Could have（后续版本实现）。
- 验证 ：UAT阶段用户确认动态口令满足安全需求。
效果：项目按时交付，用户满意度提升。
案例2：需求蔓延导致项目失败
反面案例 ： 某公司开发内部管理系统时，业务方不断新增需求（如从"基础审批流程"扩展到"预算分析模块"），导致项目延期超支。
根本原因 ：缺乏需求优先级排序和变更控制流程。
改进措施：
- 引入需求管理工具，冻结范围外的需求。
- 按季度评审需求优先级，分阶段交付。
2.6 ISO 20000对需求管理的要求
文档化：需求需形成正式文档，经业务方签字确认。
用户参与：需求收集和分析需业务方代表全程参与。
变更控制：需求变更需记录原因、影响范围，并经审批。
可追溯性：确保需求从提出到实现全程可跟踪。
2.7小结
需求管理就是给IT开发"定方向"------明确用户想要什么、什么最重要，并确保开发过程不偏离目标。就像导航软件------输入目的地（需求），规划最优路线（开发路径），途中实时调整（变更控制），最终准确抵达（交付验收）。
三、容量管理
容量管理（Capacity Management） 是 ISO 20000 IT服务管理体系 中的核心流程之一，其核心目标是确保IT基础设施的资源（如服务器、网络、存储等）能够以合理的成本，持续满足当前和未来的业务需求。它的本质是在资源供给与业务需求之间找到平衡，避免因资源不足导致服务中断，或资源过剩造成浪费。
3.1 容量管理是什么？
定义：
容量管理是通过规划、监控和调整IT资源，确保其性能、可用性和扩展性能够支持服务级别协议（SLA）的达成，并适应业务增长或变化。
核心输出：容量计划（Capacity Plan）、资源优化建议、性能报告。
类比 ： 就像高速公路的交通管理------根据车流量预测和实时监控，动态调整车道数量或限速标志，确保道路畅通且不浪费资源。
关键要素：
- 容量规划：预测未来资源需求（如服务器扩容时间点）。
- 性能监控：实时跟踪资源使用率（如CPU、内存、磁盘I/O）。
- 需求分析：将业务目标转化为技术资源需求（如用户增长需增加服务器数量）。
- 资源优化：调整资源配置以降低成本（如虚拟化整合服务器）。
3.2 为什么需要容量管理？
避免服务中断：
防止资源不足导致的系统崩溃（例如电商大促期间流量激增，未扩容服务器导致宕机）。
控制成本：
避免过度采购硬件或云资源（如预留10倍算力但实际仅用20%）。
支持业务增长：
确保IT资源能弹性扩展以适应业务扩张（如新市场上线需快速部署资源）。
优化性能：
通过调整资源配置提升用户体验（如数据库查询速度慢时增加缓存节点）。
3.3 容量管理的核心流程
（1） 容量规划
步骤：
- 需求预测：基于历史数据、业务计划和行业趋势，预测未来资源需求（如用户量增长30%需扩容服务器）。
- 场景建模：模拟不同业务场景下的资源需求（如峰值流量、故障切换）。
- 制定计划：明确资源采购、部署时间表和预算。
示例： 某视频平台预计世界杯期间流量增长5倍，提前租用云服务器弹性扩容。
（2）性能监控与分析
工具：使用监控系统（如Prometheus、Zabbix）实时跟踪资源使用率。
关键指标：
- 利用率：CPU使用率、内存占用率、存储IOPS。
- 性能阈值：设定资源使用上限（如CPU超过80%触发告警）。
示例： 发现某数据库服务器磁盘写入速度接近瓶颈，提前升级为SSD。
（3）容量调整与优化
方法：
- 垂直扩展：升级单台服务器配置（如增加内存）。
- 水平扩展：增加服务器数量（如部署负载均衡集群）。
- 资源回收：释放闲置资源（如删除未使用的虚拟机）。
示例： 将物理服务器迁移至云平台，按需启停实例以节省成本。
（4）定期评审与改进
频率：每季度或半年一次。
内容：
- 分析容量计划执行情况（如预测偏差是否需调整模型）。
- 优化监控策略（如新增关键指标）。
3.4 容量管理与其他流程的关系
| 关联流程 | 协同作用 |
|---|---|
| 服务级别管理（SLM） | 容量管理确保资源能支持SLA中的性能指标（如可用性≥99.9%）。 |
| 变更管理 | 容量扩容或技术升级需通过变更管理流程审批和执行。 |
| 财务管理 | 容量规划需考虑成本效益，避免超支（如云资源按需付费 vs 预留包年包月）。 |
| 事件管理 | 容量不足引发的故障（如服务响应缓慢）需快速定位并扩容。 |
3.5 实际案例
案例1：电商大促容量规划
背景：某电商平台"双十一"期间流量预计增长10倍。
容量管理行动：
- 预测：基于历史数据模型，计算所需服务器数量。
- 弹性扩容：提前与云服务商协议，活动期间自动扩展服务器集群。
- 监控与回滚：实时监控负载，若流量低于预期则释放资源。
效果：活动期间零宕机，IT成本仅增加20%。
案例2：资源浪费导致成本超支
反面案例： 某企业为未来3年业务预留大量服务器，但实际需求仅增长10%，导致硬件闲置和电费浪费。
改进措施：
- 引入容量管理模型，动态调整资源采购计划。
- 迁移至混合云架构，按需使用公有云资源。
3.6 ISO 20000对容量管理的要求
**文档化：**需制定《容量管理策略》《容量计划》，并经过管理层审批。
**持续监控：**建立性能基线，定期生成容量报告。
**业务协同：**容量规划需与业务部门沟通，确保符合战略目标。
**风险管理：**识别容量不足或过剩的风险，并制定应对计划（如备用资源采购）。
3.7 小结
容量管理就是给IT资源"定尺子"------既不能让资源"饿着"（性能不足），也不能让它们"撑着"（浪费成本），确保资源与业务需求动态匹配。就像餐厅管理座位------根据客流量动态调整桌椅数量，高峰期加桌，低峰期撤桌，既保证顾客用餐体验，又控制运营成本。
四、 参考文档
国家标准馆：信息技术 - 服务管理第1部分服务管理系统要求
ISO20000-1：2018 信息技术 服务管理 中文纯净完整版