|
这就是闭环思维的重要性，它强调的是一种即时反馈闭环，如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的时间内给出明确的反馈。 例如：在跨部门的沟通会议中，虽然各方达成了一致，会议发起者已经将最终的记录周知大家。但是，到这一步其实并没有完成真正的闭环，在落地执行过程中很可能还存在一些潜在的问题。 例如：会议纪要是否经各方仔细核对并确认过？会议中明确的To Do进展是什么？完成结果有没有Check的机制？ 如果这些没有做到的话，就会陷入“沟通-发现问题-再沟通-再发现问题”的恶性循环中。 真正的闭环，要求我们对工作中的事情都能够养成良好的思维习惯，沟通要有结论，通知要有反馈，To Do要有验收。 “闭环思维”还要求能够定期主动进行阶段性的反馈。刚参加工作时，我接了一个工期为两个月的项目。整个项目需要独自完成，自己每天按照计划，有条不紊地进行开发。大概过了两周之后，Leader询问项目进度，虽然我已经跟他说没问题。然而，Leader告诉我，因为我每天对着电脑也不说话，让他心里很没底。 这时，我才意识到一个很重要的问题，我跟Leader之间存在信息不对称。从那以后，我就时不时得跟他汇报一下进度，哪怕就只有简短的一句话，也可以明显感觉，他对我的信心增加了很多。特别是我做Leader之后，对这种闭环反馈的理解，就更加深刻了。从Leader的角度看，其实只是想知道项目是否在正常推进，是否遇到问题需要他协助解决。 原则五：保持敬畏“君子之心，常怀敬畏”，保持敬畏之心能够让我们少犯错误。在工作中存在各种各样的规范，例如代码规范、设计规范、上线规范等等。我们必须明白，这些规范的制定一定是基于某些客观原因的，它们都是历史上无数Case积累而来的经验。团队里的每一个成员都应该学习并严格遵守，这一点对于新人尤其重要。 当我们进入到一个新的团队，请先暂时忘掉之前的习惯，要尽快学习团队既有的规范，并且让自己与团队保持一致。以编码风格为例，很多同学往往习惯于自己之前的代码写作风格，在做新公司第一个项目时，也按照自己的习惯进行变量、包的命名等等。结果在代码Review过程中，被提了很多修改意见，不得不返工重写，得不偿失。 如果能够保持敬畏之心，提前了解编码规范，这种问题完全可以避免。 类似的问题，还包括对上线流程的不了解，对回滚操作不熟悉，对SRE线上变更过程不了解等等。除了这些显而易见的规范，还有一些约定俗成的规则。个人建议是：如果有事情拿不准，不妨多问问其他同事，不要凭自己的感觉做事情。 保持敬畏之心并不意味着要“因循守旧”。在我们充分了解这些规范和约定之后，如果觉得存在不妥之处，可以跟全组同学讨论，是否采纳新的建议，然后及时去更新迭代。其实，让规范与约定与时俱进，也是另一种形式的敬畏。 原则六：事不过二“事不过二”，是我们团队一贯坚持的原则，它可以解读为两层含义。 一层含义是“所有的评审与问题讨论，不要超过两次”。之所以有这样的要求，是因为我们发现，很多RD都把时间花费在一些无休止的评审与问题讨论中，真正投入到实际开发中的时间反而很少。在实际工作场景中，我们经常会遇到一些不是很成熟的需求评审。这些需求文档，要么是背景与目标含糊不清，要么是产品方案描述不够细化，或者存在歧义。RD与PM被迫反复进行讨论，我曾经遇到过一个需求评审，进行了三次还被打回。 同样的问题，在设计评审中也屡见不鲜。方案固然需要经过反复的讨论，但是如果迟迟不能达成一致，就会耗费很多RD与PM的宝贵时间，这就与提升研发效率的理念背道而驰，因此我们团队规定：所有的评审最多两次。 通过这种方式，倒逼利益相关方尽可能地做好需求与方案设计。评审会议组织前，尝试与所有相关人员达成一致，询问对方的意见，并进行有针对性的讨论，这样能够大大提升评审会议的效率和质量。如果在第一次评审中不通过，那么就只有一次机会进行复审。一旦两次不通过，就需要进行Casestudy。 （责任编辑：晨鸿） |
