信息资源管理案例
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
§7.6 案例学习——解剖微软项目管理
• PCM包括五个阶段：计划、设计、执行、稳定、发布。
Design Plan
Implement
Release
Stabilize
2024/4/17
Information resource management
Hai Mo
Page 1
§7.6 案例学习——解剖微软项目管理
Hai Mo
Page 4
§7.6 案例学习——解剖微软项目管理
（4）稳定阶段（Stabilize）：软件整体质量趋向稳定，整 个产品将作为一个整体进行测试。团队重点放在产品的整体 测试上。这一阶段，产品的界面已经锁定，用户文档也已完 成。
稳定阶段完成的衡量标准有： • 功能测试全部完成、任何源码改动通过回归测试； • 发行前完成全程测试、程序到达零缺陷； • 试行版中发现的所有关键缺陷都完成纠错和订正。 • 使用说明内容最后校验； • 开发团队用“作战室会议”（War meeting）进行变更 管理。
2024/4/17
Information resource management
Hai Mo
Page 16
2024/4/17
Information resource management
Hai Mo
Page 9
§7.6 案例学习——解剖微软项目管理
• 程序经理团队： 控制产品的开发过程； 管理产品的细节； 促进团队内部的交流沟通； 保证产品的开发进度； 控制全局，并作一些折衷的决定 素质要求： 熟悉项目管理的知识和手段 熟悉软件开发技术和界面设计 知道有效地利用各种设计工具 跨团队之间的沟通 …
2024/4/17
Information resource management
Hai Mo
Page 3
§7.6 案例学习——解剖微软项目管理
（3）执行阶段（Implement）：也叫开发阶段，执行阶段 通常又会分为一个个里程碑，本阶段，团队的各个角色并行 工作：开发人员负责产品的功能开发；测试人员进行功能性 的测试，编写自动测试的脚本及测试工具；UE写用户文档； 程序经理负责功能规格书的更新和整体进度的推进……
（2）开发团队模型的作用 • 充分运用大家的智慧来做决定，各司其职又互相制约， 确保项目顺利完成。 • 产品管理团队：是产品的管理部门，从行政结构上看， 程序经理、开发经理和测试经理等都直接向产品单元经 理汇报。
清楚掌握用户需求，并详细定义； 明确新产品能带来的利润； 控制用户的期望值； 设计产品的特性和进度表； 负责管理市场、推销及公共关系。
2024/4/17
Information resource management
Hai Mo
Page 10
§7.6 案例学习——解剖微软项目管理
（3）团队成员的沟通交流
文档
正式和非正式报告
每个团队成员的Daily Report
内部网站
项目开始前，建立一个内部站点，将项目所有
资料放在上面，便于成员随时了解项目进展情况。
会议
不开无关紧要的会议；
开会时不要无关紧要的人参与；
任何会议必须事先发出会议日程，会后发会议
记录，说明会议的决定及相关人员接下来要完成的
任务。
2024/4/17
Information resource management
Hai Mo
Page 11
§7.6 案例学习——解剖微软项目管理
3. 微软项目管理经验点评 （1）功能规格书
程序经理需要准备产品功能规格书，它是软件开发的 蓝图。其内容一般包括：软件所有功能，使用界面的 行为，描述用户对软件的使用方法等。功能规格书的 完成一般需要1到几个月的时间。 （2）软件开发周期估算 程序经理负责估算项目规划、产品设计、撰写功能
说明书、团队协调等时间； 开发团队负责估算撰写设计规格书、编码、Bug修
（4）团队编码的策略 开发团队小型化； 确立强制性编码规范； 对项目进行源代码管理； 源代码审阅；
2024/4/17
Information resource management
Hai Mo
Page 13
§7.7 案例讨论
背景知识： 关于IT项目监理
IT项目的开发方式有四种：独立开发，委托开发，合作 开发，以及购买现成软件然后再进行二次开发。后三种开 发方式，在项目组内部，则出现两个利益主体的成员，一 方主要表现为系统开发人员，另一方则主要表现为业务支 持人员。
执行阶段完成的衡量标准有： • 功能程序编写按照里程碑完成； • 使用界面的设计及验证； • 测试计划和方案完成、可展开； • 用户使用文档的内容确定； • 市场及营销计划确定； • 系统安置和部署计划确定； • 售后服务系统计划完成。
2024/4/17
Information resource management
由于双方在技术和业务上的信息互不对称，就很有可能 发生通过损害对方使自己受益的事情，如果将IT项目组的 两类人员简单地称为甲方(用户方，由业务人员组成)和乙 方(开发方，由系统开发人员组成)，并且在两方之间建立 一个合同关系， 即“委托人——代理人”关系。
2024/4/17
Information resource management
2024/4/17
Information resource management
Hai Mo
Page 6
§7.6 案例学习——解剖微软项目管理
为了保证PCM的五个流程顺利执行，需要重视三方面 工作： • 事先制订每个流程完成的标准； • 严格进行变更管理来保证质量的稳定； • 建立分工明确的团队来保证责任的完成； • 实施时要进行重复循环的运作，利用重复的五个阶段来 进行不断的工作调整。
24/4/17
Information resource management
Hai Mo
Page 5
§7.6 案例学习——解剖微软项目管理
（5）发布阶段（Release）：主要工作有三个：最后的纠 错和测试；产品的发行黄金版本通过媒体发行；系统软件 进行最后部署。
发布阶段完成的衡量标准有： • 使用说明书提交印刷或电子发行； • 发行后勤准备完毕； • 市场营销及发布活动准备就绪。 • 软件产品黄金版本送交发行； • 软件系统发行通过整合的试车及验证； • 售后服务及用户支持系统进入运行。
2024/4/17
Information resource management
Hai Mo
Page 7
§7.6 案例学习——解剖微软项目管理
2. 微软产品开发团队 （1）微软开发团队模型 • 一个完整的产品团队模型包括六个地位平等的小团队； • 一个小的项目组也能够将之压缩为三个小团队。
Program Management
（1）计划阶段（Plan）：产品市场定位和粗线条Plan 的制定，具体而言，有五项任务： • 制定产品的远景规划（Product vision） • 总结分析市场的调查和反馈 • 用户需求总结 • 制定项目范围 • 确定开发资源 计划阶段完成的衡量标准主要是形成四个文档： • 项目远景目标总结（Vision Statement） • 市场机会分析总结书（Mkt. Opp. Document） • 市场需求总结书（Mkt. Req. Document） • 开发资源评估总结书（Dev. Res. Summary）
复的时间； 测试团队负责估算撰写测试文档、测试代码、运行
测试的时间；等等
2024/4/17
Information resource management
Hai Mo
Page 12
§7.6 案例学习——解剖微软项目管理
（3）保证项目进度的原则 项目进度的估算必须由具体实施的团队成员来进行； 尽可能估算每项细致的工作,制定完整的项目计划； 建立团队工作效率的历史档案； 根据风险适当调整项目的完成时间；
2024/4/17
Information resource management
Hai Mo
Page 2
§7.6 案例学习——解剖微软项目管理
（2）设计阶段（Design）：明确设计的范围，功能和性能 设计、架构设计、开发执行设计、使用界面设计、系统整合 设计、产品安装部署设计、用户教育设计。
设计阶段完成的衡量标准主要是形成几个文档： • 制定产品的市场定位（Branding Strategy） • 设计规范书（Design Spec） • 开发构架设计（Architecture Design） • 测试计划（Test Plan） • 使 用 说 明 书 及 客 户 教 育 文 档 计 划 （ User Mannual/ Education） • 开发时间表 计划阶段和设计阶段经常迭代进行，在设计阶段会更新计 划，进行完善,这两个阶段一般统称 M0（Milestone 0）。
Hai Mo
Page 14
§7.7 案例讨论
作为委托人的用户方要改变自己的信息不对称地位，就 需要设计一套机制和合同来激励或约束作为代理人的开发 方。聘请咨询和监理就是委托人采取的对策。
监理方不仅对乙方有约束，对甲方也有约束。对乙方而 言，是监督和管理，重在监督；对甲方而言，是督促和助 理，重在助理。
Product Management
Development
程序经理
User Education
Testing
软件开发 软件测试
logistics Management
2024/4/17
Information resource management
Hai Mo
Page 8
§7.6 案例学习——解剖微软项目管理
2024/4/17
Information resource management
Hai Mo
Page 15
§7.7 案例讨论
1. 案例背景 第三方咨询服务：银行信息化的保障 监理走向前台
2. 结合案例讨论： (1) 分析信息系统工程监理应该包括哪些主要工作内 容？ (2) 分析信息系统工程监理给信息系统建设带来了哪 些好处？ (3) 如果你是CIO，应该从哪几个方面来决定某个项 目是否需要信息工程监理？
• PCM包括五个阶段：计划、设计、执行、稳定、发布。
Design Plan
Implement
Release
Stabilize
2024/4/17
Information resource management
Hai Mo
Page 1
§7.6 案例学习——解剖微软项目管理
Hai Mo
Page 4
§7.6 案例学习——解剖微软项目管理
（4）稳定阶段（Stabilize）：软件整体质量趋向稳定，整 个产品将作为一个整体进行测试。团队重点放在产品的整体 测试上。这一阶段，产品的界面已经锁定，用户文档也已完 成。
稳定阶段完成的衡量标准有： • 功能测试全部完成、任何源码改动通过回归测试； • 发行前完成全程测试、程序到达零缺陷； • 试行版中发现的所有关键缺陷都完成纠错和订正。 • 使用说明内容最后校验； • 开发团队用“作战室会议”（War meeting）进行变更 管理。
2024/4/17
Information resource management
Hai Mo
Page 16
2024/4/17
Information resource management
Hai Mo
Page 9
§7.6 案例学习——解剖微软项目管理
• 程序经理团队： 控制产品的开发过程； 管理产品的细节； 促进团队内部的交流沟通； 保证产品的开发进度； 控制全局，并作一些折衷的决定 素质要求： 熟悉项目管理的知识和手段 熟悉软件开发技术和界面设计 知道有效地利用各种设计工具 跨团队之间的沟通 …
2024/4/17
Information resource management
Hai Mo
Page 3
§7.6 案例学习——解剖微软项目管理
（3）执行阶段（Implement）：也叫开发阶段，执行阶段 通常又会分为一个个里程碑，本阶段，团队的各个角色并行 工作：开发人员负责产品的功能开发；测试人员进行功能性 的测试，编写自动测试的脚本及测试工具；UE写用户文档； 程序经理负责功能规格书的更新和整体进度的推进……
（2）开发团队模型的作用 • 充分运用大家的智慧来做决定，各司其职又互相制约， 确保项目顺利完成。 • 产品管理团队：是产品的管理部门，从行政结构上看， 程序经理、开发经理和测试经理等都直接向产品单元经 理汇报。
清楚掌握用户需求，并详细定义； 明确新产品能带来的利润； 控制用户的期望值； 设计产品的特性和进度表； 负责管理市场、推销及公共关系。
2024/4/17
Information resource management
Hai Mo
Page 10
§7.6 案例学习——解剖微软项目管理
（3）团队成员的沟通交流
文档
正式和非正式报告
每个团队成员的Daily Report
内部网站
项目开始前，建立一个内部站点，将项目所有
资料放在上面，便于成员随时了解项目进展情况。
会议
不开无关紧要的会议；
开会时不要无关紧要的人参与；
任何会议必须事先发出会议日程，会后发会议
记录，说明会议的决定及相关人员接下来要完成的
任务。
2024/4/17
Information resource management
Hai Mo
Page 11
§7.6 案例学习——解剖微软项目管理
3. 微软项目管理经验点评 （1）功能规格书
程序经理需要准备产品功能规格书，它是软件开发的 蓝图。其内容一般包括：软件所有功能，使用界面的 行为，描述用户对软件的使用方法等。功能规格书的 完成一般需要1到几个月的时间。 （2）软件开发周期估算 程序经理负责估算项目规划、产品设计、撰写功能
说明书、团队协调等时间； 开发团队负责估算撰写设计规格书、编码、Bug修
（4）团队编码的策略 开发团队小型化； 确立强制性编码规范； 对项目进行源代码管理； 源代码审阅；
2024/4/17
Information resource management
Hai Mo
Page 13
§7.7 案例讨论
背景知识： 关于IT项目监理
IT项目的开发方式有四种：独立开发，委托开发，合作 开发，以及购买现成软件然后再进行二次开发。后三种开 发方式，在项目组内部，则出现两个利益主体的成员，一 方主要表现为系统开发人员，另一方则主要表现为业务支 持人员。
执行阶段完成的衡量标准有： • 功能程序编写按照里程碑完成； • 使用界面的设计及验证； • 测试计划和方案完成、可展开； • 用户使用文档的内容确定； • 市场及营销计划确定； • 系统安置和部署计划确定； • 售后服务系统计划完成。
2024/4/17
Information resource management
由于双方在技术和业务上的信息互不对称，就很有可能 发生通过损害对方使自己受益的事情，如果将IT项目组的 两类人员简单地称为甲方(用户方，由业务人员组成)和乙 方(开发方，由系统开发人员组成)，并且在两方之间建立 一个合同关系， 即“委托人——代理人”关系。
2024/4/17
Information resource management
2024/4/17
Information resource management
Hai Mo
Page 6
§7.6 案例学习——解剖微软项目管理
为了保证PCM的五个流程顺利执行，需要重视三方面 工作： • 事先制订每个流程完成的标准； • 严格进行变更管理来保证质量的稳定； • 建立分工明确的团队来保证责任的完成； • 实施时要进行重复循环的运作，利用重复的五个阶段来 进行不断的工作调整。
24/4/17
Information resource management
Hai Mo
Page 5
§7.6 案例学习——解剖微软项目管理
（5）发布阶段（Release）：主要工作有三个：最后的纠 错和测试；产品的发行黄金版本通过媒体发行；系统软件 进行最后部署。
发布阶段完成的衡量标准有： • 使用说明书提交印刷或电子发行； • 发行后勤准备完毕； • 市场营销及发布活动准备就绪。 • 软件产品黄金版本送交发行； • 软件系统发行通过整合的试车及验证； • 售后服务及用户支持系统进入运行。
2024/4/17
Information resource management
Hai Mo
Page 7
§7.6 案例学习——解剖微软项目管理
2. 微软产品开发团队 （1）微软开发团队模型 • 一个完整的产品团队模型包括六个地位平等的小团队； • 一个小的项目组也能够将之压缩为三个小团队。
Program Management
（1）计划阶段（Plan）：产品市场定位和粗线条Plan 的制定，具体而言，有五项任务： • 制定产品的远景规划（Product vision） • 总结分析市场的调查和反馈 • 用户需求总结 • 制定项目范围 • 确定开发资源 计划阶段完成的衡量标准主要是形成四个文档： • 项目远景目标总结（Vision Statement） • 市场机会分析总结书（Mkt. Opp. Document） • 市场需求总结书（Mkt. Req. Document） • 开发资源评估总结书（Dev. Res. Summary）
复的时间； 测试团队负责估算撰写测试文档、测试代码、运行
测试的时间；等等
2024/4/17
Information resource management
Hai Mo
Page 12
§7.6 案例学习——解剖微软项目管理
（3）保证项目进度的原则 项目进度的估算必须由具体实施的团队成员来进行； 尽可能估算每项细致的工作,制定完整的项目计划； 建立团队工作效率的历史档案； 根据风险适当调整项目的完成时间；
2024/4/17
Information resource management
Hai Mo
Page 2
§7.6 案例学习——解剖微软项目管理
（2）设计阶段（Design）：明确设计的范围，功能和性能 设计、架构设计、开发执行设计、使用界面设计、系统整合 设计、产品安装部署设计、用户教育设计。
设计阶段完成的衡量标准主要是形成几个文档： • 制定产品的市场定位（Branding Strategy） • 设计规范书（Design Spec） • 开发构架设计（Architecture Design） • 测试计划（Test Plan） • 使 用 说 明 书 及 客 户 教 育 文 档 计 划 （ User Mannual/ Education） • 开发时间表 计划阶段和设计阶段经常迭代进行，在设计阶段会更新计 划，进行完善,这两个阶段一般统称 M0（Milestone 0）。
Hai Mo
Page 14
§7.7 案例讨论
作为委托人的用户方要改变自己的信息不对称地位，就 需要设计一套机制和合同来激励或约束作为代理人的开发 方。聘请咨询和监理就是委托人采取的对策。
监理方不仅对乙方有约束，对甲方也有约束。对乙方而 言，是监督和管理，重在监督；对甲方而言，是督促和助 理，重在助理。
Product Management
Development
程序经理
User Education
Testing
软件开发 软件测试
logistics Management
2024/4/17
Information resource management
Hai Mo
Page 8
§7.6 案例学习——解剖微软项目管理
2024/4/17
Information resource management
Hai Mo
Page 15
§7.7 案例讨论
1. 案例背景 第三方咨询服务：银行信息化的保障 监理走向前台
2. 结合案例讨论： (1) 分析信息系统工程监理应该包括哪些主要工作内 容？ (2) 分析信息系统工程监理给信息系统建设带来了哪 些好处？ (3) 如果你是CIO，应该从哪几个方面来决定某个项 目是否需要信息工程监理？