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

duck

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

我们先从一个需求变更说起吧，如果你的客户想改一个字，那么你的应对方法是怎样的呢？
7 G* Z2 N9 K: m. g" i1 ?8 N
- ~# a/ E" {. b  q6 {7 E0 S直接走到开发的面前让他改了，因为这是“顺手”的事。
告知需求方需求变更的成本（改需求文档、配置文件、测试用例、用户手册等）和风险（因为工作量的变化影响交付时间），让需求方知难而退或者转化为自己的谈判筹码。
放入需求池，设置优先级，尽量安排到下个迭代。

: ]1 k$ e, k$ Y  S* `第一种方法的破坏性极大，看似我们在个例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破坏了流程，破坏了团队的工作流。研发的流程不是为了限制创造力，而是为了保护创造力。如果缺少流程的保护，那么产研体系的员工就会在各类突发性工作中东奔西走，导致团队无法制定有效的工作计划，也无法准确的预估结果，更没有一种稳定的交付能力。
$ E' |; N0 ^: E  ^; j
第二种方法因为有严格的风险把控和时间节点要求，因此往往能够履行交付承诺。但是它对于变化的响应能力太差，往往变更都要经历复杂的流程，而且经常性的牵一发而动全身。对于需要根据市场反应及时调整策略的互联网产品来说，这样的开发方式实在是跟不上节奏。

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

! w$ o- n# p) \工作流管道

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


有了这样的工作流管道，我们的产品它要么是正在部署，要么就是准备部署。那么我们的产品对外提供的服务是什么样的呢？用一句话形容就是：用户每一次体验到的都是更好的服务。这句话有点太夸张了，不过这样的工作流是存在的，并且早已应用于领先的互联网公司中。

关于工作流的搭建和进化之道，我在年初七牛云主办的ECUG For Feature中有一个主题为“基于Scrum+XP+DevOps的工程化实践”的分享，今天为了回馈公众号的朋友们的持续关注，PDF放在原文链接里了，谢谢大家。
) n# A( }- A* k  B/ p
7 G+ A3 A' w* z+ B' n研发管理如何理

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

! z9 [) W: G  N7 Z1 e" y0 d9 x, Y一、让无形的工作显现出来
6 U! X0 u0 ]+ [3 Q" O$ h
6 o2 f2 O2 L. ], B* S4 L经常接触开发工程师的人都知道，如果不借助外部工具，真实的进度只有写代码的那个人才知道。对于管理者来说，通过流程和工具将无形的工作显示出来非常重要，因为工作流的可视化是基础，当一切暴露在阳光下，管理者才知道如何“管”。
; p+ ?: [' }; j! K

（截图来自Worktile研发版）

我的研发团队使用的管理工具是Worktile，我会要求所有的工作必须有一个工作项卡片进行跟踪，而所有人都需要及时的领取任务、拖拽卡片、更改状态、拆分子任务、关联代码、关联构建、提供验收说明等等，通过这些“习惯性动作”让工作进度显现出来。
' I8 }7 P( {5 z# H9 }5 p. \( _
- q" I' i. x) O* x( D二、定义完成的定义，配合拉动策略，让工作“流动”起来

/ c4 W8 D7 t% k1 k0 \! o! ~* y根据DevOps的第一工作法，我们要建立一个从左到右的工作流，这个工作流的每个阶段都要有清晰的输入和输出，然后通过标准化的输入和输出，将它们组装成一个顺畅的工作流管道。工作流梳理完成后，我们通过拉动策略让工作进行“流动”。例如：当我完成一件工作时（一定要符合我和下游约定的完成的定义），我的下游可以将这个工作拉过去继续做，而我则可以在我的上游拉另一件工作继续做。对于“我”个人而言，只要“我”现在空闲，同时看到上游有一件工作标记为完成，那么“我”就拉过来继续做，然后将它标记为完成，每个阶段的“我”使用同样的工作策略，这些“我”让工作持续的流动。
% I" S' Z1 m/ G; V! {4 X; s

三、引入自动化，让速度和质量并存，摸索适合自己的持续交付方案
" [( w: p+ u* j
当我们开始运转工作流的时候就会发现，有些高度重复化的工作非常的占用人力资源，比如工程师修改了代码之后有可能影响任何一个功能，那么回归测试就有其必要性，但是每次变更都需要人工来回归吗？要知道回归一次的时间是非常长的，但是不测试又无法保障质量（积累多次变更后统一回归，并不符合我们建立上述工作流的初衷）。这时引入自动化是最好的选择，我相信朋友们对于CI/CD、流水线这些词汇并不陌生，但是很多人并没有创建和维护好自己的自动化脚本，这个我打算下一期专门讲一讲如何让研发和测试这两个角色合二为一，有效的落地一套面向研发过程的测试方案。
' }. N6 Z- q% {; M& I3 @, j
% A' d: M9 ]7 P' c  b$ }; I四、Being agile，适应变化，不断优化工作流
- ~# B: Y% o0 K2 c. F. U
敏捷开发最重要的还是价值观，是内功，而无论是Scrum还是Kanban，归根到底是通过行为约束让使用者在不知道法门的情况下也能成为高手。我认为无论是团队级别实施敏捷，开始企业级转型敏捷，更关注的应该是发展，一种面对变化能够从心态和行动都及时进行调整的能力。

真正落实到日常工作中，就是让所有人主动领取和负责工作，当目标没有完成时是全部人的责任，而不是部分人的责任。让所有人参与到工作流的改进中，在一个周期内加入20%的非功能性需求，尽情的去优化自动化，去调整系统结构，去创造去发展。

五、建立包容的文化，让问题暴露出来，促进企业进化

% F1 W0 H; W; h7 K% g7 E很多人一看到文化，第一反应是这个有点虚，但是职位越高，越能真切的体会到文化的重要性，人少的时候很多事当面说就好了，但是人多的时候，我们需要通过文化作为载体传达我们的行事原则。因为篇幅的问题，今天我不想分享的太大，我只说两个在团队级别就能落实并且十分有效的方法：周期性全员回顾和月度1v1。
! G; @/ N2 F5 H- |! P
周期性回顾其实就是Scrum里的Sprint Retrorespective，所有人在一起提出我们流程上的问题，我们一起制定改进计划，并在未来的回顾中验证计划是否奏效。回顾是团队自我改进最有效的方式，也是让团队成员把“怨念”释放出来的机会，一个能够自我优化的团队一定少不了类似的会议。月度1v1是我在外企学来的经验，那时候我通过1v1向我的老板表达我的想法，后来我也一直通过它管理我的团队。我在1v1上讨论近期的工作、讨论工作流程、讨论成长方向，我有时扮演导师、有时扮演倾听者、有时扮演鼓励师，我通过1v1了解我的团队，也将他们真切的想法反馈给我的老板。

) J( W% E3 d- p# O写到最后

掌握了这五点核心原则，基本上就能把研发团队“打理”的清清楚楚。这些年我养成了一个习惯，一旦出现问题我的第一反应是看一看是不是流程的问题。我会更加关注如何避免未来出现类似的问题，关注团队的成长。虽然人与人有能力的差距，但是故意破坏规矩的人我还是很少见到的，为所有人建立一个正确的轨道，这便是我说的“理”，也是我今天想分享的最核心的东西。

  q3 a8 v; D  _) f1 r/ t2 W

turth

第一种方法的破坏性极大，看似我们在个例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破坏了流程，破坏了团队的工作流。研发的流程不是为了限制创造力，而是为了保护创造力。如果缺少流程的保护，那么产研体系的员工就会在各类突发性工作中东奔西走，导致团队无法制定有效的工作计划，也无法准确的预估结果，更没有一种稳定的交付能力。