二手车技术团队研发效能实践

近几年来，中国乘用车市场逐步走向“存量时代”，依托于互联网强大的信息发布以及获取能力，二手车行业得到了快速发展，不断涌现出众多二手车线上化平台，为二手车买家与车商提供多种服务。汽车之家•二手车作为一体化线上平台，多年来不断探寻多种商业模式，根据市场情况能快速调整产品策略，及时满足终端用户需求与商家需求。得益于汽车之家的平台优势——整合汽车之家、天天拍车和平安“三合一”的优势资源，汽车之家•二手车完整布局C2B2B2C生态圈，实现二手车流通全链路覆盖，并从提供线索服务向提供增值化、数字化服务方向升级，打造中国最大的二手车平台。

二手车技术部以降本增效、提升产研效率、为公司战略快速落地为基本原则，通过数据化研发资源、优化流程、合理分配、技术打通、业务打通等方式做到需求及时响应、灵活处理、快速上线

，并逐步形成了自己的一套行之有效的效能提升方法论。

效能是一个综合性的概念，是对效率效果进行综合性的评价。研发效能是指：研发团队持续为用户产生有效价值的效率；可长期、持续、高效的开发出有价值的产品。

二手车技术团队为了合理化分配任务、调配资源、快速响应，实践了如下策略：

1. 标准化产研对接流程；

2. 引入工单看板;

3. 规范化需求拆解与任务研发;

4. 数据化研发资源;

5. 引入业界先进技术实践;

6. 研发技能打通/业务打通。

   
   

效能的关键指标是效率和质量，在效率维度上，如何可以清晰得到组织的效率呢？我们知道，在传统制造业，效率是指单位时间内可生产出的产品数量，同样时间，在质量不变的情况下，生产的产品越多，效率越高。这个理论同样适用于互联网企业，在同样时间内，质量不变的情况下，上线的需求越多，那么这个组织的效率就越高。 但我们知道，不同产品需求投入的开发成本是不一样的，开发一个新的体系化的业务模块，远比给某个页面加一个按钮操作要耗费多的多的人员和时间。 不同开发人员在开发同一个任务时，需要投入的时间也并不是完全一致的，有的人做的快；有的人做的慢一些；有的人考虑的全面做的看起来时间长，但完成度高、质量高，测试就比较顺畅；有的人一开始没有考虑那么全面，做的很快，但完成后测试期问题就比较多，需要投入更多的时间来解决问题，并且耗费了更多测试人员的时间。我们在考虑提升效率的时候，不能只是考虑单一团队的效率，要从整个流程上去考虑；并且，一定要考虑质量的提升，效率高了，但是质量下降是不对，必须要都提升起来，整个组织的效能才算是真正的提升起来。

二手车技术部按照研发的内容以及顺序分为后端、接口、前端三个组，之前，每个组有各自方法来评估一个需求的投入成本，这样导致无法从整体研发团队的角度，拿到整体资源投入总量，没有直观的数据来评判整体产出量。针对这个问题，我们做出了下面的改进。

1.1 度量单位

标准化度量成为了我们的第一步，依托于以下三点分析，我们选用时间（完成任务的小时数）作为统一评判需求成本的单位，原因有以下3点：

1. 在实际工作中，”时间”为研发侧每天最直观、并且可衡量的投入；

2. 研发同学对一个功能开发需要投入的时间基本都会有预估时间；

3. 不同开发同学对于同一开发需求的预估时间不会相差太多。

   
   

1.2 统一度量

时间维度是最贴近研发生产侧的度量单位，研发同学的投入基本都可通过时间来衡量，但这里也有几个痛点问题：

1. 不同需求研发需要的资源不同;

2. 同一个需求，占用不同开发组的资源不同;

3. 不同的开发同学对于同一个需求的时间评估也不同。

如何才能对需求投入的资源有一个统一标准进行衡量(资源量化)呢?

1.2.1 统一度量 - 任务拆解

这是一个需求细化的过程，把需求拆解成可执行开发的最小颗粒度。当一个需求需要用天来衡量和跟踪的时候，是非常不利于进度把控的，只有拆解成最小可执行单元，才可以精准的进行进度的跟踪与问题的把控。 当需求到达研发团队时，组长和组员一起对需求进行拆解，拆解成多个小颗粒度的研发任务，开发同学来各自认领或指派任务，进行任务开发。 在时间维度上，每人每日的工作时长为8小时，因此，二手车技术团队基于敏捷研发理论，制定任务拆解细化的基本原则：

1. 任何需求一定会拆解成子任务，再小的需求也会有一个子任务并指派到具体研发人员;

2. 每个子任务的研发时长最小为0.5小时，最大不超过4个小时;

3. 当日完结的任务要置为开发完成待测试状态；

4. 完成的任务日期记录不跨指标统计周期。

1.2.2 统一度量 - 黑盒估时体系

在任务拆解逻辑基础上，时长最小0.5小时，最大不超过4个小时是如何确定下来的？我们采用了一种“黑盒估时”的办法，类似于敏捷研发的故事点数，但是, 我们用更直观的小时数来衡量拆解好的研发任务成本。

如何操作:

1. 研发组对需求进行分析后，组长拆解任务或组员自主拆解任务；

2. 所有组员对齐任务拆解结果;

3. 依据产品需求文档，组员对每一个研发任务进行需要投入的研发时间进行预估；

4. 把预估结果以单聊的形式发给组长，由组长对每个人的估时进行比较核对；

5. 对于同一个任务，如果有2个人的估时相差巨大，那么，组长组织，让2个人分别阐述观点，看是否是考虑不全，或考虑过多；

6. 如果所有人员对某一个任务的评估均超过4个小时，说明任务拆分的不够细致，需要继续细化拆分；

7. 组长收集到组员对每个任务的估时之后，组织组员一起对齐估时差异的任务研发逻辑，确定统一后，选取每个任务估时的中位数作为研发任务的最终研发时间成本。

8. 组员确认最终结果后，各自认领任务进行研发。

研发同学每开发完成一个任务，就拿到一个任务工时点数，因为工时点数是选取的一个相对中立的数值，这样，开发的快的同学，在单位时间内就会拿到更多的工时点数，没有那么熟练的同学也可以通过不断的提升自身能力，通过的努力，可以拿到比较不错的工时点数。 当组员能力整体提升以后，对于同类型类似的任务需要投入的时间成本会降低，这样在单位时间内就可以消耗（完成）更多的研发任务。

所以，对估时体系的数据进行整体监控，可以看到组织的整体效率的提升。

一个需求可以被精准拆解成研发任务（不遗漏），每个任务可以被精准估时，需要一个非常重要、并且是“强制性”的前置条件：到达研发侧、可被研发同学细化估时的产品需求必须是完整的、完善的、严谨的需求文档！

2.1 背景

在平均每周30个新增产品需求的情况下，技术团队需要快速理解、快速消化需求，从而才能快速地对需求进行任务拆解，衡量需求研发成本。因此，产品需求文档的质量是决定性因素。

2.2 需求质量的指标定义

需求沟通：产品经理与技术针对某业务需求进行讨论，商定产品方案与技术方案。 需求评审：产品经理与技术研发组长或团队成员，完整细致的讲解对齐产品需求。 需求完整度：需求文档内容需包括以下几个方面内容:

1. 业务逻辑说明;

2. 产品原型;

3. 数据需求(埋点以及数据分析说明);

4. 完成度≥90%的设计图;

   
   

2.3 评审规则

评审次数：

评审一般分2次进行：

第一次对产品文档的整体性、业务逻辑、交互等做整体沟通和评估；

第二次为完整的需求文档做细节核对并与具体需求开发人员理清细节。

评审参与人员：

第一次：产品、技术负责人、数据负责人参加； 

第二次：产品、具体执行技术人员、具体执行数据人员、技术负责人、数据负责人参加。

评审流程以及结果：

1. 评审前准备： 第一次评审：需准备逻辑完整的业务需求wiki、产品原型、基本数据统计需求。 第二次评审：需准备逻辑完整的业务需求wiki，完整的数据需求（数据需求包含埋点文档及数据分析需求），完整度超过90%的设计图。

2. 评审时： 第一次评审，确认需求wiki中业务逻辑清晰且无漏洞，明确需求未完成部分事项。 第二次评审，确认wiki内容完整、逻辑清晰无漏洞；数据需求逻辑清晰无漏洞；设计图与需求交互相符、无缺失。

3. 评审后：

1. 如评审时有问题产生，产品经理需在会后与相关人员整理好对应的解决方案，落实到文档中，下次评审核对。

2. 如二次评审后，无业务逻辑问题，物料完整，最晚 T+1 技术组负责人给出排期，技术侧按照排期时间进行开发测试上线。

3. 如二次评审仍有问题，则会重复第2步，进行多次评审，直至没有问题，达到研发标准。

4. 当评审有待解决问题时，以快速完成研发必须的要素为原则，争取2次评审通过为原则，研发组长会协同产品经理一起解决问题，促进业务需求尽快落地。

2.4 需求插队

如遇到相对大需求插队，则需要进行整体性评估，并与业务方重新确认需求优先级，重新定排期：

1. 产品经理提出需求插队, 明确需求优先级以及必须上线时间；

2. 产品经理与技术按照需求评审会规则进行需求评审；

3. 需求评审通过后, 技术按照需求上线时间, 根据开发量, 反推各阶段开发起止时间；

4. 根据时间节点, 查看与当前已排期需求冲突的部分；

5. 根据插队需求节点, 对受插队影响的需求新排期；

6. 产品发申请插队邮件, 邮件内容包含如下内容: 需求业务方, 产品需求概要, 需求目标结果, 需求上线时间. 邮件收件人: 研发组组长 抄送: 受影响的需求的相关团队长, 产品经理, 相关开发人员；

7. 研发组组长回复邮件, 内容写明受影响的需求提前/延期情况, 并附上 插队前/插队后 的排期图对比；

8. 团队长回复邮件确认是否可以插队开发；

9. 如可以插队, 按照新排期开发后续需求；

10. 如有异议，各方协商开发时间与开发资源，以及受影响项目，确定方案后，邮件同步即结果。

11. 研发组按照协商的最终方案进行开发、测试、上线。

3.1 发版规则

为保证业务需求严格按照预期时间快速落地，二手车产研没设置迭代周期，以“动态上线“模式进行研发测试以及发布。

每一个需求的研发到上线都会遵循瀑布流模型，如下图：

我们的需求量级很大，完全不会有断档情况，因此，研发侧进行中的需求基本上是并行开发，或者错开一个小阶段来开发，相当于多个瀑布流交叠在一起，逐步推进：

所以，我们的发版策略相对灵活，高优先级需求研发测试完成即上线，已完成的低优先级需求则合并到同一版上线。

除嵌入主站App中的功能与主App的发版周期保持一致，其它二手车各端遵循如下逻辑：

1. 自有App，商家端、用户端以最高优先级需求的上线日期为发版日；

2. 小程序、H5页面则按照测试UAT完成即上线的原则进行发布。

   
   

3.2 代码规则

为了保证“灵活发布”、“随需上线”特性的可持续迭代，技术研发侧制定了尽可能灵活的分支策略：

1. 每个需求一个分支;

2. 需求之间如有代码依赖，则建立中间代码分支（base）作为代码共享分支；

3. 每个研发阶段，共享一个“提测”分支，所有研发功能均合并到提测分支供测试打包验证；

4. 已UAT完毕，确认发版的需求，则合并开发分支代码到master分支上；

5. 发布新版本仅从master分支进行打包编译；

6. 发布完成后，在master分支发布节点上做tag标记。

3.3 可持续集成/交付

CI/CD：可持续集成、可持续交付是提升研发测试效率的重要手段和工具，可以极大地解放开发资源的占用，节省人力成本；而可持续交付、持续部署系统的应用，可以极大地简化上线流程、简化人员操作成本、减少人为因素引起的上线问题。

2018年，二手车移动组开始了App的可持续集成交付系统的部署与尝试，借助Jenkins，搭建了移动组线下提测&正式发布编译流水线：

1. 商家端与用户端的iOS与Android共6款应用的编译提测与正式版发布任务；

2. React Native项目的编译提测与正式发布任务；

3. H5页面测试环境的自动化编译部署。

整套系统稳定运行至今，每个应用平均节省时间成本：1人年。

二手车作为先期接入汽车之家云平台的事业部，在几年的业务实践应用上，积累了不少经验，充分体验到了云平台的便利性，接口发布上线不再心惊胆战，脚本指令话的部署方式快速便捷，节省大量人工成本，并且最大限度的避免了人为因素的上线问题。

前文讲解了评审流程、任务拆解、任务工时，通过什么样的方式来执行、以及如何能记录下来这些数据用做后续分析呢？

我们采用工单看板系统(精益云)，精益云为之家自研的任务看板系统，支持多泳道，多工序，自定义配置灵活，可以满足多种团队任务管理需求。 我们按照前端、后端，拆分成2个看板，方便分端查看与统计数据。前端看板按照C端与B端，拆分为2个泳道，因为前端需求开发有交叠，就不再分看板，减少管理成本。

每个看板包含8个工序，从起始到结束排列为：未评审需求、需求池、已排期、开发中、待测试、测试中、测试完成、上线。

看板: 所有的产品需求的主任务工单均建立在看板的需求池泳道中，评审后，技术组长填写好“初次评审日期”、“评审通过日期”，技术排期后，则有技术组长移动卡片到开发已排期列，并填写好“技术排期时间”。

子任务单: 开发组长对以进行拆分和估时的任务建立子任务工单，并填写好“开发预估工时”与“技术排期时间”。

任务完成: 当研发同学完成一个子任务工单后，研发同学需要把该任务工单拖动到“测试待排期”列，并填写好“实际开发时间”与“实际开发日期”2个字段。

任务测试: 当一个需求整体开发完成提测后，测试同学在该需求的主工单下创建测试任务工单，并填写“预估测试时间”，开始测试。 当测试期产生了Bug，测试同学在需求主任务单下创建Bug工单，把Bug工单设置经办人为对应功能的开发同学。 当需求测试完成，所有Bug均已验证，测试同学把需求主工单拖动到“测试完成/验收”列。

上线: 当产品与设计对需求开发内容进行UAT，无任何问题以后，研发组对此需求进行发版编译，App上线后，测试负责人/产品经理把该需求工单拖入至上线列，完成需求上线。

至此，一个产品需求在看板上走完了整体流程，主工单下也收集到了所有需要的过程数据。

我们通过对工单系统中的任务工单进行统计梳理，获得了迭代内需求数、迭代内研发任务数、需求池需求数、新增需求数、上线需求数、完成任务数、研发实际总工时、测试环节日均BUG数等静态数据指标。再以周和月的时间维度进行加工分析，得到了日均任务平均工时、技术吞吐率、测试Bug率等过程指标数据。

在不断的收集分析指标，同时贯彻执行如上方法论：我们得到了明显的2个指标的提升：

1. 子任务平均工时从3.9下降并稳定在3.2小时左右。

2. 全员贯彻执行工单拆分标准化，随经验的增加，估时越来越准；

3. 精细的任务时间管理，最大化的减少了任务研发的时间旷量，保证需求进度相对精准可控，降低项目延期风险；

4. 技术整体吞吐率由 6.4 提升并稳定在7.2(小时/人/天)，提升12.5%。

5. 通过加强研发人员的技能栈打通策略，做到后端/接口做到全技能打通，可承接.net/java/go语言的各项任务；前端全员基本承接H5/Flutter/React/React Native/原生各类需求研发任务；

6. 业务打通：前/后端全员可承接各业务需求研发，最大化人员动态调配能力。

7. 日均工作工时基准产出比稳定在110%~115%，保证稳定消耗新增需求。

8. 通过研发左移策略，需求质量较开始有很大提升，1评通过率由33%提升到了67%，降低反复评审，并且降低了研发过程中的需求变更与反复。

9. 通过测试左移，研发加强自测与测试用例的双重应用，测试期Bug率由5.98%下降至2.08%，大幅减少了复测环节，提高测试效率。测试研发人员比在1:3.5的情况下可如期完成需求任务的测试。

目前在产研比1:1的状态下，技术部整体较4月份提效每天1人天，相当于全年可多完成290人天的需求任务。

效能管理方法论是双向的，与管理学大师泰勒提出的流水线工人管理方法论同理，虽然互联网公司、科技企业对产研效率提升方法论的不断探索优化，是帮助公司快速落地战略规划的有效方式。但是，员工的创造性、主观能动性、自发的追求卓越、对公司产品的持续改进、对组织和业务发展持续提供的价值也是至关重要的。

因此，产研的效能管理应在关注量化指标的同时，平衡好其他不可量化的、定性的价值创造，才可以保持组织健康的、可持续的发展。