【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

红帽峰会 2018 第二天:“人”的改变

  • 2018-05-10
  • 本文字数:4035 字

    阅读完需:约 13 分钟

2018 年 5 月 9 日,美国旧金山,第十四届红帽峰会第二天。以下是 InfoQ 中文站记者从一线发回的报道。

往年的红帽峰会,红帽 CEO Jim Whitehurst 的主题演讲都有一个特点:他会在历史上找出一段可以代表“开放”精神的小故事拿到台上分享。比如,他在 2017 年讲了一个本田公司的轻便摩托车在 20 世纪中期入主美国市场并大获全胜的故事。

今年,Jim Whitehurst 没有再讲历史小故事了。他今年的做法是:在主题演讲之前发布了一篇新的博客,在现场简单的介绍了一下博客当中的观点,然后把现场的时间都交给了红帽的客户们。

这篇博客的标题叫做: Rethinking how we work in an era of disruption 。翻译过来就是:对我们在这个变革时代将要如何工作的重新思考。文章大意摘录如下:

Rethinking how we work in an era of disruption

两年前的红帽峰会,我谈论了“参与的力量”这个话题。

去年的红帽峰会,我谈论了“个体的影响力”这个话题。开源的参与并非被动,而是主动。每一个个体都不是旁观者,而是发起人。由于数字转型的广泛影响,传统意义上的计划(planning)已死。任何组织不可能再依靠“五年计划”这样的东西,因为世界变化太快。取而代之的,是伟大的组织创造好的环境,让每一个有才能的个体都能在这个环境当中发挥他们最大的才能、交付最好的成果。

我们正处于一个新的转折点。我每天与世界各地的高管们对话,他们都在面临相似的问题。我越来越发现,我们当前的工作方式是不够好的。它们需要的不是一点点的修订,而是彻底的革命。

在快速变化的世界当中,我们越来越无知。我们如何在大规模的体量下保持高速发展,并且去恰当的处理我们尚且不知道前方是什么的挑战?这个问题的答案不存在于任何已知的解决方案当中,你不可能仅仅通过花钱就能买到它们。这不仅仅是一个技术问题。我们必须鼓励人们用不同的方式思考。但是,我们该从哪里改变?

对“组织架构”的重新思考

今天常见的组织架构是针对 19、20 世纪的工业生产而设计的,它们专门针对它们的生产环境而设计——组织知道自己的目标,它为此制定一个计划并且高效的实现该计划。

但是在一个充满未知的世界中,一切的预测与定义的尝试都开始变得无力。问题的改变,需要答案的改变。今天的世界与工业时代的世界已经是两个不同的世界。

本次革命并非仅仅是自动化的故事。自动化改变的是我们工作的流程,但是我们今天的故事是有关“人”的改变。

“配置”(Configuring for change)

根据红帽在开源方面的经验,组织改变的关键在于“从下至上”:让组织内部的个体能够以新的方式去主动思考、主动作为。整个文化的关键在于“拥抱无限的可能性”,拥抱一切值得去探索的创意——“Ideas worth exploring”,同时又不会牺牲速度、性能和安全性。

相比传统企业,开源社区在过去的十几年间是基于如下三大支柱而运作的:

1、“配置”(configuring),而非“计划”(planning)。组织内部的行动以“实验”和“学习”为主,而非针对某个特定目标的计划。组织架构的设计更多专注于模块化,而非专注于整体效率。

2、“赋能”(enablement),而非“规定”(prescription)。组织的决策主要在一线人员处进行,而非是某些“高层”处进行;组织的管理工作致力于将这些一线决策者所需要的资源与信息导向他们,而非是传递某些“高层”的指令。

3、“志愿”(engagement),而非“执行”(execution)。组织成员的角色由他们自己定义,而非通过某些复杂的模型来定义。组织知道“微管理”是行不通的。组织通过“鼓励正确的行为”来实现相关目标。组织无法再去关注每一个“合作”是如何进行的,但是对于合作实现共同目标的团队与个体之间的“相互定位”是组织所关注的。

回头来说,组织架构的运作并不存在好 / 坏或者对 / 错这样的事情,重点在于我们永远可以找到更好的方式来优化一个组织架构。关键在于,我们如何“定义”我们的组织架构如何被“配置”。最后,所谓的“组织文化”是一个“输出”而非“输入”。我们可以观察一个“文化”是如何生成的,但我们不能为组织事先“定义”一个文化。

文化的改变是困难的。一个领袖必须有开放的心态,才有可能实现文化的改变。

埋下变化的种子

财富 100 强企业的 CEO 们将这一系列变化形容为“自我的转型”。一个新世界的领袖为他的人才所做的事情,有点像是种地:

你关注的是为你的植物创建合适的生长环境。你的种子要种在合适的土壤里。你无法命令你的植物生长,或者命令你的植物不要生病。你不可能指望一颗仙人掌在雨林生长的很好,或者指望一颗番茄在沙漠里生长的很好。

你需要做的,是根据你的植物的天性为它们提供尽可能好的环境。如此,无论外在的世界如何剧变,植物们仍然有更大的可能性结出好的果实:)

(摘抄结束)

针对 Jim Whitehurst 在上面分享的思考,笔者希望分享自己所看到的、红帽在上述方面所做的三个尝试的最新进展:

1、CTO 办公室的新技术研究小组 / 新市场研究小组

CTO 办公室是一套从五、六年前开始运作的机制,现任红帽 CTO Chris Wright 从三年多前接手这套体系。该组织重点关注业界一些新生技术与新生市场,在它们尚未成熟之前进行相对轻量级的关注与参与。

五六年以来,已经有相当数量的技术从 CTO 办公室“毕业”成为红帽产品线的一员,目前红帽最重要的产品之一 OpenShift 最早也是在 CTO 办公室“孵化”出来成为产品(当时还没有 Kubernetes 这个方向。OpenShift 最早用的是红帽自研的 Gears/Cartridges 体系,后来是到 2014 年才全面往 Kubernetes 方向转变,重写了几乎所有的代码)。

当前在 CTO 办公室的两个代表性“新技术”分别是区块链与 Serverless(Cloud Functions)。其中,基于 Apache OpenWhisk 的 OpenShift Cloud Functions 已经进入开发者预览版阶段,看起来有可能在数年后转化为一个新的企业级产品。区块链工作小组目前主要是与 BlockApps 公司有一些合作,也在密切关注 Hyperledger 等上游项目。

2、开放创新实验室 Open Innovation Labs(OIL)

红帽的开放创新实验室创建于 2016 年,可以简单理解为红帽在“企业咨询”方面的尝试,只是这个“咨询”不是针对某个具体的业务需求的咨询,而是红帽的工程师们将自己在开源运作方面的经验结晶出来,形成一套协助其他企业 / 组织架构进行“组织优化 / 变革”工作的体系。

换句话说,OIL 的目标是协助“客户”一起将其团队的“文化”改造成更加适合创新的模式,但是并非通过直接改造“文化”的方式来进行。按照 Jim Whitehurst 的话来说,文化是“输出”而非“输入”,尝试直接改变文化只能以失败告终。OIL 会针对对方的情况设计“流程产品”,比如按照 devops 的思路或者敏捷开发的思路,但是重点在于对方最终能够掌握这套工具的使用方式,乃至于没有这套工具也能够按照新的方式去运作,这是 OIL 的真正目标。

所以 OIL 具体是如何操作的呢?以下举例说明。 OIL 刚刚与联合国儿童基金会(UNICEF)合作完成了一个项目,项目为期 2 个月,合作方式如下:

  1. 双方找一个一起居住 + 封闭办公的场所,这个地方不是红帽的也不是 UNICEF 的。OIL 在这个项目参与大约 2-3 人规模,UNICEF 方面也不是一个很大的团队。之所以要寻找一个中立的场所,是为了避免人在公司总是要开会这样的干扰因素。
  2. 双方进行“探索集会”(discovery session),寻找项目的“关键使命”(driving mission)。
  3. 为期一周的“设计周”,制定目标,确认在有限的时间、有限的资源下,如何以“周”为单位交付价值。
  4. OIL 的工作重点在于,确保自己交付的产品是“可用”(workable)的。
  5. 大量的节点检查、采访调研,探索团队获取他们所需信息的合适方式。
  6. 每一次出产品原型,OIL 都会向 UNICEF 成员面对面展示原型,双方进行讨论。
  7. Demo Day:由 UNICEF 的成员独立进行产品展示,最理想的情况是:这个展示不需要依赖 OIL 成员的干预。

这样一个合作模式是 OIL 探索了两年半之后的一个阶段性成果。此前,OIL 试过 4 个星期的周期,其结论是:4 个星期做个实验还可以,但是想要改变一个组织的习惯,至少需要 6-8 个星期,否则的话,就算有了新工具也只会被束之高阁。

UNICEF 方面对这次合作表示是满意的,项目期建立的工作习惯目前仍在延续,工具仍在使用。

3、Co.Lab

第二天下午的主题演讲,有这样一群十几岁的中学生们上台分享:

笔者这两天跟一位老 Fedora 开发者谈起一个话题:在十几年前,Fedora 是当时非常酷的东西,年青人愿意去玩这个东西,在上面开发一些好玩的小应用,Fedora 社区也因为他们的加入而蓬勃发展。但是现在,Fedora 已经变成老古董了,如何能让年青人对这个东西感兴趣呢?还是说,Fedora 还值得年青人们去感兴趣吗?如果一直没有年青人对 Fedora 感兴趣,那么 Fedora 的未来要怎么办呢?

老 Fedora 说:年青人始终会为“我能做些什么”这件事情感兴趣。他们发现,当他们把 Fedora 与开源硬件结合做成一个教学平台的时候,那些孩子们对这件事情是感兴趣的,这让他们觉得“我可以让这个东西变得更好”。

他说的这个教学平台长这样:

这就是 Co.Lab 做的事情:让更多的女中学生接触开源技术、喜欢开源技术并因此进入开源技术的世界。

Co.Lab 是红帽开源故事汇(Open Source Stories)项目下的一个衍生项目。Open Source Stories 是一个很难描述清楚的项目,笔者一开始听说这个项目时,还以为他们的工作是拍摄纪录片;后来才知道,原来拍摄纪录片只是该项目的一个阶段性成果展现方式。

简而言之,Open Source Stories 项目的宗旨是在软件产业之外——乃至科技产业之外的领域——发现“开源”可以在其中发挥作用的故事,并探索红帽能在其中做些什么。目前,红帽已经探索了科研、设计、教育、交通、博物馆、医疗、农业等多个领域,拍摄了约七、八集纪录片并撰写了两篇“论文”(如果那可以算是论文的话)。

总的来说,还是非常有意思也很有价值的一些尝试!

相关阅读

2018-05-10 19:211358

评论

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

HarmonyOS 2正式发布 硬件生态品牌HarmonyOS Connect一同亮相

科技汇

分治(详解残缺棋盘 —— Java代码实现)

若尘

算法 分治 java代码 6月日更

“扯皮”终结者,区块链帮农民工计薪水

CECBC

Redis数据结构

邱学喆

数据库 redis 跳跃表

面试系列-3 限流场景实践

李阿柯

php lua redis 面试 限流算法

【Vue2.x 源码学习】第二篇 - Vue的初始化流程

Brave

源码 vue2 6月日更

ARTS- 日常打卡5

pjw

致恰达耶夫,致鸿蒙

脑极体

持续测试 | 让测试更自由:在 CODING 中实践自动化执行用例

CODING DevOps

DevOps 自动化测试 持续测试

BZZ节点挖矿系统搭建,BZZ矿机分币系统

情指勤一体化指挥调度平台搭建,情报研判分析系统搭建

Spring Boot FatJar类加载机制简要分析

luojiahu

Spring Boot 类加载 ClassLoader FatJar

手把手教你在IDEA中配置Maven

打工人!

Java maven 6月日更

我对技术潮流的一点看法

Phoenix

面试系列-2 redis列表场景分析实践

李阿柯

php 面试 redis cluster

Hello Python! 第一天学 Pyhton 语言

在即

6月日更

微博评论的高性能高可用计算架构设计

唐高为

React Hooks - 如何安全地使用state

蛋先生DX

大前端 React React Hooks JavaScrip 6月日更

你真的了解 “开源” 么?请查收【保姆级】开源百科

程序员鱼皮

Java c++ Python GitHub 开源

k8s 插件管理工具之krew使用

雪雷

6月日更

你们公司的数据库出过问题么?

escray

学习 极客时间 朱赟的技术管理课 6月日更

【Flutter 专题】114 图解自定义 ACEProgressPainter 对比进度图

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

OpenKruise v0.9.0 版本发布:新增 Pod 重启、删除防护等重磅功能

阿里巴巴云原生

容器 运维 云原生 k8s

基于 BDD 理论的 Nebula 集成测试框架重构(上篇)

NebulaGraph

深圳首辆数字人民币主题观光巴士亮相

CECBC

react源码解析4.源码目录结构和调试

全栈潇晨

React Hooks react源码

5分钟速读之Rust权威指南(十五)

wzx

rust

🏆大势所趋,迈向认识WebRTC的第一步,加油!

洛神灬殇

WebRTC RTC RTC征文大赛 6月日更

Dubbo SPI

青年IT男

dubbo

关于第四次财富狂潮的思考,区块链如猛虎出笼?

CECBC

VSPD9.0基础 建立一对互联的虚拟串口,进行串口通信的测试

万里无云万里天

IoT 6月日更 VSPD

红帽峰会2018第二天:“人”的改变_DevOps & 平台工程_sai_InfoQ精选文章