在最近十几年的互联网圈子里，若是把产品比作一个小孩，那产品经理就是他妈，项目经理就是他的班主任。妈没法换，可老师带完这一批还有下一批，这就注定了项目经理永远只能奔跑在项目未结束或正开始的途中。
任何一个互联网项目从构思到落地，到完成，要确认的事项成千上百，项目经理都可谓是职场上的多面手，既要应付得老板，也要手刃得了开发，不仅要衔接好产品，还得关注用户体验设计。处理过程中稍有不慎，项目可能就会整体延期，而锅就一口，你不背谁背...
这次分享的既是项目管理中的一个方法：构建闭环
何为“闭环”：
百度百科中将“闭环”同时也定义为“反馈控制系统”，我认为其中有个特别重要的此——“反馈”
回到我们实际的工作场景中，无论是主动推动的一件事情，还是简单的一个询问，亦或仅是微信里的一条信息，都会希望对方给予一个反馈，而这就是最简单的闭环了。
总结为三点即为”凡事有交代，件件有着落，事事有回音“
项目管理中的闭环
在一些初创公司或者没有流程系统的中小型公司，在项目和工作中，很多信息的获取或同步，都会相对被动。举几个详细的场景：
场景原型：
场景1：
开发的前后台联调，大家一开始各做各的事情，到该联调的时候，总会希望别人来主动发起，或者说自己的部分写完了，就一声不吭继续做其他事情了；
场景2：
产品经理安排好了一个需求评审会，会议结束后，对应需求或者模块人员也落实了，后来却要一再催促开发，才能给出WBS（工作分解结构（Work Breakdown Structure））和工作量评估；而在项目推进的过程中，时常会要求按时反馈才进度，但开发却总是延迟，更甚者直接就忘记了；
场景3：
提出了一个设计需求，安排了具体的负责人，也明确了设计时间，但是到了时间节点的时候，还需要去问设计师，是否已经完成；
场景4：
需求在开发实现过程中，好像还挺顺利的，但一到验收环境，就问题频出，导致上线时间延后，甚至影响以前已开发的功能；
场景5：
当前版本开始测试了，但每天并不知道测试的具体进度，也不知道是否有什么问题，发现的问题也不知道什么时候能解决后上线；
场景6：
老板交代了一件事，比如写总结或分析报告，自己写完了，也发给了老板，但老板可能好多天后才想起来，而且有些还会问，你的报告什么时候能写完发给他？
场景7：
一件老板比较关心的事情，安排自己去处理，事情比较复杂或者比较费时，短时间内给不了结论或者反馈，恰是这种情况，老板因为关心，又来催问，想了解事情的进展。
诸如以上的场景，大家是否都或多或少地经历过？而这些场景，在项目管理过程中，时常会出现。概括起来说，这些场景，都可以归类为"没有形成较好的闭环和较好的反馈"。
那么问题来了，我们在辅助、引导和管理一个项目时，哪些是可以形成闭环的呢？这里不去说项目的五大过程管理组，也不去讲PDCA闭环管理，因为这些本身就是很好的闭环，这里要谈的，更多是聚焦具体团队可以形成的闭环模型。
闭环模型
产品经理：
一个需求的提出，不管落实到功能还是想法，不管是设计还是开发，都需要形成这个闭环：
项目经理有没有落实下去，落实的是谁在做，什么时候做，什么时候做完，什么时候可以验收，验收完，转给测试验证，这个需求最终实现，这就是一个完整的闭环。
里面其实是有一个大闭环和一个小闭环：
小闭环：需求方提的需求，产品经理是否有落实下去，你确认了；
大闭环：什么时候做，什么时候做完，什么时候验收，然后到验收完。
模型中标注颜色的部分，是在负责具体需求时，比较容易忽略的。项目过程中，有很多需求方在提出需求后，就基本上不管了，也不专注去验收的。
开发：接到一个需求任务，从需求的评审开始，到方案设计，编码，联调，自测，转验收，bug解决，需求完善，周知设计或者产品经理验收，才算一个完整的闭环。同样，有不少同学可能只专注于自己的编码和自测，并没有去同步或者及时同步到相关人验收。
设计：设计的同学接到需求，制作完成，周知到下一个环节的负责人，然后在版本里面验收完效果，才算一个完整的闭环。这点在以往的一些项目中，是很弱的一个环节，经常会在验收版本的时候才发现，版本的实现效果和设计的效果差别很大，很明显就是验收的环境，没有把设计纳入到验收的闭环里面来。
测试：从需求评审开始，用例设计，版本的测试，bug的回归，版本质量风险的评估、总结，最后到项目报告的反馈，形成完整的闭环。而实际测试的过程中，因为周期往往比较长，或多或少会缺少中间测试环节或测试进度的反馈，也会缺少版本质量风险的评估。
综合以上闭环模型来看，每个团队或多或少都会出现某个环节的遗漏，或者反馈不到位的地方，而这些情况累计起来，对项目的推进，是会有很大的影响的。作为项目经理，不仅仅只是在项目启动阶段，规划阶段做好了，就万事大吉了，而应该是把更多的精力投入在执行和监控阶段。
我们每天可能75%的时间都在沟通，对于项目中的很多事情，我们坚持“相信团队，但必须核实”的原则。
检查项目具体事项，小团队可能还好，晨会或者发发邮件聊聊天，就都了解清楚了；一旦团队规模大起来，在成员很多的情况下，什么事情都要一一去审查的话，那会累到不行，而且一天下来，基本上没什么收获。审查的时间耗掉太多，基本上也就没留下什么时间去思考和解决项目中可能存在的问题；没有时间去汇总、整合项目的有效信息同步给主要干系人，这样势必会导致一个恶性循环。
所以，作为项目经理，我更认为应让以上各闭环模型都形成真正的闭环，形成良性的闭环，这样不仅可以释放大量的精力，让自己轻松很多，还会事半功倍。
构建闭环
那么在项目管理的过程中，如何更好地让各个环节都形成有效的闭环呢：
1.规范流程
流程是为了效率服务的。通过规范项目开发流程，把大大小小的闭环串联起来，形成项目的大闭环，可以让团队成员清楚地知道，每个团队在哪个阶段需要做什么事情。
下图是我们在项目过程中总结提炼的一个双闭环的验收流程，从多个项目的实际反馈来看，的确有比较好的效果。每个需求完成后，开发在自测期间，涉及到设计资源的验收，就及时周知设计负责人一起验收，可以很好地避免需求转策划验收时，出现大量的设计效果方面的问题。
2.建立规则
光有流程还不够，因为流程并不具备很好的约束力。因此建立规则的目的很简单，就是希望在有限的时间内，获得有效的反馈，让团队互相形成一种约束力。
比如，流程走到需求评审完，该输出WBS任务分解和具体的工作量时，提醒过一次没有按时输出，可以豁免，后面还没有按约定时间输出，就要有相应的惩罚措施了；
同样，比如设计完成时需确定且及时告知下个环节的负责人，提醒过一两次之后，还是没有按时，也需有惩罚；
产品没有按时体验和验收需求或版本的，也要有惩罚措施。
建立很基本的有效反馈机制，更深层次的目的是释放项目经理，不用事无巨细地去问，以此形成积极主动且有效的反馈机制。
但有一个前提，项目经理在定这些规则时，一定是要和团队达成共识，切忌单方面去制定某种规则，要不然，很容易适得其反。
3.用好工具
工具可以帮助我们在管理的过程中，尽可能自动化。
项目经理要尽可能让能自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才能进一步地释放自己的精力。
例如，TAPD就是一款非常强大的工具，我们可以设定需求管理流程和缺陷管理流程，这可以帮助我们将需求管理和缺陷管理的流转全部自动化，起到事半功倍的效果；可以让项目的整个过程和信息更加透明化；可以让团队成员彼此都清楚知道上下游环节的负责人；还可以起到互相监督的作用。
工具自动化还有另外的优势：不用什么事情都去问一遍，可以很大程度上减少沟通成本。
比如：我们在明确设计完成时，要在TAPD需求单的评论里面，备注好资源输出的路径（svn地址），然后转给具体负责的开发人员，同时，在群里面艾特对应的负责人。
这样等到开发负责人要用这个资源的时候，就不用再来问术负责设计的同学了。如果开发人员和美术人员一对一，那去问一遍倒还好，但实际在项目进程中，往往的1个设计师对多个开发人员，而且在当前快节奏的情况下，都是多个系统并行走的，也对效率有更高的要求。
试想，如果开发过程中，要反复沟通美术资源在哪里，设计师恐怕大部分时间要去应对问答了。而且开发人员时常找不到所需要的资源，也会严重影响开发进度。
4、积极主动
流程，规则，工具，如果说是形成有效闭环和反馈的客观因素，那么积极主动就是形成闭环的主观因素，是催化剂。
很多时候都是多线程的工作状态，一个人可能会同时处理很多任务，这也涉及到多任务的管理。
因此在很多时候，需要更积极，更主动地反馈，让下个环节的负责人清楚知道当前的情况，以便提前做好预判。
此外，积极主动，还可以确保很多有必要的反馈，尤其是向上管理，比如领导交办可能是一个需要很长时间周期完成的工作，那么中间过程或者中间结论，要及时地进行反馈，占据主动权，避免领导来主动询问。所以，无论是作为项目经理，还是项目成员，都应要积极主动去同步或者获取信息。请主动出击！
细细分析和挖掘上述闭环模型，我们会发现，在跟进、落实每项工作和事情时，我们彼此都不仅仅是完成事情本身，更需要心里装着与此相关的或同事或团队或整个项目的目标；在跟进、落实每件事情时，我们彼此不仅仅是做事情时积极主动，更需要养成“凡事有交代，件件有着落，事事有回音”。因此，闭环思维强调的不仅仅是责任心，进取心，更强调的是团队间的合作，配合的成熟度还有团队间的信任，同时，还有彼此间的契约精神。
网友评论