8 年产品经验，我总结了这些持续高效研发实践经验 · 协同篇

「人与人之间的如何高效协同？」这是一个伴随人类诞生以来，从未停止过追求更高目标的课题。从原始社会的集体狩猎、语言的创造和改进、农耕文化的协作耕种、工业革命后的协作生产再到现代文明中公司的团队协同，从始至终，「协同」在创造和生产中起到至关重要的作用。

在软件研发中也不例外，其生产过程中最核心的角色是「产研团队成员」。「成员之间的透明高效协同研发」也是当前 DevOps 理念中非常重要的一个部分，为此，海内外也有很多优秀的公司一直在深耕这块领域，一直通过产品沉淀理念，帮助研发团队不断迈向协同高效的新高度。（今天我们不讨论具体的产品，有兴趣同学可以联系我们细聊）

回归到今天的话题，我们先共同分析下：

• 项目高效协同目标是什么？
• 能够高效协同的团队在协同方面具备哪些共性？

只有通过分析了解和深入认识什么是协同，才能进一步讨论分享协同的实践。基于自身的一些实践总结分析，在这里罗列出了几点高效协同团队的共性：

• 团队信息透明清晰，目标明确、迭代节奏清晰、团队成员清楚自己的工作以及工作对于目标的贡献；
• 研发团队协同的文化规范明确，不同角色清晰知道协同的工作流程；
• 满足个性化的协同分析统计数据，帮助团队和个人成长；
• 有强有力协同功能的平台支撑，让团队成员能够高效规划、跟踪处理团队/个人相关的事项；
• 有强有力协同功能的平台支撑，让跨团队的沟通协同变得更简单，让团队及跨团队的成员沟通协同更高效；
• ……

以上罗列出的内容不一定全面，只是想通过自己的思考，针对「研发协同」这一话题进行一次 Erda 团队的实践分享，希望能给大家带来一点帮助或启发，也非常希望有同学能够深度参与进来一起讨论，共同促进团队的高效协同。

团队文化

良好的协作氛围是团队迈向成功的基石，良好的「团队文化」能促成团队成员之间相互信任，并能坦诚、开放、平等地沟通等。关于什么是团队文化，这里引用了百度百科的解释，主要关键词就是培训、统一、规范、凝聚。

团队文化是社会文化与团队长期形成的传统文化观念的产物，包含价值观、最高目标、行为准则、管理制度、道德风尚等内容。它以全体员工为工作对象，通过宣传、教育、培训和文化娱乐、交心联谊等方式，以最大限度地统一员工意志，规范员工行为，凝聚员工力量，为团队总目标服务。” https://baike.baidu.com/item/团队文化/6348971?fr=aladdin

加入到 Erda 项目的同学，进入项目后第一眼就会看到团队崇尚的协作文化，核心是透明和异步协同。

我曾经一度认为，人与人之间面对面同步沟通和协作是最高效的，但是随着与开源社区接触和对异步协同的理解不断加深，这个曾经正确的想法也在不断被挑战。接下来，我们来看一个最典型的会议场景：

• 会议前，只通知了会议时间、地点和会议主题，详细内容不知。即使组织会议者非常用心准备了会议内容的材料，参会者也会抱着懒惰心理，没有仔细阅读，详细内容留在开会时再去了解；
• 会议中，发言者慷慨激昂地讲述着自己的观点，其他人对于正在讲述的内容兴趣度不高，甚至开小差，轮到自己发表观点时，仅仅是「发表观点」，无法形成观点间的碰撞和有效的讨论。

有关开会的段子更是层出不穷，“开会的人基本不干事，干事的人基本不开会”、“人多的会议不重要，重要的会议人不多”……相信每个职场人看到都能会心一笑，一群“状况外”的员工凑在一起，期望通过一到两小时了解事情的来龙去脉，附带提出深刻的建设性意见，这可能吗？

有些公司或者团队为了提高会议质量，制定了一系列规范措施，比如：

• 会议室门口放一个手机收纳盒/袋；
• 公司层面有一定会议制度，比如会议室预约，会议主题明确、会议内容事前发送等规范制度。

这些措施执行到最后，往往都会变得形同虚设，有的执行好，那还得专门配备监督人员，成本增加的同时，收益微乎其微。

异步协同

Erda 项目崇尚的异步协同的方式，核心主要围绕以下几点：

• 高质量的发言

「高质量的发言」还可以理解为让别人能看明白、听明白，为此，事前要有充分的图文信息做支撑，让人清晰的知道你要干什么、要达到什么目的、要什么样的协助等；

• 信息的接收与处理

异步协同不追求成员做到时刻在实时通讯 APP 保持“待机”状态，但是要求至少每天来协同平台看一次，哪些需要自己处理和回复。同时，在内容发出之前，需要对内容质量负责，确认自己写的内容能够让别人明白。

如何养成文化

科学上认为「21 天能养成一个习惯」，但如果每来一个新人就是一个新的循环，这对于一个团队来说成本有点高，与高效协同的愿景相悖。

这样的话，能不能把这些协同的规范和理念沉淀到协同产品的「功能特性」上，培养用户使用产品功能时的「用户心智」，不知不觉中按照团队的文化规范进行下一步行为？

Erda 始终致力于将这样的特性与自身产品相结合，把所有的内容都提炼为 flow，然后通过实践沉淀 flow 配置，以配置内容的方式去分享自己的最佳实践。比如，研发协同事项上针对需求、任务、缺陷都有相应的状态流转流程，对应的状态需要相应的角色进行处理，每个角色处理好对应的内容后才能流转到下个状态，同时，流转状态会触发相应的动作……这些都是通过一条 flow 或者 多条 flow 配置来完成。这个和研发的分支管理策略配置沉淀是一样的，详细可以查看上一篇《8 年产品经验，我总结了这些持续高效研发实践经验 · 研发篇》文章。

产品迭代规划的方针

在团队的「协同」文化下，产品规划也变得井然有序，Erda 产研团队推行和建议采用以下策略：

• 迭代规划周期推荐 1 -2 周作为一个迭代周期，不要超过 2 周 （Erda 团队是 2 周 1 迭代 的周期）。至于为什么要定义这样一个快节奏的迭代周期，主要是为了应对不断变化的行业的需求，软件需要加快迭代速度，越快交付用户使用，接收有价值的反馈和用户数据，可以让产品尽量避免走过多的弯路，这也符合敏捷研发小步快跑的理念。迭代规划方面建议采用「1 1 模型」推进，进行一个迭代，规划一个迭代。虽然在当前快速变化的时代背景下，但是最近两个迭代（也就是一个月内）的目标还是需要非常明确，并且在有效的协同平台（如 Erda）中进行管理维护。一个月之后的目标往往变化较快，所以建议统一在产品的 backlog 中进行管理，由产品经理线下维护更为久远的产品 Roadmap；
• 发布频率每周有发布班车（小版本，不对外部署）；
• 产品版本发布产品的版本可以由单个迭代或者多个迭代来完成，版本需根据产品功能特性来决定，推荐一个版本由多个迭代来支撑，需要团队控制好版本频率（Erda 一般是 3 个迭代发布一个正式产品版本，具体可以视情况灵活操作）。

迭代事项协同

在团队文化和研发迭代规划方针下，接下来就要真正进入产品/项目的迭代研发阶段了，在这个阶段中整个团队围绕的目标是明确的，在这个目标之下 PD/PM 会规划制定产品/项目的 RoadMap，把相关的目标拆分成若干迭代的需求来完成，当然目标拆分落地始终需要遵循 MVP 理论（Minimum Viable Product –最简化可实行产品）。

任何规划和计划都一定的策略，在 RoadMap 规划这个事上，Erda 产品主要由以下的策略来支撑有效落地：

• 责任者：主要由 产品经理 主导完成；
• 规划周期：规划半年目标，明确 1 个月内的产品需求；
• 目标/需求来源：用户诉求、竞品、行业预判、技术演进、知识理念的演进发展；
• 目标/需求的维度：
  • 行业竞争力领先
  • 优势保持
  • 加强不足

RoadMap 规划完成后，接下来的过程可能大家就非常熟悉了——迭代研发的阶段。围绕目标，研发团队在敏捷迭代评审会议上明确迭代的需求范围，然后紧接着就是需求、任务拆分、研发、测试、缺陷解决、发布上线等内容，本次主要还是围绕协同相关的需求、任务和缺陷进行讨论分享，研发过程相关内容可以查看上一篇《8 年产品经验，我总结了这些持续高效研发实践经验 · 研发篇》文章。

需求

迭代开始后，所有的研发成员都是应该围绕「需求」进行落地，产品经理确保需求的 PRD（Product Requirement Document）是清晰的，能够让所有成员明白这个是要做什么？谁用？解决什么问题？（BRD - 商业需求文档和 MRD -市场需求文档这边就不展开讨论了）

为此 Erda 产品对需求的管理主要采用以下策略进行：

• 责任者：每个迭代的需求规划主要由 产品经理来主导完成，最终需要进行迭代评审会议后最终由整个团队一起确定迭代的需求范围；
• 节奏：上一个迭代的最后一周内完成本迭代所有的需求的设计；

• 需求管理：每个需求都要管理好团队、模块、类型、上线时间等标签内容；
• 需求的内容：一段话描述解决的问题（包含用户角色、完成活动、实现目标和验收标准），核心是方便团队每一个人都能够理解全团队做的事情，即便不是自己负责的模块，需求状态的设计如下：

• 标签管理：标签的正确使用可以有效提高团队在线协同效率，为此 Erda 产品从以下几个标签维度出发，便于后续事项查询、统计分析使用，迭代执行产品规划规；

• 其他重要内容：
  • 研发需求的粒度大小非常重要，一定要控制在一个迭代周期内完成，最好是一周内就可以搞定一个需求；所以产品上的大需求一定要拆解成合适粒度的小研发需求；
  • 根据团队历史数据总结出团队的需求吞吐量，一个迭代做多少需求的工作量是合适的。

任务 & 缺陷

迭代开始后，基于需求，「能够合理有效拆分任务和合理成员安排」是整个迭代中非常关键的一个内容，由于缺陷整理和任务管理类似，所以就合并在一起来讲了，具体的 Erda 团队实践的内容如下：

• 责任者：由研发 TL/架构师等主导完成；
• 任务粒度：每个 todo 项（任务）足够小，推荐控制在 2 天内完成，如果是一个开发 todo，那么就是 2 天内会完成对应任务的代码提交/合并；
• 任务覆盖内容：产品设计、前后端开发、测试、文档 （完成一个需求的全生命周期的任务）；
• 任务标签：和需求的标签管理一致；
• 任务拆分理念：任务拆分尽量小，实现功能能够尽快验证、快速看到效果。

敏捷管理的好辅助——晨会

迭代过程中关键进度和风险同步中，「看板」和「晨会」绝对是比较重要的两把利器，对于看板相信大家都比较熟悉，在此就不赘述，对于 Erda 晨会还是想罗列几点供大家参考讨论：

• 晨会以完全的产品团队为单位 （包含 pd，开发，测试等完整关键角色）；
• 晨会主题始终围绕 “发布班车，能否正常上车，哪些内容会 delay 到下一班车”展开；
• 晨会一起关注燃尽图和甘特图的 deadline；
• 时间控制在 10 - 15分钟，主题不能过度发散。

结束语

正如开始所说，高效协同是一个永恒的话题，大家对于高效协同的目标也一定会伴随科技和文明的发展而有更高的追求，效率问题也一定会有一些创新的思维和方法来解决，比如 github 把五湖四海的研发兄弟姐妹汇聚在一个开源项目上进行协作开发，slack 让大家的异步沟通协作变得更轻松，等等。这些产品和大家正在创造新协作产品，肯定会让软件研发行业的远程异地协作模式变得越来普及和简单！最后欢迎对此有兴趣的小伙伴和我们一起来探讨～