微软中国高级经理人培训成功的产品管理(编辑修改稿)

微软中国高级经理人培训成功的产品管理(编辑修改稿)内容摘要：

开发 测试 发布 管理 用户 体验 产品 管理 项目 管理 团队模型：大项目多重团队形式 项目 管理 发布 管理 产品管理 用户 体验 开发 测试 领导团队 桌面 功能 团队 项目 管理 用户 体验 开发 测试 文件和打印 功能 团队 项目 管理 用户 体验 开发 测试 信息传递 功能 团队 项目 管理 用户 体验 开发 测试 团队模型：小项目角色重叠形式 测试 发布管理 开发 用户体验 产品管理 项目管理 项目经理的特质  了解项目产品的技术  了解可以应用于项目管理的工具  联系外部因素  在问题还没有变得太大前认识到问题  轻松管理上下级关系  找到问题的多种解决方法并选择最合适的  指出专家帮助的来源并寻求帮助  做出决定  做出不受欢迎的决定；采取不令人愉快的行动  放弃不相关的 项目经理的权力基础 • 正式的（合法）权力：指组织内各管理职位所固有的法定的、正式的权力 • 奖励权力（奖励权）：指提供奖金、提薪、表扬和其他任何令人愉悦东西的权力 • 惩罚权力（强制权力）：亦称惩罚权或处罚权，指施加扣发工资或奖金、批评、降职乃至开除等惩罚性措施的权力 • 专家权力（专长权）：指由个人的特殊技能或某些专业知识而产生的权力。 • 感召力（个人影响力）：个人影响权，是与个人品质、魅力、经历、背景等相关的权力 练习 4：项目干系人分析  产品开发项目干系人分析  内容：  识别选定的产品开发项目的干系人  确定干系人的需求以及与他们的沟通策略、方式  对干系人进行优先级的排序  形式：小组  时间： 1015分钟  参考资料：  软件开发  软件本地化 项目干系人分析 序号 干系人名称 主 要 需 求 IT项目需求  I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为： 1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。 2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 3）一种反映上面 1）或 2）所描述的条件或权能的文档说明。  软件需求：  商务（业务）的需求  使用者需求  功能需求  性能需求  质量需求  系统需求  非功能需求  开发局限 IT项目需求的获取 并没有一个清晰、毫无二义性的“需求”术语存在， 真正的 “ 需求 ” 实际上在人们的脑海中。 任何文档形式的需求（例 如需求规格说明）仅是一个模型，一种叙述。 Lawrence， 1998 开发软件系统最为困难的部分就是准确说明开发什么。 最 为困难的概念性工作便是编写出详细技术需求，这包括所 有面向用户、面向机器和其它软件系统的接口。 同时这也 是一旦做错，将最终会给系统带来极大损害的部分，并且 以后再对它进行修改也极为困难。 Frederick Brooks， 1987 例：软件产品开发项目的 WBS 练习 5：产品开发范围管理  产品开发项目范围  内容：  确定选定的产品开发生命周期  选择一个阶段并确定该阶段的里程碑及交付成果  编制该阶段的工作分解结构（ WBS）  形式：小组  时间： 1520分钟  参考资料：  软件开发  软件本地化 需求变更的管理  需求变更的原因  需求变更管理指南  制定需求基准线  由专人作决定  对所有改动要求一致对待  考虑变更对其它部分的影响  记录所有需求变更的来源  变更管理的运作步骤与流程  需求变更管理的文件模板 例：变更通知 刘先生： 您好。 经研究决定 ， 原门户项目的服务范围需扩展 ， 项目管理信息系统纳入该项目。 致礼。 王 xx X年 X月 X日 王先生： 您好。 门户项目服务范围改变的函件收到 ， 服务范围的改变使计划发生下列改变： 增加实施人员 5人 ， 增加电脑 5台。 增加 4个月工作量。 原计划进度推迟 2个月。 预算增加 40万元。 致礼。 刘 xx X年 X月 X日 估算时间的方法  与其它项目中类似工作类比  已完成项目的历史数据  专家意见 关键路径分析 集成 1 周 开始 0 周 选择软件 1 周 测试软件 2 周 采购软件 1 周 选择硬件 1 周 采购硬件 1 周 结束 0 周 关键路径决定项目的最短完成时间 练习 6：绘制网络图 并找出关键路径 活动 前置活动 活动时间 (周 ) A B C D E F A B B D,E 2 6 3 4 5 4 甘特图 控制工期的方法  赶工  增加投入  成本增加。  快速跟进  调整任务依赖关系  质量风险。 例：利用 MS Project控制工期 项目风险的概念 • 项目风险：一旦发生将对项目目标产生某种正面或负面影响的不确定事件或条件。 • 所有风险都有其原因，并且如果发生将导致某种后果。 • 项目风险即包括对项目目标的威胁，也包括促进项目目标的机会。 • 风险的特性：  风险事件  风险概率  得失量 (Amount at Stake) 风险管理计划的内容 • 方法论：定义可能用于项目中进行风险管理的方法、工具 和数据源 • 角色和责任：在风险管理计划中每一类行动的领导、支持 和风险管理团队成员 • 预算：为项目确立一个用于风险管理的预算 • 定时：在整个项目生命周期内审视风险管理过程的频率 • 评分和解释：采用的定性和定量风险分析类型与相适应的 评分和解释方法 • 阈值：由谁、以何种方式作用的风险的阈值标准 • 报告格式：描述风险应对计划的内容和格式 • 跟踪：记录和保存风险活动的所有方面信息以利于当前 项目、未来需要和教训。 分析并排列 轻重缓急 主风险 清单 最主要的 n个风险 计划与 时间表 确认 风险 叙述 控制 总结学习 风险知识库 概念和流程 跟踪和 报告 风险管理的流程 • 规避 (Avoidance):“无法忍受厨房里的高温，所以我远离厨房。 ” • 如合格供货商筛选，增加项目资源和时间等 • 转移 (Transference): “无法忍受厨房里的高温，所以我让厨师代替我站在里面。 ” • 让他人来分担风险，如保险、各种保函、担保及选择合同类型等 • 缓解 (Mitigation): “我将呆在厨房里，但是为了防止中暑，我将安装空调。 ” • 如执行一种能够减少问题的新行动方案等 • 接受 (Acceptance): “我将呆在高温的厨房里，忍受中暑的折磨并且接受这个结果。 ” • 积极接受：制定应急计划；消极接受：不采取任何行动 风险应对策略 时间 功能 把大项目划分成几个版本将风险减到最小。 版本 1 版本 2 版本 3 软件的版本 讨论： 产品开发项目风险管理  公司正在开发一个基于微软 Windows平台的软件，计划半年后发布。  有一个员工从某个渠道了解到微软也将在半年后发布新版的 Windows。  问题：  对公司这个软件项目，这一新情况是否代来新的风险。  如果不是风险，为什么。  如果是风险，该如何应对。 练习 7：产品开发风险管理  产品开发项目风险管理  内容：  识别选定的产品开发项目的风险  对风险进行分析、评价  制定相应的应对策略  形式：小组  时间： 1520分钟 IT项目的质量标志和特征  对使用客户重要的质量标志  可靠性  效率性  灵活性  安全性  互操作性  稳定性  健全性  可用性 • 对开发者重要的质量标志 – 可维护性 – 多用转换型 – 重复使用性 – 可测性 Karl E. Wiegers, Software Requirements, Microsoft Press, 1999 如何提高项目质量。  让顾客成为质量过程的一部分，从而可以全面了解和了解顾客需求和期望；  高层管理者必须充分重视质量，组织有明确的质量方针；  在组织中有力强调 “ 预防为主 ” 的思想；  与供应商 /制造商 /分包商结成伙伴关系，共同提高质量；  在执行项目的每一个过程前都应加以验证；  对项目团队全体成员进行培训；  将科学的统计方法作为决策依据；  让执行任务的团队成员参与制定计划；。