01 什么是闭环思维？
“闭环思维” 源于质量管理专家 休哈特 & 戴明 联合提出的 “PDCA 循环”：Plan（计划）→Do（执行）→Check（检查）→Act（处理），一个循环完结解决一些问题，未解决的问题进入下一个 PDCA 循环，直到需求完结。
职场上的闭环，决定了一个人是否靠谱。具象到工作中，对于一个需求的提出，也要建立闭环思维 ，“凡事有交代，件件有着落，事事有回音”。
你的工作中，是否经常遇到这样的情形：
A：开单不规范（不附需求文档，未记录信息变更……），来自 QA 的灵魂拷问 “这我要怎么验收？”
B：任务上下游衔接混乱（守住自己的一亩三分地，他人与我何相干），来自 PM 的灵魂拷问 “你们上下游为什么不自行沟通一下？”
C：虎头蛇尾不验证（这片天下还等着我架构呢，我做我的设计，你做你的实现），来自执行的灵魂拷问 “这实现的是你要的吗？”
这些情形的核心原因是什么？没有责任心？没有团队协助意识？—— 都是，总结成一点，就是没有闭环意识，此人不靠谱。
所谓闭环，即 做事有始有终，需求从启动到结束有完整的反馈回路，持续验证并有效迭代。
我们每个人都处于一个复杂的协同网络中，从网络中接到一个任务，处理完成后反馈到网络中，并提交给下个节点。你负责制作的功能，是一个协同网络；你所在的项目，是一个协同网络；你所在的公司，更是一个协同网络。
每个人在网络中的所作所为都决定了此网络的健康和稳定，而形成需求闭环则是核心保障。
02 没有闭环，带来哪些负面影响
来看几个工作中的案例，你的团队中是否有类似的情景？
【案例 1】
策划小 A 被上级指派了一项 重要需求，需要在测试完成后在最近一次周版本更新时 尽快进行正式外放。
策划小 A 开始着手处理这个需求，写完方案后，开出了需求单指派给程序。
时间过去了 3 天——
上级询问策划小 A 需求进展，小 A 赶忙询问程序，程序回复：身上还有别的需求，这个还没空做。
小 A 崩溃哭泣：单子都开给你了，为什么不做？
小 A 是否有做错什么？
——小 A 开完单子后，若主动告知程序这个需求优先级高，需要在哪个时间点前交付，也许就不会浪费三天宝贵的开发时间。程序若制作前，明确手中所有任务的优先级排序及各自 deadline，也就能更好做出排期抉择。
——开完需求单，只是需求闭环的开始。需求沟通、制作、验收、跟进测试、外放、接收反馈、优化修改直至线上稳定，才是一个需求的闭环。而作为需求发起方，需要对全流程负责。
【案例 2】
程序小 A 发现 线上运营产品的某模块 B 性能不佳，排查下来评估需代码重构，吭哧吭哧码完代码，通过自测，default 提交，截图通知了一次 QA，在大版本更新时，进了外放版本。
观察线上反馈后，性能确实有提升。正当一切看起来 “很完美” 时，暴露出另一交叉模块 C 出 bug，经复查是模块 B 的代码改动牵连到模块 C，且此两模块分别由不同 QA 负责测试，模块 C 的 QA 并没收到任何测试通知，且无单子记录，导致测试未到位。
那，自主任务的迭代应该怎么进行呢？
——程序小 A，发现问题，先开单（plan 环节），再拉多人讨论组 通知模块 B 的负责策划 + 负责 QA（do 环节），检查模块 B 的关联系统列表，加入关联 QA 进行评审测试（check 环节）。
——提交 refs 到单子，经过代码 review + 相关 QA 的复查及回归测试，确保不影响原始系统需求（或者，若略微改需求能更好地保障性能时，可让负责策划做抉择）（act 环节）。
03 什么是需求闭环？
需求闭环思维的核心在于真正做到把事做完整，从接收需求开始到验证需求效果结束，要形成闭环：明确需求→制定计划→敲定方案→执行检查→交付成果→反馈回顾。
网上有段风靡一时的文章《主管欣赏的人》：介绍了主管让 A 和 B 去做同一件事，两者不同的执行方式。
公司欲 采购大杂蟹作为中秋礼回馈客户，分别简单交代 A 和 B：“你去南门市场看看，有没卖大闸蟹？”
A：虽有疑惑为啥要去，但主管让干啥就干啥。跑了一趟市场，回复主管 “南门市场有大闸蟹”。主管又问 “大闸蟹怎么卖，论斤 or 论只？”，A 又跑一趟……
B：接需求前先明确目的，询问 “大闸蟹有什么用途”。跑一趟市场后，拿着 2 个大闸蟹样本，回复主管 “南门有 2 家大闸蟹，分别的购买方式和平均重量是什么，若要送人建议选哪家，若要自食建议选哪家”
这就是面对需求时，开环思维和闭环思维的差异：
A 没有思考需求的目的，一个口令一个动作，来来回回多次才能把一件事情做好。
而 B 应用全局闭环思维，明确目的，收集完整的情报，甚至提出建议与分析，协助作为上级判断的参考。一次性地做对做好，需要的是分析事件执行需要的完整回路，“把事做完整”。
再比如，项目里程碑接近尾声，开展回顾会，据不完全统计，80% 的人会提出抱怨和不足，30% 的人会给出优化建议，而只有 10% 的人会去推进问题改进措施的实际落地。
评头论足总是容易的，而真正带着全局闭环思维，分析不足→制定计划→执行并监控→复盘效果及未来措施，全情地投入全流程，积极主动地推进下一环节，才是靠谱与否的分水岭。
单人参与的需求，只要对自己全负责，总是容易达成闭环的，那对于多方参与的事件呢？
在游戏开发中，小到一个需求、大到一个产品，都需要各职能的的相互协作，比如需求从构思到面向玩家，经历了策划出方案→程序实现功能→美术提供素材→策划验证功能与效果→QA 全面测试→收集反馈→小范围验证→决策并迭代。
只有每个人先达成各自环节的任务闭环，串联上下游并保障信息流转通畅，形成整个大需求的闭环，才能顺利推进以达成项目目标。
概言之，一个人是否靠谱，在于他能够提供对方需要的确定性，衔接好上下游，把他参与的环节做到闭环收敛。 具象地说，你会很放心的把事情交给他，因为你知道他一定能负责到底，即便目标没达成也会及时提供反馈及应对措施，真正做到事事有回音。
04 构建你的闭环思维
实践闭环需要有意识地培养自己的闭环思维：闭环思维 = 保持责任心 + 团队协作能力 + 换位思考意识 + 事情做到位
需求闭环思维的三重境界：
1、明确需求目的，制定计划，遵照排期执行，持续跟踪并汇报进展，监控主要指标，分析输出结果。
2、提前识别风险，清晰有效地汇报问题，提供有效的解决建议，做出三思后的行动决策，并继续落实 PDCA 循环，直至需求完整解决。
3、复盘，形成组织过程资产。
把事做完整，不仅是事情执行完整，而是真正的交付、跟进反馈、回顾完整。那如何能够做到呢？我认为要修炼以下 4 个能力：
【承担责任】 敢于并愿意承担责任，责任心帮助你把分内的工作做好，从而形成个人任务闭环。
——“这个我的”，“这个我来处理吧”，“这个我的错，下回一定注意”
——这些回答是责任心的表现，比起甩锅掩盖错误让人觉得靠谱得多。
【团队协作】 在不同的工作岗位上各尽所能，与其他成员协调合作，从而使得一个需求的完成形成闭环。
——策划对全流程负责，美术按需求规范设计，程序按需求开发并自测，测试反馈 BUG。
——各个职能互相协作，才能够完成一个需求交付的闭环。
【换位思考】 保持信息透明，主动沟通、信息同步将闭环过程变得更为润滑
——做事前多思考：我的下游环节 / 我的用户 / 我的领导需要什么信息？我的任务对后续环节 / 整体任务会有什么影响？
——信息透明：“我大概今天下午 3 点能把图切好，到时候辛苦开发大哥处理了”，“我正在处理这个问题了，把原来使用的 xx 结构换成了 xx 结构，等下 QA 就可以测了”。
——变更同步：“不好意思，上次你跟我说的那个任务，因为 xx 原因，今天没能完成，预计明天可以搞完”，“跟开发沟通之后，功能的这里做了一些变动，我等下更新文档传到单子里，辛苦 QA 更新下用例”。
——换位思考，提供信息，让上下游信息流动更为畅通，减少不必要的工作等待和重复沟通，让各职能之间对任务产生明确的预期，进而产生信任。
【事情做到位】 全方位执行需求的完整流程，建立 PDCA 循环，达成闭环收敛。
——通知你的上下游：“这个功能我根据需求 checklist 自测提交了，还缺美术效果在等资源到位，策划大哥可以先验收整体功能是否达标，等资源到位后我再加上表现项”，“功能已满足策划案了，辛苦 QA 大哥多测测边界情况”。
——同步需求的反馈：“这项需求上线后的运营效果是 xx，玩家提了反馈 xx，经评估后这几项需要完善，接下来我们开个三方会议评估一下优化的需求方案”
——做好回顾总结，复盘该项需求的优劣处，为以后同类型需求提供参考。
总结
建立闭环思维，持续地为你所在的协同网络提供别人可预期的确定性，愿你我都能成为别人眼中靠谱的人。
若有收获，就点个赞吧
0 人点赞
