文章内容摘录于《持续交付2.0》书籍,用于学习备忘,如有侵权联系删除。
持续交付2.0,强调“持续探索”和“快速验证”,而探索必然会伴随着失败,失败会令人产生挫败感与不安全感。而学习与成长也通常发生在失败之后。这就要求组织必须建立“安全、互相信任和持续改善”的组织文化。
失败是安全的
一个组织对待“失败”的态度至关重要,无论是实验中的失败,还是组织改进中的失败。我们在持续交付“8”字环的探索环中,识别了很多假设,为这些假设建立了衡量标准,并对验证环的结果进行了度量。这些试验结果不应该直接评判个人,否则会使组织成员在设计方案时倾向于“为了证真而设计”,而非“为了证伪”。这样,我们也很难从这种“持续成功”中学到更多的知识。
对于组织改进也是如此。组织是一个复杂系统,它的改进更为复杂。如果组织成员发现,在组织中“犯错”是一个很糟糕的事情,会受惩罚,那么,为了避免出错受到惩罚,组织成员就会放弃做出有风险的决策。
在一个高度不确定的环境中,没有人能够保证自己的决策不会出错。如果无法让组织成员感到“失败是安全的”,那么组织成员的行为就会倾向于避免犯错就,各扫门前雪,逃避责任,缺少合作。
相互信任
相互信任是高效合作的基础,也是组织凝聚力和成员士气的基础。成员之间的相互信任既包括对彼此个人品质的信任,同时也包含对专业能力的信任。这种信任是恍惚的,赢得他人信任的同事,也要信任他人,认可他们的个人品质与专业素养。
持续学习
我们无法保证每个决策都是正确的。团队应当将每一次反馈作为一次学习的机会,结合从中学习到的新知识,总结成功经验或失败教训。除了通过业务实验产生的业务结果对业务领域进行深入了解和学习,还要保持对做事过程的学习与反思,不断优化工作流程,提升各环节的效率。
对于团队日常工作过程的学习与反思,有两种常见的方式,一是定期回顾,二是事件复盘机制。
1、定期回顾
定期回顾是指每隔一定周期,团队主动安排一次会议,共同讨论过去的这个周期内,团队在写作过程中的优点与不足,并讨论相应的对策,以便在后续的工作中能够保持优点,改进不足,持续取得进步。在敏捷软件开发方法中,有一个非常重要的团队实践,名为“回顾会议”,其作用就在这里。
《项目回顾》一书中指出,在回顾会议开始时,一定要强调回顾宣言,即“无论我们发现了什么问题,我们必须懂得并坚信:每个人根据他当时所知、他所拥有的技能和可得到的资源,在当时限定的环境中,已经尽其最大的努力了”。这就是在强调团队的“安全”与“信任”文化。
另外,还需注意的是,回顾会议结束后,应该有改进措施与计划,并能够跟踪执行的结果。同时,不要制订过多的改进项,以免落入“反复提出,反复执行,没有实际进展”的镜况。
2、复盘机制
复盘机制通常是指针对发生的问题进行分析,其目的是避免相同问题重复出现。首先要针对问题发生的前后进行信息收集与整理,确定问题的严重程度,理解问题发生的过程(对于疑难问题,可能还需要在事故后进行线下模拟测试,甚至线上测试,以复现问题和寻找原因)。然后进行根因分析,最后总结经验,制定改进措施与计划,并能够跟踪执行结果。
对于根本原因分析,需要注意以下几点。
1)、放松心态,开放共享。
2)、分清“因”和“果”。
3)、五问法,鼓励多问“为什么”。
4)、发挥群体智慧。
5)、不要停于表面,而要寻找深层次原因。
6)、对答案进行求证。
值得一提的是,对于每一次复盘,都应该详细记录和总结,作为知识在企业中全员共享。只有这样,才能收益最大化。
在以上两种学习方式中,都应该运用“系统思考”方法。系统思考是从整体上对影响系统行为的各种力量与相互关系进行思考,以培养人们对复杂性、相互依存关系、变化及影响力的理解与决策力。简单来说,就是对事情全面思考,不能仅是就事论事,而是把想要获得的结果、实现该结果的过程、过程优化以及对未来的影响等一系列问题作为一个整体系统进行研究。在传统的思维模式中,人们假设因与果之间是线性作用的,即“因”产生“果”;但在系统思考中,因与果并不是绝对的,因与果之间有可能是环形互动的,即“因”产生“果”,此“果”又成为他“果”之“因”,甚至成为“因”之“因”。