反馈机制的重要性

    复盘原是围棋术语，本意是下完一盘棋后，重新把对弈过程还原一遍，看哪些地方下得好，哪些地方下得不好，哪些地方可以有不同或更好的下法，把这个对弈的过程还原且进行探讨、分析的过程，就叫复盘。

    复盘被许多企业采用，例如在经营会议、IT预算、项目推进等汇报中，要求将过去一段时间的工作进行复盘，即行动后的回顾和反思。

    许多领导认为，复盘讲不清，下一步工作也就基本上不用听了；换句话说，过去发生的事都说不明白，还讲什么未来呢？

    而事实上，对于许多同事而言，复盘既耗时又痛苦，发生的事不好说，相反未来的事好说。

    那么，复盘的目的是什么呢？一个同事曾总结为教育训练。

    教育指理论，解决认知层面的问题，一般为自上而下宣贯，主要包括三个方面：

    第一，已有规范、标准、规章，却没按要求做，产生了偏差或损失的事情，要通过教育的方式，以敬效尤。

    第二，没有规范、标准、规章，但上层有思想阐述的，没有按要求做，归属于理念接轨及响应速度范畴。

    第三，没有规范、标准、规章，例如一个全新的领域，出现偏差的，应予以理解，宽容创新性错误。

    通过复盘，基于沉淀的经验或吸取的教训，修订、完善或新增规范、标准及规章，以便对照执行。

    而训练指技能，解决能力层面的问题，一般为自下而上的反馈，同样包括三个方面：

    第一，对规范，标准、规章的理解；

    第二，对照规范，标准、规章去模拟、反馈及执行；

    第三，执行中有无偏差，如果有偏差，原因、建议和思考是什么。

    许多企业在新的领域、新的战略、新的产品、大的投资、大的决策项目（含IT项目），在过程或结束后，要求进行复盘。

    而在IT管理过程，一般会在IT预算、IT项目、阶段总结中被要求复盘，我们接下来重点探讨IT项目如何复盘？

    注：复盘不同于工作总结，主要表面在2个方面：

    1、 主体不同：

    复盘以团队为主，通过复盘历练思维、提升组织能力；而工作总结以个体为主（当然个人也可以复盘），更多是回顾、罗列和复述。

    2、 方法/路径不同：

    复盘一般会对照目标，总结差异，挖掘价值，吸取教训，形成规范；也包括推倒重来，模拟演练，比对价值差异等；是一种结构性的总结方法。

    而工作总结，可根据不同的习惯、悟性，相对随意，没有固定的结构和流程，其中可包括问题及解决措施，但一般不会上升到规范、体系层级。

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

任何一个互联网项目从构思到落地，到完成，要确认的事项成千上百，项目经理都可谓是职场上的多面手，既要应付得老板，也要手刃得了开发，不仅要衔接好产品，还得关注用户体验设计。处理过程中稍有不慎，项目可能就会整体延期，而锅就一口，你不背谁背

这次分享的既是项目管理中的一个方法： 构建闭环

何为“闭环”：

百度百科中将“ 闭环 ”同时也定义为“ 反馈控制系统 ”，我认为其中有个特别重要的此—— “反馈”

回到我们实际的工作场景中，无论是主动推动的一件事情，还是简单的一个询问，亦或仅是微信里的一条信息，都会希望对方给予一个反馈，而这就是最简单的闭环了。

总结为三点即为 ”凡事有交代，件件有着落，事事有回音“

项目管理中的闭环

在一些初创公司或者没有流程系统的中小型公司，在项目和工作中，很多信息的获取或同步，都会相对被动。举几个详细的场景：

场景原型：

场景1：

开发的前后台联调，大家一开始各做各的事情，到该联调的时候，总会希望别人来主动发起，或者说自己的部分写完了，就一声不吭继续做其他事情了；

场景2：

产品经理安排好了一个需求评审会，会议结束后，对应需求或者模块人员也落实了，后来却要一再催促开发，才能给出WBS（工作分解结构（Work Breakdown Structure））和工作量评估；而在项目推进的过程中，时常会要求按时反馈才进度，但开发却总是延迟，更甚者直接就忘记了；

场景3：

提出了一个设计需求，安排了具体的负责人，也明确了设计时间，但是到了时间节点的时候，还需要去问设计师，是否已经完成；

场景4：

需求在开发实现过程中，好像还挺顺利的，但一到验收环境，就问题频出，导致上线时间延后，甚至影响以前已开发的功能；

场景5：

当前版本开始测试了，但每天并不知道测试的具体进度，也不知道是否有什么问题，发现的问题也不知道什么时候能解决后上线；

场景6：

老板交代了一件事，比如写总结或分析报告，自己写完了，也发给了老板，但老板可能好多天后才想起来，而且有些还会问，你的报告什么时候能写完发给他？

场景7：

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

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

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

闭环模型

产品经理：

一个需求的提出，不管落实到功能还是想法，不管是设计还是开发，都需要形成这个 闭环 ：

项目经理有没有落实下去，落实的是谁在做，什么时候做，什么时候做完，什么时候可以验收，验收完，转给测试验证，这个需求最终实现，这就是一个完整的闭环。

里面其实是有一个大闭环和一个小闭环：

小闭环： 需求方提的需求，产品经理是否有落实下去，你确认了；

大闭环： 什么时候做，什么时候做完，什么时候验收，然后到验收完。

模型中标注颜色的部分，是在负责具体需求时，比较容易忽略的。项目过程中，有很多需求方在提出需求后，就基本上不管了，也不专注去验收的。

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

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

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

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

我们每天可能75%的时间都在沟通，对于项目中的很多事情， 我们坚持“相信团队，但必须核实”的原则。

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

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

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

1规范流程

流程是为了效率服务的。通过规范项目开发流程，把大大小小的闭环串联起来，形成项目的大闭环，可以让团队成员清楚地知道，每个团队在哪个阶段需要做什么事情。

下图是我们在项目过程中总结提炼的一个双闭环的验收流程，从多个项目的实际反馈来看，的确有比较好的效果。每个需求完成后，开发在自测期间，涉及到设计资源的验收，就及时周知设计负责人一起验收，可以很好地避免需求转策划验收时，出现大量的设计效果方面的问题。

2建立规则

光有流程还不够，因为流程并不具备很好的约束力。因此建立规则的目的很简单，就是希望在有限的时间内，获得有效的反馈，让团队互相形成一种约束力。

比如，流程走到需求评审完，该输出WBS任务分解和具体的工作量时，提醒过一次没有按时输出，可以豁免，后面还没有按约定时间输出，就要有相应的惩罚措施了；

同样，比如设计完成时需确定且及时告知下个环节的负责人，提醒过一两次之后，还是没有按时，也需有惩罚；

产品没有按时体验和验收需求或版本的，也要有惩罚措施。

建立很基本的有效反馈机制，更深层次的目的是释放项目经理，不用事无巨细地去问，以此形成积极主动且有效的反馈机制。

但有一个前提，项目经理在定这些规则时，一定是要和团队达成共识，切忌单方面去制定某种规则，要不然，很容易适得其反。

3用好工具

工具可以帮助我们在管理的过程中，尽可能自动化。

项目经理要尽可能让能自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才能进一步地释放自己的精力。

例如，TAPD就是一款非常强大的工具，我们可以设定需求管理流程和缺陷管理流程，这可以帮助我们将需求管理和缺陷管理的流转全部自动化，起到事半功倍的效果；可以让项目的整个过程和信息更加透明化；可以让团队成员彼此都清楚知道上下游环节的负责人；还可以起到互相监督的作用。

工具自动化还有另外的优势：不用什么事情都去问一遍，可以很大程度上减少沟通成本。

比如：我们在明确设计完成时，要在TAPD需求单的评论里面，备注好资源输出的路径（svn地址），然后转给具体负责的开发人员，同时，在群里面艾特对应的负责人。

这样等到开发负责人要用这个资源的时候，就不用再来问术负责设计的同学了。如果开发人员和美术人员一对一，那去问一遍倒还好，但实际在项目进程中，往往的1个设计师对多个开发人员，而且在当前快节奏的情况下，都是多个系统并行走的，也对效率有更高的要求。

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

4、积极主动

流程，规则，工具，如果说是形成有效闭环和反馈的客观因素， 那么积极主动就是形成闭环的主观因素，是催化剂。

很多时候都是多线程的工作状态，一个人可能会同时处理很多任务，这也涉及到多任务的管理。

因此在很多时候，需要更积极，更主动地反馈，让下个环节的负责人清楚知道当前的情况，以便提前做好预判。

此外，积极主动，还可以确保很多有必要的反馈，尤其是向上管理，比如领导交办可能是一个需要很长时间周期完成的工作，那么中间过程或者中间结论，要及时地进行反馈，占据主动权，避免领导来主动询问。所以，无论是作为项目经理，还是项目成员，都应要积极主动去同步或者获取信息。请主动出击！

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

20210514

反馈机制的重要性

有些人的成功是很偶然的，有可能是因为一个不经意间的机会让自己的人生有了很大的气色，在此基础上一发不可收拾，事业越做越大。如果你问这些人当初为什么这么做，他们估计会说：这是自己运气好！运气这个东西，是可遇而不可求的，你不能天天等着天上掉馅饼。往往说自己就是运气才取的成就的人，其实这中间有一个很重要的环节就是反馈，这种反馈都是正反馈。

说到反馈，反馈可以有两种形式一种是正反馈，一种是负反馈。正反馈是对某件事可以起到促进作用的方式方法，负反馈是对某件事可以起到妨碍作用的方式方法。

刚提到的因为偶然因素取的成功的情况，就是正反馈的结果。正是因为一次次的正反馈驱使着人们不断的向前发展，正反馈本质上就是一种奖赏机制，不管是物质还是精神的，只要是奖励就可以使人不断的向前进步。我们无论做什么事情，一定要把反馈这个机制给分析清楚了，在军事上有一个很重要的原则就是首战必胜，这其实是很典型的正反馈的例子。

干一件事情，当目标确定的时候，在实施的进程中，一定要有意的制定出产生正反馈的方案。有效的正反馈方案，基本上事情就成功一半了，干成就只是时间的问题。那是不是所有的事情都可以设计出正反馈的方案呢？理论上是这样的，但是在实际 *** 作上，因为我们不可能总是可以设计出正反馈的方案，甚至在实际 *** 作上没有结果，有时候还会出现负反馈，事情不但没有气色而且后退了，一般在这个时候好多人都放弃了。大部分人都活在对为了的憧憬中，如果看不到希望，就选择了放弃，这就是人性吧，普遍来说，没有反馈甚至是负反馈选择放弃是普通人的常态。

所以成功属于少数人的游戏，那大的成就就更是这样了。取的大成就的人，一般都可以忍受没有反馈甚至是负反馈的境况，当没有结果时，他们是可以忍受的，他们会不断的尝试，直到找到正反馈的机制。

做成一件事儿其实本质就是建立正反馈的机制，任何事情都是这么做成的。有的人可能会说，我干的事情也没有什么明显的效果，可是我依然在持续下，事实是，只要你持续，那肯定是正反馈的结果，只是有的正反馈是隐性的，看不到，甚至感觉不到，也许它满足的你是的一个心理上的需求。

任何半途而废的事情，都是没有建立正反馈机制或者是出现了负反馈的机制。这也在提醒我们，当事情出现瓶颈的时候，我们要有耐心重新建立一套正反馈的机制。

一事无成的人，肯定出在反馈机制这个环节，建立反馈机制需要策略、方式、方法这些因素的辅助，只有不断的学习，丰富我们的阅历，增加我们的见识，才可以建立符合事实的反馈机制。

我记得去年在樊登读书会里面有一本书，叫做《低风险创业》，他讲了一句话：一个团队，队长必须要学会给队员及时地正面反馈（而不是负面反馈）。

什么叫做正面反馈呢？我的理解就是让对方能及时知道这件事情做得不错，感到自己又成长了！

而负面反馈是大多数领导，尤其是体制内的中国式领导的特长。叫到办公室一问：“你知道为什么叫你过来吗？你知道你做的那件事有多糟糕吗？你到底有没有用心啊……”一连串的批评与指责带给下属的创伤实在太大，两人的距离也逐渐生远。出现的结果就是让对方认为自己很糟糕，感觉自己没有进步。

所以，今年我在自己的小团队中很注意反馈的机制设定。刚开始我就是直接反馈，心想：我反馈给他，让对方知道哪些需要改进是很好的事情，没想到有时会有小伙伴的些许反感。后来我记起《非暴力沟通》有重点提到反馈的细节：“在给他人反馈时，我们的语气十分重要。一个人在听别人谈自己的感受和需要时，将会留意其中是否暗含着批评或嘲讽。当人们通过我们的语气意识到我们是在体会，不是在下结论，他们就不会产生反感。”

真是前辈实践出来的真理啊，确实有极大的帮助！

我开始心平气和地沟通，我开始多找队员身上值得肯定的地方，甚至每日一会的流程包含大部分的内容都是彼此之间找到闪光点，而且我也开始用文字在群里做一个总结性地、公开性地反馈，让队员实实在在get到自己的进步在哪里，改进之处又在哪里！团队氛围一直很有节奏地进行，给自己也点一个赞！

案例分享：

长沙复盘时间

时间：520

任务：兴盛配送体系

上架单品：3008/362

队长：@曹浪

[强]今日点赞

①昨晚送货十二点多，凌晨1:58睡觉，早上第一个起床6:40，做早餐给小伙伴吃，迎接新的一天。超付出，很有担当

②按照每天七件事程序化执行程度高达85%

③能充分吸收前两天给的建议[强]

[加油]今日改进：

①贺师傅的一车692件，签单时写成了622件（对数字的敏感程度可以更细心）

②每天七件事的第六件事――质/量检查，自己做了，但只完成了一半，没提醒的话，就可能会没完成的结果。

了解并满足客户的需求。信息反馈机制的目的了解并满足客户的需求，发掘各类有利于公司业务管理的可行性改善建议，树立起全员持续以客户需求为导向，打开信息通道满足客户需求的意识，不断的推进企业管理创新，以提高公司系统管理水平，提升市场竞争力。

IT项目管理进行合适有效的团队激励可以参考以下方法：

1、项目管理者通过自身激励来激励他人。

2、明确一个激励的目标。

3、激励分为两个阶段，关键在于找到与团队目标相关的个人目标。作为一个项目经理，你的目标是激励你的手下，只有这样才能实现团队目标。

4、激励机制一旦设立，永不放弃。通过定期的团队会议、明确的沟通、认可和经常性的一对一反馈，源源不断的将你的激励灌输到团队之中。

5、激励需要认可。

6、参与激励。

7、看到自身的进步能够激励人。看到自己向目标奋进的道路上所取得的进步，人们会获得很高的激励——我们都喜欢看看自己做的怎么样——看到自身的进步让我们体验到成功——未来的成功建立在一个成功体验的基础之上。

8、只有人人都有优胜的可能，竞争才能激励员工。竞争频繁应用于激励中，但是只有每一个拥有平等获胜的机会时，才真正起作用。否则，竞争能够激励优秀员工，但同时会降低其他员工的动力。

9、每一个人身上都存在激励的火花。

10、“团队归属”激励。作为团队中的成员之一，肯定会为了一个团队的目标而工作。当然，他们必须已经“向往”那个目标。

以上就是关于破界突围之路：关于IT项目复盘的几点思考(一）全部的内容，包括:破界突围之路：关于IT项目复盘的几点思考(一）、互联网经验——项目管理、反馈机制的重要性等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！