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

引导回顾会在线沙龙的复盘

5月份交付了一场线上的回顾会沙龙。本来计划是90分钟，结果花了150分钟，超时60分钟。超时是活动中最大的问题，目前我对时间的控制度还不够。主要体现在大组发言的环节，大家的时间没有办法有效的控制，原本觉得每小组两分钟就可以汇报结束，但实际上可能都在五分钟左右的时间。难怪其他老师老师们的工作坊都是两个半小时起步的。

回到大组的汇报环节，如果想比较深入的讨论和澄清，每个小组两分钟完全是不够的，而且这也是引导中非常有意义的一部分，促进所有人的相互理解。总结下来并不是引导上时间控制的问题，而是对整个在线工作坊时间规划的问题。如果下一次还是在新工作坊时间，保证在两个小时以上更靠谱。

对的事情排除万难也要去做，给自己一些压力。

接上文，5月收到了回顾会的分享的邀约，最初听到这件事情本能的想拒绝，因为感觉准备时间不够，但是另一个声音告诉我：这对你而言是学习和成长有帮助。而且我今年也希望在引导上有更多的精进，这是一个特别好的机会，所以最终答应了下来。

线上的回顾会已经结束了，效果还不错。我也学到了很多的东西，所以我觉得这是一个正确的决定，也更加坚定了：对的事情，一定要给自己一些压力，去尝试去挑战自己。

不同视角下的研发效能到底是什么？

站在财务的视角来说，我的研发成本是不是可控，这对于他而言就是效能。站在人力资源的视角下，大家做的事情是不是变多了？这也是效能。站在业务部门的视角下，需求是不是能快速上线？每个迭代做的事情能不能更多，这也是效能。站在技术的视角下，整个研发过程的卡点是不是解决了，这也是效能。

不同人对效能的理解不一样，背后要做的事情也不太一样。一般来说研发效能分为三个方向，分别是人员能力的提升、交付流程协作效率的提升、以及研发过程的卡点治理（devops）。

实际上我们做一些研发效能实践，不同的事情也对应到了不同层面上的效能。

在提高需求的前置时间响应效率上，我们针对不同的业务属性设置了不同发布窗口，从面向C端的两周一个版本演化成一个迭代多个版本，面向B端的随时发布，这是为了提高需求的响应效率。

从技术的视角来说，我们去重构代码，引入统一的包、代码规范，让我们做同一件事情能有更低的成本，这是可以提高吞吐量的部分。同时面向中台的团队，构建行业解决方案，降低接入成本，这也是提高前置时间、吞吐量的实践。

从组织的流程规范上来说，如何进行过程管理，提高团队协作效率，这也是提高需求前置时间、响应效率的部分。最后从人员的能力上来说，我们建立人员的培养体系，搭建技术分享平台，这也是提高效能的部分，这里提高的是人员的能力和知识。

在引导中，不完全一致的观点，不要强行分类。

在头脑风暴的过程中对观点进行有效的整合是必须的，因为我们要去重整合。但是很容易陷入一个陷阱，就是对观点进行过度抽象。例如人的配合度问题和人的积极性问题，很容易被抽象为人的问题。但是这对于问题的解决是不利的。因为不同的问题，会带来不同的解决方案。

所以在引导中进行分类汇总时不完全一致的两个观点就保留着，当成两个观点来考虑。

团队效能的治理 VS 团队DOD

在敏捷的语境下，我们经常谈论的是dod，dod保证了团队的工作质量。我们需要不断地去演进自己的dod以提高团队的工作质量和效率。最近互联网比较流行的研发效能，其实和dod有异曲同工之妙。研发效能会度量团队的一些过程，指标和结果指标。例如开发过程的一次冒烟通过率按时提测率等等。如果我们把他当做团队的dod就会很容易理解研发效能推进的逻辑。

当我们对工序有更高质量的要求时，我们就需要不断的检视和调整来提升团队的工作质量。那这一部分工作就类似于团队的效能治理。

在产品侧建立自己的影响力

最近在辅导团队遇到一个难题，如何有效辅导产品负责人？过往我在辅导团队时我往往会从交付着手，随着辅导的深入，一般都会遇到产品管理的问题：

- 如何让产品的规划更清晰

- 如何让产品定期反馈项目及业务价值

- 如何建立自己在产品侧的影响力推动他们做出改变

我想可以从具体的事情出发，在这个过程中和产品pair工作，帮助他们找到更好的工作方法。如何有效辅导产品负责人这可能是绕不开的话题，尤其是不同的职能部门背景下如何有效的辅导产品经理。

项目周会需要开吗？

最近一直有一个执念，想把团队的项目周会开起来，主要是为了想解决项目价值回收的问题和项目风险管理的问题。但是项目风险管理其实是一个伪命题，在日常迭代战会中就可以很好的解决为什么还要单独开个项目周会呢？如果我们能将项目比较好的拆分，每个迭代都有聚焦的目标。那么只在迭代层面上去管理风险，也是OK的。

这一部分对于产品的发布计划和迭代计划的设定提出了更高的要求。然后回到价值回收这个问题，我们可以在项目层面上进行价值回收，是否引入项目周会的机制其实不太一定。