一、写在前面

我所理解的闭环

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

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

三、项目管理中的闭环

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

3.1 场景原型

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

场景2：PM安排好了一个需求评审会，需求评审完了，对应需求或者模块人员也落实了，总是要一而再再而三的催促给出WBS分解和工作量评估；在项目推进的过程中，也时常会出现要求按时反馈进度，也总是姗姗来迟，或者压根就给忘记反馈了；

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

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

场景5：版本开始测试了，然后每天并不知道测试的具体进度是啥，是否有什么问题；

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

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

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

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

3.2 闭环模型

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

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

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

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

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

综合以上闭环模型来看，每个团队或多或少都会出现某个环节的遗漏，或者反馈不到位的地方，尤其是标注的部分，而这些情况累计起来，对项目的推进，是会有很大的影响的。作为PM，不仅仅只是在项目的启动，规划阶段做好了，就万事大吉了，而应该是更多的精力在执行和监控阶段，要去发现、去预测，去分析项目过程中可能存在的或风险，或瓶颈，然后提前规避，或者提前想好应对策略，让项目始终处于可控状态。

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

另外，在一个项目团队里面，PM要面对的是不同性格，不同特质的团队成员，他们彼此有自己的工作方式和习惯，就以上这些闭环模型，可能大多时候，并不是团队成员间的有意为之，而是会沉浸在自己的工作状态和角色里面，或有些团队成员的性格本身就是会偏内向，会无意间忽略上下游环节的合作和沟通。

因此，构建一个良性且循环的闭环模型，就显得非常的重要了，不仅仅可以让团队间更好的自运转，释放PM的精力，还可以从另外一个层面来解决人的问题。通过闭环模型来间接解决人的问题，有时候会事半功倍。

3.3 构建闭环

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

3.3.1 规范流程

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

3.3.2 建立规则

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

3.3.3 用好工具

工具可以帮助我们在管理的过程中，尽可能的自动化。PM要尽可能的让能够自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才可以进一步的释放自己的精力。鹅肠的TAPD则是非常强大的工具，我们可以设定需求管理流程、缺陷管理流程，这些可以帮助我们在需求的流转，缺陷的流转全部自动化，起到事半功倍的效果；可以让项目的整个过程和信息更加透明化；可以让团队成员彼此都清楚的知道上下游环节的负责人；还可以起到互相监督的效用。通过工具自动化，还有另外的优势在于，不用什么事情都去问一遍，也可以在很大程度上减少沟通成本。比如：我们在明确美术设计完成时，要在tapd需求单的评论里面，备注好资源输出的路径（svn地址），然后转给具体负责的开发人员，同时，还在群里面艾特对应的负责人。这样等到开发负责人要用这个资源的时候，就不用再来问美术负责设计的同学了。如果开发人员和美术人员一对一，那去问一遍，到还好，但实际在项目进程中，往往的1个设计师对多个开发人员，而且在当前快节奏的情况下，都是多个系统并行走的，也对效率有更高的要求。试想，如果开发过程中，要反复的去沟通美术资源在哪里，设计师恐怕大部分时间要去应对问答了，而且开发人员时常找不到所需要的资源，也会严重影响开发进度。

3.3.4 积极主动

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

四、结语

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