闭环思维
“闭环思维” 源于质量管理专家 休哈特&戴明 联合提出的“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,经评估后这几项需要完善,接下来我们开个三方会议评估一下优化的需求方案”
——做好回顾总结,复盘该项需求的优劣处,为以后同类型需求提供参考。
总结
建立闭环思维,持续地为你所在的协同网络提供别人可预期的确定性,愿你我都能成为别人眼中靠谱的人。作者介绍:
网易雷火项目经理。手游+端游产品PM,负责研发与运营的项目管理工作