【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2020-02-09
  • 本文字数:4548 字

    阅读完需:约 15 分钟

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

前言

最近“新型冠状病毒(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


2020-02-09 10:002370

评论

发布
暂无评论
发现更多内容

阿里中间件团队技术官手撸笔记,全新演绎“Kafka部署实战”,已开源

Java架构之路

Java 程序员 架构 面试 编程语言

一道好题!我觉得面试如果考察「双指针」的话,这题是刚刚好 ...

宫水三叶的刷题日记

面试 LeetCode 数据结构与算法

Elasticsearch 查询结果排序

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

简单的网站搭建

很甜回忆

网站

构建“金融+司法”新局面:兴业消费金融区块链电子存证系统正式上线

CECBC

金融

【2021海量真实校招】软件测试面试真题,(大数据整理)刷完应对各家企业面试完全没有问题!

程序员阿沐

面试 软件测试 自动化测试 黑盒测试 白盒测试

优雅编程 | javascript代码优化的4个小技巧

devpoint

递归 命名空间 闭包 函数绑定

牛掰!面试不再慌,苦刷这份2020最全的“基础-中级-高级”面试题库,已涨17k

Java架构之路

Java 程序员 架构 面试 编程语言

区块链电子合同存证,电子合同区块链服务平台

13530558032

一口气发布十大建网利器,华为打算煲出怎样的5G味道?

脑极体

科大讯飞发布全新一代智能办公本X2

Lucien

Android NativeCrash 捕获与解析

vivo互联网技术

c++ android NativeCrash

小程序开发-云开发技术总结

我是哪吒

小程序 程序员 大前端 28天写作 2月春节不断更

runtime笔记

Conan

ios

Linux入门篇 —— Shell详解

若尘

Linux 命令行 linux操作

解读云原生技术

xcbeyond

Kubernetes 云原生 服务网格 28天写作

性能优化知多少

圣杰

sql 性能优化 dotnet

深度丨从货币历史看比特币的诞生

CECBC

比特币

Selenium 利用 JS/JQ 操作元素、鼠标键盘事件、Cookie 操作

梦想橡皮擦

Python 28天写作 2月春节不断更 selenium

关于央行数字货币若干问题的思考 | 比较

CECBC

数字货币

诊所数字化:患者数字档案的价值机遇和风险

boshi

数字化医疗 七日更 28天写作

字节跳动面试官这样问消息队列:高可用、不重复消费、可靠传输、顺序消费、消息堆积,我整理了下

冰河

面试 分布式 中间件 消息队列 一起进大厂

风口上的量子计算机:核聚变一样的赌局,钻石一样的骗局

脑极体

Kalm——基于Kubernetes的部署工具

David

开源 Kubernetes DevOps 运维 运维平台

javascript中的内置对象和数据结构

程序那些事

JavaScript 数据结构 ES6 程序那些事

最新大厂Java面试题库,测试一下你能坚持到哪一面 “美团+字节+腾讯”三面技术问题

Java架构之路

Java 程序员 架构 面试 编程语言

热点浅谈:低代码开发平台发展前景与市场规模!

优秀

低代码 低代码开发 低代码开发平台

【计算机内功修炼】十:线程间到底共享了哪些进程资源

码农的荒岛求生

c c++ 线程 操作系统 进程

火山翻译:工业级应用与研究

DataFunTalk

基于grpc手撸一个RPC框架

cloudcoder

阿里粗排技术体系与最新进展

DataFunTalk

在家办公是软件研发组织的“敏捷试金石”之沟通篇_研发效能_胡皓_InfoQ精选文章