都问研发管理如何管，我想谈一谈研发管理如何理

Worktile

+ 关注

2022-01-17 10:15

599次阅读

这两个月一直全身心的投入到公司的产品研发中，始终没有安静下来写点东西，前几天应邀在线上进行了一场研发管理主题的分享，效果还不错，收到很多朋友的消息。我觉得这个话题可以更深入一些，索性写一篇文章吧。

01“我想改一个字”

我们先从一个需求变更说起，如果客户想改一个字，那么你的应对方法是怎样的呢？

1、直接走到开发的面前让他改了，因为这是“顺手”的事。

2、告知需求方需求变更的成本（改需求文档、配置文件、测试用例、用户手册等）和风险（因为工作量的变化影响交付时间），让需求方知难而退或者转化为自己的谈判筹码。

3、放入需求池，设置优先级，尽量安排到下个迭代。

第一种方法的破坏性极大，看似我们在个例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破坏了流程，破坏了团队的工作流。研发的流程不是为了限制创造力，而是为了保护创造力。

如果缺少流程的保护，那么产研体系的员工就会在各类突发性工作中东奔西走，导致团队无法制定有效的工作计划，也无法准确的预估结果，更没有一种稳定的交付能力。

第二种方法因为有严格的风险把控和时间节点要求，因此往往能够履行交付承诺。但是它对于变化的响应能力太差，往往变更都要经历复杂的流程，而且经常性的牵一发而动全身。对于需要根据市场反应及时调整策略的互联网产品来说，这样的开发方式实在是跟不上节奏。

第三种方法有较强的节奏感，周期性的完成一个产品增量，它比第二种方式灵活，也不会像第一种那么冒进。不过这样就够了吗？

02 工作流管道

设想我们有这样一个管道，当新的需求来的时候，可以将它们引入管道中，它们像水一样流动到生产环境，在这个过程中流动是快速的、单向的、稳定的、持续的、高质量的，最终它们在用户无感知的情况下生效。我们可以扩大管道的直径从而实现量化，也可以分割产品建立多条相似的工作流管道。

有了这样的工作流管道，我们的产品它要么是正在部署，要么就是准备部署。那么我们的产品对外提供的服务是什么样的呢？

用一句话形容就是：用户每一次体验到的都是更好的服务。这句话有点太夸张了，不过这样的工作流是存在的，并且早已应用于领先的互联网公司中。

03 研发管理如何理

搭建和优化工作流的过程其实就是“理”的过程，这里我总结有五点核心原则：

让无形的工作显现出来

经常接触开发工程师的人都知道，如果不借助外部工具，真实的进度只有写代码的那个人才知道。对于管理者来说，通过流程和工具将无形的工作显示出来非常重要，因为工作流的可视化是基础，当一切暴露在阳光下，管理者才知道如何“管”。

我的研发团队使用的管理工具是PingCode，我会要求所有的工作必须有一个工作项卡片进行跟踪，而所有人都需要及时的领取任务、拖拽卡片、更改状态、拆分子任务、关联代码、关联构建、提供验收说明等等，通过这些“习惯性动作”让工作进度显现出来。

定义完成的定义，配合拉动策略，让工作“流动”起来

根据DevOps的第一工作法，我们要建立一个从左到右的工作流，这个工作流的每个阶段都要有清晰的输入和输出，然后通过标准化的输入和输出，将它们组装成一个顺畅的工作流管道。工作流梳理完成后，我们通过拉动策略让工作进行“流动”。

例如：当我完成一件工作时（一定要符合我和下游约定的完成的定义），我的下游可以将这个工作拉过去继续做，而我则可以在我的上游拉另一件工作继续做。对于“我”个人而言，只要“我”现在空闲，同时看到上游有一件工作标记为完成，那么“我”就拉过来继续做，然后将它标记为完成，每个阶段的“我”使用同样的工作策略，这些“我”让工作持续的流动。

引入自动化，让速度和质量并存，摸索适合自己的持续交付方案

当我们开始运转工作流的时候就会发现，有些高度重复化的工作非常的占用人力资源，比如工程师修改了代码之后有可能影响任何一个功能，那么回归测试就有其必要性，但是每次变更都需要人工来回归吗？

要知道回归一次的时间是非常长的，但是不测试又无法保障质量（积累多次变更后统一回归，并不符合我们建立上述工作流的初衷）。这时引入自动化是最好的选择，我相信朋友们对于CI/CD、流水线这些词汇并不陌生，但是很多人并没有创建和维护好自己的自动化脚本，这个我打算下一期专门讲一讲如何让研发和测试这两个角色合二为一，有效的落地一套面向研发过程的测试方案。