团队项目完成后进行复盘总结，需要注意哪些问题？ - 知乎有问题，上知乎。知乎作为中文互联网最大的知识分享平台，以「知识连接一切」为愿景，致力于构建一个人人都可以便捷接入的知识分享网络，让人们便捷地与世界分享知识、经验和见解，发现更大的世界。183被浏览<strong class="NumberBoard-itemValue" title="1分享邀请回答该回答已被折叠 2添加评论分享收藏感谢收起问题复盘的必要性
问题复盘的必要性：
在集成测试中， 必然会发现一些问题，这个时候就需要重试，然后复盘，找到问题所在；
这个过程需要从头（最上游）开始，一点点排查；不能急躁；问题总是能定位到的（一点点排除）;
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！案例| 复盘的“六个问题”：联想是这样做复盘的
我的图书馆
案例| 复盘的“六个问题”：联想是这样做复盘的
前言 复盘”是联想通过企业实践总结出来的重要方法论之一，指做过的事情，再从头过一遍。目的是不断检验和校正目标，不断分析过程中的得失，便于改进，不断深化认识和总结规律，对于联想的发展和组织智慧的积累，“复盘”起到了非常重要的作用。
Q1如何用一句话描述复盘是什么？
答案：“做过的事情，再从头过一遍。”
其中包含两个要点：
第一，大多数人都更关注未来，容易“喜新厌旧”，而“联想式”复盘指的是，对我们经历过的事情不要轻易放过，需要认真审视，仔细琢磨，从经历中学**，从而得到经验和教训。考虑到人喜新厌旧的特质，复盘并不是一件自然而然的工作，而是需要管理者和倡导者付出更多的精力，推动团队和组织一同来完成。
第二，人们在做事时有时不容易想清楚目的，或在过程中忘记最终目的，也容易混淆目的与目标。我们所说的“从头”指的是“从目的”开始复盘。所谓目的就是想要解决什么根本问题,目的往往决定了后续目标该怎么定，乃至实现目标的策略是怎么样的。这并不是一件容易的事情，因此，联想控股董事长柳传志常在内部说：“要把嘴皮子磨热，想清楚你的目的。”
Q2复盘的本质是什么？
答案：复盘的本质是“解决问题”。
“联想式”复盘就是要考查“当初是怎么定目标的”和“现在做成的结果”之间的差异，然后根据差异分析原因，寻找解决方案，并开展后续的行动。
目标和现状之间的差异就是大家通常所说的“问题”。因此，复盘就是通过回顾实际经历发现问题、分析问题并解决问题，从而不断吸取经验教训，将经历转化为经验，推动组织和个人的成长。
Q3在复盘的过程中，如何定义问题？
答案：在复盘第二步“评估结果”中，设定好“实事求是”的复盘氛围，比较结果与目标的差距之处，找出成功之处（正向偏差）和可提升之处（负向偏差），这其实就是在“定义问题”，以便进入复盘的第三步骤——“分析原因”。
“联想式”复盘定义问题时，需要干净、清晰地将“目标”和“结果”之间的差异描述出来，这里不包含出现问题的原因以及解决方案，更不应是指责、抱怨和撇清责任等。
定义问题示例：
目标：原定于12月20日前，去3次目标企业，与该企业7名高管一一面谈。
现状：截至12月20日，只去2次目标企业，只与7名高管中的4人面谈了，未达到预定目标。
定义问题：在规定时间内，计划去目标企业3次，结果去2次，数量差1次；计划与7名高管一一面谈，结果面谈4人，有3名高管没有面谈。
Q4“联想式“复盘倡导什么？
答案：“成功时，主要看客观原因；失败时，主要看主观原因。”
一般人在分析成功失败原因时，往往是“成功时看主观，失败时看客观”，而“联想式”复盘正好相反。这要求我们分析成功因素时，多列举客观因素，精选自身真正的优势。分析失败原因时，多从自身深挖原因，狠挑不足以补足短板。
其实，一味抱怨客观环境的变化导致失败是没有意义的，故要多改变自己的行为**惯等，只有跳出自己的舒适区，才能获得更多成长。“联想式复盘”强调的是养成随时反思的**惯，首先要改变自己，“一条是一条”地复盘到根上，只有大家都从改变自己开始，组织才能不断成长壮大。
Q5联想式复盘的特色体现在哪个步骤？
答案：第一步“回顾目标”，集中体现联想的方法论——目的性极强。
复盘由两部分构成：复盘的硬逻辑即“复盘四步法”：回顾目标-评估结果-分析原因-总结经验；复盘的软文化即“复盘的五个态度”：开放心态、坦诚表达、实事求是、反思自我、集思广益。
”联想式”复盘的特色主要体现在第一步的“回顾目标”中，应该至少包含三部分内容，即目标是什么（What）、目的是什么（Why）和实现的策略／路线是什么（How），其中最最重要的是要想清楚目的所在。
Q6在实际运用时，何时复盘最佳？
①小事及时复盘：行动结束后及时复盘，制定改进方案并落实；
②大事阶段性复盘：大的项目在执行中，要进行阶段性复盘，对目标或策略及时调整；
③项目结束后全面复盘：大的项目或战略结束后，要进行总复盘，全面总结经验教训和规律。
而且，企业**以身作则：带头做复盘，给下级示范；中层管理者身体力行：掌握工具和方法，带领团队实践并运用；普通员工主动运用学**方法和工具，在实践中应用并养成**惯。
最后，小编再啰嗦一下：“联想式”复盘的关键到底是什么？柳传志说：“复盘首先就是要敢于否定自己，人们在复盘的时候往往不自觉地谈客观条件和环境，这样不行，要从根上分析清楚，从自身出发，把根本原因找到。而且，复盘要反复地做，打一仗进一步，慢慢就会找到规律。”
小贴士：联想式复盘
来源：联想控股微空间
喜欢该文的人也喜欢为者常成，行者常至，常为而不置，常行而不休，思者无域，行者无疆
线上问题管理----记录、复盘、追责
作者：cryanimal
微信：lazytest导语
线上问题的管理，不管对于开发还是测试来说，都是极为重要的一环。把好线上问题复盘和分享这道关，有助于产品质量的稳步提升。管理目的回顾复盘线上问题发生的背景、原因、解决过程、影响范围，及其避免办法。对线上问题在一定范围内进行分享，警醒当事人，提醒身边人，避免类似问题继续发生。使用线上问题，对线上质量进行后验，作为评价员工的后验指标之一。名词解释线上问题 线上，以及在上线过程中，发生的故障、缺陷等漏提RD（开发）原因，导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的 如：未告知QA，私自修改上线的、人为原因merge掉代码的，等等。 以下情况不属于漏提：上线过程中发现并解决的；RD或QA发现的线上问题，未造成影响的；多方达成一致，在线上环境进行测试的；产品设计上的隐秘缺陷；未对线上造成任何影响的；1.0项目，对线上有轻微影响的；其他战略层面达成一致，因为效率牺牲质量的；漏测 QA原因，导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的 以下情况不属于漏测：上线过程中发现并解决的；QA发现的线上问题，未造成影响的；多方达成一致，在线上环境进行测试的；产品设计上的隐秘缺陷；测试环境无法具备验证条件，且不能在线上进行验证的；测试过程中发现，成本极高的；未对线上造成任何影响的；1.0项目，对线上有轻微影响的；其他战略层面达成一致，因为效率牺牲质量的；考核原则凡是原则上不属于漏提、漏测的线上问题，未在wiki上记录分享的，算做漏提、漏测，纳入KPI考核；凡被定义为漏提、漏测，纳入绩效考核 。一次上线，回滚三次（含）以上的，纳入绩效考核。如果是已有人分享过的线上问题，再犯的，计入漏提或漏测。记录模板【问题背景】 此处描述问题，以及问题产生背景。【问题发现】 此处描述问题的发现过程，建议带上时间。【影响范围】
此处描述问题的影响范围，包括具体的数据。【解决过程】此处描述问题的解决过程， 建议带上时间和解决时长。 示例：
21:22 研发同事通过告警短信发现异常：content_service no provider。
21:40 通过JSF监控平台得知本有8台机器的服务，只剩一台可用。
解决时长：4小时。【原因分析】
此处描述问题的原因分析【避免办法】此处描述问题的避免办法，从研发过程、测试机制等角度思考。记录示例 缓存过期时间设置错误【问题背景】双十二小金库现金红包支付成功后返活动【问题描述】由于目前小金库现金红包有个硬性规则是月限制30元，每个用户每个月只能获取30元的现金红包，而用户得到的红包总金额记录在缓存r2m中，时间本应该是2个月，但程序里误写了成了60小时，代码截图如下：该金额上限缓存过期时间本应该设置为60天，但是代码中该缓存的有效期只设置了60个小时用户在得奖60小时后，缓存失效，用户又获得获奖资格出现一种情况：用户后返小金库现金红包（例如30元）后，缓存60小时后失效，用户再进行退单，其缓存被设置为-30元，此时用户做多可以后返60元的小金库现金红包【问题发现】上线后在线上环境发现统计时发现有一个Jdpin用户先后两次得到了40多元的红包，立刻通过排查，发现用户第二次领时缓存里记录的总金额为空，怀疑是缓存过期，一看代码过期时间果然设置成了60小时【影响范围】由于60个小时还是能拦住别有用心的刷奖用户，当时应该就只有少量正常用户拿到了超过30元的现金红包，当晚赶紧上线修复此问题并清洗线上缓存，截止当前时间，超发红包金额统计为40365.49元，异常用户个数为4679个，期间若用户退款，数量还会减少。且日会上线洗数任务，回收多发的红包，客服同时同步到用户知悉。回收后不存在资损，但消耗研发资源较多【解决过程】1.于14号发现问题当时立刻修复缓存过期BUG并上线，缓存过期时间修改为：60*60*24*30*22.14号晚间上线洗数任务，清洗线上缓存。3.16号上线回收超发红包任务，回收超发的红包。【原因分析】1.当时自己想的方案是很明确的知道缓存过期时间为2个月，还给其它开发同事说过此方案，但是粗心少写了个24,导致此问题。2.review代码未检查出该问题（时间仓促也许是导致该问题的原因之一）3.测试为功能测试，无法发现此问题【避免办法】1.以后缓存这块过期时间和缓存构成要非常仔细，做好wiki维护，每加一个缓存就在wiki上补充，并做好过期时间等缓存详细信息的填写，很有可能在写wiki的时候就发现问题。2.以后开发提测和测试都注意提一下缓存过期时间，并说明重要程度XXX否，后续请增加测试机制 是，轻微，经回收补救后，不存在资损
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！提升运维稳定性的利器：故障复盘
我的图书馆
提升运维稳定性的利器：故障复盘
为什么要进行故障复盘
&稳定性是运维工作的基石。故障，也就是稳定性问题是悬在各位运维从业者头上的一把达摩利斯克之剑。稳定性一旦出现问题，运维的其它工作基本也就算前功尽弃了。那么如何提升稳定性是所有运维从业者都绕不开的话题。那么出现了稳定性问题怎么办？，没关系，请老中医坐诊，药到病除。「望闻问切」后，开出了一味药方，药方很简单，但是一剂猛药，按时按量服用，但可药到病除。药方上书只有两字：「复盘」。这剂药该怎么用呢？先别急，做为一个坐台多年 的老中医，先从为什么开这剂方子说起。什么是故障复盘
&先来介绍一下这个方子，即什么是复盘？复盘源于围棋术语。复盘也称「复局」，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。回到「故障复盘」本身也是一致，就是对故障发生及处理过程重新「过」一遍。对这个过程的进行和思考进行回顾，反思和探究，实现稳定性及能力的提升。怎么进行故障复盘
&为什么开出的是「复盘」这剂方子？大致来讲，这剂方子可以有以下疗效：避免出现同样或同类的故障。让出现过的故障处于「可控」又或「收敛」的状态；从出现的故障中可以提炼、固化一些流程，提升效率的同时，同样或同类也可以避免出现同样的故障；从「蒙着打」变成「瞄着打」，让我们所有的动作更有目的性，清楚自己的目的是什么。看清故障背后的问题，找出故障背后真正的原因。发现解决问题的新思路或者新方法；更加客观的认清业务当前稳定性的现状，以便寻求最佳的解决办法。「复盘」这剂药要该怎么服用呢？这剂药服用方法很简单，药品的使用说明上都有写，其实也就四个字母：RASA。我们再翻看药盒的背面，上面写着有这剂药的禁忌：该药品需要在病状发作时2日内复用，如不及服用，可出现药力减弱甚至出现负作用；该药品处方药。不可单独1人服用。需要在专业医生的指导下使用；请严格按照「RASA法」吞服。如使用此药品单个疗程不见效果，请在专业医生指导下反复使用；那么什么是「RASA」呢？简单点说服用「复盘」这剂药的整个过程。即Review(回顾),Analyze（分析），Summary(总结)，Action(行动) & &。来来来，我们来逐一来讲解一下这四步要该怎么走。
& &Step 1:Review即回顾故障发生的整个过程。这一步是最简单，但同时也是最重要的。这一步只需要完整的记录下故障的发生、发现、原因定位、决策、处理、预案执行、回滚、故障解决等的关键人与关键时间点。这一点记录一定要尽可能的准确，这一步会直接关系到本次复盘的效果。为了保证信息尽可能的客观、准确，所以需要按照这剂药的禁忌上所写：故障发生并解决后尽快着手开始复盘，以避免因时间较长出现的偏差。按老军医的建议，最好是在故障出现后两日内完成；同样为了避免出现信息偏差，建议参与故障处理的相关人员、角色共同参与复盘；
& &Step 2:Analyze即分析故障的根本原因及故障处理过程中可以优化点。这一步需要本着抽丝剥茧、根因分析（RootCause）原则来进行开展。这个过程大概可以分成－ & &故障的原因是什么？－ & &再往下想一层，这个故障发生是因为其它原因导致的吗？－ & &再往下想一层，这是故障发生的根本原因吗？如果不是，请继续往下想一层－ & &其次我们还需要分析在处理故障过程中是否有需要优化的点。比如处理时间是否可以缩短？如何缩短？&& &Step 3:Summary即总结本次故障及处理故障的过程。简单点说就是，故障进行定性、故障定责及总结本次故障带来的经验教训。为什么要对故障进行定性？简单点说有以下几个方面：A. & &通过故障定性，评估对业务带来的影响、损失及范围；B. & &通过故障定性，我们可以更加有序、科学的投入不同程度的资源来解决不同级别的问题；C. & &跳出本次故障本身，更抽象性的看待同级别、不同级别故障的共性或差异，以期更加系统化的解决有普实性的共性问题；故障定责这个就比较清晰了。即谁或哪个团队对本次故障负主要责任及次要责任。做到边界清晰、权责对等；由本次故障带来了哪些经验教训。包括得失的体会，以及是否有规律性的东西值得思考。除了上述之外，在总结这一步，还需要完善以下信息：A. & &故障的故障发生到最终解决的时长；B. & &监控是否发现？C. & &是否业务可用性是否受到影响
& &Step 4:Action即对上面的分析、总结确定进行后续相关的改进、优化的落地措施。所以制定的动作及措施都需要符合SMART原则，即：Specific：即改进项。我们需要改进、优化的单项、指标是什么？Measurable：即验收标准。指定改验收标准是什么？Attainable：即改进项是否可以达到。避免出现一些假大空、无法落地的改进；Relevant：即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改进；Time-bound：即预期解决时间。这个时间建议最长不要超过三个月，避免改进流于形式；除了SMART之外，还需要用5W1H原则进行补充：明确相关改进项的负责人。负责人可以有多个，但主要负责人有且只能有一个。即这个人需要对这个改进项的落地全权负责。当然，这个负责人的指定也需要在权责对等的基础之上。后续改进项的状态如何？是在准备？进行中？还是完成？同时，在所有的改进项未关闭前，需要周期性的对后续改进进行跟进、确认。最终改进的结果与验收标准的贴合度，是评价复盘效果最好指标。实战
&某业务在业务高峰期出现异常，导致业务关键指标下跌超过30%。从表面上来看是业务在高峰期触发了程序的BUG导致，修正掉这个BUG即可解决问题。但我们通过复盘发现了该业务基础技术结构耦合过重导致业务自愈能力弱、部分应急响应机制流程缺失、多个业务关键节点存在单点或弱备份等多种较为严重的问题。后续我们通过多次针对此故障的复盘，并持续更有针对性的进行改进。使得同类型故障从原来的发生到恢复需要15~30分钟提升到目前的1~3分钟内由程序自愈解决。总结
&我们通过使用故障复盘这把利器，更加系统化的解决业务问题的同时，也提升了整个团队的战争力。当然，故障复盘这剂药虽说是剂猛药，但还是需要坚持服用才能看到明显效果的。作者介绍胡杨，目前就职于阿里巴巴移动事业群网络运维部。高级运维专家。多年工作于大型互联网领域，擅长容灾体系设计、自动化、性能优化、troubleshoot等方面。
喜欢该文的人也喜欢