数据驱动过程改进

作者|郭胜君

互联网高速发展的时代，敏捷开发已被各公司广为使用，其核心是MVP（最小可行性产品）、快速试错、小步快跑。在转转也如此，转转的项目采用MVP短平快为核心快速试错。大多数团队在追求效率的同时，流程规范往往被忽视，即使遇到让团队很不爽的问题，考虑到优先保证效率，也只能一忍再忍，导致团队士气低落。但是，转转做到了在快速交付产品的同时，不断优化规范流程，帮助团队进行过程改进，使团队协作更加高效，项目运转更快。

本文主要通过具体案例，分享如何通过数据驱动团队进行过程改进，欢迎大家一起探讨交流。

依据什么进行过程改进？

过程改进要从痛点驱动，如何获取团队痛点呢？方法有很多，比如：深入团队去观察、和一线人员沟通了解、分析项目数据等，最有效的方法是分析项目数据，用数据反映团队的真实情况，有理有据。

转转平时收集项目中比较关注的数据（主要从质量和效率两个维度），并定期分析总结，重点分析异常数据，对于共性问题进行优化改进，主要采用PDCA原则。

开发自测让团队转的更快

开发自测可以提高开发人员的质量意识，提升代码质量，减少对测试人员的依赖，减少沟通成本，节省测试工作量，因此，很多公司都在实践开发自测，转转是如何推广此实践的呢？数据为依据，选择合适的试点团队，试点ok后逐步推广，定期分析数据，不断优化改进。具体如下：

1、 数据分析：转转项目以小需求为主，且更新频繁， 通过分析数据发现，测试bug主要集中在大需求上，小需求基本没有bug产出，类似小需求测试资源投入大产出小

2、选择合适团队：依据数据，结合各团队实际情况，选择合适试点团队。初期选择了迭代速度较快的业务团队做为试点团队。试点团队起初没有明确的开发自测标准，执行效果不明显。后来根据团队情况，和团队沟通明确开发自测标准，开发自测标准可以有不同维度，比如：

（1）按开发工作量

（2）按工程

（3）特殊情况，团队提前沟通

3、效果跟进：推广后，需要定期分析执行情况，对于未按要求执行的case，要求团队总结给出原因，并不断完善开发自测标准

试点团队明确自测标准后，在执行过程中，不断优化完善，效果明显提升，开发自测率达到了95%以上。有了标杆团队，可以很好的去其他团队推广，甚至有些团队看到标杆的效果，会主动要求进行开发自测，很快就推广到了全公司。

实施开发自测后大概50%项目由开发自测，不需要QA测试，提高代码质量，大大的节省了QA的人力成本，减少沟通成本。

让Code review成为一种团队习惯

Code review 可以提高代码质量，尽早发现bug，降低成本，同时促进团队内部知识共享，帮助更好地理解系统。之所以有这么多好处，很多公司都在推广code review。但是困难重重，团队大多以项目时间紧、人力不足等理由拒绝。转转也会存在同样情况，主要采用如下方法推广code review。

1、 分析项目异常数据，主要针对上线过程进行分析，发现有一些共性问题，比如新人不熟悉业务编写的代码有问题、上线过程中反复修改配置文件等导致上线回滚。通过一段时间的数据积累，导致上线回滚的原因中，代码问题、配置文件不全、漏测等问题占比较高，其中代码问题、配置文件不全可以通过code review避免

2、 数据推动，以痛点数据为依据，和团队沟通，制定code review 的流程。根据团队实际情况，转转的code review分为两种流程：

底层基础系统：为了保证系统的稳定性，所有人的代码都要进行code review

业务型系统：主要考虑到业务快速迭代的特点，核心工程、新人的代码要进行code review

转转的code review集成在Beetle平台，可以根据团队特点自定义配置（按工程维度、按人维度）

3、 效果跟进：推广后，要定期分析团队使用情况，不断优化改善，可以从 code review 次数，批注次数、 code review趋势等分析。重点关注异常数据，通过分析发现code review 过程中大家很少进行批注，进而重点分析code review次数较多但是没有批注的数据，了解原因，不断优化

总结

过程改进是一个长期持续的工作，需要不断优化完善。本文只介绍了开发自测、code review两个案例，期待后续能够有更多的案例与大家分享，让过程改进帮助团队跑的更快更稳。

往期精彩回顾