工作当中一些项目管理的心得体会.pdf

工作当中一些项目管理的心得体会 基本上，产品开发过程中的一些重大的关键问题，都是需要产品经理来拍板 ;至于拍板之前的种种 沟通、权衡等，就要靠产品经理本身的 素质“ ”了，正文开始： “1人 100 个月完成的项目，不是 100 个人 1个月就可以完成。 ” 项目管理是让项目活动中相互竞争的各类制约因素：质量、进度、资源、风险等取得平衡的艺术， 同时也是平衡项目干系人的各种需要、关注和期望，带领不同的人朝着相同目标迈进的领导艺术。 成功的项目管理可以简单理解为：按时、在预算内 + 满足产品需求 +满足质量需求 地完成项目。 以下是我对项目管理的一点体会记录。 　　需求等级 视觉 A ：图片没有分享功能吗 ? 技术 K ：图片有链接转发分享、微博或邮件形式分享等多种分享，全部开发的话需要推延时间表。 策划 D ：图片只做预览、下载已经足够了，暂时不做分享。 交互 E ：如果我们的用户是基于邮箱用户，图片的邮件分享还是建议做。 如果在前期产品需求文档中没有明确定义每个需求的优先等级，或者说项目成员对需求的优先等级 没有明确的意识，可能类似的争论会时常发生在项目成员之间，每个人会基于自己对产品目标的理 解来考虑这个需求是否要做，什么时候做，做到什么程度而产生分歧，因而增加项目推进的阻力。 所以在前期产品需求文档中，必须明确定义出每个需求的优先等级，需求的粒度可细化到每个大功 能下的子功能需求，如：图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的 划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等 ; 　　一般的需求等级划分： P0 -Must have ： 如果缺失，产品不能发布 P1 -Should have ： 如果缺失，产品能发布，但不能达到预定目标 (功能/性能 ) P2 -Nice to have ： 做了则更好 P3 -Neutral ： 对产品没有明显的好处，用户不在意 每个需求的优先等级确定之后，产品经理根据产品预定目标、开发成本、运营计划等来定义一个等 级分界线，高于或等于这个等级分界线的需求在本期开发，部分根据成本、运营计划等因素调整到 下期开发，而低于这个等级分界线的需求则只会在下期开发，这样让全体项目成员对本期要做的需 求达成共识。 　　需求等级的实际应用： WBS 各工作包 Triage 的参考基准之一 ;Triage 即确定需求任务是否要做，是否要现在做的一个共同决 策过程 ;在Triage 的过程中，任务 owner 对自己的任务以及其他人的任务有更全局的认识。 Bug 的Triage 的参考标准参考基准之一 (也是 zero bug * 注 1 和code freeze * 注 2 时间节点计算的参考 基准之一 );Triage 即确定测试中的 Bug 是否要修，是否要现在修 ;如：在功能开发期间， P0 、P1 、P2 及以上的 Bug 都要修 ;当进入接口冻结期后，只有 P0、 P1normal 及以上的 Bug 才允许修，以保证优先 的Bug 问题更快地被解决。 *注 1 Z ero Bug ：当前不存在 active bug ，或不存在高优先级或特别严重的 bug *注2 Code Freeze ：除高优先级或特别严重的 bug 外，代码冻结不再接受提交 　　 WBS 技术 K ：相片上传的界面还没有搭建好吗 ?这部分我们需要先做起来。 前端 J ：视觉设计师没有完成呢 ! 视觉 A ：我在做相片的展示页面，还没有做到相片上传。 项目各成员对自己需要负责的任务粒度细分不到位，每个任务的交付时间点不够明确，对任务之间 的依赖关系也不够清晰，造成项目推进中的协作成本提高，项目时间预估准确率不高，项目控制的 风险增加 ; 因此在产品需求文档确认之后，必须做工作分解 WBS(Work Breakdown Structure) ，即把需求分解 成较小的、易于管理的工作包。一般的工作包是最小的 可交付成果“ ”。工作包必须详细到可以对该 工作包进行估算 (成本和工时 ) 、安排进度、分配负责