当众思考

迄今为止,我已经在Wolfram Research公司当了30多年的CEO。但这份工作究竟有什么要求?我平时都做些什么?毫无疑问,我工作非常努力。但我觉得,我不是特别典型的科技公司CEO。因为就我而言,我很多时候都工作在第一线,比如弄清楚我们的产品应该如何设计和构造,应该具有什么功能。

30年前,我基本上是独自做这些。但现在,我几乎总是跟公司里大约800名员工中的一些人一起工作。我喜欢和其他人商量着做事情。

实际上,过去15年里,我把大量时间都用于我所说的“当众思考”上:与其他人一边协商,一边解决问题、作出决定。

人们常常问我这是如何进行的,在我们协商的过程中,到底发生了什么。最近,我意识到:以直播方式将我们的会面展现出来,让人们了解整个过程,还有比这更好的方法吗?所以,几个月来,我直播了近40个小时的内部会议,实际上,就是把参与产品创造过程的所有幕后人员都放在幕前。(没错,直播内容会被存档。)

直播CEO.jpg

观看作出决定的过程

人们常常抱怨“开会没效果”。我的会议却不是如此。实际上可以说,在我开的每一场产品设计会议上,都解决了重要的问题,至少作出了一些重要的决定。

例如,今年以来,我们已经为Wolfram语言增添了250多项全新功能。其中的每一项功能都是在会议上讨论通过的。很多时候,这些功能的设计方案、命名甚至想出这些功能的点子本身,都是在会议上提出的。

在我们的会议上,总是会上演某种程度的头脑风暴。我们会去解决复杂的问题,无论要耗费多长时间,这需要对某个方面或另一个方面有深刻的了解,最后,我们提出的想法、作出的决定往往能够产生长远的影响。

过去30多年里,我努力保持Wolfram语言的统一性和一致性,但每天我都要开会,我们在会上就添加到Wolfram语言的新东西作出决定。维持我们设定的标准,并确保我们今日作出的决定将在未来数年里发挥良好的作用,这始终是一个艰巨的挑战,也是一项重大的责任。

我们讨论的可能是神经网络的象征性框架,也可能是与数据库的整合,如何表现复杂的工程系统,新的函数编程原语,新形式的地理数据可视化,量子计算,与邮件服务器的程序化交互,分子的符号表示,或者Wolfram语言当前和将来所涉及的很多其他话题。

在一个特定的领域,重要的功能是什么?它们如何与其他功能联系起来?它们是否拥有恰当的名称?我们如何解决看似矛盾的设计限制?人们是否可以理解这些功能?相关的图标或符号是否尽可能地做到了清晰明了、简洁漂亮?

到目前为止,我在这些方面已拥有40年的经验,和我共事的很多人同样经验丰富。会议开始时,往往是有人先提出一项提议,有时只是一个关于理解、思考和证实提议的疑问。但通常来说,为了维持我们设定的标准,我们必须解决一些实际问题。会议将来回拉锯,反复讨论,努力解决某个问题。

想法提出后,常常会被枪毙。有时,我们会觉得完全卡住,会议进行不下去了。但参加会议的每个人都知道,这不是一场练习。我们必须找到真正的答案。有时,我会设法作比较,寻找我们解决类似问题的先例。或者,我会要求我们回到首要原则(问题的核心),从头开始理解一切。会议上,人们会提出很多具体的理论或技术知识,而我常常试图看本质、抓重点。

如果把标准定得低一点,无疑会容易许多。但我们不想妥协。我们想要真正的、经得住时间考验的正确答案。这往往需要真正的新想法。而结果通常令人非常满意。我们下了很多功夫,费了很多脑筋,最后找到解决办法,很好的解决办法。这是真正的智慧结晶。

通常来说,所有这一切都是在公司内部进行。但通过直播,任何人都能亲眼目睹,能看到功能被命名或问题被解决的时刻。

直播CEO2.jpg

会议上是怎样的景象?

如果你观看我们的会议直播,会看到怎样的景象?相当地丰富多样。你可能会看到对Wolfram语言某个新功能的测试(常常基于几天甚至几小时前才编写完成的代码),看到关于软件工程、机器学习趋势以及科学哲学的讨论,或是如何处理某个流行文化问题或者怎么纠正某个概念性错误,你还会看到某个新项目的启动,看到Wolfram语言文档某个部分的完成,看到最终的视觉设计敲定。

在我们的会议上,有形形色色的人,他们拥有各种各样的口音、背景和专业。某个具有特定专长的人,我们原以为不需要他参加会议,结果后来发现还是少不了他,于是又把他喊来开会,这也是常有的事。(让我感到欣慰的是,在我们企业文化的熏陶下,没人因为被叫进会议室询问某个独特话题的细节而感到惊讶,哪怕他们以前不知道这个话题和我们有关。)

我们是一家地理分布很广的公司(我从1991年开始就是一位远程办公的CEO)。所以,基本上我们所有的会议都是视频会议。(我们使用音频和屏幕共享,但从来不觉得视频有用,除非需要观看一台移动设备、一本书或者一张纸上的图。)

大多数时候,开会的人都在看我的屏幕,但有时也会看别人的屏幕。(最常见的原因是有些东西只能在他们的设备上运行。)我主要使用Wolfram Notebook文档。通常来说,Notebook文档里会有一个初步议程,以及可执行的Wolfram语言代码。我们将以此作为开始,然后我会修改Notebook文档,或者创建新的Notebook文档。我常常会测试设计方案。有时,员工会把代码发给我运行,或者我会亲自编写代码。有时,我会当场编辑我们的主要文件。有时,我们会实时观看图形的设计过程。

会议上,我们的目标是尽可能做出些东西,现场向相关人员征询意见,解决问题。没错,某些时候,有的人(有时是我)事后会意识到,我们原以为正确的答案其实是错误的,或者是无效的。但好消息是,这种情况相当罕见,这或许是因为我们开会的方式确保了事情在会上已经得到了很好的实时沟通。

会上的人往往说话都非常直接。如果他们不同意,他们会直接说出来。我非常希望会议上的每个人都能真正理解与他们有关的每一件事情,这样我们就可以受益于他们的思考和判断。(这可能导致我讲出像“这说得通吗?”或者“你明白我在说什么吗?”这种过于直率的话。)

当然,我们拥有非常优秀的人才,这一点也起到了作用,他们理解事情的速度很快。现在,所有人都知道,为了取得进展,我们可能不得不偏离会议的主题,去讨论完全不同的事情。这需要机敏的头脑才能跟上节奏。撇开其他不谈,我觉得这本身就是一个值得推行和培养的优点。

在我看来,连续几个小时讨论这么多不同的话题,是一件令人神清气爽的事。虽然辛苦,但也有趣。常常可以听到诙谐幽默的言论,尤其是在细节之处,有很多脑洞大开的 场景。

会议规模有大有小,从两三个人到二十人不等。随着讨论内容的变化,有时会加人进来,有时会有人中途离开。在规模较大的会议上(往往是涉及多个部门的项目),一般会有一个或多个项目经理出席。项目经理负责项目的整个流程,特别是要在不同部门之间做好协调工作。

直播CEO3.jpg

史蒂芬·沃尔夫勒姆(Stephen Wolfram)

如果听我们的会议直播,你会听到某些专业术语。有些在软件行业里非常普遍(UX=用户体验,SQA=软件质量保证),有些则是我们公司所独有,比如某些部门的首字母缩写(DQA=文件质量保证,WPE=网络产品工程)或者内部事物的名称(Xkernel=原型Wolfram语言构建,pods= Wolfram|Alpha输出元素,pinkboxing=标示不可显示输出,knitting=文件的交联元素)。当然,会议上偶尔也会当场发明一个新的术语或者新的名称。

通常来说,我们的会议节奏很快。想法一提出,与会者就会立刻发表意见。一旦决定了一件事情,就会以此为基础,提出更多的想法。这相当富有成效,我认为也是一个非常值得观看的过程。虽然没有与会者所具备的经验基础,但有时,你也许会感受到想法层出不穷,让人跟不上节奏。

直播的过程

直播我们的内部会议,这是个新点子。但多年来,出于其他目的,我已做过很多次直播。

2009年,我们发布Wolfram|Alpha的时候,直播了现场制作该网站的过程。我觉得,如果出了问题,不妨让所有人看到是哪里出了问题,而不是贴出“网站不可用”的消息。

我直播了我们发布的新软件的演示过程,直播了我编写代码或生成“计算文章”的过程。(我儿子用Wolfram语言编程的速度比我还快,他也做过编程直播。)我还直播了现场实验,尤其是我们Wolfram暑期学校和Wolfram夏令营的实验。

但直到不久前,我所有的直播基本上都是单人表演,不涉及其他人。但我一直觉得,我们公司内部的设计评审会议相当有意思,所以我想:“为什么不让其他人也听听这些会议呢?”必须承认,我起初有点不放心。毕竟,这些会议对我们公司所做的事情非常重要,如果会议因为任何原因受到拖累,我们承受不起这样的代价。

因此,我要求会议必须如常进行,不管直播与否。对于直播,我唯一的让步是,我会先介绍几句,大概解释一下开会的目的。所幸,会议开始后,参加会议的人(包括我自己)似乎很快就忘记了正在直播这回事。所有人都专心于会议上的讨论(往往相当热烈)。

但在我们进行会议直播时,会发生一件很有意思的事:与观众的实时文字聊天。通常是提问和一般性讨论,但有时会有一些有趣的评论或建议。这就像拥有现场顾问或者焦点小组,为我们提供实时的意见或反馈。

直播过程中,参加会议的主要人员专注于会议本身,没空进行文字聊天。所以,我们让专人负责此事,找出最中肯的评论和建议。这样做效果很好,在大多数会议上,至少会有一两个好主意来自于观众,我们也能立刻将之纳入我们的思考范围。

直播有点像真人秀,只不过直播是现场和实时的。我们正打算针对录像,制定系统性的“播出时间”。直播有其时间限制,必须和会议同时进行。对于我要做的所有事情,我习惯于制定完整且全面的时间表。某一次设计评审会议何时举行,这往往取决于相关代码或设计工作何时就绪。

这还取决于其他参加会议的人是否有空。他们有自己的时间限制,而且常常住在不同时区。我尝试过其他方法,但现在最常见的情况是,设计评审会议在真正开会前不久才安排好时间,通常最多只提前一两天。虽然我自己晚上白天都在工作,但大多数的设计评审是在上班期间做好安排,因为那个时候最容易安排所有的既定参会者,以及可能被中途叫去开会的人。

从直播的角度来说,让会议时间做到可预期,自然再好不过,但会议的时间安排是为了达到最好的开会效果,直播只是外带的。

我们试过利用Twitter来预告直播时间。但最终,预告直播时间的最佳工具,来自于我们使用的Twitch直播平台上的通知。没错,Twitch目前主要用于电子竞技直播,但我们(和他们)希望Twitch也能用于其他事情。由于该平台的重心是电子竞技,因此其屏幕共享技术非常出色。我很早以前就知道Twitch。2005年,在创业孵化器Y Combinator的首个演示日上,我见到了Twitch的创始人。我们使用其前身justin.tv直播了Wolfram|Alpha的发布。

工作的方式

并非我做的所有事情都适合直播。除了在会议上“当众思考”以外,我还会“独自思考”,比如写作。

如果看看我一周的日程,你会看到各种各样的事情。通常来说,每天至少有一两次我直播的那类设计评审会,也有不少的项目评审,还有一些战略和管理方面的讨论,以及偶尔的外部会议。

我们公司的重心是研发,努力打造最好的产品。这一点,从我的时间分配以及我对知识价值而非商业价值的强调中,无疑得到了体现。有些人也许认为,经过这么些年,我不可能依旧事无巨细,就连出现在设计评审直播中的那些细节都不放过。

但事情是这样的:我尽量在以最有利于长远发展的方式来设计Wolfram语言。经过40年的软件设计生涯,我对此非常有经验。所以,我做起这个来既速度快,又善于避免犯错。当然,现在我们公司里有很多优秀的软件设计师,但我仍然是那个对Wolfram语言设计最有经验的人,也是对该系统最有全局观的人。(在设计评审会议上,我会花一部分时间把不同但相关的设计工作联系起来。)

没错,我不放过任何细节。那个选项到底应该取个什么名字?那个图标应该是什么颜色?这项功能在特定的极端用例中应该起到什么作用?即使没有我,所有这些事情也能以某种方式得到解决。但我能在相当短的时间内,帮助确保一点:我们现在所做的事情能够为将来打下基础,并能让我们为之自豪。我认为,把时间用在这上面很值得。

通过直播我们的会议,让外界目睹此过程,这是一件很有意义的事。我希望,这可以帮助人们更好地理解Wolfram语言是怎么创造出来的。软件设计往往是无名英雄,只有在出错的时候,才会引起人们的注意。所以,向人们展示设计过程,这是一件很有意义的事。

从某种程度上来说,Wolfram语言的设计是计算思维的一个极端化缩影。我希望,通过观看我们的会议直播,人们可以更多地学会自身如何进行计算思维。

我们现在直播的会议是讨论我们当前正在开发的Wolfram语言功能。但考虑到乐观的时间表,我们现在讨论的东西距离成为现实,应该不会太久。届时,你会有一种独特的感觉。因为有史以来第一次,人们不仅能看到成品本身,还能从录播中看到它的诞生过程。

这是对一种强大智力活动的记录,记录形式有趣而独特。但在我看来,能把我每天参与的一些有趣的谈话分享给大家,就已经很好了。通过直播观看我如何做一名亲力亲为的CEO,不仅能带动Wolfram语言和我们打造的其他产品,还能向世界上更多的人传播知识,兴许还能为他们带来欢乐。


本文作者史蒂芬·沃尔夫勒姆(Stephen Wolfram)是Mathematica、Wolfram|Alpha和Wolfram语言的创造者,也是Wolfram Research公司创始人兼CEO,著有《一种新科学》一书。在近40年时间里,他是计算思维领域的先驱,参与了科学、技术和商业领域的诸多发现、发明和创新。本文最初发表于他的博客。


翻译:于波

来源:Wired

  • 科技公司
  • 开会
  • 决策
  • 思考
  • 协商

造就评论0

造就  发现创造力