透明思考

我们如何对外推广创新成果

在向企业外部的行业社区进行推广时，内容的组织就显得尤为重要。常见的对外推广的渠道有微博、博客、公开演讲、文章、书籍等，这里不必赘述每种渠道的特点，反而值得指出这些渠道的相关性：实际上，有机地用好这些渠道，有助于组织作者的思路和获得反馈，从而获得更好的内容。

个人而言，当一个内容结构在我脑海中出现时，我会快速地在微博上把它写出来。140字的限制恰好有助于我厘清最核心的要素，从而形成一个可以在30秒内讲出来的电梯演说（elevator pitch），随时可以跟任何人介绍我的想法。随后我会用脑图把内容结构整理出来 ，再用一篇不超过2000字的博客来阐述这个结构 ，其中只有最简单的介绍，不做任何展开。这样一篇博客已经足以唤起有类似痛点的读者的共鸣，他们会给作者提供反馈。

随后，作者就可以把这篇博客交给媒体——包括在线媒体和印刷媒体——的编辑，看这个内容对他们是否有吸引力。如果某个媒体愿意发表这样一篇文章，就可以根据该媒体的特点在内容骨架的基础上增加阐述和实例，形成一篇文章并发表。与此同时，基于同样的内容骨架，作者也可以做出一份演讲稿，写文章时用到的阐述和实例即可填到PPT的“演说者备注”当中。于是当文章完成时（实际上，通常在文章完成之前），你就会得到一个结构严整内容丰富的演讲稿，到各种有影响力的行业会议（例如InfoQ举办的QCon）去提交你的演讲话题吧。

在Moco这个例子上，我们做的还不止这些。在InfoQ中文站发表了一篇文章之后，为了让客户看懂，ThoughtWorks成都的两位同事银大伟和崔鹏飞把这篇文章翻译成了英文，随后我们意识到：这篇英文的文章同样可以发表。于是我们又联系了InfoQ全球主站的编辑，向他们投稿，并且再次被采用了。经过几轮反馈和修改，这篇文章在InfoQ全球主站发表了。我们还提名Moco参加Oracle主办的“Duke选择奖”（Duke’s Choice），并最终获奖。至此，Moco已经由一个籍籍无名的内部创新变成了具有较大业界影响力的开源项目。

为什么大家都应该读SICP

【2006年】来到班加罗尔，我的包里带着一本《计算机程序的构造和解释》，也就是传说中的SICP。这本书是MIT（麻省理工学院）的6.001课程、电子工程与计算机科学系本科第一门编程课的教材，MIT网站上还有教学视频公开着。这本使用LISP作为教学语言的教材在MIT被使用了超过二十年，甚至在1984年成书之前就已经被该系教师用于教学，直到2008年才宣告退休，且继续被无数黑客顶礼膜拜。

可别小看了这本MIT的编程入门教材。看看目录你就会发现，这本书不一般：

第1章 构造过程抽象1.1 程序设计的基本元素1.2 过程与它们所产生的计算1.3 用高阶函数做抽象第2章 构造数据现象2.1 数据抽象导引2.2 层次性数据和闭包性质2.3 符号数据2.4 抽象数据的多重表示2.5 带有通用型操作的系统第3章 模块化、对象和状态3.1 赋值和局部状态3.2 求值的环境模型3.3 用变动数据做模拟3.4 并发：时间是一个本质问题3.5 流第4章 元语言抽象4.1 元循环求值器4.2 Scheme的变形——惰性求值4.3 Scheme的变形——非确定性计算4.4 逻辑程序设计第5章 寄存器机器里的计算5.1 寄存器机器的设计5.2 一个寄存器机器模拟器5.3 存储分配和废料收集5.4 显式控制的求值器5.5 编译

每个小节的标题看起来已经有点高级了吧？其中的内容比标题所透露出来的还要高级。比如第二章，一上来讲的就是“什么是整数”：在只有函数（准确说，只有lambda运算）的情况下，如何定义“0”，如何定义加法，从而得到一个完整的整数系统。再比如第三章，它讲的是“什么是时间”。当“整数”、“时间”这样的基本概念都需要被重新定义，这本书对读者世界观的颠覆性可想而知。

如果说这些内容有点过于抽象、过于远离现实的话，书中关于列表和高阶函数的内容则会改变一个程序员看待很多编程任务的方式——主要是看待列表（list）操作的方式。众所周知，LISP是“LIStProcessing”的缩写，也就是说“操作链表（linkedlist）”乃是LISP的题中应有之义。从最原始的递归函数调用开始，SICP归纳出一组基本的列表操作（求长度、添加元素、排序、反转等），然后是几个最常用的列表计算：map、filter、accumulate。这几个概念是如此简洁清晰，实现又是如此简单，一旦进入了脑子里就再也无法忘记。比如map操作，SICP的描述是：

…to apply some transformation to each element in a list and generate the list of results.

也就是说，你手上有一个列表，你要对这个列表里的每个元素通过“某种方式”进行转换，从而得到一个等长的列表，前后两个列表中的元素根据“某种方式”一一对应。这就是列表的映射（map）操作。于是对于所有“从一个列表映射到另一个等长列表”的操作，你就再也不会去写for循环。例如“列出一组用户的年龄并由大到小排序”这个需求，你就会这样写（Ruby代码）：

# users是一个列表

users.map{|user| user.age}.sort.reverse

显然这比每处理一次users列表就写一次for循环要漂亮太多了。有了这样的概念在脑子里，我才开始愈发清晰地意识到：针对列表的for循环，在大多数情况下也是一种重复代码。后来Google的Java基础库Guava提供了列表的transform操作（也就是map操作，只是换了个名字）和filter操作，使这些发轫于LISP的列表操作终于被广大Java程序员所了解。

有趣之处在于，像“抽象出基本的列表操作”这样的想法，即使是经验丰富的程序员，没有通过读书或者别人的讲解获得这个概念之前，是很难通过自己的实践和思考总结出来的；而一旦获得了这个概念，又会觉得它如此符合直觉以至于不这样思考才是奇怪的。在厦门的好望角项目里，我自己实现了map操作和accumulate操作，用来处理程序中的列表。Andy看了这段代码的第一反应是“Err…it’sclever…”我们知道，“clever”其实不是什么褒义词。后来我又在一个超过20年经验的老程序员身上看到过类似的反应，尽管这次用Guava写出来的代码更加好看。没有获得“天启”之前，我们就是根本看不到这种“高阶的”重复代码的存在。如果说在我学习编程的整个过程中有那么一本书是不可替代、不可能靠自己的勤学苦练弥补起来的，那就是这本SICP。所以我现在也总是向所有有志于从事软件开发工作的人推荐这本书——未必急在一时，但早晚得读。

（八年前）我在ThoughtWorks的第一个月

（2005年10月，我刚满25岁。跟现在的很多新同事一样，满怀憧憬地加入了ThoughtWorks。那时的ThoughtWorks，很多东西和现在不一样，对新员工也没有现在这么多的关爱。但在这第一个月里，我还是学到了很多……）

连着国庆节，我给自己放了25天大假，然后去西安报到。正如郭晓所说，作为一家咨询公司，ThoughtWorks的办公室很空，除了我之外总共三个人，其中倒有两个我已经认识：徐昊早我一周入职；陈慧是行政主管，管一切杂事。漂亮的HR夏洁拿过一堆文件让我签字，然后四人就在办公室相依为命。那是在软件园秦风阁一个两百多平米的小办公室，连厕所还是和隔壁家公司共用的。

Sid和郭晓不在，直接的影响就是没人知道我和徐昊应该干什么。我问夏洁，夏洁撑着下巴沉思半晌，说：“这样吧，我给你问问。”过了一会儿，她过来说：“我给郭晓打了电话，郭晓说他也不知道，让你们自己看着办，什么有价值就做什么。”传说中“给员工最大自由度”的管理哲学，原来真正发生的时候是这样的啊……于是我俩就开始到处找活儿干：帮着印度同事配置西安办公室的内网，跟夏洁参加校园宣讲，翻译公司网站，凡此种种。总之不能闲着，太难受。

说起翻译公司网站这事儿挺有意思：我们跟着夏洁去参加在西安电子科大的宣讲，主题大概是关于求职与就业的，中间有个学生反映说看了我们的网站但是看不太懂。回去的路上一讨论，虽说我们也觉得连这么个网站都看不懂的人应该就不属于我们的招聘目标了，不过还是有个中文网站比较好。于是我在邮件列表里一问，找到现在维护网站的人，开始着手翻译网站上的内容。

翻译公司网站至少给我两个收获。第一，让我快速地把公司业务熟悉了一遍，知道我们做些什么、为哪些客户服务；第二，从发布网站内容的过程中我学到了一些软件开发的实践。比如说整个网站是放在SVN里的，而且不光网站，连运行网站所需的Tomcat也在SVN里，所以只要有一台装了JRE的机器就可以运行整个网站。这种把运行环境也配置管理起来的做法，我在以前的工作中是没见过的。

四个人相依为命过了两周，又来了一位老兄：从加拿大来的JeffreyQiu，华裔，中文名叫仇俊义，出生在新加坡，之前在卡尔加里办公室工作，现在携家带口回国来支援中国分公司建设了。Sid和郭晓也回来，Sid进门就大喊“Hello, my Jeff andJeff！”（我的英文名也叫Jeff）。这时办公室总算有点热闹劲儿了。

郭晓一回来就给我安排活儿：“11月底有个演讲，可是我不一定有时间去北京，你来讲怎么样？”

“行啊，什么主题？”

“敏捷软件开发。我这儿有个英文的PPT，你和Jeffrey一起准备一下，做个中文的材料吧。”

这个PPT的结构很简单：先是几页公司介绍，全球5个国家（美国，加拿大，英国，澳大利亚，印度），500多名员工，技术上领先，出版了一堆书；然后是敏捷的优点；接着讲敏捷实施中的一些实践，测试驱动开发啦持续集成啦结对编程啦什么的。我觉得最有意思的部分是“敏捷的优点”，这个PPT用这样一张图来讲述迭代式软件开发：

郭晓给我讲解：这张图的要点在于软件产生业务价值的时间，也就是图上的美元符号。按照传统的瀑布式开发流程，要到最终项目上线时才产生业务价值；而采用迭代式开发方法，第一个版本发布上线就已经开始赚钱。两者相比，迭代式开发产生的现金流比瀑布式开发要好得多。之前我也曾经给别人讲过敏捷，但这还是我第一次听到从现金流的角度来看待软件开发方法。以前我总觉得敏捷是一个程序员喜欢的软件开发方式，而管理者则会本能地反对，因为这种方式给了程序员更多的自主权。听郭晓这么一讲解，我才意识到：敏捷其实是可以把客户、管理者和程序员的利益协调一致的。不光是程序员会喜欢敏捷，老板、客户也会喜欢。

想到这儿，我突然想起个问题：“这次是什么活动啊？讲给谁听的？”

“微软的企业决策者峰会，”郭晓答道，“大概是他们那些大客户的CTO啦、研发主管啦之类的吧，还有就是跟微软合作的开发商了。我们被邀请做keynote，微软应该会有个副总开场，你跟在他后面第二个讲。”

“啊？”我盯着郭晓，想确定他是不是在开玩笑。

“没事儿，你是代表ThoughtWorks的。”看我这么惊惶的样子，郭晓开始安慰我，“再说你对敏捷很了解啊，其他人根本不知道敏捷是怎么回事，你就是专家，大胆去讲好了。”

好吧，你敢交给我，我就敢站上去讲。接下来的三个星期，我每天抽着空就跟Jeffrey结对准备演讲，先把PPT全部翻译成中文，然后一页一页练习，感觉讲不通就自己删改。因为心里没底，我练得很细，连每句话怎么说、每个手势怎么做都预先做了准备。后来有一张照片，是我在演讲的时候抬起左手数“第一、第二、第三……”，而且是从大拇指开始算“第一”。这个小动作以前我是没有的，就是看Jeffrey有这个习惯，我觉得还挺酷的，练习中不知不觉就学了过来，一直到现在说话时也还有这个习惯。

演讲本身平淡无奇，没出什么纰漏也没什么特别的反响，有两个听众问“有没有国内的成功案例”，听说我们刚到中国还没有成功案例也就转头离去了。那天我穿了一件灰色的衬衣去上台，这是我长这么大以来头一回做衬衣西裤皮鞋的装扮。都是让郭晓给逼的。

打造创新型组织

（本文系昨天在QClub所做同名演讲的摘要。）

所有的企业领导者都在说他们希望自己的组织充满创造力，所有的员工都在说希望加入一家充满创造力的企业。但是真正有创造力的企业并不多。打造一个创新型的组织并非易事，它需要企业领导者刻意地经营和培育。（全文结构如下，可以点击看大图。）

ThoughtWorks成都公司的创新

作为一家成立时间不长的分公司，ThoughtWorks成都公司已经催生了一些值得留意的创新。例如Moco这个用于Java应用集成测试的工具，已经有多个国家的用户，并且有一篇文章在InfoQ中文站发表，英文版本即将在InfoQ全球站发表。再例如移动开发，成都的同事提出了数字渠道细分带来的架构演进和精益的移动应用开发。

除了这些已经进入公众视野的创新，还有数量众多的微创新、小改进正在公司内部发生。去年4月才开门、绝大部分员工来自本地招聘的这个分公司，体现出了很强的创新氛围。

为什么要创新？

这种创新的氛围，是ThoughtWorks公司自身、客户和员工三方的要求共同促成的。

• 作为一家专业服务公司，ThoughtWorks需要用创新来提升服务水平。
• 我们的客户并不是来采购廉价外包劳动力的，他们希望IT合作伙伴给他们提供新思路、新方法、新技术。
• 员工希望通过创新提升自身能力和竞争力，并且让工作更有趣。

创新的迷思

业界存在很多关于创新的误解。

• “改变世界的大发明才叫创新”。实际上重大发明只是冰山一角，更大数量的是微创新，它们的价值绝不亚于“大创新”。而且大创新往往是由微创新积累产生的。
• “创新靠的是不可控的灵感”。实际上创新的点子很大程度上可以由日常工作的痛苦与约束催生出来，这个过程是可组织、可管理的。
• “创新只能靠一小群人在车库里进行”。实际上成熟的企业可以提供很多资源来支撑创新，在成熟企业架构下很多人进行创新是有可能的。

《精益创业》提供了一个很好的框架：build=measure=learn。创新活动同样可以用精益的方式进行。

创新漏斗

由微创新到大创新，组织需要一个漏斗型的机制。漏斗的关键在于两点：（1）保障源头点子的丰沛；（2）保障中间流转的畅通。

1. 发现痛点。从日常工作中发现不爽的事情，以及留意别人不爽的事情。每个痛点就是一个潜在的创新。
2. 解决问题。发挥持续改进的精神，有痛点就解决，让生活和工作变好一点点。
3. 分享经验。把痛点和解决方案分享给整个组织，很可能别人就有类似的问题。
4. 泛化桥接。从一时一地的解决方案抽象出具有普遍适用性的概念，这就是一个通用的创新了。
5. 宣传推广。得到通用的创新之后，积极宣传推广，使更多人知道它使用它，给它提供反馈。

每个环节都需要一些具体的措施来推动。企业管理者的职责之一就是使这个机制运转起来。

领导者的职责

作为有心打造一个创新型组织的领导者，有一些要点需要特别注意：

• 意识。在企业中树立改进和创新的意识，让大家知道创新是被鼓励、被要求的。
• 眼界。帮助同事开拓眼界，把一时一地的问题和解决方案与更广泛的环境联系起来，使创新的想法发挥更大价值。
• 资源。用企业资源支持创新活动，包括时间、技术、高层关注、外界曝光等等。

在所有的方法与机制之外，创新的根源是乐于助人的精神：只有痛苦于别人的痛苦，才会有发自内心的动力来想办法改善。因此在所有的“术”之外，一个创新型组织应该是外向的、乐于助人的，不仅帮助自己的同事和客户，而且渴望帮助更广大范围的同行乃至社会弱势群体。这种助人的内驱力是企业保持创新动力的“道”之所在。

学画素描不难的

学画素描这件事，我是几年前看一本书《像艺术家一样思考》学起来的。我的亲身经历证明，只要照着这本书来练习，任何毫无美术功底的人都可以在一两个月之内画出让自己惊叹的素描。

这本书讲的最重要的一点：不会画画不是因为你手上画不出，而是因为你眼睛看不到。很多时候我们看到的不是我们真正看到的，而是我们想看到的，对画画也是一样。

比如说吧，当你想画个熊猫，你会怎么开始？反正我就会想：熊猫么，圆头圆脑的，黑白相间的…于是我就画出了这么个东西…

额…这种淡淡的忧伤感是从哪儿来的…

这本书告诉你，你别老想着画熊猫，因为“熊猫”这个概念会在你脑子里造成一个过度简化的投影，使你不能看到眼睛所看到的。你要画的，是物理世界真实存在的线条、形状、色彩，不是“熊猫”这个概念。

所以我换了个方式。我这次照着娇子香烟盒上的熊猫来画，并且我只是在画我所看到的线条、形状和位置关系，我彻底忘记面前的是个熊猫……

嘿，这回有点意思哈？

这本书讲了很多方法，教你怎么抛开左半脑的影响，用右半脑去“看见”这个真实的世界。比如有一个很好玩的练习：把一幅世界名画上下颠倒过来，照着去临摹，这时左脑已经无法理解那些线条代表什么概念，只好把控制权交给右脑，这时你就能更清晰地看到线条、形状和位置关系。两个小时以后，你会惊讶地发现两件事：第一，时间竟然流逝得这么飞快；第二，你竟然能临摹出这么精彩的画作。

当你习惯了看到双眼真正看到的东西，你就可以照着相片画、照着图片画、照着桌上的静物画，你可以出门去写生，画建筑、画植物、画人像。你会发现，画什么东西根本就不重要，因为“什么东西重要”是左脑的事，而右脑主导的素描过程每次都能让你体验这两种惊讶。

在每天练习一小时后，我第二个月——也就是四五十小时的练习时间——就画出了这样的人物素描（猛击图片还有更多）：

画素描能让人进入“心流”状态，而且很有成就感。所以这是件很爽的事，而且每个人都可以很容易地做到。所以你真的也应该试试。

（本文是应彭萦之邀，为“改变自己”这个微信公众账号所写的。这个励志的微信账号致力于帮助读者“每天改变自己一点点”。感兴趣的话可以搜索微信公众账号“wechanger”，或扫描下面的二维码。）

五天之内，三步读懂一个行业

作为职业咨询师，在很短时间内熟悉一个行业，是我经常要面对的工作内容，我也很愿意分享自己的心得。根据我的经验，对于掌握了基本商业知识的咨询师而言，一个星期之内熟悉一个之前陌生的行业并非难事。当然一个星期不会让一个新鲜人成为行业专家，但是足以让一名咨询师在这个行业里顺利开展工作。

这有限的五个工作日，必须高效地利用。我的建议是分三步走：首先，确保自己不会乱开黄腔；其次，让自己进入这个行业的对话；第三，争取提出令人眼前一亮的观点。

第一步：首先不要开黄腔

进入一个新的行业，首先应该了解这个行业里的领导企业——很可能正是你马上需要去服务的企业。了解一个领导企业最直接的方式，就是读它的财务报表。上市企业的财务报表都是公开的，并且通常会附上很有用的董事长致投资者函。阅读一份财报，就可以了解很多基本的信息：这家企业的所有权性质、主要业务、主要客户、收入结构、成本结构、员工规模、人才结构、战略方向、主要风险……即便你真正想了解的企业是非上市企业（比如华为），它也必定与其最主要的竞争对手（比如中兴）有很多相似之处。所以阅读财报可以让你对这个行业里的主要玩家有一个基本的了解，不至于提一些太离谱的问题或者建议。

花一天时间读完一两家企业的财报之后，接着就得下点死工夫，读一本这个行业的综述性书籍，例如对于保险行业我推荐《风险管理与保险》。读这样一本书的目的，第一是更深入地理解这个行业的商业模式和惯例，比如你得知道财产险和寿险存在一些根本性的差异所以它们的经营也会很不同；第二是掌握一些行业里的“黑话”，比如当你听到“承保”、“核保”时你得知道这都是指什么。我个人而言，读这本书是用业余时间，加起来用了8小时左右。

第二步：进入行业对话

做到了不开黄腔也还不足以跟行业里的CxO们展开对话，因为大家平时不会谈论那些最基本的东西。要进入一个行业的对话，你得了解这个行业当下的趋势。有些人会推荐跟行业里的朋友去聊天。但作为一个时间紧迫的内向型人，我个人更愿意以研究材料为主，与朋友聊天为辅。

行业趋势的最佳来源是麦肯锡之类管理咨询公司做的行业分析。我个人尤其推荐麦肯锡季刊（McKinsey Quarterly）发布的研究报告，以及经济学人（The Economis）的行业分析。从这两个网站搜出最近五年所有与你关注的行业相关的文章，花一到两天时间全部通读一遍，你应该就能把握住这个行业的脉搏。

在中国市场上工作，我们会担心来自麦肯锡和经济学人的分析不够“中国特色”。我的经验是，一方面可以适当补充一些本土内容；另一方面，中国各行各业的发展基本上与世界先进水平保持3~5年的差距，也就是说欧美发达国家在三五年前发生过的应该就是中国当前正在发生的，欧美发达国家一两年前发生过的应该会在一两年后在中国发生。比起“中国特色”，很多时候简单的市场规律和时间差更有效。

与此同时，在这整个一周时间里，你要让自己浸泡到这个行业的上下文中。办法很简单：订阅一堆与这个行业、与你想要针对的目标企业直接相关的新闻RSS，把其他的RSS频道都暂时屏蔽，在地铁上、咖啡馆里、床头上、马桶上……所有的空闲时间都用来看这个行业、这家企业最近发生了什么。比如我在关注澳洲保险行业的阶段，就订阅了GoogleNews的“australia insurance”关键字和我客户公司的名字，客户公司出什么重大理赔案或是高层人事变动，我能比客户的大多数员工还先知道消息，于是就有了很多可以谈论的话题。

第三步：以我为主，提出观点

开始这个连载的时候彭萦讲了一个故事，说某咨询公司的创始人要应聘者一周内给出一份行业报告，但回头他发现这些名校毕业生做的报告都没有一个亮点。且不论这个故事是真是假，在我看来，“没有亮点”的症结恐怕就在于应聘者是“毕业生”：虽然是研究另一个行业，其实“亮点”的关键不在对那个行业研究得多好，而在研究者自身的专业技能。所谓“功夫在诗外”，就是这个道理。

举个例子来说。如果你看麦肯锡去年所做的中国寿险行业分析，首先你会发现它遵循了前面说的两步：数据详实，术语准确，而且把握住了行业脉搏。但它的亮点在于它指出了中国寿险行业的几大痛点，并且从战略和管理的角度提出了对应的解决方案。归根到底这才是行业里的CxO们期望你作为一个专业人士拿出来的东西，也是你之所以要去快速了解这个行业的根本目的：快速了解一个行业不是为了显示自己的学习能力，而是为了使自己的专业技能在这个行业中得到运用。

所以，在做了前两步功课之后，你至少应该给自己留出一整天的时间来回答这样三个问题：

1. 这个行业所面临的痛点有哪些？
2. 哪些痛点对于业内人士是最紧迫的？
3. 如何把自己的专业技能与这些痛点结合起来？

其中前两个问题的答案应该是相对客观的。也就是说，你大可以把麦肯锡的寿险行业分析打印出来，扔掉最后的“解决方案”部分，然后结合自己的专业领域，来尝试给它所列举的几大痛点寻找解决方案。如何用IT手段改善寿险销售？寿险行业需要何种人力资源战略？甚至何种MBTI人格更适合从事高水平的寿险服务？凡此种种不一而足。提出观点这部分，就是专业人士站在自己专业领域的命题作文，能不能讲出亮点，第一靠快速理解目标行业的小聪明，最重要的还是看在自己专业领域里的造诣。

（本文是应彭萦之邀，为“改变自己”这个微信公众账号所写的。这个励志的微信账号致力于帮助读者“每天改变自己一点点”。感兴趣的话可以搜索微信公众账号“wechanger”，或扫描下面的二维码。）

十年前的Java企业应用开发世界

在2003年用Java编程比现在要更痛苦一些。比如说，J2SE 1.5还没有发布，也就是说一些现在大家认为理所当然的特性，比如泛型容器、staticimport、Annotation，都是不存在的；Integer和int是不能自动转换的；枚举只是整数换了个写法没有任何类型安全机制……我还在2003年第6期《程序员》杂志发表了一篇文章，介绍J2SE1.5的新特性。而在项目里，不管是浙江省财政厅的项目，还是杭州市工商局的项目，我们用的都还是J2SE 1.3。

更大的挑战——或者说，乐趣——是框架乃至编程思想的不统一。几年以后，当Java企业应用开发彻底成熟，所有人都知道SSH（Spring+Struts+Hibernate，后来Struts终于被SpringMVC取代），连培训学校也拿这几样东西来作为就业敲门砖。可是在2003年，MartinFowler那篇“Dependency Injection”还没发表，关于“什么是好的容器框架”还远远没有定论。且不提ApacheAvalon这样的容器——照现在的眼光来看，Avalon根本算不上一个合格的容器，但你必须意识到它是Java 1.3之前的作品，这样才能理解为什么它会存在并进入这个讨论——Spring之外还有PaulHammant和JonTirsen的PicoContainer在与之竞争成为事实标准。而当时还在0.x版本的Spring（当年10月Spring才发布1.0版本），其功能也并不比单纯专注对象容器的Pico丰富。

Web框架的情况更加混乱。Struts被使用最多同时也被诟病最多；RickardOberg刚做出了WebWork，大家还没充分意识到它的好处。更麻烦的是，其时整个J2EE社区并未——像今天这样——达成一个共识说“MVC是好的”，于是其他种种构造Web应用的方式以及相应的框架层出不穷：有人相信Web开发也应该走“组件化”道路，于是有了面向组件的Web框架（例如Tapestry）；有人认为Portal才是未来Web的发展方向，于是有了形形色色的Portlet容器（例如JetSpeed）；甚至还有人尝试用“XML文档+XSLT转换”的方式来实现Web应用。当年最火的全功能Web框架还是Turbine ，到如今它给我们留下的也就只剩Velocity了——恰恰Velocity所代表的“viewtemplateengine”在当时还没有被广泛接受，更多人仍然习惯于在JSP里直接写上一大堆Java代码。当时有人笑称，每周都会有一个新的Web框架在TSS上发布——其时最具影响力的J2EE网上社区TheServerSide.com被简称“TSS”，由此可见那时的企业软件世界是有多爱三字母缩写词。InfoQ的创始人FloydMarinescu当时还在TSS做内容主管呢。

持久化框架的情况也好不到哪儿去。Hibernate倒是已经发布了2.0版本，不论功能还是性能都已接近成熟；可是Hibernate与ADO之间的争论正在如火如荼地展开着，究竟应该选一个刚开始热门的开源框架还是选一个“标准”也颇让人头疼；同时也别忘了另一边，很多程序员更愿意用简单的SQL来操作数据库，而不是在对象与关系数据的映射中绞尽脑汁；再加上2003年普遍的“XML热病”，真的有很多人相信可以把企业应用中的数据持久化成XML从而抛弃关系型数据库——你也可以说这是NoSQL的早期萌芽，总之当时这些思想只是让事情变得更复杂而已。

当你谈论2003年的J2EE世界时，千万别忘了这里还有EJB。实际上，EJB 2才是当时J2EE的正统——再提醒一下读者们，Spring还在0.x的阶段，RodJohnson那本旗帜般的“withoutEJB”还没写出来呢。曾经有IBM的咨询师来跟我们讨论应用架构，听说我们完全没用EJB时都连连摇头。如果不是石一楹坚持不用EJB，也许我会走上一条相当不同的技术路线。后来我一直对EJB不怎么上手（虽然还翻译过一本与EJB关系不少的书），倒是轻量级J2EE架构接受起来驾轻就熟，不得不说是种运气。

仿佛是嫌事情还不够复杂，那时很多企业对开源软件抱持一种不信任的态度，所有框架都愿意自己开发，似乎只要“not inventedhere”的东西就不可靠——这样的企业现在也有，毕竟数量少多了。这里固然有心态的原因，同时技术上的原因也不应该忽视。J2SE 1.3引入了动态代理（dynamic proxy）技术，以RickardOberg为代表的一帮天才开发者们立即敏锐地意识到：这是一件框架开发的利器——在与JBossGroup决裂之前，Oberg是JBoss的首席架构师，可以说是他一手创造了JBoss；同时他也是AOP和Interception的狂热爱好者，因为他早早地看到了这些元编程技巧在框架开发中的重要意义，而动态代理则正是让Java不依赖于外部的、非标准的代码生成技术（例如AspectJ、CGLib等）实现动态元编程的基础设施。其结果是，从Java1.3开始，很多新的框架显著地变得更优雅、更少侵入性——Java1.3之前的“老”框架，例如Avalon、Turbine，与这些后来者比起来就显得相形见绌。然而这种优雅同时也意味着更难理解其内部运作机制，有时对着一个漂亮的框架就仿佛在看一场精彩的魔术，愉悦之余也难免有些心里犯嘀咕。正处在这场转变之中的企业和团队，希望自己动手开发框架从而获得更多安全感，也是情有可原。

不过这种复杂、混乱与缺乏信心对于程序员来说倒未尝不是好事。短短的几个月时间里，我的项目主管带着我把J2EE Web应用的全套框架——对象容器、持久化、WebMVC——都实现了一遍。这个过程不仅让我的技术水平突飞猛涨，而且还让我交了不少朋友：因为我比较喜欢显摆，做出点东西就在网上谈论，一来二去就结识了一些与我有着同样困惑的同行。在这些“以技术会友”的新朋友之中，最有趣的是一个叫DreamHead的家伙。这人每每写邮件长篇大论洋洋千言，博客也是一副正襟危坐的范儿。我们讨论的主要就是这些基础框架与架构，没想到类似的话题我竟然与他一直讨论了十年。

当我谈扁平组织时，我谈些什么

CSDN最近给徐昊做了一个采访。作为ThoughtWorks中国区的CTO，徐昊说他自己“非常不想成为技术管理者”。在我看来这个调调非常有代表性，它集中体现了一个扁平组织的诸多特征。

ThoughtWorks是一个真正意义上的扁平组织。行政管理的层级在这里只有三级：CEO（我领导最近刚升了这个职位），地区管理董事（比如“中国区老大”），然后就是所有人。所有人的直接汇报和负责对象是地区管理董事。以成都公司为例，所有咨询师的直接汇报和负责对象是新任的pair中国区老大胡凯和张松，其他任何人都不是你的行政管理者。

这就引出了第一个问题：别的那些头衔（比如徐昊的“CTO”，我的“成都公司负责人”，郑晔的“校长”，等等）算怎么回事呢？新同事（尤其是有工作经验的新同事）往往会困惑：不是据说扁平组织没有管理者吗？怎么还有那么多有头衔的人在那儿呢？

这是扁平组织的一个重要特征。扁平组织不是乌合之众。在一个扁平组织里，仍然会有各种各样的分工、各种各样的人需要对各种各样的事情负责，因此会有各种各样的领导者。领导者不是管理者，领导者所负责的是功能而不是组织机构（例如“部门”），他带领一群人一起完成一件事，而不是管理这群人的所有巨细。所以，在一个扁平组织里，你会只有很少的管理者，却会有很多的领导者。比如你工作的项目会有项目经理，你们共同达成项目交付；你参加的学习活动会有校长，你们共同组织学习；你对iOS开发感兴趣，会有移动实验室负责人来组织研究和市场开拓；你所在的办公室还会有办公室负责人，你们共同创造一个牛逼的工作环境。人的能力、见识有所不同，要组成一个团队达成一个目标，必定就会有人要做最终的决定、要对结果负责，这些人就是领导者。成为领导者不需要“晋升”，从一个领导者角色走出来也不是“左迁”。

下一个问题跟着来了：既然不是管理者，既然是扁平组织，这些领导者可以/应该强迫我做什么事吗？扁平组织不就应该让我“follow my heart”，做我想做的事（并且不做我不想做的事）吗？

很遗憾，答案可能跟你想象的不一样。这是扁平组织的另一个（并且经常被误解的）重要特征。扁平组织不是乌托邦。正如前面所说，领导者要带领一群人一起达成一个共同的目标。然而人是有局限性的。每个人了解的信息不同，对信息的理解程度不同，能力水平不同，自律程度不同。就像那句老话说的，“一懒二拖三不读书”，这是人人都有的毛病。因为有这些毛病，我们才需要与别人构成一个团队，以期达成自己无法达成的目标，并从这个过程中获得自我的提升。为了获得这些，我们就得放弃一定程度的自我中心。领导者就是会不时地强迫我们做自己不想做的事、不做自己想做的事，而接受这种强迫就是进入这样一个群体必须做出的承诺。

很可能出乎意料地，在一个扁平组织中，这种承诺有时会很重，比层级结构的组织中更重。在一个以命令、汇报和制度驱动的组织中，你只要弄明白制度规定了什么，然后做制度规定的事、不做制度禁止的事，就够了，（理论上）谁也不能挑你的毛病。而在一个扁平组织中，你需要理解自己所加入的每个团队，接受每个团队的承诺和强迫。比如一个学习函数式编程的小组会要求你每周拿出两天下班后的业余时间，你要加入这个组就不能“followmy heart”说我每天晚上都得去健身干不了别的。不去理解、不去遵守规章制度之外的承诺，在一个层级结构的组织中也许关系不大，但在一个扁平组织中就是极具破坏性的行为。

第三个问题是如何激励人。这里没有升迁机会，没有掌权的机会，也没有赚大钱的机会，那么人们到底为什么来到这里，为什么被激励？说实话，这是一个无法解决的问题。只要看看连徐昊都在说“非常不想成为技术管理者”，你就可以知道：这个扁平的组织真的没什么办法激励人选择他们不想选择的方向、跟随他们不想跟随的领导者。所以我们唯一能做的就是：如果有那么一个人没什么自己想做的、没有钱和权的激励就不会往前走，那么我们就不跟他做同事，我们不让他进入这个圈。因为我们知道，我们真的给不了他想要的。

现在小结一下：像ThoughtWorks这样的扁平组织，不是乌托邦，不是想干什么就干什么，可能会有更多的领导者，可能会强迫你做更多的事，而且掌不了权发不了财。所以，如果你跟我们一样，认为追求软件卓越和社会公正是那么一件有意义的事，欢迎来加入；如果你发现我们给不了你想要的，我们也并不为此感到抱歉。

为什么程序员应该写作

能写技术文章的，十有八九都是在一线打拼的程序员，写作对他们而言不是主业，很多（也许应该说“绝大部分”）优秀的程序员根本就没想过自己也可以写文章发表。然而，越是优秀的程序员，写文章发表越是对自己有价值，原因有二：

第一，写作有助于自我成长。刚入行时，困扰大家的问题都是书上写过、Google上现成能搜索到的，只要花心思去找就能找到；随着程序员的水平提高，他思考的问题就开始变得更有深度、规模更大、更抽象、更复杂，更需要以写作的方式来整理成型。从我认识这么多人来看，这个阶段写文章和不写文章，会对一个人知识体系的构建有重大的影响。很多人也有多年经验积累，也有不少想法，但是没有形成一个完善的体系，随着年纪增大，生活压力越来越重，记忆力越来越差，渐渐就说不出到底从这么多年经验中学到了什么。我觉得这是件很可惜的事。

第二，写作有助于扩展见识。程序员从业有些年头以后，如果是喜欢技术的人，总会想与别人做些更深入、更高层次的交流，但毕竟水平越高，能进行这种交流的人就会越少、越分散。写作、演讲、著书立说，这都是让自己进入一个更高水平的交流圈的方式。进入了这个对话环境，你才发现：原来还有那么多可学、可发展的方向。很多人到了三十岁上下就开始惰怠、看不到发展方向，在我看来一个重要的原因就是眼界不开，没有进入一个更高水平的交流生态。

新书推荐：敏捷软件度量

软件项目、软件组织和软件专业人士的度量是一个由来已久的难题。

当ISO、CMM等“重量级”管理方法占据言论主导地位时，我们看到管理者们拿出条目繁多的度量方法和KPI，试图量化员工的工作绩效；与此同时员工们却一边抱怨冗杂的报告和数据表，一边行之有效地找到了敷衍“上头”使他们不再干扰自己正常工作的妙策，顺便——借由呆伯特漫画——嘲笑高高在上不知民间疾苦的管理者们。

而当SCRUM、看板之类“敏捷”方法甚嚣尘上，被一句“人和交互重于流程和工具”激励起来的程序员们高声喊出“我们不要文档/度量/KPI，我们交付可工作的软件”；而——绝非邪恶的——软件组织领导者们则郁结于如何在更大范围、更长周期了解员工和团队的状态和能力水平。毕竟，如果连“全局”究竟是什么样子都无法看到，“全局优化”就只能是一句空话。

我无意在此引发又一轮软件方法学之争，只想提醒读者的注意：对于度量这件事，我们这个行业存在着如此明显的张力，使得任何一位严肃的领导者乃至从业者都无法也不该忽视其中的挑战。一方面，所有人都赞同：“好的”度量对组织以及个人都将大有裨益；另一方面，真正找到“好的”度量方法者寥寥。这个问题的解决，需要丰富的软件、工程、管理乃至商业理论与实践经验的深度结合，并且需要在实际的运用中不断改善精炼。

在所有探索有效软件度量方法的尝试中，这本《精益软件度量》是一本开创性的佳作。从精益软件开发入手，作者首先建立了一个适用于现代软件组织的度量体系。基于这个体系，作者介绍了如何对软件的价值、速度、质量等每个软件组织都高度重视的核心要素进行有效度量。

如果前面这些还是其他著作也有所提及的内容，接下来的部分就是极具开创性——而且极具价值——的思考与经验了。除了软件交付的“业务”本身，作者专章论述了如何对软件组织及从业者个人的能力进行度量，并给出了建设学习型组织、持续提升组织和个人能力的指导。最后，作者还以可观的篇幅讲述如何在一个“传统”的软件组织中引入这些精益度量方法，以度量的植入来拉动软件组织的精益转型。这种饱经思辨又与实践紧密结合的“落地指南”，是我在论述同类主题的其他著作中从未见过的。

整本《精益软件度量》读完，除了丰富的思想与实践，字里行间还渗出一种浓浓的人文关怀。作者在第一章就明确指出：“在理念上，我们希望把度量的重心从‘控制’转向‘改进’。”面对加速变化的世界，只有充分发挥员工的主观能动性、帮助员工提升自身能力，企业才能具备长久的竞争力。而管理者或领导者更多地需要扮演“导师”和“服务员”的角色：引导、帮助员工成长去达成他们自己向往的目标，而非以度量指标来控制员工的行为。这种管理思路的转变，意欲为自己的组织引入度量体系的领导者不可不察。

有幸作为张松的同事，与他在最近几年紧密合作，使我清楚地知道：讲述这样一个主题，松哥正是最理想的作者。在加入ThoughtWorks之前，松哥就有着MBA背景及在大型IT企业中工作的经验；在ThoughtWorks的6年中，他在大规模离岸交付项目中艰苦奋战过，也在国内超大型IT组织的敏捷转型中舌战群儒过；作为交付总监和咨询总监他体会过同时关注十余个项目时的惶恐无力，作为人力资源总监他清楚打造一支持续学习、持续改进的团队对于整个企业而言是何其重要。而且在ThoughtWorks中国区管理团队中，松哥一向扮演着“智库”角色：虽然说话不多、嗓门不大，却总是字字珠玑，每每使我们其他成员受益良多。现在松哥的思想与实践得以付梓，使更多读者得以分享他从若干焦油坑中淬炼的菁华，实在是幸事一件。

更多的阅读乐趣，还是留给读者自己在翻开书之后慢慢体会吧。作为在国内帮助IT组织进行精益转型的实践者之一，我希望这本《精益软件度量》能帮助它的读者在他们的组织中建立一套行之有效的度量体系，并最终帮助这些组织的员工切实地提升自己的能力。如此，善莫大焉。