一、写在前面项目管理者联盟
谈到闭环,想必大家都不陌生。还记得5月份的时候,乐问上也有一个关于闭环的热帖,而且还发起了红蓝方的PK大讨论(有兴趣的同学可以搜搜看看)。既然是PK,总归是没有谁对谁错,更多是的彼此对闭环有着不一样理解。项目管理者联盟
因此,当笔者提笔想写点项目管理中的闭环思维时,总觉得有种莫名的虚,哈哈,但还是想结合项目管理中一些实际的场景和模型,浅谈下自己的理解,也算是抛砖引玉吧,欢迎大家一起探讨!项目管理论坛
二、我所理解的闭环项目管理者联盟
我们先看看百度百科关于闭环的一个定义:闭环(闭环结构)也叫反馈控制系统,是将系统输出量的测量值与所期望的给定值相比较,由此产生一个偏差信号,利用此偏差信号进行调节控制,使输出值尽量接近于期望值。这里有一个笔者认为特别重要的词——反馈。回到我们实际的工作场景中来看,我们主动push的一件事,或者一个询问,是不是都希望能够得到对方的反馈,或者说最简单的,我们在企业微信里面给对方发了一个信息,都会希望对方给予一个反馈,而这就是最简单的闭环了。PgMp.mypm.net
前段时间在微信公众号上面看到这样一篇文章——《一个人靠不靠谱,就看这三件小事》,文章认为,一个人靠不靠谱,其实就看这三点:“凡事有交代,件件有着落,事事有回音。”而这正是笔者想引申和借鉴的闭环思维,也即如果别人发起了一件事,你不管做得如何,都要最后闭环到这个发起者。这是文章中所提到的观点,也是笔者非常认同的观点。项目经理圈子
三、项目管理中的闭环项目管理者联盟
不知道大家是否有这样的感觉,在做项目的过程中,或者是在平时的工作中,很多信息的获取,或者信息的同步,都会相对被动。以下这些场景,大家是否有熟悉的画面:项目管理者联盟
3.1 场景原型pmp.mypm.net
场景1:开发侧的前后台联调,大家一开始各自做自己的事情,然后到联调的时候,总会希望别人来主动发起,或者说是自己的部分写完了,然后继续做其他事情了;pmp.mypm.net
场景2:PM安排好了一个需求评审会,需求评审完了,对应需求或者模块人员也落实了,总是要一而再再而三的催促给出WBS分解和工作量评估;在项目推进的过程中,也时常会出现要求按时反馈进度,也总是姗姗来迟,或者压根就给忘记反馈了;项目经理博客
场景3:提交了一个美术需求,安排了具体的负责人,也明确了设计时间,但到时间节点的时候,还是需要去问APM或者当事人,是不是已经完成了;项目管理者联盟
场景4:需求是实现过程中,好像还挺顺利的,但一到验收环境,就各种问题频出;pmp.mypm.net
场景5:版本开始测试了,然后每天并不知道测试的具体进度是啥,是否有什么问题;项目管理者联盟
场景6:老板交代了一件事情,比如写的总结报告或者分析报告,然后自己写完了,邮件或者企业微信发给了老板,但老板可能过了好些天想起来,还是会问,你报告或者PPT输出了没;
场景7:一件老板比较关心的事情,安排自己去处理,比较复杂或者比较费时,短时间内给不了结论或者反馈,恰是这种情况,老板因为关心,又来催问,想了解事情的进展。转自项目管理者联盟
诸如以上的场景,大家是否都有或多或少的经历过,而这些场景,在项目管理过程中,时常会出现或者遇到,概括起来说,这些场景,都可以归类为,没有形成比较好的闭环,没有形成比较好的反馈。项目管理者联盟
那么问题来了,我们在辅助、引导和管理一个项目时,哪些是可以形成闭环的呢。这里不去说项目的五大过程管理组,也不去讲PDCA闭环管理,因为这些本身就是很好的闭环。training.mypm.net

3.2 闭环模型www.mypm.net
这里要谈的更多是聚焦具体团队可以形成的闭环模型:项目管理者联盟
产品/策划侧:一个需求的提出,不管是美术落实还是开发落实,这个闭环就是PM有没有落实下去,落实的是谁在做,什么时候做,什么时候做完,什么时候可以验收,验收完,转给测试验证,这个需求最终实现。那就是一个完整的闭环。里面其实是有一个大闭环和一个小闭环,小闭环:你提的需求,PM是否有落实下去,你确认了,这就是小闭环了;大闭环:什么时候做,什么时候做完,什么时候验收,然后到验收完,就是大闭环。模型中标注颜色的部分,是在负责具体需求时,比较容易忽略的。项目中过程中,有多少策划同学是在提了需求之后,就基本上啥也不管的,也不专注去验收需求的,可以自省,哈哈。pmp.mypm.net

转自项目管理者联盟
开发侧:接到一个需求任务,从需求的评审开始,到方案设计,编码,联调,自测,转验收,bug解决,需求完善,周知美术或者策划验收,才算一个完整的闭环。同样,有不少同学可能只专注于自己的编码和自测,但并没有去同步或者及时同步到相关人验收。项目管理论坛

项目管理者联盟
|