尔东陈的四月工作小结！

“ 四月份工作碎碎念！”

工具箱、指示器、基本管理逻辑

我们经常提到的研发团队的研发效能提升，结合 Scrum、极限编程、看板、度量，他们怎么结合起来呢？

我觉得所有的敏捷实践、敏捷框架都是我们的工具箱，每个工具箱都有适用的边界和上下文，我们在遇到团队组织内部的各种问题时，可以利用这些工具箱帮助我们去解决这些问题。但是科学的管理方法是通过做实验、观察、对比来验证的。所以需要有度量体系帮助我们客观的验证和管理，那效能度量体系就像是我们研发团队的指示器。

有了工具箱和指示器，还会遇到问题是：我们选择什么样依据选择合适的实践？其取决于我们面临工作的特性，我们更多是可预测性的工作，还是不可预测性的知识性工作？它决定了我们应该采取什么样的实践。如果是知识型的工作更应该关注价值，关注人，关注持续改善。如果是流水线的工作，我们更应该关注于计划，强调控制和执行。

建立流程规范的初衷是为了提高效率

一直有个问题困扰我：流程规范和团队的灵活性应该如何平衡，或者类似的问题还有边界清晰好还是模糊好？

如果抛开这个问题去看本质。我们制定流程规范也是为了提高团队的工作效率，如果流程规范反而限制了大家的协作，降低了大家效率的时候，那这个流程规范就应该让步。就像我们一直要求需求的文档，要写到多么细致，但是这个规范反而约束了产品的工作效率，降低了整个团队的产出，那就要思考这个流程规范是否合适。

我们需要更多的是平衡，而不是绝对推翻。例如 PRD 的规范肯定是需要的，但是写到什么程度是需要团队一起讨论的。

管理是将复杂的问题变成简单化

在每个迭代KO的时候，我们需要做的是将需求确定下来，保证大家在开发阶段的稳定性，可以按照我们的计划一步一步去执行，提升整个团队的交付效果，这也体现出了研发团队的延迟决策重要性。

这背后的基本功是作为团队的负责人，我们怎么把复杂的问题简单化、降低不确定性，让团队拿到的是确定性的需求，这个阶段的产品探索设计，是非常重要的工作。

同时大家对敏捷的误解是不做计划要响应变化，这是非常错误的。相反我们要高频的去做计划，延迟决策，保证团队在每个迭代的工作都能聚焦，有明确的计划性，迭代交付过程中燃尽图就是一个很好的监控变化的过程，一个好的团队他的燃尽图应该是非常丝滑的。

了解工具背后的方法论才能更好地帮助团队

企业对数字化研发管理的诉求不是上一套工具就可以，而是真正利用工具解决团队的问题。但是实际工作中，大家对工具的态度是拿来就用，不去思考这些工具背后的方法论是什么，怎么对团队产生更大的价值和意义？这是作为团队的管理者经常会忽略的地方。

真正对工具的使用态度应该是：了解工具背后的方法论，然后基于此深度实践，利用工具背后的方法论帮助团队达成成效。当我们作为PMO/敏捷教练，当你不理解敏捷相关工具背后的东西，那你也很难利用工具帮到团队。

大型研发组织中，一致性是必经之路

我们在组织中遇到一个典型的问题是：在各个技术栈、各个平台选择了太多的时间。例如大前端来说，我们用到了太多的工具库，第三方的包，导致我们整个管理过程非常混乱。所以我们对这一部分需要进行治理，方式就是保持一致性，整个组织使用的技术栈、对应的类库都趋同，这样的话能够有效的维护，同时降低每个人上手的难度。

数字化研发管理一直被忽略

过往几年随着互联网的蓬勃发展，我们的业务基本都实现了数字化，从生产制造、销售交易都能看到数字的影子。可是我们研发过程管理依旧处于非常原始的阶段，依赖人的主观判断来解决，流量见顶的时代，我们更多要修炼组织的内功，这个时候研发管理的数字化是绕不开的话题，这也是为什么研发效能度量一直火热的原因之一。

什么情况下需要试点？

试点本身也是一种实验的思维，当你对想做的事情拿不准的时候，就需要通过试点来收集结论。例如最近在做的一个效能项目，我们对用户的接受度不太有把握，所以决定通过灰测来进行验证。本质上灰度测试也是一种试点的行为。

另外之前在火种计划（内部兼职scrum master的机制）这个项目上，原本我们想通过试点来验证大范围培养技术PM是否可行？可是最终多次评审后决策这就是对的事情，领导坚持一次性全部推广。我们最终也发现一次性推广并没有太大的问题，反而让组织更快认可兼职 scrum master的机制。

综上所述，试点是一种实验思维，但同时它也意味着滞后性。对于组织想要强有力的变革，且认准了方向的时候，直接全员推广也是可以的。

产品经理的数据分析能力必不可少

在最近项目中我作为产品负责人，从最初的产品探索、立项、规划到后期的灰测数据分析，汇报都是我独立负责，也发现了自己对数据分析其实不太敏感，而且整体的调研、分析、汇报也不是特别熟练。但是作为一个项目的owner，这些能力都是必须具备的。所以在今年的学习计划中，会刻意锻炼自己数据分析、呈现、汇报的能力。