尔东陈的五月工作小结！（下）

基于问题进行持续改进，更容易被接受

最近一个月在辅导新的产研团队，一开始告诉我没有告诉他们正确的方法应该怎么做，而是去观察大家的站会。通过在站会中发现的问题和团队的技术PM讨论，找到更好的解决问题方法。

这种场景下技术PM更愿意采纳你的意见，并且做出尝试，在团队中我看到技术PM第二天就做出了改变，尝试用新的看板工具来开站会，而不是基于excel表格。同时整个团队的过程规范治理也看到了切入口，大家开始意识到规范治理是一个问题，它会影响到我们的站会流程和效率。在这个背景下我们去进行过程改进，推销一些我的方案会更容易引导大家的支持。

快速反馈，解决问题才能带来信任感

接上文，在接触新团队时最重要的一件事时：让团队同学对你产生信任感，这是你的工作能继续开展的基础。回顾这几天我觉得最有用的是快速反馈和解决实际问题。快速反馈体现在别人的诉求，你能及时响应，让对方有安全感和控制感。解决问题体现出你的能力和承诺。

例如我发现团队的看板工具配置有问题，30分钟内就配置了一个新的过滤器给团队开站会。我还遇到了产品对需求与项目的观念关系不清晰的问题，也会主动约他们时间帮他们解决了问题。对一些遗留问题也会持续跟进，及时给出了反馈。这样大家对你的能力和态度有了更多的信任，也愿意更多的跟你说真话，相信你说的话，支持你。

除了快速反馈和解决问题之外，更多的表达感情也能拉近大家的距离，例如对大家参与会议表示感谢，对大家投入的时间和支持表达感谢。

研发效能中的数据分析

我们在做研发效能时，时常要对研发过程数据进行分析，洞察出问题进行持续改进，整个过程中对数据分析的能力是必不可少的，但是数据分析背后有哪些基本能力有哪些基本方法我们是不清晰的。常见的数据分析方法有4种：同比、环比数据分析法；分群、分类数据分析法；漏斗数据分析法。

在研发效能的度量主要帮助我们了解当前的效能表现，发现效能问题进行持续改进。那我们对研发效能的数据分析有两个诉求，第一了解当前的效能表现如何，第二找到具体的效能问题在哪？

了解效能表现有两种对比维度，第一跟自己比、第二跟别人比、涉及到几种分析方法。

第一、环比分析法。我们观察过往一段时间，团队在某些指标上的表现，来判断团队的效能情况，例如说团队的需求吞吐量是不是持续增长？团队在需求上的投入时间是不是增长，在OKR的目标关联度上，是不是持续增长？我们可以通过趋势图看到团队的发展情况，对异常峰值拉取明细数据进一步的分析。

同时还可以与其他人比。例如行业内这一指标的情况怎么样，可以作为参考，再比如整个组织的平均值是如何？都可以作为参考对象。

第二，Top投入分析法。找到 Top 投入的事项进行进一步分析。例如我们资源投入Top10的项目是哪些？这些项目当前的进展情况如何？有没有风险？

以上分析都是在帮助我们了解团队的效能情况如何。但是具体想知道问题在哪里的时候，我们除了看明细数据找异常之外，还应该掌握更多的数据分析方法。

第一、分类分群体数据分析法。例如我们的bug根因分析时可以了解在不同环境上造成的bug占比，还可以分析在不同种类的bug上占比，例如程序bug，数据问题，环境问题，产品PRD问题等等。还可以分析一个需求在不同阶段的停留时长，找到阻塞需求流动的最严重环节。

第二、漏斗分析法。我们在分析需求池积压的情况时可以通过漏斗分析的方式，来进行判断积压情况。例如，开放中的需求到待评审的需求到待排期的需求，到开发中的需求漏斗情况如何？整个漏斗中转换率比较低的那一环节是什么？如何进行有效地优化。

目前所用到的整个研发效能分析方法，更多的体现在趋势同比分析。Top投入分析，分群分类分析。这三种分析方法几乎涵盖了95%以上的效能报告场景。

指标的自信程度决定你的用法

在效能指标体系中是分层的，最底层devops相关的，编译时长、发布时长、发布回滚等指标都是非常准确的。因为他与人的规范行为无关，都是一些必须要经历的卡点系统自动采集的。基于这部分的指标去驱动行为，驱动优化是靠谱的。

但是还有一部分上层的指标类似需求吞吐率，需求前置时长等就非常不可靠。因为他背后依赖整个组织的流程规范和行为约束。这部分指标只能让大家有一个认知的提升，针对于极限情况下可以做一些异常的判断。但是你要用它做精细化的判断，几乎不可能。

软件行业的，管理水平很低

scrum为什么会起作用？是因为it行业管理的成熟度很低，或者说压根没有什么管理的手段。那scrum作为一个管理框架平衡了这一部分的缺失。这也是为什么scrum会受欢迎的原因。但是当一个团队已经有了自己的管理框架，再想引入scrum的时候就会有非常大的阻力。

回顾我在第一个团队的辅导之旅，最初的时候团队是一张白纸，导入任何的管理框架都相对容易。但是在后来团队导入的时候，就遇到了非常多的阻力，体现在TL其实有自己的管理框架。这个时候就是一场变革之旅，更有效的方式应当是从团队内部自己生长出来的敏捷实践，而不是强硬加在团队头上的。

有一个小建议，不要用太多的专有名词，例如scrum、冲刺等，因为这些名词会限定团队，朝着某一个方向去发展，一个好的健康的团队是应该自己生长出来的，自己有各种自己的名词。这样团队的天花板才会更高。