在家办公是软件研发组织的“敏捷试金石”之沟通篇

前言

最近“新型冠状病毒（2019-nCoV）”汹汹来袭，一时间“在家办公（Working From Home，简称 WFH）”成了一个非常现实和火热的话题。我心想着：“这时候理应有篇写在家办公的文章”，但是又一想：“想必一定有很多人写”，所以一直没动笔。

结果呢，各种渠道和平台的在家办公类文章铺天盖地，无奈的是，里面大量的都是在卖自家产品，没几个在认真说在家办公的挑战和问题的。似乎买了某家的在线协作平台产品，就能真正实现在家办公了一样——如果真的靠买产品就能实现在家办公，那岂不是绝大多数的软件研发团队平时都应该在家办公吗？为啥还要天天车马劳顿的赶去公司上班？

这次突如其来的疫情所带来的在家办公一事，更像是一次针对软件研发组织敏捷程度的“国考”。在家穿着睡衣披头散发的办公，还都只是大家呵呵一笑找点乐子，但是如果长时间下去，还有多少软件研发组织能够笑到最后呢？

在 IT 行业，在家办公一直是一个非常火热的话题。我在加入 ThoughtWorks 之前，有过半年时间的在家办公尝试。在加入 ThoughtWorks 之后，在做培训、做开发、做咨询的过程中，阴差阳错的竟然实现了相当时间比例的在家办公。在我看来：

以绝大多数软件研发组织的敏捷实践水平之低，还谈不上如何在家办公。

从这篇文章开始，我将围绕制约在家办公的一些关键挑战，以多篇文章（每篇关注一个维度的方式）来谈一谈为什么在家办公是软件研发组织的“敏捷试金石”。

本篇，我们优先说一说：沟通成本。

沟通成本带来的挑战

在众多制约在家办公的挑战中，沟通成本是首当其冲的，很多人第一个反应就是：“都不在办公室了我咋沟通啊？”当然这也是众多在线协作产品的核心服务之一。

当然，这也是“就算是买了在线协作产品也用不好”的关键方面之一。正所谓“治标不治本”。并不是说你有个在线视频会议软件，你就可以在家办公了。影响团队沟通成本的主要因素有很多，我们很难全部都讲一遍，在这里我主要基于我在咨询过程中的观察，讲一讲我所认为非常重要的几个“本”：

• 团队规模

• 会议种类

• 可视化程度

团队规模

团队规模越大，沟通成本越高。

我曾经在 20 个人左右的开发团队从事过开发工作，在从事咨询的工作中也看到过客户存在接近 30 人左右的开发团队（嗯，没错，20-30 人共同开发一个产品模块）。在这种规模的团队中，沟通成本简直难以忍受，每天要么需要通过各种会来沟通和对齐工作，要么当出现一个问题之后，需要四处找人寻找问题发生的原因。而当团队转入在家办公之后，由于缺少了办公室里“吼一声”就能解决的便利，最直接的，就是每天会被各种即时通讯软件的提醒和视频会议的提醒淹没……

在客户现场，我亲眼看到过和我结对编程的客户方开发人员，每天平均只有 1 个小时能够安静的坐在那里和我一起写写代码，其他时间他要么在开会，要么就是在去开会的路上。那什么时候他才能专心的写代码呢？答案很简单：晚上啊！996 求福报，很多人只能利用晚上加班这个大家已经疲惫开不动会的时间来写写代码。对于这样的团队来说，在家办公简直是不可接受的，于是就有这样的疑惑：“在家办公怎么能解决好团队沟通的问题？”

而从敏捷的视角出发，我们首先应该做的，就是通过约束团队的规模，来从根本上降低沟通成本。

我相信很多人都听说过亚马逊 CEO 贝索斯所提倡的“2 Pizza Team”这个概念，也就是一个团队适合的规模，应当在 2 个披萨刚好够吃的人数范围内（嗯……然而我一直不知道这个里面对于披萨尺寸和饭量的约束……手动滑稽……）。

很多人都只记住了“2 Pizza Team”的结论，就是要小，大概在 6-10 人左右（Scrum 提倡开发团队规模应当控制在 9 个人左右），但是却忽略了其中的一个非常重要的计算公式，就是（其中 N 代表人数）：

人与人之间的沟通管道数量 = N(N-1) / 2

如果以图来举例（图片来自于https://www.calcey.com/blog/why-the-two-pizza-team-rule-is-the-name-game-at-calcey），就是：

人员沟通管道关系图

让我们举例来说：

• 一个 7 个人的团队，会有 21 个沟通管道；

• 一个 12 个人的团队，会有 66 个沟通管道；

• 一个 20 个人的团队，会有 190 个沟通管道；

• 一个 30 个人的团队，会有 435 个沟通管道；

• ……

所以，如果一个软件研发组织，不能基于“特性团队（Feature Team）”，或者不能依据“逆康威定律（组织适配架构）”和“领域驱动设计（DDD）”思想来划分和组件小团队，怎么能防止在家办公不会加剧提升沟通成本？

会议种类

会议种类越多，时间越长，沟通成本越高。

在团队足够小之后，会不会开会，则成了影响在家办公沟通成本的下一个关键因素。

在当下，随着 Scrum 等敏捷方法论已经在中国推广了快 20 年，很多软件研发组织都已经在实践“敏捷”方法论了，为什么我要把“敏捷”打上引号呢？是因为这里面有很多的“伪敏捷”，这里就拿火遍天南地北的 Scrum 来说。

Scrum Framework

几乎所有实践过 Scrum 的团队都知道有个“每日 Scrum（Daily Scrum）”，很多人都习惯叫“站会（Stand-up Meeting）”因为站会在很多的敏捷方法论中都存在，只是具体内容可能有所不同。

在 Scrum 中，对于这个会议的时长要求，是每天不超过 15 分钟，平均每人发言在 1-2 分钟，而每个人在会议上所讲述的内容则聚焦在三个问题:

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？

• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？

• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

那如果是在 Kanban 中，则每个人的发言内容则是：

• 有哪些障碍阻碍了我的价值流动？

• （看板从左至右）当前的流动情况如何？

但不论是哪种方法，对于 15 分钟的时间控制，平均 1-2 分钟的每人发言时间，以及对发言内容的聚焦和约束，都是不同敏捷方法论中对于站会的相同要求。

但是在实际中，我亲眼看到过以下几种令人“印（dang）象（chang）深（pen）刻（fan）”的在某个号称是 Scrum Master 的人带领下的站会：

团队 A：十几个人围绕电子看板站成了一个圈（嗯，姿势正确……），然后每个人走到电子看板前（嗯，没什么毛病……），然后和项目负责人窃窃私语，其他人则发呆（噗……你等会儿……）……

团队 B：七八个人站在白板前（嗯？等下，板上咋啥都没有？），然后每个人开始长篇大论（噗……你等会儿……），以及各种艰难问题的探讨和扯皮（唉……喊不住……），最后每天站会在一个多小时的时间结束……

要不是我亲眼所见（以至于屡见不鲜），我真的不能理解，为什么一个简单的站会要求，最后能被执行成各种五花八门的方式。

嗯，好吧，那么如果是这样子的团队，变成在家办公会是什么样子呢？脑补一下：

一群人，在冷冷的屏幕后方，穿着各类服饰，披头散发，不修边幅，以各种姿势，刷着网页，会议语音中的各种内容从左耳朵进右耳朵出……（那句话咋说来着？坐姿嚣张，工作不慌？）

当然了，可能会有人说可以开视频，可是，你面对面站着都能发呆开视频有个毛线的用……

综上，可见虽然有团队号称是“敏捷团队”，但是实际中真的是花样百出的“伪敏捷”。而提升会议效率，降低会议对于沟通成本和研发效能的障碍，是所有敏捷方法所强调的重点（当然也是最容易被忽视的重点）。

我们说“个体和互动胜于流程和工具”，其实某个方面就是在强调，在合理的团队规模下（别忘了前面讲的小团队和沟通管道数量计算），应该充分的发挥个体间的交流来解决问题，而不是依靠开例会的方式。那么当处于在家办公的情况下，我们完全可以按照每日站会的要求，围绕电子看板，在 15 分钟内开完站会，然后利用 Slack 等交流工具，由问题的相关方去单独解决。（现实中我们也是强调会后由问题的相关人员去单聊）

所以，如果一个研发组织，连最起码的敏捷类例会都开不好，怎么能防止在家办公不会加剧提升沟通成本？

可视化程度

工作的可视化程度越低，沟通成本越高。

正所谓，工作中最害怕的事情，就是“你在那里天天加班到天亮，然而我却不知道你在干什么”……

原先呢，很多软件研发组织，都是希望以各种会议，来拉通和对齐每个人的工作内容和进度，但是呢，君不见一个人做一个需求，一做就是一周多不见合并代码的……

再加上平时也不做每日代码检视（Code Review），也没做好前面所说的每日站会，所以在做咨询的过程中，看到的绝大多数软件研发组织，都是普遍缺乏工作透明度的。

一旦缺乏了工作透明度，那么各种偷奸耍滑，以偷懒和加班表达自己很努力很用功的方式就成了相当一部分人应对工作的日常操作（反正需求天天加班都做不完，那我为什么要做那么快嘛……）。

而到了在家办公的时候，那……岂不是就更开心了！！！之前在办公室，总还是抬头不见低头见，哪怕坐在格子间。现在可好了，我在我家我是爷，你管我咋工作？

而应对这种问题的方式也非常简单，就是：赶紧把工作透明出来，赶紧把有效可视化看板建起来。

有了可视化的看板（不管是物理板还是电子板），我们就能围绕可视化的看板来跟踪每个人的工作进度（至于怎么做才对，留待后面的文章去讲），也就能让我们前面说的每日站会有了可视化的依据。

PS：这里面需要特别注意的是，看板一词是有二义性的，在英文中， kanban指的是可见的卡片，而大写开头的 Kanban则指的是“看板方法”，而在日常沟通中，当我们说到“看板”的时候，绝大多数指的是可视化的卡片系统，而“看板方法”则指的是以精益思想为基础的方法论。

看板方法的拉动式看板

在办公室内，我们一般提倡同时维护物理看板和电子看板，这样的好处是，物理看板大家抬头就能看到，可以在平时路过的时候就关注一眼当前的工作情况，而电子看板的优势是可供记录、追溯和分析计算。

那么当在家办公的时候，遇到的很麻烦的情况是缺失物理看板，而并不是每个人都有多个显示器，拿其中一个来展示电子看板，因为操作系统窗口切换很麻烦，很容易造成大家忽略了对于工作进度的关注。那么这时候的解决办法，是可以将电子看板和我们的即时消息通讯工具（例如 Slack）集成起来，设置通知的规则，当电子看板进行更新的时候，能够依据策略通知相关的人员，以便提醒关注。或者，还可以通过在当日的某个时刻，增加一次快速的看板检视会议的方式，来让全体人员关注整体的项目进度和每个人的工作情况。

建立可视化的看板，是最为快速有效的增加工作透明度的方式。除此之外，还可以坚持每日的远程代码检视来补充解决这个问题；以及充分发挥持续集成流水线，集成更多的可视化工具来进一步增强工作的透明度。

所以，如果一个研发组织，连最起码的工作可视化都做不好，怎么能防止在家办公不会加剧提升沟通成本？

后话

由于篇幅原因，我们无法对影响在家办公沟通成本的全部挑战进行一一讲解，我只是找出了我所认为的最关键的三个重点关注的内容进行了介绍。

还是那句话：

以绝大多数软件研发组织的敏捷实践水平之低，还谈不上如何在家办公。

希望本文能为众多因为“被在家办公”搞得鸡飞狗跳的软件研发组织提供一些参考和帮助。

作者介绍：

胡皓，ThoughtWorks 首席咨询师。十年以上软件开发工作经验。从士兵成长起来的软件技术顾问，从事过广泛的业务分析，项目管理，全栈软件开发、培训和技术咨询等工作。当前，作为 ThoughtWorks 中国区咨询 BU 数字化架构能力团队的负责人，正深耕于以演进式架构、领域驱动设计、云原生微服务为代表的数字化架构能力，帮助客户实现软件工程能力提升和数字化转型的目标。

本文转载自公众号枪炮与代码（ID：guns_n_code）。

原文链接：

https://mp.weixin.qq.com/s/6bKNANEz9k4qBmLDh-kpTg