对于互联网项目管理中的PDCA资料

上传人:f****u 文档编号:128306651 上传时间:2020-04-20 格式:PDF 页数:6 大小:190.45KB
返回 下载 相关 举报
对于互联网项目管理中的PDCA资料_第1页
第1页 / 共6页
对于互联网项目管理中的PDCA资料_第2页
第2页 / 共6页
对于互联网项目管理中的PDCA资料_第3页
第3页 / 共6页
对于互联网项目管理中的PDCA资料_第4页
第4页 / 共6页
对于互联网项目管理中的PDCA资料_第5页
第5页 / 共6页
点击查看更多>>
资源描述

《对于互联网项目管理中的PDCA资料》由会员分享,可在线阅读,更多相关《对于互联网项目管理中的PDCA资料(6页珍藏版)》请在金锄头文库上搜索。

1、云之讯 对于互联网项目管理中的云之讯 对于互联网项目管理中的 PDCA 1 互联网产品项目管理现状互联网产品项目管理现状 根据 Standish Group 发布的报告 在 2012 年所研究的 IT 项目中 有 18 的项目是失败 的 43 的项目是有问题的 只有 39 的项目是成功的 能够同时满足时间 范围和成本的 要求 也就是说 在 2012 年有 61 的项目是没有达成项目目标的 影响项目成功的因素很 多 如不清晰的需求 频繁的需求变更 不合理的进度计划 低效沟通 风险管理的缺失 不稳定的项目团队等 对单个问题进行分析时发现每个都能被解决 但当问题交织在一起时 整个项目就像陷 进了焦油

2、坑 如 Brooks 在 人月神话 中所说 表面上看起来好像没有任何一个单独的问 题会导致困难 每个都能被解决 但是当它们相互纠缠和累积在一起的时候 团队的行动就 会变得越来越慢 对问题的麻烦程度 每个人似乎都会感到惊讶 并且很难看清问题的本质 2012 年 IT 项目执行结果 而在互联网行业 产品功能需要快速迭代以解决用户痛点问题 并且需要根据用户对产 品的反馈快速对功能做出调整 因而需求很难在项目初期被准确定义 为了持续交付对客户有价值的功能特性 互联网产品的项目管理多采用敏捷开发 以 小 步快跑 的模式来适应不断变化的需求 但每个项目团队所处的行业不同 公司文化不同 人员素质不同及对 敏

3、捷 的理解程度不同 互联网型项目管理还存在很多问题 比如 迭代内需求模糊 项目进度延迟严重 缺乏风险管理意识 项目团队不稳定 进度与问题沟通不畅 产品质量不高 如何解决这些棘手的问题 成为很多项目经理关注的焦点 2 PDCA 循环简介循环简介 如图 2 所示 PDCA 是 Plan 计划 Do 执行 Check 检查 Act 行动 的首字母缩写 来源 于质量管理领域 由著名统计学家休哈特 Walter A Shewhart 在 20 世纪 30 年代提出构想 后来由戴明 W Edwards Deming 完善并加以广泛宣传 运用于持续改善产品质量 因此 PDCA 有时也被称为戴明环或休哈特环

4、PDCA 循环是一个持续改进的过程 它是针对在计划和执行过程中遇到的问题进行分 析 并通过制定相应的解决措施 在下次计划和执行中进行改进 从而达到流程和质量持续 提高的目的 如下图所示 下一阶段在改进上一阶段问题的基础上执行 因而可以达到一个 更好的水平 这四个过程周而复始 整个水平呈阶梯上升的趋势 PDCA 循环是一个发现问题 解决问题的过程 其适用范围不仅仅在质量管理领域 它 的思想同样可用于互联网项目管理 3 PDCA 在项目管理中的运用在项目管理中的运用 互联网产品的项目周期通常比较短 从需求导入到功能发布一般在 2 4 周 有的互联网 公司可以做到每周发布新版本 频繁的项目需求导入以

5、及固定的项目团队能够保证 PDCA 循环可以很容易的应用到项目管理中去 下面将探讨在项目管理中应用 PDCA 时需要注意 的地方 3 1 Plan 阶段需要注意以下几个方面阶段需要注意以下几个方面 清晰明确的需求是计划的前提 很多项目经理在需求没有弄清楚之前 因迫于管理层的压力而匆匆做计划 结果执行的 时候发现很多问题 最后做出来的功能并不是产品经理想要的 如果在做之前没想清楚产品 要做成什么样 那么如何保证开发出来的产品符合产品经理的要求 需求清晰明确并不是要求一定要有详尽的需求规格说明书 因为那需要花费大量的时间 和精力去维护这些重量级的需求文档 但是对于需求 产品经理 项目经理 开发团队

6、和测 试团队至少要有清晰一致的理解 即大家对需求的认识是一致的 有了对需求一致的理解 才可以准确地将功能需求转化为设计 开发和测试任务 进而 对每个任务进行准确的时间估算 通过产品需求文档结合产品原型的方式可以帮助项目团队 更快更准确地理解产品需求 做到需求清晰明确其实并不困难 任务分解谁执行谁估算 在很多公司 项目执行不好的原因之一就是从需求分解 任务拆分 工期估算 任务排 期都是项目经理一个人依据自己的经验搞定 但是项目经理又不负责具体任务的执行 大多 数情况下在做计划时往往很乐观 任务工期估算的偏少 结果就是项目总是处于延迟的状态 团队为了赶进度经常加班 如果再碰到一些技术难题 延迟就更

7、严重了 因此在计划阶段做工期估算时 需要让具体执行任务的人依据自己的知识和能力去估 算 项目经理根据自己的经验可以针对估算结果做调整 但是调整时需要向任务执行的成员 说清楚为什么做调整 敏捷开发中的 扑克法估算 是让每个项目成员都对同一个任务进行估 算 这样得出的结果比较准确 如果有条件可以尝试这种估算方法 项目管理也是项目任务 第一次担任项目经理的时候 我在计划里给自己安排了很多开发任务 基本上在工作时 间都安排了开发任务 天真地认为项目管理就是每天与团队成员开个会了解一下进度 不会 耽误太多时间 更不会影响项目进度 结果到了项目执行的时候 我需要花很多时间去和每 个人沟通进度和问题 比如

8、每天组织项目晨会 组织设计评审会 整理会议纪要 与产品 经理讨论需求有争议的地方 与采购同事沟通设备的采购进度 向领导汇报进度 处理突发 问题 组织团队活动等等 后来学习 PMBOK 时了解到项目经理 75 90 的时间都是在沟通 项目经理不在沟通 就在沟通的路上 去沟通计划 沟通进度 沟通问题 沟通风险等等 所以 项目经理的时 间就是被各种沟通碎片化 如果在计划时还要像其他项目成员一样排任务 那估计只能在加 班时候完成了 所以 在项目计划里面一定要把项目管理工作当成一项重要的任务 它也需 要时间 风险管理不可缺 为什么要有风险管理计划 要回答这个问题 首先要想清楚我们做好的项目计划 准确 说

9、应该是进度计划 是在什么情况下制定的 我们假设项目组成员都不会生病 家里有事 不会离职 因此可以每天 8 个小时工作 我们假设项目里的技术难题可以在估算的时间内解 决 不会影响进度 我们假设采购的设备可以在和供应商谈好的时间内交付 保证测试环境 可以按时搭建 我们假设项目组成员小 A 每天心情都很好 可以在每天 6 个小时高效工作 从这几点我们可以看出 我们的项目计划很多都是基于假设来做的 我们认为这些假设 都是成立的 那么问题来了 当假设不成立的时候我们该怎么办 这就需要风险管理计划了 一般来说 在计划阶段 可以采用专家判断 头脑风暴和检查表等工具来识别风险 并通过 定性分析和定量分析形成风

10、险登记册 最后针对每个风险制定相应的应对措施 通过风险应 对计划来解决假设不成立的问题 将实施过程中意外情况对项目造成的影响降到最低 3 2 在在 Do 阶段需要注意的几个方面阶段需要注意的几个方面 控制需求变更 在项目执行过程中 需求变更常常会会引起设计返工或项目进度计划的变更 频繁的变 更会导致项目计划不具备可执行性 另外也会对团队士气造成影响 团队会认为反正计划会 变 做了可能也是白做 在互联网项目中 2 4 周的项目计划一般情况下都不应该进行需求 的变更 如果有特殊情况必须变更 建议重新制定项目计划以保证项目计划具备可执行性 确保沟通高效 项目经理 75 90 的时间都是在沟通 同时也

11、要给团队创造一个便于高效沟通的氛围 尤其要提倡 面对面沟通 在敏捷项目管理中 每日站立会是很好的方式 每天固定的时间 每个人通过回答 昨天做了什么 今天准备做什么 和 有什么障碍 这三个问题向团队其 他人同步自己的工作进度和问题 简单的问题在站立会上就会马上解决 除了站立会外 很多成员习惯于 QQ RTX 上说问题 有的甚至通过邮件来问问题 一 个简单的问题当面沟通三分钟就解决了 结果在 QQ 上说了一上午也没搞定 所以项目经理 要鼓励大家在有问题时尽量当面沟通 能 动嘴 的坚决 不动手 做到沟通基本靠 吼 3 3 在在 Check 阶段需要做什么阶段需要做什么 PDCA 循环中的 Check

12、 可对应于敏捷项目管理中的项目回顾会议 团队通过对本次迭 代的完成情况进行回顾 找出本轮迭代中团队中哪些方面做的好 哪些方面需要改进 在回 顾会议上需要注意的是要营造一个开放安全的氛围 大家可以放心说问题而不用担心说问题 会导致领导不高兴 从而影响自己的绩效 所以有的团队在做回顾会议之前会做安全测试 即大家对这次会议的安全性进行不记名投票 如果安全性过低 则 ScrumMaster 会将领导请 出会议室 以保证大家可以放心说问题 会议最后会选出在这次迭代中 TOP 3 GOOD THINGS 和 TOP 3 NEED IMPROVEMENT 会议之后需要将这 3 件做的好的方面和需要改进的三个

13、方面记录下来 以鼓励团队在下一次迭代中继续保持好的方面 改进不好的方面 3 4 在在 Act 阶段需要注意的两个方面阶段需要注意的两个方面 确保改进措施可行 在回顾会议上会选出 3 个需要改进的方面 但是具体的改进措施有时在回顾会议上不会 制定出来 会后可组织团队专门针对问题改进措施进行讨论 制定可行的改进措施 可行的 意思即为在下一次迭代中团队可以做到 如果改进措施团队无法做到 则改进没有意义 督促改进措施落实 有些敏捷团队按照敏捷实践组织了项目回顾会议 选出了需要改进的方面 也制定了相 应的措施 但是在下一次迭代中 没有人监督这些改进措施的落实 团队仍然按照上一迭代 的方式做事 项目回顾会

14、议完全沦为一种形式 PDCA 是一个通过发现问题和改进问题达到 持续改进目的的过程 如果只有发现问题而没有改进问题 则谈不上改进 更没有持续的项 目管理水平的提高 因此 项目经理需要在每个迭代中监督上次回顾会议上制定的改进措施 的执行情况 保证制定的改进措施执行到位 4 总结总结 大多数 IT 项目在项目收尾时都无法达到同时满足时间 范围 成本三方面预期的项目 成功标准 在项目管理中通过引入质量管理领域的 PDCA 循环 可使项目管理水平持续提 高 从而保证项目具备越来越高的成功率 在 Plan 阶段 制定计划前需要确保所有的需求都清晰明确 还要保证由具体的任务执 行人来做任务分解和工期估算 把项目管理作为重要的项目任务 最后要做好风险管理计划 在 Do 阶段 需要控制需求的变更 同时要营造高效沟通的氛围 在 Check 阶段 总结团队在本次迭代中做的好的方面和做的不好的方面 针对做的不好 的方面制定相应的改进措施 在 Act 阶段 有时需要适当修正改进措施以确保改进措施可行 最重要的是要监督改进 措施真正执行到位

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 其它办公文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号