技术人员如何写一本书?

我在过去的几年中,写了4本书。有传统意义上的两本实体书:《JavaScript核心概念及实践》《轻量级Web应用开发》,还有两本电子书《3周3页面》《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。

在写作的过程中,有一些有趣的心得。

  • 写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
  • 写书非常枯燥,特别是校对的时候
  • 写作不会让你变得富有,但是有时候会让你开心(不总是)

写文章 vs 写书

写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。

投入与回报

首先要明白的一点是,不要指望用写书来赚钱,至少前4本是这样的。粗略的算一下:我的第一本书卖了3000册,每卖一本我可以得到4元RMB,一共就是12,000元RMB。而这本书我断断续续写了三年。那是很多个周末,很多个假期,很多个夜晚的付出换来的,如果真正要计算投入产出比的话(纯粹金钱上),这显然是一个毫不合算的事情。

作为一个参考,IBM developerWorks的投稿,千字200元,一般写5,000字以内,也就是800元RMB左右。而要写一篇这样的文章,我只需要一天(当然需要数周/数月的积累)。12,000元RMB需要写15篇文章,如果每周写一篇,不到4个月就可以写完,而且写文章比写书容易多了,毕竟篇幅比较短小,易于校对。而且对于大部分开发者来说,固定在一个主题上的难度要比15个独立的主题简单的多,因为无需特别深入。

所以根据经验,要抱着公益的情怀来写书。也就是说为了让知识更好的分享,让你学习到的先进科学技术来帮助更多的开发者,提高他们的开发效率,让他们可以在周末多休息一天。而至于翻译技术书籍,那基本上就是免费的了,完全是一个公益活动(耗时数月,斟酌字句,推敲表达方式,但是价格极为低廉:千字60元RMB),所以下次见了技术书籍的译者,就多少给他捐点吧,他们才是在为人民服务

知识的诅咒

“知识的诅咒”是指人们在获得了某种知识之后,就无法想象没有这种知识的情况了。这种现象随处可见,比如一个你到了一个从未去过的陌生城市,遇到以为当地人,然后向他问路。当地人觉得已经说的很清楚了,但是你还是不知道该怎么走。另一个例子是:假设你不认识泰文,然后你打开任何一本泰文写的小说,你只能依稀感觉到这是一种文字,除此之外你并不能从中获取任何的信息。但是当你学习了一段时间泰文之后,再来看这本小说,之前的那种感受就再也没有了。

curse-resized

写书的时候,你首先需要具备某种知识。但是写书的目的是将这些知识传递给那些不具备此知识的人,而根据“知识的诅咒”,你又无法确知那些初学者会遇到哪些问题!解决这个问题的方法就是找初学者来试读。而且为了保险起见,还应该找尽可能多的人来试读。

写作方式

一种方式是自下而上的,写一些独立的文章,最后发现可以串起来,然后形成一本书,另一种方式是自上而下,但是又会逐步调整。根据经验,不论是写一篇简单的博客,还是写一本书,都需要按照自上而下的方式。随心所欲的写下去,基本上都收不住,而且整个文章支离破碎,貌似有很多内容,但是不成章法,读者也无法轻松的获取知识。

先列出大的章节,然后逐步细化,但是未必是按照顺序来写。先编写自己最熟悉的部分,然后逐步完善。例子的选取需要精妙而恰当,最好有图例来说明。

配图制作

一般而言,我在书中会使用两种图:流程图和一些截屏。截屏通常使用Mac OSX自身的功能就已经足够,而流程图我会采用一些额外的工具如:

  • graphviz
  • keynote/sketch

cgi

用Graphviz画图的好处就是可以将图像代码一样放入版本库来管理。

除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:

  • 字形/字体(大小,粗细的变化)
  • 颜色(基本的配色理论就可以做出很舒服的配色)
  • 层次(尺寸,位置,颜色的深浅)
  • 阴影

mock-server-resized

代码格式

书中实例需要很多代码来说明,如果是制作电子书的话,可以使用Markdown预处理器自带的功能来高亮。另外如果需要RTF格式,可以使用这些工具:

  • highlight工具
  • intelij中的插件copy on steriod

这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到Word或者Keynote中了。

jest.dontMock('../components/headline.jsx');

describe('Headline', function() {
  var React = require('react/addons');
  var Headline = require('../components/headline.jsx');
  var TestUtils = React.addons.TestUtils;

  it('#render', function() {
    var text = "this is a title";
    var headline = TestUtils.renderIntoDocument(<Headline title={text} />);
    var title = TestUtils.findRenderedDOMComponentWithTag(headline, 'h4');
    expect(headline.getDOMNode()).toBeDefined();
    expect(headline.getDOMNode().textContent).toEqual(text);
  });
});

一些潜在的坑

在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于平淡。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。

内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。

另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟知识的诅咒的道理一样。

typo

发布方式

实体书

传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:

  1. 时滞性(新技术的更新速度远远超过审批,印刷等流程的时间)
  2. 排版(如何低成本做到语法高亮,或者彩图)
  3. 更新频率(当技术更新之后,如何更新,是传统纸质书无法解决的问题)

传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时4-8个月,着这个过程中,很多东西都可能发生了变化,一个典型的例子是《用AngularJS开发下一代Web应用》,原版为英文版,翻译成中文版再到出版之后,书中的很大一部分内容已经过时。读者拿到书之后,会发现书中的内容已经和当前的版本/文档不匹配了。这种现状随着技术的更新速度和频率还会再加剧。

第二点是排版。我听说国内有些出版社已经开始接受Markdown作为稿件的格式,但是大部分还采用Word或者WPS等格式,这样排版就变成了一个大问题。以我自己为例,我的原稿用Markdown写,但是写了几章之后不得不切换到Microsoft word上,而我自己的Mac OSX下的排版到编辑的Windows下就会变样,而且还会涉及字符集,字体,Word版本等等问题的影响,最后导致印刷出来和原始稿件出入很大。

最后一点是更新频率,如果发现了错别字或者错误的地方(即使之前检查过多次,仍然会有漏网之鱼),由于实体书的特殊性,一般需要等到再次印刷才能解决。这意味着先购买的读者会承担一些风险,更新后的版本又如何让读者看到呢?总不能又买一本吧。

但是这些问题都可以通过电子书来很好的解决。首先,电子书可以随时更新,最低限度的降低时滞性。排版上来说,作者可以使用Markdown来编写,而展现则可以应用一些预定义的模板来完成。最后,更新频率完全可以控制,对读者来说风险更低,因为电子版书籍的可以很容易的追踪交易记录,从而得到免费的更新过的版本。

电子书

目前已经有很多的渠道可以发布电子书,比如gitbook知笔墨。这些应用的出现,大大降低了发布书籍的成本,我的《函数式编程乐趣》,用了3天就完成了草稿,而发布只需要数秒。

另外一个问题是书籍的价格和作者的收入。一本书定价50元RMB,出版社给作者的版税是8%,也就是说,没卖出一本,作者可以得到4元,如果你的书非常畅销,这还是一个不错的价格。但是可能90%的书籍都不会是畅销书(就好比每个班级都会有优等生,但是他们仅占全班人数的10%一样)。这对作者是一种浪费:你需要耗时数月甚至数年来写一本书,然后市场的反馈又非常慢(毕竟你无法出版一本未完成的书)。

我在selfstore.io上有两本电子书:《3周3页面》《函数式编程乐趣》《3周3页面》定价为16元,每卖出一本,扣除掉交易费之后,我可以得到14.7元。

对我来说,这样可以得到更多的回报,对于读者则可以更加快速的得到更新,而且由于有预览版和一系列的其他信息,还可以在很大程度上降低读者的风险(更不用说快递费,等待时间等问题)。我在gitbook上的统计显示,《3周3页面》已经被累计下载了28,861次,实际的读者也将近5,000。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。

Share

如何快速发布你的点子?

过去的几年中,我参加过好多次Hackday活动。每次看到在为期两天的时间里,2-3个人将一个想法变成现实,都会有一种强烈的成就感。而且这个Hack的过程中,会重拾编程的乐趣,大家的积极性都非常高,用着各种有趣的技术(大数据,开源硬件,Node.js,GIS系统),逐步的将模糊的想法,变成现实,并最终为客户带来价值。最新的一次在这里

通过这些Hackday的经历,以及在众多项目中的经验,我总结了一些轻量级的方法/实践。这些方法/实践非常容易落地,并且久经验证。在很多项目中已经在不断的使用。它们可以帮你更好的将一个想法变成现实,并且在随后的开发中还可以继续发挥作用而不至失效(测试,构建脚本,自动化部署等等)。我希望你可以在自己的项目中尝试这些方法/实践,也希望这些方法/实践可以真正的帮助你和你的项目取得成功。

细化你的“点子”

根据一个已有的产品来参考,演绎,并形成自己的产品并非难事,而创新则是一件非常困难的事情,因为你需要“无中生有”。在ThoughtWorks,我们有这样一些步骤可以帮助客户来梳理信息,并最终交付产品,简而言之,可以归结为这样几个步骤:

  1. Discovery(用户研究,探索)
  2. Define(归纳洞见,发现)
  3. Design(原型设计,验证)
  4. Delivery(制定计划,实施)

01

上图是一个“点子”的原型(一个交换技能的应用,用户可以教别人自己擅长的技能,作为交换,也可以从别人那里学习心得技能),原型事实上是第三步的产物。我们通过一些调查(口头采访,或者问卷调查)得到一些基本的信息,然后归纳这些信息,并和真实用户再次确认,得到一个概念。有了概念,再来设计一个基本的原型,这个原型还可以迭代数次,然后进入下一个阶段。

前三个阶段更多的是用户体验设计师,以及客户的业务人员参与的。在前三步完成之后,进入实施的时候,软件工程师开始投入。这篇文章更关注第四步(Delivery)中的各种实践,通过这些实践,我们可以很好的完成交付计划,使得我们的好想法最终可以变成为用户提供服务的产品。

实现“点子”的方法

在软件领域,将一个想法变成实际的产品需要经历若干个阶段。按照传统的软件开发方式,会有前期的调研,需求分析,概要设计,详细设计,编码实现,测试,发布等一系列的流程。这种方式对每个阶段的定义都非常明确,而且每个阶段需要依赖前一个阶段的输出,因此往往被称为“瀑布模型”。后来慢慢发现,这个模型的反馈周期太长,一个软件从调研到发布往往需要数年,当发布之后,可能市场早已经沧海桑田。人们后来发明了更加符合现代市场需求的“敏捷开发”,在敏捷中,更加强调短平快的将需求变为产品。

简而言之,敏捷开发更强调:

  1. 快速发布
  2. 渐进增强
  3. 小步迭代

而在敏捷开发的继承者精益中,这几点理念也被更进一步的深化。由于没有办法预见未来,我们只能用一种边做边看的方式来验证想法。简而言之,就是先根据经验和调查,做出一个合理的推断,然后定义好范围,构想出一个最小可行产品(MVP),这个MVP的功能非常内聚,非常紧凑,我们需要尽可能快的让其上线,并被真是的用户使用,测试。根据这些用户的反馈,我们会做一些调整,比如去掉那些很少人使用的功能,聚焦在用户喜欢的功能上;从用户的实际使用中,调整界面元素的位置,子功能的入口等等。这个过程会持续多轮,最后的结果会是一个有真是用户使用,并且比较贴近真实需求的产品。当然这还不够,我们需要不断的打磨,渐进式的增强产品的功能,逐步完善功能等。

有一个非常形象的图,可以看出瀑布模型和敏捷开发两种方法的对比:

02

 

敏捷开发通过逐步细化,迭代前进的方式,分阶段的将需求实现,在整个过程中,更容易做到快速调整。

所有的这些过程,都非常依赖“快速”这个关键点。如果MVP花了3周就产生了,但是为了让其上线,你花费了1个月,那么很可能这个MVP已经过时了;如果你确实快速的将MVP发布了,在得到了用户的很多反馈之后,花费1个月来实现这些反馈,又会让你落在竞争对手之后;如果快速的发布了多次,并且幸运的是,你的用户量变多了,如果花费很长时间来调整架构,则可能失去当前的市场窗口。也就是说,你需要非常快速地对变化做出反应!

轻量级的开发方式

开发中的三个重点

在工程实践中,我认为有三个特别需要注意重要的点,这三点可以极大程度的改善项目现状,提高效率,并使得产品的高质量交付成为可能,它们分别是:

  1. 自动化(自动化一切)
  2. 质量内嵌(defect的数量,是否真正满足了需求)
  3. 代码本身的质量(可读性,可维护性,可扩展性)

自动化包括,自动provision,自动部署,自动化测试,自动打包等等。这是提高团队开发效率的必要工具。比如书中提到的grunt/gulp脚本,jasmine/rspec/capybara测试,部署脚本,vagrant/Chef等,都是关于如何将日常开发中的任务尽可能的自动化。

软件没有Bug当然是所有人都追求的,我们有很多中方式来保证代码质量。而在编写产品代码的同时,写大量的自动化测试,是投入产出比最高的一种了。通过单元测试,集成测试,以及一些有限但是关键的UI测试,我们可以覆盖很多的需求,而将这些测试自动化起来之后,可以节省大量的开发/测试成本,并减少回归测试的代价。

要支撑快速的发布,我们需要一系列的技术实践。这些技术包括环境的搭建,框架的使用,代码的编写,产品的发布;而且包括后台的数据库设计,业务代码,同样还有前端的展现等。

03

 

何为轻量级?

《轻量级Web应用开发》中,我介绍了一系列的实践/工具,这些实践/工具贯穿整个软件开发的生命周期,使得敏捷开发/精益的开发方式变得可以“落地”。比如如何使用轻量级的开发框架来搭建API原型,如何将应用发布在免费的云平台上,如何通过虚拟化技术快速搭建开发环境,从而节省环境配置的投入,如何快速平滑的发布,如何使用测试先行的方式来保证代码质量,如何做高效的自动化UI测试等等。

  • 轻量级Web框架
  • 前端开发流程
  • 构建工具
  • 环境自动化(开发环境的搭建,CI服务器的搭建)
  • 自动化部署
  • UI测试
  • 实例驱动(书中有很多的实例,也有很多从项目中总结出来的实践)

这是一本主要关注开发实践的书,书中通过很多实际的例子来帮助读者建立一套完整,高效,轻量级的开发方式,这些方式可以直接在你的下一个项目中使用。甚至如果项目的技术栈变成了另外一种语言,你也可以迅速找到同类的替代品。比如rake之于gradlesinatra至于spring-mvc等等。

每个组件都是可以替换掉的,比如ORM,如果你觉得DataMapper无法满足实际需要,那么可以换成ActiveRecord。如果Rails太重,使用Sinatra或者Grape或许是一个更好的选择。AngularJS包含了太多东西,Backbone.js或许适合你的场景,而也未尝不可以用Riot.js来替换掉Backbone中的view层。

在本地,可以将应用部署到一个vagrant+chef来provision的环境中,而通过部署自动化,这个动作可以很容易的在AWS的云上实现。轻量级的开发方式,帮助你用最小的代价来替换系统中的任意一个组件,因为每个组件在一开始都是按照可替换原则选用的。

另一方面,轻量级的另一个意思是:现发布静态的版本,然后再将内容替换为动态版本。发布一个静态的页面非常容易,具体细节可以参考这篇文章。当需要动态内容是,免费版的Heroku是一个触手可得的选择,AWS则是一个更加专业的选择(各种服务都配置完善,你只需要关注自己的应用部署即可)。

Share

数字消费者与传统行业互联网转型

面对换商经济的冲击,从前几年尝鲜感受电子商务,到最近不得不为之,传统企业正在发生着变化,它们认识到消费者的生活方式已经彻底改变,数字化、智能化和社交化已经成为新常态,这迫使传统企业开始寻求打通线上和线下多渠道的途径。埃森哲2013年中国零售商全渠道零售能力调查显示,63%的传统零售商已开展多渠道零售,78%的单一渠道零售商正计划向多渠道转变。受调查企业中61%已拥有独立官方网,超过半数 (52%)已在第三方平台开设了网店。

数字体验业已成为消费体验不可或缺的重要组成 ,越来越多的企业也意识到了提升数字体验的重要性,从我们的观察来看, 围绕用户体验的提升建设企业分析数据的能力,打通线上和线下的体验是传统行业互联网转型的一大类方向。

用户数字体验,新方向

提到用户数字体验的提升,常见的误区是把用户数字体验简单的看成视觉设计而没有意识到用户数字体验的改进是系统工程,从实施的角度看,它往往被划分为快速启动、体验设计和实施三个阶段。快速启动关注愿景,着力于帮助相关人之间对未来产品的愿景达成一致,然后规划并设计产品最核心的用户体验, 包括完整的信息架构、信息及交互设计。在设计的过程中,往往采用各种原型工具来辅助交流,让相关人减少误解,尽快达成一致。

有信是微信在国内最大的竞争对手,设计团队和相关负责人在快速启动中从企业用户场景和业务模式入手,识别出了“舍不得挂断电话的异地情侣”的场景,从这一点出发,设计团队利用纸质原型、互动原型、低保真原型、高保真原型对需求进行了充分的发掘以及交流,从在相关人之间达成了对业务模式和设计的共识。

Screen+Shot+2014-12-23+a

体验设计关注设计本身。体验设计主要回答三个问题,用户看什么内容? 用户怎么找到这些内容?用户消费内容时的感受如何? 看什么内容是内容策略,设计团队往往需要从业务上下文出发对现有内容进行梳理。“怎么找到这些内容”是产品的信息架构,需要应用交互设计原则对产品的核心交互行为进行系统性的设计,这这个过程中,往往会利用用户的真实行为数据来辅助设计,让整体设计更容易落地。“感受”是视觉设计,即通常意义上的做“漂亮”,设计团队往往结合企业现有品牌和视觉标视对产品进行定位和设计。

实施关注的是验证和演进。产品在使用中往往有很多意想不到的地方,这需要通过真实数据不断验证,对设计进行调整打磨。买房网 是面向中国富人销售澳洲房产的项目, 设计师在初期设计了 澳洲行政区域图 ,用户可以通过点击区域来完成相应的搜索,令人吃惊的是 这一特性 上线后使用度为零。在回访中,设计师发现用户不知道这个图是可以交互,这说明设计过于复杂,需要进行调整。

用户常见的行为是在网上对商品进行比对、挑选、购买,再通过实体店享受产品和服务,数字 体验的改进必须同时考虑线下和线上。诺德斯特龙((Nordstrom)是美国一家高档连锁百货店,它 推出了一个 具有交互功能的显示屏 科技产品,一眼看去就像镜子但镜面可以交互,顾客可以在试穿衣服的同时浏览不同的尺码、颜色、款式甚至是产品评价,就像网购一样,不过优于网购的地方是:顾客可以随时召唤店员把想要购买的衣物拿过来让他们试穿。而不是试完一件衣服后脱下,又换上自己的衣服走回销售区去找挑选。 充分利用传感器和数字技术增强用户在物理世界的体验是线上、线下体验整合的新趋势。

9209426C-6213-4113-9E32-

创新,没有最好,只有更好

创新,则是着眼于尚未满足的体验。尼尔森提出了创新的三步:第一步,找出的尚未得到满足的需求,思考怎样才能实现;第二步,通过一种进化的测试-改进程序,不断地改善这些概念,进而完善依据这些概念而推出的产品;第三步,上市推广。

在实践中,我们发现寻找“尚未满足的需求”有两个关键路径,首先要学会与用户合作创新,Woolworth是澳洲最大的超市,客户对付款时排队久抱怨极大,Woolworth想通过手机应用让用户可以随时扫码付费,提高用户体验。设计团队采取了在超市现场与用户共同研发的方法,在几天内他们就发现这个计划行不通,大量客户不习惯提篮子所以腾不出手来使用设备扫码。同时,团队发现了一个“尚未满足的需求”:帮助客户决定晚餐吃什么? 并最快找齐食材,满足这个需求会大大提升购物体验和销售收入。

Screen+Shot+2014-12-25+a

学会与IT合作创新是另一个关键途径, 当今IT的角色绝不仅仅是支持业务,企业应当建设IT与业务融合的能力。内部创新日是帮助市场与 技术结合形成草根创新的行之有效的方法。 市场和IT部门自由组队围绕某主题进行头脑风暴,产生创新想法;团队2天内利用各种快速开发技术产出产品原型;通过创新市场 共同向市场部门 推销产品,寻找内部投资; 最终实现产品化。澳洲最大的房产门户正是通过这一套方法孵化数十个新产品。

尼尔森所提到的可演进的测试-改进程序是 不断试错、快速小步骤改进产品的能力。这种快速、高效、灵活的向用户交付新功能的原则和技术实践被称为持续交付。通过实现自动化的构建、部署和测试过程,并改进开发人员、测试人员、运维人员之间的协作,交付团队可以在几小时(甚至几分钟)内发布软件变更,从而得以不断收集数据判断软件的功能是否被用户接受,继而作出相应的改进。

围绕企业的核心竞争优势,寻找差异化,利用IT进行创新是我们观察到的另一大类企业互联网转型的方向。

着眼未来

马云和王健林打赌未来电商能不能超过零售的50%,雷军和董明珠以10亿豪赌小米在五年后能否超过格力。随着阿里巴巴的上市和小米的突飞猛进,让人颇有传统行业江河日下的 感觉。但其实风生水起的数字消费不过占了整个零售市场9% ,传统企业还大有潜力可挖。

着眼于中产阶级的消费升级。更更有趣的购物体验将吸引中产阶级回到传统渠道。电影是个很好的例子,在Youku, iQiyi们25元包月看电影的冲击下,中国全年电影票房依然保持着27.51%的高速增长,电影院提供的已经不仅仅是电影本身,而是周末全家出行,从吃到娱乐的全套服务和体验。

着眼于大规模定制化。定制化意味着差异化,从差异化出发, 传统企业可以避开目前数字渠道的劣势,以及充分利用生产的强项。 定制与大规模经常是一对天然的反义词,而最近然声名鹊起的红领西装,就用规模工业生产满足了个性化需求。定制西服往往就意味着手工量体、手工打版、制作毛坯等,一条小型定制生产线一天产量一般在五套左右,而让红领每天可以生产1200套西服。红领充分的利用了企业现有数据和计算机辅助设计大大提高了效率,而用户则被粘在了红领的终端上。在其它企业饱受高库存煎熬时,红领今年以来却实现了生产、销售、利润指标150%以上的同比增长。

着眼于未上网的消费者。在中国还有超过7亿没有使用互联网的消费者,有些是因为年龄的原因难以掌握新技术,有些是因为教育的原因,相比于互联网,传统企业的营销网络可以在不同的区域采取不同的策略,更容易去服务这个群体。

着眼于服务。劳斯莱斯在飞机引擎中安装了上百个传感器,引擎工作过程中任何的微小细节, 如振动, 压力, 温度, 速度等,都会通过卫星传送到进行数据分析的计算机中。通过利用这些数据,劳斯莱斯可以预测引擎的问题,根据航班的安排,可以在飞行目的地机场安排备货及时维修。这样,劳斯莱斯把自己从提供硬件重新定位为提供服务,从而获得更高的利润和粘性。

Share

极限会议: 原则与实践

luobosi.rules_

极限会议是解决开会过多, 会议效率低下的一组原则和实践. 它基于两个简单的理念:

  • 如果一个实践是有用的, 那么我们能不能把它做到极限?
  • 如果每个人都尽自己极限努力推进会议进程, 那么会议定会卓有成效.

会议效率是产出和所花时间的比值. 我们的原则跟实践, 有的致力于提升高价值产出, 有的致力于缩短所需时间, 有的两者皆涉及.

比如说:

  • 如果答疑对听众是有价值的, 那么我们能不能把它推到极致? 极致就是如果没有人有疑问, 就不要召集会议, 由有问题的人召集会议, 而不是有信息的人召集会议, 把推模式变成拉模式.
  • 如果做结论是好的, 那么我们能不能从第一分钟起就开始做结论?
  • 如果换位思考是好的, 那么我们能不能把它做到极致, 与会人员交换立场来发言?

这类实践会比较多, 本文主要介绍在其它类似主题的资料中少有涉及的几种实践. 更全面的实践敬请期待后续介绍.

会前实践

实践: 缺省是不参会

最节省时间的方式是减少参会的数量. 对于所有会议, 缺省是拒绝参加, 除非满足以下两点之一:

  • 你有问题想当众获得答案
  • 别人有问题想当众获得答案, 而你有其他人没有的信息或观点

总结一下就是, 如果你可以不发言, 就可以不去开会. 不发言意味着你对会议议程和结果不会产生影响, 同时你有很多其它途径可以获得会议内容及结论. 而一个等价的关于会前准备的规则是, 要么带着问题参会, 要么带着信息和观点参会.

如果你不确定自己有没有问题, 比如会不会讨论中触发你的疑问, 那你随便, 自己决定.

开场实践

如果做结论是好的, 我们从第一分钟起就做结论.
实践: 一分钟结束会议常识是会议结束时要有结论. 而常识往往不是最高效的. 有多少次, 你听着主持人开场介绍各种背景, blablabla, 而你不知道重点该听哪一句, 思考哪个方面. 好一点的主持人会介绍会议目的, 但依然无助于快速得到结论.既然你已经不得不来开会了, 那么节省时间的手段无非就是如何尽快的得到结论从而结束会议. 能花一分钟就不要花两分钟. 一种做法是先说结论, 先表决结论, 不一致了再讨论, 一致了就可以随时散会了. 这个实践也叫: 先表决再讨论.

最常见的两个例子, 是面试和工作量估算. 几轮面试完毕, 面试官开碰头会决定候选人去留的时候, 可以先手势表决, 如果大家意见一致了, 那么后面的讨论就可以随意点了, 你如果有事中途离席也影响不大了. 不一致了再讨论.

工作量估算也一样. 如果你还保留着估点的陋习的话, 那么一开始也是先表决, 意见一致或接近, 讨论时间就可以压缩.

每条规则都有适用场景. 你可能觉得一分钟结束会议适用于封闭性结论的讨论, 比如上面的去留或点数. 对于开放式的讨论, 开场根本就没有结论, 如何表决?

上面的质疑是有道理的. 但即使对于开放式的讨论, 也可以开场就扔个结论出来, 不过其意图不是快速结束讨论, 而是更好的激发讨论.

会中规则

如果积极思考是好的, 我们就把它做到极限.
下面的抛玉引砖, 欺负老实人, 挤牙膏等实践希望把与会人员的思路激发到极限.
实践: 抛玉引砖你很不幸, 会议没有在一分钟内结束, 只能让讨论尽可能高效了. 人们总是善于批评, 拙于创造. 利用这一点, 你只需扔块玉, 就能激起民愤, 群起而攻之, 一堆板砖飞过来.为什么不叫抛砖引玉呢? 这牵扯到对初始结论的要求. 初始结论必须极端, 才易于激发讨论. 它要么是工作量最小最简单的, 要么是最大最复杂的, 要么是最无厘头的. 总而言之, 你需要脑洞大开. 四平八稳的结论无助于大家思考.

比如对于任何(注意是任何)需求实现方案的讨论, 你都可以这样开头: “这个功能, 我们打算用导入导出Excel来实现, 大家有什么意见吗? “ (“有, 为什么不用金数据?” “…”)

实践: 欺负老实人

有时候作为主持人, 你感觉到场内不是每个人都精力集中, 开动脑筋, 而是开小差, 看手机等. 或者即使不看手机, 也感觉没有投入. 如何让大家始终精力集中呢? 你只需缺省做出对大家不利的结论即可, 除非参会人员抗争, 否则就是定论.

还是拿估点的陋习举例, 尤其是你的交付方式是基于承诺的风格的话. 在计划会议上, 你可以宣布, 所有story, 缺省都是一个点, 或者都必须在一天内完成, 除非开发团队拿出足够的理由. 这时大家为了合理的工作计划, 必须全神贯注的讨论对Story的理解.

会有一些副作用吧. 所有规则都有适用场景. 这个适用于跟团队的信任关系已经建立起来, 团队理解这是讨论的技巧而不是真正的压迫.

实践: 挤牙膏

有时你会发现气氛比较沉闷, 掌握最多信息的人拼命在说, 想把知道的一切都告诉大家, 但听众没什么反应. 一个可能的原因是你说的太多了, 剥夺了听众主动思考的机会. 那么指导思想很简单: 说得越多越沉闷, 问得越多越活跃, 我们只需要制造一种张力, 让团队不得不问.

还是拿估点陋习来说. BA惜字如金, 拿着Story, 除了念一遍, 不做任何解释, 就让大家估. 除非开发人员发问, BA不需要说任何一个字. 就算是回答开发人员的问题, 也点到为止, 一个字都不多说, 除非开发人员继续发问. 反正缺省都是一天做完, 而BA可以通过Story Kickoff, Story Signoff等手段来把关不会有验收条件缺失. 开发人员要争取合理的开发时间, 必须主动发问以获得足够的信息. 这在基于承诺的开发方式中比较适用.

如果获得全面的观点是好的, 我们就把它做到极限.

下面留白, 拱卒, 暗牌, 叛变等实践, 都是为了获得最全面的意见.

实践: 留白

如果你有多于其他参会人员的上下文, 甚至你知道讨论的话题某种程度上在开会之前就已经有结论了, 但你又想知道大家真实的想法, 各自的逻辑, 以便更好的利用集体智慧, 那么你应该留白, 不要一次性把所有上下文和结论都扔出去, 而是随着讨论的推进, 一点点的把约束加上.

上周项目开工会之前, 韵涛纠集了少数几个人上午讨论了下开工的准备工作, 有了一个初步的事项列表. 下午整个项目组开工讨论的时候, 我并没有直接抛出上午的结论, 而是让大家提供自己的意见, 就当上午的会没有发生过. 上午的结论只是备胎, 查缺补漏.

实践: 拱卒

有时你提供了发言机会, 但发现机会被少数人把持, 其他人参与程度不高. 常见的建议是轮流发言. 这里我要说的是, 仅仅轮流发言是不够的, 顺序很重要.

参与程度不高的两个原因是:

  • 即使我不参与, 反正也有别人参与, 即使没有我的输入, 反正也能得出结论.
  • 别人都已经说了, 我没有什么新东西.

那么我们可以让寡言者, 对话题不熟悉不权威的人先发言, 上面两条原因的前提都不存在了: 此时还没有别人参与, 别人也没说什么, 那么我不得不说. 而对话题上下文比较熟悉的人, 永远都可以在后面补充, 他们不会有什么顾忌.

统计表明, 机长驾驶飞机的事故概率高于副机长驾驶飞机的事故概率, 因为机长驾驶的时候, 就算副机长发现有什么不对劲, 也不太敢指出. 而副机长驾驶, 机长在旁边监督, 一旦发现什么问题, 机长是没什么顾虑的. (信息来自<<异类>>). 这是类似的做法.

实践: 暗牌

跟拱卒类似, 你想获得更全面的观点, 但又担心部分人员被权威影响. 那么只需让每个人准备好自己的观点, 同时亮出来就可以了. 这样异议就会暴露出来, 获得足够的关注. 面试和估点依然是常见的两个例子. 它跟一分钟结束会议形式类似, 意图不同. 一分钟结束会议是为了节省时间, 暗牌是为了暴露异议.

实践: 叛变

当你总是基于自己立场的话, 你是狭隘的. 常说要换位思考, 那为什么不直接换位呢? 销售和产品团队开会, 销售人员从产品团队立场去辩论, 产品团队从销售立场去辩论. 任何涉及多种角色合作的会议, 都可以尝试换位.

如果具体比抽象好, 那么我们就举例说明, 看图说话

实践: 比如说

有的人说话形容词副词太多了, 动词名词代词量词数词太少. 智能的, 自动的, 高效的, 等等. 碰到这种情况一定要摁住, 让他举例子. 你不需要在意他说了什么东西, 你只需要在他说完一句话停顿的空隙朱唇轻启补上一句: “比如说?

实践: 看图说话

这个在别处有详细介绍, 比如<<视觉会议>>等. 不多说了.

如果简短是好的, 我们就做到极限, 一个词, 一句话, 一分钟.

实践: 调教

有的人讨论很发散, 表达很跳跃, 永远都是在陈述, 在打转转而不对原始命题表态. 这种情况一定要摁住, 让他做完形填空. 打断他直接追问同意还是不同意, 限制他一个词或一句话或一分钟表明立场.

一个完形填空的例子就是Elevator Pitch, 提供一种结构化的断言, 来收敛结论.

收官实践

如果达成共识是好的, 那我们就追求内心深处的共识.
实践: 闭卷考试“大家都清楚了吗?” 这种问题是没有意义的. 大家都说”清楚了”你也无从确认是否真的清楚了. 而在讨论结束的时候, 我们需要每个人都对当天的结论, 后续的行动有一个一致的认识. 会议结束前我们必须验证大家的理解. 方法也很简单:关掉投影, 擦掉白板, 合上电脑(除了放投影的机器, 这个东西本就不应出现在会议室)和记事本, 参会人员依次回答每个议题的结论, 以验证对会议的理解是一致的. 第一个人说第一个结论, 然后问其他的人是否同意还是认为结论另有其它. 说完之后第二个人说第二个…

要点在于参会人员不得参考任何资料, 只能依赖自己的大脑.

实践背后的原则

上面的一组极限会议实践, 背后其实基于两条原则: 以终为始, 保持张力.

  • 以终为始: 在最早的时刻就把候选结论抛出来, 后续的讨论只是对初始结论的修正. 任何跑题的讨论都通过命题调教或举例说明拉回来.
  • 保持张力: 方式很多, 暴露异议来PK, 减少必要信息供给来促进思考, 制定不利的初始结论来提升紧迫感.

组合运用这些手段可以得出更多的规则.

答疑

这么着急得出结论, 会不会有些话题没有足够的时间充分讨论而错过更多可能性?

丧失部分可能性是可能的, 但讨论是否充分, 跟时间长短没有必然联系, 更能影响讨论充分性的, 是看目的是否明确, 是否有备而来, 是否有足够张力让你调动大量脑细胞. 给你充足的时间反而放松了. 放松的环境, 随意的交谈或许有助于激发灵感, 但那不需要组织会议也可以创造这种条件.

另外不是每个规则都奔着”时间短”去的, 比如”留白”. 真正的关注点还是效率: 单位时间内更充分的沟通和理解.

有些建议是冲突的, 比如”一分钟结束会议”和”留白”

实践不只包含具体操作, 还包括场景及意图. “一分钟结束会议”和”留白”的场景及意图不同.

Share

在ThoughtWorks我们如何做内部培训?

banner

ThoughtWorks内部培训

对新人的培训是每个企业都绕不开的一个话题,企业当然想要每个新人都能直接独当一面,最好可以直接上项目贡献自己的价值。但是从经验来看,所有新人到一个新环境都需要学习很多不同的新东西(新技术,框架,语言,工作方式等等),而每个企业对于培训新人都有各种各样的策略,比如老人带新人,比如扔到项目上让新人自己学。

在ThoughtWorks,我们有着丰富的培训方式,有面向社招的,有面向毕业生的,有民间自发的,有官方组织的,有内部的,也有面向社区的。

TWU

TWU全称ThoughtWorks University,面向毕业生,入职之后的第一堂课。TWU的地点设在印度,之前在班加罗尔,后来改到了普内。每一期5周,学生们需要和和全球其他国家地区的同学一起,一般会尽量将各个地区的学生打乱安排,尽量让学生体会多元化的文化,培训内容设计公司文化,软件开发方法论,敏捷开发(Project SImulation)实践等,同时还需要保证学生有足够的代码练习机会。

我在2013年作为讲师参加了一起TWU,对我自己的帮助也非常大,在和来自不同地区的讲师一起备课,学习中学习到了很多的东西,之前似是而非的一些概念也得到了纠正。

twu

TWI

TWI全称ThoughtWorks Immersion,面向有经验的社招同事,主要涉及的内容为公司文化(合作,沟通),专业服务(如何专业的解决客户的问题),软件开发流程,敏捷开发方法论等。

我在2012年时参加过TWI,并整理了几篇相关文章,可以参考这里这里还有这里

twi

Session

Office局限在ThoughtWorks办公室之内,内容随意,参加不参加随意,可以随时加入或随时离开。虽然内容没有限制,但是大多数时候分享的都是技术主题。比如自动化部署自动测试Spring 4Ruby中的构建工具等等。

Sessoin的形式是主讲者找一个自己感兴趣的主题,一个人讲,其他参与者听,鼓励互动。时间一般控制在一个小时以内,所以一般选择在中午饭的时候,有的session会给大家订饭,一边吃一边听。

虽然大部分Sessoin的主题是技术相关的,但是并不局限于此。比如旅游见闻,历史,财务,摄影等等,都可以分享,有时候这些趣味性的Session的参与者更多。

session

WorkShop

Office之内,内容随意,以动手为主,讲解为辅。

  • HTML/CSS
  • Testable JavaScript
  • 设计工作坊
  • OO BootCamp
  • Ruby BootCamp

一般来说,Workshop都会组成一个系列,通常会占用几天到几周不等。参与者需要带上电脑,在课堂上进行练习之外,课后还会有一些练习。

3周3页面可测试的JavaScript是我去年做的两个Workshop。由于Workshop会在下班后或者中午的休息时间,公司会为每个参与者订饭,以节省时间。

郑大晔校

面向刚刚得到offer的毕业生,在上项目之前,我们希望学生的基本技术达到特定的水平,因此设置了一系列的练习。包括

  • 编程基础
  • 开发流程
  • 工作方式
  • 公司文化

等等。郑大晔校的周期为每周一次,一次一天。涉及的内容会与大多数项目上的要求一致,比如西安office的Java/Ruby项目居多,我们的课程安排就会涉及到Java/Ruby方面。当然,各种软技能如工作方式也会在课程中涉及,尽量的寓教于乐。

每期郑大晔校大概会有10周,学生入职之后有的会直接去TWU,有的则会在项目上工作一段时间再去TWU。

组内培训

各个组内自行组织,并不要求其他同事参加。比如某个项目需要一些docker的知识,或者需要AngularJS相关的培训,一方面是找自己组内的专家组织一次内部培训,,另一种是找办公室内相关的专家来进行培训,形式比较灵活。

  • 项目中已经在使用的技术
  • 项目中将要使用的技术
  • 请别的组的专家来咨询

group learn

社区

  • OpenParty
  • Rails Girl

rails girl

问题

  • 谁当讲师
  • 活动经费
  • 内容如何持久化(人,内部知识分享系统)
  • 如何保证效果(宽松)

由于对任何的话题都没有限制,也没有对参与者的限制,因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施,参与者和主讲者都凭着自己的热情来组织,这也算是比较独树一帜的事情。

而关于内容的持久化,更多的是为参与者打开一扇新的窗户,或者说洒下一些火星,而至于火星如何形成燎原之势,则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后,被问到最多的问题是如何强迫参与者产生热情?

这个问题在ThoughtWorks不是问题,我们在一个人进入公司的最开始,也就是面试的时候,就考察了他的热情,如果在热情上有缺陷,则很可能会直接拒掉,免得破坏我们好不容易构建起来的学习氛围。

Share