团队超过 10 个人的时候，我们就陆续建立的我们研发管理规范，但是不完善，也一直在学习和思考。

这里的观点部分借鉴了网络观点，更多的是我们自己结合自身情况摸索出来的规范， 也许不成熟，就当是抛砖引玉吧。

为什么要有研发管理规范？

当没有一个合理的管理规范，可能会遇到的问题：

• 需求的进展不透明，不知道现在到哪里了

• 需求延期发布成为了家常便饭，不知道什么时候会发布上线

• 需求发布上线后，心里总是忐忑不安，不知道什么时候会出现问题和故障

• 需求插入随意、频繁，不计成本

• 团队沟通成本太高，经常性出现 RD、FE、QA、PM 信息不一致

• 不清楚，研发团队的工作量，是正常、超负荷、还是有人不饱和

在互联网初创公司里，需求和有限的资源，永远是矛盾命题，如何在矛盾中寻找平衡，把有限的资源专注于符合公司战略的需求，保持团队的节奏和良好的情绪，这是我们建立规范的背景和目的。

研发规范的 10 个方面

需求管理

建立需求时，需明确需求背景，期望时间和优先级

项目管理人员综合评估进行排期

研发人员需对任务进行详细的拆解

任务的拆解，有助于项目管理人员评估项目难度，工作量和风险，有助于项目有条不紊的推进， 也有助于研发人员清晰高效准确的完成任务。

以后端开发为例， 需拆解到接口或功能单元，涉及合作方配合的工作要单独列出，以下是示例：

1. 功能一开发

2. 功能二开发

3. 接口对接联调

4. 前后端联调

研发人员任务开发在时间上应保持一定的冗余度，避免出现延期情况， 项目管理人员负责每日检查任务细项， 开发人员及时标记项目进度。

流程规范

上述周期安排适用于常规需求。

• 特别的，如果是紧急需求，会安排走特殊发版流程。

• 特别的，如果是大型项目，会提前安排提测，至少预留 3 天的测试时间。

• 一般的，先进行项目进度跟踪和问题复盘，再进行需求评审

【关于问题复盘】

• 项目进度情况，是否出现延期，如果延期，项目 owner 应说明原因

• 提测和发版是否符合预期，是否出现导致发版时间大幅延长的情况

【关于需求评审】

• 讲清楚需求背景和细节

• 评估可行性

• 确定对接的研发人员

• 确定是否要进一步进行技术方案评审

产品研发早会

每日三问

1. 任务拆解了么

2. 任务是否如期完成，为什么

3. 任务遇到了什么阻碍，需要什么帮助

每天早上 10 点， 直接进行投屏过进度， 时间控制在 10~15 分钟。 以上反馈记录到 tower 看板

代码管理

将测试和生产的工作流分开，避免产生一堆无效分支和标签严格按照 git flow 流程进行分支的合并

以下是 git flow 流程的图解

• [发布生产]: 主要用 master 分支

• [开发新特性]: 主要从 master 分支，fork 出 feature 分支，比如 feature/add-new-feature（develop -> feature）

• [开发结束]: 合并到 release 分支，各个功能开发快完成时，需要发到预发布前，生成 release 分支，如 release/1.5.5 （feature -> release）

• [测试完成] : 提交 release 分支，提交 PR，进行 code review . PR 会合并到 master 分支

• [PR 合并]: PR 合并后会将 release 分支合并到 master （release -> master)

• [修复线上紧急 bug ]: 从 master fork 出一个 hotfix 分支，比如 hotfix/fix-some-bug，发布测试测试后没有问题，提交 PR，进行 code review ， PR 会合并到 master 分支 (master -> hotfix -> master)

• [正式环境发布 ]: 需 在 master 分支上打 tag，tag 格式如 2.4.9 或 2.4.9.1 , 第 4 位为 hotfix 版本号

代码评审

代码评审不设固定时间评审，代码开发完成后进入评审。 评审的关注点如下：

• 是否满足产品文档需求

• 是否有逻辑漏洞

• 日志是否规范

• 是否有错误捕捉

• 是否有性能问题，如果有增加查询逻辑或者字段，要考虑是否要加上索引，高并发情况下是否会产生性能问题

• 注释是否清楚，重要或者复杂逻辑是否有文档说明

• 代码是否满足可读性要求

• 代码是否满足扩展性要求

• 代码是否可以简化

• 代码里是否有写入不必要的调试信息或者 mock 数据

• 变量名称是否规范

• 过线上错误日志信息，检查是否有需要处理的 ERROR 级别错误

项目测试规范

• 开发人员在提交给测试之前，应该先进行自测，后续引入自动化测试平台开放给前后端研发人员使用

• 开发开发提测之前，需要告知测试人员相关的代码改动和影响范围，影响范围由前后端对接人进行确定

• 开发人员项目提测最迟在发版前一天交付

• 测试人员测试完成后，产品经理介入产品验收流程

• 测试人员需要梳理出核心项目的测试主流程和测试步骤

• 遗留产品需求由产品经理跟进， 遗留项目 bug 由测试人员跟进

• 需要向合作方申请资源（比如 app）， 测试人员需要提前跟进

项目发版规范

【发版前】

• 开发人员发版要写发版计划，前后端发版都要写好发版计划

• 开发人员要明确回滚步骤， 没有回滚计划的发版计划将被驳回

• 开发人员应在发版计划里标注此次发版的影响范围，方便测试/产品进行验收

• 视情况， 开发人员发版前发出发版公告，以邮件告知给公司全部同事，如有必要还应通知相关合作方，可以同时在相关工作群同步通知

【发版中】

• 生产环境的每次重要操作需要有记录，且能追溯

• 如果有多个项目需要发版，优先发重要紧急的项目

• 原则上只留相关人员发版，确保第 2 天有其他同事可以正常处理项目需求

【发版后】

• 视情况， 开发人员将发版结果，以邮件告知给公司全部同事，如有必要还应通知相关合作方，可以同时在相关工作群同步通知

• 项目上线时需要完善监控机制，确保发布的重要功能模块能够被监控

• 开发人员在发版后应该把电脑带回去，方便第一时间处理问题，手机要保持畅通状态，方便出问题联系

• 对于改动较大的重构，需要在发版后的次日观察会员开通情况，前后端的报错日志

故障处理规范

• 对于影响会员开通和权益使用的大规模故障 5 分钟内不能定位故障，应该第一时间回滚，回滚完测试人员介入测试， 开发人员再进行问题定位

• 客服人员在接到故障反馈后，应第一时间和发版负责人/项目负责人进行联系

• 技术负责人应完善通讯录，确保出故障时能及时联系到相关负责人

故障复盘制度

• 出现中级以上故障后，相关责任人需要在故障处理后填写故障复盘报告

• 团队负责人需要在在 1 天内组织故障复盘会，深度剖析故障原因，有必要需要对相关人员进行问责和处罚

激励制度

随着业务的发展，我们面临更多的挑战，人员的能力模型也要进行相应的升级， 我们会针对满足能力模型的优秀人员给予相应的激励。

1. 快速响应（对需求和故障处理的快速响应）

2. 使命必达（设定了目标全力以赴完成， 不挑活， 有困难及时请求协助）

3. 能力过硬（技术能力，学习能力）

4. 抗压力强（不骄不躁，不玻璃心， 面对压力，不被击垮）

5. 团队精神（不抱怨，及时补位，通过配合完成任务）

（以上的要求总结起来就是：事不拖，话不多，人不作）

激励包括但不限于：荣誉激励，特殊福利，特殊假期等