研发效能与上班恐惧症

沈立彬——研发效能高级经理。于2007 年毕业于哈尔滨工业大学。曾任职于 Autodesk、Splunk、字节跳动等公司，曾负责AutoCAD, Splunk旗舰版，亿级DAU短视频等核心产品的质量保证和工程效能工作。拥有 15 年以上的软件测试和工程生产力经验，在DevOps、大数据测试、测试自动化等方面有丰富的实践和积累。也是华东师范大学软件学院专业选修课《大数据测试》授课讲师。

▼

整年度唯二的第一个黄金周就这样过去了！

切换成工作模式的你，是否患有上班恐惧症呢？

实际上这并不是一个羞于启齿的话题，大多数人或多或少都会有上班恐惧症，对于快节奏的信息产业从业人士更是如此。

恐惧的根源之一是人们对未知事务的担心，具体到IT职场人士可能表现为我们担心着是不是天上掉下来一口锅（严重的bug），亦或是别人甩到我们脸上的：“产品经理是不是突然加进来一个与现存项目冲突的需求；想一出儿是一出儿的老板是否给你加一个莫名其妙的KPI，然后说你这一项很低，需要balabala。。。”

这时候或许你也就默然接受了这些变化，然后上班恐惧症更上一层楼，还不忘在心里默默自我安慰一下，借用威震天的话：

其实给我们带来未知恐惧的这些人，也许也是自身对未知的恐惧、对项目的无掌控感使然，无论是甩出来的锅，额外的需求，那(bei)莫(po)名(hai)其(wang)妙(xiang)的(zheng) KPI。众所周知，现代软件开发过程的复杂程度日益加剧，研发效能的提升应该从“人治”慢慢走向“数治”。人治是靠经验丰富或者权威性高的人来把控方向，识别风险，提升效能。数治是靠制定合理的度量指标，识别整个系统/组织的成熟度，规划系统、组织效能提升的方向。一句话总结：人治是靠主观意识决定后续活动，数治根据客观情况合理规划。

说到研发效能，相信没人能反驳google作为该领域的先驱地位，我们来看看研发效能在google发挥的作用，正如来自google研发效能研究部门的技术负责人Ciera Jaspen所说：

“Google is a data-driven company. We back up most of our products and design decisions with hard data. The culture of data-driven decision making, using appropriate metrics, has some drawbacks, but overall, relying on data tends to make most decisions objective rather than subjective, which is often a good thing. ”

研发效能致力于通过跟踪各种与工程相关的指标来衡量和优化工程过程。这里的目标通常有三个：

· 识别研发过程中的问题

· 减少研发团队交付新功能所需的时间

· 允许使用不同的流程、技术和工具进行实验，以进一步改进工程过程

研发效能的着手点从度量数据开始，这些数据将成为横向和纵向比较的基础。在采集到足够多的数据（比如一个月的数据）之前，建议你不要进行任何行动，对当前的研发流程等不能妄动手脚，别问我是怎么知道的，历史的教训[捂脸］。还有一点是，许多团队以两周的时间为一个sprint，所以一个月（4周）的数据可以让你收集至少两个sprint的数据。

接下来，我们希望对研发过程进行逐渐的更改和实验，以了解是哪些东西提升了开发团队的速度，还是减慢了开发团队的速度。最好一次只试验一种变化，有效地控制变量，这样你就能看到每次变化的效果，而其他条件都是一样的。

但是很不幸，对于该度量什么，怎么去提升，看起来并没有银弹，因为研发效能是个系统性的工程，所以受制于人员技能，项目和团队文化。

不过呢，既然你都看到这个位置了，我总归不能让你带着失望离开，一般来讲，有四个关键的度量指标对于大多数的公司和团队来说都可以作为始发站，可以帮助你开始度量工程生产率。

1. 发布周期用时

软件开发周期时间度量从开始工作到交付工作所需的时间。这是一个从精益制造借鉴来的量度指标，并且它是研发团队最重要的量度之一。简单地说，周期时间度量从第一次提交到生产版本的时间。

2. 部署/上线频率

团队希望度量将新更改部署到生产环境的频率。此外，我们还可以通过跟踪各个分支的部署来丰富我们的数据，比如feature分支、hotfix分支或QA分支。这些数据可以显示一个feature通过不同的开发阶段需要多长时间。我们也能容易地看到到底是哪个环节是生产力的瓶颈。此外，部署频率反映了团队的吞吐量。这是跟踪团队速度的一个很好的指标。

3.Bug数量

每个阶段，每种类型的bug都需要被追踪，bug逃逸，bug被降级，bug被推迟修复的数据也需要进行追踪。

4. Reviewtomergetime(RTMT)– 审核合并时间

这是GitLab开发手册建议的一个有趣的指标。我们需要衡量PR发起到合并之间的时间。理想情况下，这部分时间需要不断地下降。高RTMT会阻碍开发人员花很多的时间在孤独地等待，从而耽误更多的开发工作。

那么，根据这些指标我们怎么才能消除给我们带来上班恐惧症的所有因素呢？来K+峰会，我们一起深入讨论。

“K+全球软件研发行业创新峰会”是技术领域的顶级创新峰会，秉承“开放×连接×预见”的宗旨，就科技企业技术研发方向，特设工程创新、管理创新、产品创新、技术创新和效能创新五大分论坛。融合数字化转型、产品创新、运营和增长、云原生、DevOps创新、质量创新、微服务、高并发架构、智能金融、应用性能优化、工具的革命等十几大专场。特邀近百位全球软件领域的技术领袖与一线实战专家，融合主题演讲、互动研讨、案例分享、实战演练等多种形式，共同探讨软件领域的前沿发展、最佳实践和创新应用，打造大师智慧+实践干货的技术盛宴。

本届k+峰会，沈老师将作为效能创新分论坛下，"研发效能体系建设"专题出品人，联合京东集团首席架构师叶赫华；宏信设备测试总监王培安；Thoughtworks技术负责人、全栈工程师张思楚，共同聚焦分享最前沿的研发效能理念，高效工具和平台建设最佳实践。帮助识别和定位到自己组织内研发效能建设阶段和目标，吸取嘉宾老师的成功经验，避开他们趟过的坑，真正做到开发的事半功倍。