世纪难题：为什么老板总追在你屁股后面问进展？

回答这个问题之前，小编想先跟你聊聊项目管理的问题。

在互联网界，大家经常笑称若是把产品比作一个小孩，那产品经理就是他妈，项目经理就是他的班主任。妈没办法换，可老师带完这一批还有下一批，这就注定了项目经理永远只能奔跑在项目未结束或正开始的途中。

一个项目从开始到完成，要确认的事项成百上千，项目经理都可谓是职场上的武林高手，既要应付得了老板，也要手刃得了开发，既得衔接好产品，还得关注着设计。处理过程中，稍有不慎，项目可能就会整体延期，而锅就一口，你不背谁背…

面对项目管理过程中的百般困难，鹅厂高级项目经理徐州早已在 一路摸爬滚打中 炼就了他的绝世武功， 他将自己升级打怪的经历浓缩为一则心法：构建闭环。

想知道这四个字究竟有什么奥秘？让我们一起来看看他的分享吧~

百度百科将闭环同时也定义为反馈控制系统，我认为其中有个特别重要的词—— 反馈。 回到我们实际的工作场景中，不论是主动push的一件事，还是简单的一个询问，亦或仅是微信里的一条信息，都会希望对方给予一个反馈，而这就是最简单的闭环了。

前段时间在公众号上看到一篇文章，共鸣很深。文章认为，一个人靠不靠谱，其实就看三点： “凡事有交代，件件有着落，事事有回音”。 而这正是笔者想引申和借鉴的 闭环思维 ，即如果别人发起了一件事，不管你做得如何，最后都要知会这个发起者。

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

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

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

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

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

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

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

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

我们每天可能75%的时间都在沟通，对于项目中的很多事情， 我们坚持“相信团队，但必须核实”的原则。 检查项目具体事项，小团队可能还好，晨会或者发发邮件聊聊天，就都了解清楚了；一旦团队规模大起来，在成员很多的情况下，什么事情都要一一去check的话，那会累到不行，而且一天下来，基本上没什么收获。check的时间耗掉太多，基本上也就没留下什么时间去思考和解决项目中可能存在的问题；没有时间去汇总、整合项目的有效信息同步给主要干系人，这样势必会导致一个恶性循环。

所以，作为项目经理，我更认为应让以上各闭环模型都形成真正的闭环，形成良性的闭环，这样不仅可以释放大量的精力，让自己轻松很多，还会事半功倍。

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

1 、规范流程

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

2 、建立规则

光有流程还不够，因为流程并不具备很好的约束力。因此建立规则的目的很简单，就是希望在有限的时间内，获得有效的反馈，让团队互相形成一种约束力。比如，流程走到需求评审完，该输出WBS任务分解和具体的工作量时，提醒过一次没有按时输出，可以豁免，后面还没有按约定时间输出，就要有相应的惩罚措施了；同样，比如美术设计完成时需确定且及时告知下个环节的负责人，提醒过一两次之后，还是没有按时，也需有惩罚；策划没有按时体验和验收需求或版本的，也要有惩罚措施。

建立很基本的有效反馈机制，更深层次的目的是释放项目经理，不用事无巨细地去问，以此形成积极主动且有效的反馈机制。 但有一个前提，项目经理在定这些规则时，一定是要和团队达成共识，切忌单方面去制定某种规则，要不然，很容易适得其反。

3、用好工具

工具可以帮助我们在管理的过程中，尽可能自动化。 项目经理要尽可能让能自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才能进一步地释放自己的精力。例如，鹅厂的TAPD就是一款非常强大的工具，我们可以设定需求管理流程和缺陷管理流程，这可以帮助我们将需求管理和缺陷管理的流转全部自动化，起到事半功倍的效果；可以让项目的整个过程和信息更加透明化；可以让团队成员彼此都清楚知道上下游环节的负责人；还可以起到互相监督的作用。

工具自动化还有另外的优势：不用什么事情都去问一遍，可以很大程度上减少沟通成本。比如：我们在明确美术设计完成时，要在TAPD需求单的评论里面，备注好资源输出的路径（svn地址），然后转给具体负责的开发人员，同时，在群里面艾特对应的负责人。这样等到开发负责人要用这个资源的时候，就不用再来问美术负责设计的同学了。如果开发人员和美术人员一对一，那去问一遍倒还好，但实际在项目进程中，往往的1个设计师对多个开发人员，而且在当前快节奏的情况下，都是多个系统并行走的，也对效率有更高的要求。

试想，如果开发过程中，要反复沟通美术资源在哪里，设计师恐怕大部分时间要去应对问答了。而且开发人员时常找不到所需要的资源，也会严重影响开发进度。