高效研发体系的基本特征

上一篇文章讨论了一下工程师的成长，不断提升工程师们的效率。但是工程师是否能安心，顺利的成长，依赖于公司或者部门这个大环境，依托于研发体系这片土地是否具备足够的营养来滋润。万丈高楼平地起，建设一支充满战斗力的研发团队的前提是，我们的技术生态是健康和可持续的。本文就根据我过去多个团队积累的一些经验，来尝试梳理一下。

为了让这个问题的讨论能有一个可视的画面感，我就先对比列举一下，低效研发体系 VS 高效研发体系之间的区别，大家都可以脑补一下你所在公司或者团队的情况是否和以下的情况一致：

•低效研发体系：把技术团队简单当资源使用，简单的任务派发。为什么要做这个需求，需求的价值是什么一概不知。

•高效研发体系：让技术团队觉得是在一起做一件有价值的事, 讨论清楚需求的前因后果。每次需求上线后，需求的效果有完整的数据跟踪，根据数据来总结本次项目的得失。

•低效研发体系：业务，产品和技术的观点不在一个维度上：业务的观点在业务拓展、收益上；产品的观点在需求、产品功能上；技术的观点又在产品特性，功能实现上。

•高效研发体系： 大家都聚焦在一个点上：”SHOW ME THE MONEY”，大家的沟通思路都围绕在提升产品收益或者降低营收成本，技术的所有工作都应该紧密围绕“提升收益”和“降低成本”这两个方向。

•低效研发体系： 需求评审会上，业务和产品唱“独角戏”，技术同学没有自己的想法。

•高效研发体系： 在需求评审会上，产品和技术会明确需求是否完整，确认产品功能的正常场景，是否形成闭环；异常场景的处理流程；产品细节是否考虑周全。

相信大家看过后，心里都会有自己的一份感受，当然，这和你所在的公司的文化和背景有关，更与技术所对应的业务有紧密的联系。简单来说，一个高效研发体系是否能完整的落地，一方面是技术团队内部的不断建设和演进，另一方面也需要大环境和各个团队的配合和支持。

抛开外部环境不谈，对于一个高效的研发体系，我们可以做一些什么，在这里，我列举一些共通的基本特征，为了清楚明了，按照一个标准项目的流程来谈：

•在需求阶段，深入讨论为什么做这个需求，这个需求的价值是什么？最终配合产品产出一份满意的需求评审文档。

•在开发阶段，开发和测试小组，并行输出技术方案和测试用例，技术方案中，包含系统的交互协议和接口定义，所涉及系统的一个overview, 并梳理开发对业务的理解，确保和需求一致。建立提测标准，测试产出核心用例交给开发自测。开发完成自测，再提测，避免普通体系中，开发写完代码就提测，再被测试打回，反复多次。

•在测试阶段，建立自动化发布，测试和回归是有时间约定的，形成节奏感。每天执行2~3 轮测试，开发专注于修复bug，测试集中测试，减少了不断提测、部署环境浪费的时间；至少建立接口级别的自动化回归测试，确保所有的API都能正常运行。

•在发布阶段，建立预发布环境、分批发布和灰度发布，发布完成后，开发和测试会在线上进行必要功能的验证，并持续观察线上访问日志，确保上线后功能完成没问题。如果有问题，可以迅速回滚到上一版本，避免造成线上故障。

研发团队的建设围绕着人来展开，通过研发体系这片土壤让工程师们能高速成长，反过来，“成熟”的工程师们再不断耕耘这片土壤，让土壤更加的肥沃，形成一个完美的生态。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可