[转]如何做到高效配合？浅谈项目管理中的闭环思维

前言：腾讯的游戏学院公众号还是挺不错的，经常有技术和运营、策划等游戏相关的干货分享，这篇讲管理的我觉得挺不错的，特来分享一下。

导语：谈到闭环，想必大家都不陌生。本文将结合项目管理中一些实际的场景和模型，谈谈项目管理中的闭环思维。作者徐州系腾讯互动娱乐光子工作室群高级项目经理。

我所理解的闭环

我们先看看关于闭环的一个定义：闭环（闭环结构）也叫反馈控制系统，是将系统输出量的测量值与所期望的给定值相比较，由此产生一个偏差信号，利用此偏差信号进行调节控制，使输出值尽量接近于期望值。这里有一个笔者认为特别重要的词——反馈。回到我们实际的工作场景中来看，我们主动push的一件事，或者一个询问，是不是都希望能够得到对方的反馈？这就是最简单的闭环。

（文中部分图片来源于网络，如涉及任何版权问题，请联系腾讯游戏学院）

前段时间在某微信公众号上面看到这样一篇文章——《一个人靠不靠谱，就看这三件小事》，文章认为，一个人靠不靠谱，其实就看这三点：“凡事有交代，件件有着落，事事有回音。”而这正是笔者想引申和借鉴的闭环思维，如果别人发起了一件事，你不管做得如何，都要最后闭环到这个发起者。这是文章中所提到的观点，也是笔者非常认同的观点。

项目管理中的闭环

不知道大家是否有这样的感觉，在做项目的过程中，或者是在平时的工作中，很多信息的获取，或者信息的同步，都会相对被动。以下这些场景，大家是否有熟悉的画面？

01

场景原型

场景1：开发侧的前后台联调，大家一开始各自做自己的事情，到联调的时候，总希望别人来主动发起，或者自己的部分写完了，就去继续做其他事情了；

场景2：PM安排好了一个需求评审会，需求评审完了，对应需求或者模块人员也落实了，却总是要一而再再而三的催促之后，才会给出WBS分解和工作量评估；

场景3：提交了一个美术需求，安排了具体的负责人，也明确了设计时间，但到时间节点的时候，还是需要去问APM或者当事人，是不是已经完成了；

场景4：需求实现过程中，好像还挺顺利的，但一到验收环境，就各种问题频出；

场景5：版本开始测试了，却不知道测试的具体进度，以及是否有什么问题；

场景6：老板交代了一件事情，比如写总结报告或者分析报告，自己写完之后，邮件发给了老板，但老板可能过了好些天才想起来，还是会问，你报告或者PPT输出了没；

场景7：一件老板比较关心的事情，安排自己去处理，比较复杂或者比较费时，短时间内给不了结论或者反馈，老板因为关心，又来催问，想了解事情的进展。

诸如此类的场景，大家是否都曾经历过？而这些场景，在项目管理过程中，时常会出现或者遇到，概括起来说，这些场景，都可以归类为，没有形成比较好的闭环，没有形成比较好的反馈。

那么问题来了，我们在辅助、引导和管理一个项目时，哪些是可以形成闭环的呢？这里不去说项目的五大过程管理组，也不去讲PDCA闭环管理，因为这些本身就是很好的闭环。

02

闭环模型

这里要谈的更多是聚焦具体团队可以形成的闭环模型：

产品/策划侧：一个需求的提出，不管是美术落实还是开发落实，这个闭环就是PM有没有落实下去，落实的是谁在做，什么时候做，什么时候做完，什么时候可以验收，验收完，转给测试验证，这个需求最终实现。这就是一个完整的闭环。里面其实是有一个大闭环和一个小闭环，小闭环：你提的需求，PM是否有落实下去，你确认了，这就是小闭环了；大闭环：什么时候做，什么时候做完，什么时候验收，然后到验收完，就是大闭环。模型中标注颜色的部分，是在负责具体需求时，比较容易忽略的。项目过程中，有多少策划同学是在提了需求之后，就基本上啥也不管的，也不专注去验收需求的，可以自省。

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

美术侧：美术方面的需求，设计的同学接到需求，制作完成，周知到下一个环节的负责人，然后在版本里面验收完效果，才算一个完整的闭环。这点在以往的一些项目中，是很弱的一个环节，经常会在验收版本的时候才发现，版本里面的美术效果和设计的效果差别很大，这里很明显的一点，就是验收的环境，没有把美术纳入到验收的闭环里面来。

测试侧：从需求评审开始，到用例设计、版本的测试、bug的回归、版本质量风险的评估和总结、项目报告的反馈，形成完整的闭环。而实际测试的过程中，因为周期往往比较长，或多或少会缺少中间测试环节或测试进度的反馈，也缺少版本质量风险的评估。

综合以上闭环模型来看，每个团队或多或少都会出现某个环节的遗漏，或者反馈不到位的地方，而这些情况累计起来，对项目的推进，会有很大的影响。作为PM，不仅仅要在项目的启动、规划阶段做好，还应该将更多的精力放在执行和监控阶段。

我们每天可能有75%的时间都在沟通，项目中的很多事情，我们是坚持“相信团队，但必须核实”的原则。小团队可能还好，项目事情的check、晨会等方式就能沟通清楚了，但在团队规模比较大，项目团队成员很多的情况下，什么事情都要一一去check的话，会耗费非常多时间，而且一天下来，基本上没有什么收获。如果check的时间耗掉太多，基本上也就没有什么时间去思考和解决项目中可能存在的问题，也没有时间去汇总、整合项目的有效信息同步给主要干系人，这样势必会导致一个恶性循环。

所以，笔者更加的认为，作为PM，应该要让以上各闭环模型形成真正的闭环，形成良性的闭环，这样不仅可以释放大量的精力，也会事半功倍。

03

构建闭环

那么在项目管理的过程中，如何更好的让各个环节都形成有效的闭环呢？

3.1 规范流程

流程是为了效率服务的，通过规范项目开发流程，把大大小小的闭环串联起来，形成项目的大闭环，这样可以让团队成员清楚的知道，每个团队在某个阶段需要做什么事情。下图是我们在项目过程中总结提炼的一个双闭环的验收流程，在多个项目和实际反馈来看，是形成了比较好的效果，每个需求完成后，开发在自测期间，涉及到美术资源的验收，就及时的周知美术负责人一起验收，这样可以很好的避免需求转到策划验收时出现大量的美术效果方面的问题。

3.2 建立规则

光有流程还不够的，因为流程并不具备很好的约束力。因此建立规则的目的很简单，就是希望在有限的时间内，获得有效的反馈，让团队互相形成一种约束力。比如，流程走到需求评审完，该输出WBS任务分解和具体的工作量时，提醒过一次没有按时输出，可以豁免，后面还没有按约定时间输出时，那就有相应的惩罚措施了；同样，比如美术设计完成时的确定，以及完成时及时周知到下个环节的负责人，提醒过一次两次之后，还是没有按时，那同样也有相应的惩罚措施；策划没有按时体验和验收需求或版本的，也同样有惩罚措施。建立基本的有效反馈机制，更深层次的目的是释放PM，不用事无巨细地去问，以此形成积极主动的、有效的反馈机制。但有一个前提，PM在定这些规则的时候，一定是要和团队达成共识，切忌单方面的去制定某种规则，否则很容易适得其反。

3.3 用好工具

工具可以帮助我们在管理的过程中，尽可能的自动化。PM要尽可能的让能够自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才可以进一步的释放自己的精力。

3.4 积极主动

流程、规则、工具，如果说是客观上的可以形成有效的闭环和反馈，那么积极主动，就是主观上，是形成闭环的催化剂。我们很多时候都是多线程的工作状态，可能会同时处理很多任务，这也涉及到多任务的管理。因此在很多时候，需要更积极，更主动的反馈，让下个环节的负责人清楚的知道当前的情况，以便提前做好预判。此外，积极主动，还可以确保很多有必要的反馈，尤其是向上管理，比如领导交办可能是一个需要很长时间周期完成的工作，那么中间过程或者中间结论，及时的进行反馈，占据主动权，避免领导来问。所以，无论是作为PM ，还是项目成员，都应该要要积极主动去同步或者获取信息。请主动出击！

结语

前面提到笔者理解下各个团队的闭环模型，细细分析和挖掘会发现，在跟进、落实每项工作时，我们彼此都不仅仅是完成事情的本身，更需要心里装着与此相关的同事、团队或整个项目的目标；在跟进、落实每项工作时，我们彼此不仅仅是做事情时积极主动，更需要养成凡事有交代，件件有着落，事事有回音的习惯。因此，闭环思维强调的不仅仅是责任心，进取心，更强调的是团队间的合作，配合的成熟度还有团队间的信任，同时，还体现出彼此间的契约精神。