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