从成功中学习
June 30th, 2011
（商业读书会第六期的题目：Why Leaders Don’t Learn from Success | HBR April 2011）
首先，关于为什么成功不能成为成功之母，这篇文章总结的几个因素：
- 错误的根源归因 。在获得好成绩时，人们会倾向于把成功归因于自己的能力、智慧、管理有方、决策英明⋯⋯而不是外在的、偶发的、非受控的因素。这种错误的归因会使人们产生盲目自信，并且错过从经验中学习的机会。
- 过分自信偏差 。盲目的自信会促使人们做出风险更大的决策，并且倾向于不对现状做改变，从而错过改进的机会。
- 不再追问“为什么”。就连丰田也只强调针对有问题的事情追问 五个为什么 。人们倾向于只是庆祝成功，而不是冷静解剖“我们为什么成功”——就像解剖“我们为什么失败”一样。这也让人们错过从经验中学习的机会。
其次，关于如何有效地从成功中学习，这篇文章总结的几个实践：
- 庆祝成功，然后检查。承认有些成功就是因为运气这没有什么不好意思的，卡卡西说“运气也是实力的一部分”。需要明白成功是为什么成功，否则没有办法学习。
- 进行系统的项目回顾。成功的项目也有做得不够好（或者叫“可以做得更好”）的方面。为了下次把这些事做得更好而回顾，这不会影响对这次成功的庆祝。
- 使用正确的时间线。今天的成功很可能归因于很久之前的某个决策，甚至早于现在做事的所有人进入这件事之前。意识到这一点才能提早为将来的成功做准备。
- 重复不是学习。可以采用对待失败的工具同样对待成功：根因分析。找出真正的驱动力才是学习，而不是简单重复上次做过的所有事。
- 缺陷引入。（这个词是黄亮总结的。）在成功的项目上尝试各种变量，尝试把它推向边界，从而找出成功的原因。但是我个人有点担心：这会不会成为一个漂亮的借口，对一个本来非常漂亮的项目施加越来越大的压力，直至它变成一个普通的项目呢？
（总体来说，我认为 完美主义事儿逼处女座 具备从成功中学习的潜质⋯⋯只有变得更强是唯一追求，成功不成功的算什么老子就是不满意啊不满意啊～）
再次，这篇文章再一次体现了最近的一种趋势：认知科学与其他学科的交叉研究很容易热门。前一阵读的《 非理性繁荣 》就大量使用认知科学的研究来解释经济泡沫，这一篇又谈到了认知偏差，还有 这本书 也是。老师前两年在办公室讲过好几次认知偏差，这个套路还真是百搭啊。
最后，尽管有很多组织从失败中学习并最终成功，也有很多组织沉湎于成功而一朝沦落，但从中真的能推出“领导者们无法从成功中学习”吗？会不会这也是一种认知偏差呢？
当通信业遇到云计算（下）：实施
June 28th, 2011
上一篇文章 讲到，运营商开展云计算业务的第一步，是把计算资源云化并以IAAS的形式出租。现在我们就来看这件事要如何落地实施。
功能：IAAS要做什么
从用户感知的角度，IAAS意味着对几种关键计算资源的按需取用、按使用计费、弹性伸缩。这几种关键资源是存储（内存和外存）、计算（CPU）和网络（带宽和流量）。说白了，用户希望快速开通自己想要的机器和网络，让它投入运行。
从运营商的角度，提供IAAS意味着至少要实现几方面的能力：
- 虚拟化（Virtualization）：将现有的、大批量的计算能力（大型主机、磁盘阵列、千兆以太网）加以虚拟化，使之可以被重组为可出租的小单元。
- 监控（Monitoring）：在客户租用计算能力的过程中监控其使用情况，以便计费并及时发现异常事件。
- 计费（Billing）：根据用户对计算能力的使用情况对其收取费用。
这三方面能力实际上分别对应于IAAS服务的开通、使用和结束三个阶段。云计算平台的架构描述（例如 OpenStack的概念架构 ）可能包含更多模块，但它们最终是服务于这三个阶段的。
建设：如何打造IAAS平台
对应于前面提到的三项基本能力，运营商需要做以下几方面的工作来提供IAAS服务：
利用开源平台实现资源云化
现有资源的虚拟化已经有众多虚拟机产品（例如 VMWare 、KVM 、Xen ）可以实现，IAAS平台应该使用这些虚拟机产品作为底层驱动，在其上提供服务开通、监控、镜像管理等功能。对虚拟机产品的适配以及上述通用功能已经有多个开源平台实现，没有理由重新发明轮子。
在选择开源平台时需要考虑授权许可的问题：例如 桉树 的开源版本使用了 GPL协议 ，基于其上开发商业应用就会遇到授权问题；而基于 Apache协议 的 OpenStack 则没有类似问题。（详见 各种开源授权协议的比较 ）
集成账务/计费
OpenStack当前的文档 中明确指出：目前OpenStack尚未提供计费组件，并且由于云计算服务提供商大多有自己的计费系统，因此OpenStack关注的重点是与现有计费系统的集成。
与之类似，在选用其他开源（乃至商业）云计算平台时，与现有营帐/计费系统的整合都将是一块主要的定制开发工作量，也是厂商设计云计算平台时的重点之一。
定制用户界面
此处所说的“用户界面”是指“用户可感知的界面”，包括API、dashboard、portal等。需要将开源平台提供的用户界面定制为具有运营商特征的界面、甚至需要本地化，这是一块工作量较大、但技术难度较低的工作。
对于IAAS而言，API的重要性甚至超过图形用户界面，因为用户绝大部分的工作都将通过API进行。提供清晰、规范、利于自动化的API，对于用户的体验非常有益。
能力：对研发提出什么要求
对于真正要设计实施云计算平台的厂商而言，首先对开源云平台的经验是必不可少的。这种经验不仅局限于对平台本身技术特性的了解，采用开源云平台亲身实施私有云的经验也是弥足珍贵的，因为这些经验将有助于厂商开发出更便于使用的IAAS产品。
在开发的过程中，针对基础设施的自动化构建、自动化测试的能力也是不可或缺的。以欧洲为源头发起的DevOps运动提出了 Infrastructure as Code 的口号：在涉及大量基础设施的环境下，基础设施本身就应该被当做源代码来看待，需要良好的设计、优雅的编码、不断的重构、持续的集成和测试。在编写应用软件代码中积累的相关经验，在云计算平台的开发过程中同样能发挥价值。
云计算平台本身实际上也是一个面向公众用户的互联网产品，它也需要在 持续交付 中不断获取反馈、不断改进。实际上，开发云计算平台的厂商可以尝试 吃自己的狗粮 ，在企业内部部署并使用云计算平台提供IAAS服务，不失为及早获得真实用户反馈的一个好办法。
从业务和技术两方面来说，云计算都是一个全新的领域；但云计算平台也是一款软件，而软件开发最基本的设计原则仍然是保持不变的。充分利用已有的软件开发最佳实践（例如 敏捷软件开发 ），并保持开放的心态学习最新技术，传统通信行业的软件开发者和企业也能很快找到自己在云端的定位。
当通信业遇到云计算（上）：行业
June 26th, 2011
移动有“大云”，电信有“星云”，联通有“沃云”。三家运营商都 推出了自己的云战略 ，通信业和云计算是如何拉上关系的？运营商要如何转变自我定位？
根源：用户的诉求
我们正处于一个信息加速爆炸的时代。根据 Hadoop引用的一份调查 ，截至2009年底，全世界有超过2亿台web服务器、超过8千万个域名在为超过17亿互联网用户服务，让他们每天发出超过2千万条tweet、在Youtube上浏览10亿个视频、并制造超过2千亿封电子邮件（尽管其中81%是垃圾邮件）。而且 有人声称 到2020年人类在互联网上创造的信息量将是现在的270倍。
除了其他的各种影响，对于提供互联网服务的企业（以及个人）来说，这意味着他们需要新的计算能力（即：消费、存储和生产信息的能力）报价：不仅是更便宜的计算能力，而且是弹性的计算能力——根据对计算能力的使用付费，而非预先购买昂贵的服务器和网络带宽，并且当业务量上升时能得到充足的计算能力。
作为信息和计算服务的重要提供商之一，通信运营商希望满足这种诉求。但他们发现这并不容易。
困局：运营商的局限
不难看到，现在最成功的“出租计算能力”供应商其实是亚马逊。其实作为一家互联网企业，亚马逊提供这种服务有一些难以克服的障碍，例如QoS：亚马逊没有办法保证用户一定能连接到EC2的机房，更没办法保证连接速度，因为它没有端到端的网络接入。运营商有。
但运营商有自己的问题。运营商（以及通信厂商）太习惯于用技术眼光来看待通信网络，核心网、接入网、路由器、交换机⋯⋯在整个数据通信网络之上，通信服务与用户真正体验到的网络服务却是完全隔离的。从网络协议栈设计的角度这当然是正确的，但从服务的角度这就体现出通信业一直是个供方市场——就好像从前计划经济时代润肤霜属于“日化产品”，现在叫“Beauty Industry”，供方市场上描述产品是从生产（而非消费）的视角出发的。
随着数据通信服务的日用品化，运营商必须到网络服务这块市场来寻找增长点了。把手上的优势资源（接入、网络、IDC）充分利用起来提供客户需要的计算能力（而不仅仅是通信服务），把亚马逊赚的钱变成运营商自己来赚，这是国内外运营商都在走的一条路。
转型：迈向云端
帝国主义老巢的运营商步子迈得稍微早一点。BT在2009年和微软一起给企业客户提供 基于云的商业协作软件 ，大致属于 SAAS ；AT&T的 Synaptic 提供了存储和计算的出租，就应该算是 IAAS ；Verizon把这种业务叫做 CAAS ，说白了还是抢亚马逊的生意。
国内的三大运营商盯上的也是IAAS。移动资深研究员杜宇健认为运营商切入云计算 从基础设施这个层面落地比较好一些 ：IAAS技术门槛不算高，需要的是大量的基础设施，而后者正是运营商手中已经掌握的。
首先把手中已有的计算能力云化（我颇喜欢“Cloudify”这个词，但好像已经被某公司使用了），将云化的计算能力以私有云的形式出租给企业用户，为将来提供SAAS铺路架桥。这个大概就是运营商向云端转型的策略了。
（讲完行业，下一篇讲实施。未完待续⋯⋯）
我怎么使用GMail
June 20th, 2011
最近经常瞟到同事的收件箱赫然列着千多个未读邮件。自从胡凯向我推荐 空收件箱 模式之后，我渐渐养成了这个习惯，并且感到很有效。下面是我用GMail的几个技巧。
- 清空收件箱。读完邮件立即点“Archive”回到收件箱首页，不用读的邮件批量archive。
- 用好Tag。按项目/客户/工作性质给邮件打tag，创建对应的filter自动tag，把当前要关注的几个tag（例如当前在工作的项目）显示在左边栏里，其他的tag隐藏。
- 标记重要邮件。有些人喜欢用 Priority Inbox ，我更喜欢用 Multiple Inboxes ，然后结合 Starred Messages ，把需要后续处理的邮件标上星号，专门用一个inbox来显示带星号的邮件，有时间就逐一处理。
- 使用Unread Message Icon。因为收件箱始终是空的，这个功能 会在GMail的浏览器tab上显示当前有几个邮件未读，当我有空的时候如果没有新邮件，我根本不用去查看。
- 使用Default ‘Reply to all’。我自己留意一下，大部分时候我都会回复所有人，所以 缺省回复所有人 好了。
- 使用Better Gmail。这个插件 可以在附件图标上显示文件类型，更容易找到想要的附件。
邮件是每天最重要的工作环境，不搞干净是不行滴～
创新的张力
June 18th, 2011
（商业读书会第五期的题目：The CEO’s Role In Business Model Reinvention | HBR January–February 2011。我又延伸了一篇：Stop the Innovation Wars | HBR July–August 2010。）
这两篇文章都是关于“现在”与“将来”的平衡：绝大多数取得成功的企业都拥有一个运转良好的效能引擎（performance engine），它是稳定的收入来源，它确保当前的成熟业务持续正常运行。但效能引擎的问题在于：它从本质上不是面向剧变的。而现代企业越来越多地需要面对剧变，例如新技术的发明，例如全球化带来的超低价格，例如互联网企业得到了所有潜在用户之后的增长瓶颈。效能引擎在面对剧变时，表现出的是温水煮青蛙的痛苦和无力。
作者的观点是：在最大化利用今天的同时，为了应对剧变的明天，企业必须有意识地打破昨天的习惯。另一方面，昨天的习惯往往是效能引擎在今天运转良好的重要原因。在三者之间做好平衡，就是CEO需要扮演的角色。
以InfoSys的咨询业务为例，作者提到了商业模型创新中需要注意的三个方面：策略制定，责任明晰，组织设计。在这三个方面，创新工作需要体现与效能引擎的极大不同。如何应对这种差异带来的张力，是第二篇文章的主题，也是我更关心的主题，因为它的视角出发点是创新领导者而非CEO。
从创新领导者的角度，同一位作者用Westlaw的例子阐述了业务创新的一个根本原则：创新不能脱离效能引擎进行。游离于运行良好的效能引擎之外去“一心搞创新”，实际上就是在浪费企业过去积累的经验和资产。创新领导者的挑战就在于促成创新团队与效能引擎之间的协作关系。这需要创新领导者做好三件事：
- 划分任务。哪些事是效能引擎善于达成的？哪些事是必须在创新团队中实现的？如果一件任务需要超出现有人员的能力、或者要求不同的协作方式，它很可能应该在创新团队中实现。
- 组建团队。创新团队需要尽量借助于效能引擎，但又不能全无变化。通过引入空降兵、设立不同的团队结构和考核标准，创新团队必定要在某些方面差异于效能引擎。“如果来自效能引擎的员工全都对在创新团队中工作感到舒服，那只能说明这是又一个具体而微的效能引擎。”诚哉斯言。
- 管理两者之间的张力。通过前两个环节建立创新团队的独特性，随之而来的问题是如何保持协作和企业文化的连贯性。两个团队互相尊重吗？他们在面对资源争用时是在积极地协作解决问题吗？跨团队的成员对创新行动有足够的重视吗？创新团队与效能引擎之间的冲突很容易被升级为企业文化的断裂，保持平衡是一件微妙并且需要持续努力的事。
在做好现在的同时关注未来，在积极创新的同时给予效能引擎充分的尊重，这是谈到业务创新时战略和执行层面的两个基本原则。InfoSys和Westlaw遵循这些基本原则成功地实现了业务创新。在固有文化中就不去极端强调可预测、可控制的企业，业务创新时的张力可能相对较小；但在保持创新团队的独特性同时保持企业文化的连贯性，这对于创新领导者而言始终都是一个挑战。
遇到了好学的小孩
June 14th, 2011
ThoughtWorks西安办公室搞了一个“开放日”活动，邀请在校学生来参观我们的工作环境，了解IT行业以及ThoughtWorks这家公司。在开放日上，遇到了西安电子科技大学的李朝印同学，一个好学的小孩，跟他谈到阅读一些根本性著作的重要性。
有点出乎意料，李同学晚上给我发来邮件：
下午和你聊到计算机“树根”，我想做个2~3年的阅读计划把这些最核心的知识吃透。 以下是一个书单：
- The C++ Programming Language
- Computer Systems： A Programmer’s Perspective
- Indroduction to algorithm
- Compliers:Parinciples, Techniques, and Tools
- Code Complete
- The Pragmatic Programmer
- Refactoring: Improving the Design of Existing Code
- Thinking in java
- Effective C++
- The Art of Computer Programming(First Volume Hardcover)
这些是我根据网上大家的建议大致列出的，不足或不妥之处希望你能指出！
我的回复：
不错的书单。具体说起来，C++ Programming Language（如果你是指Stroustrup那本的话）比较生涩而且过于细节化，作为语言向导而言不如C++ Primer。TAOCP很艰深，需要量力而为。算法导论和编译原理应该都是专业课里的内容，把课程和自学结合起来可以事半功倍。另外我推荐SICP ，这本书关于计算本质的介绍是你的书单（以及整个中国的计算机教育）所缺少的。如果能用两三年把这些书读完（不一定”吃透”，吃个七八分透就够了），对自己的水平提升是非常有好处的。另外记着读万卷书行万里路，多读书同时多写代码，学以致用是长进最快的。
不由得想起十年前在学校里，跟虫虫、孟岩等人一起读书的时光。好学的年轻人总是让人看着充满希望。
可以不要那么土吗？
June 9th, 2011
最近在西安认真住一段时间，除了仍然很享受凉皮肉夹馍和羊肉墩子之外，感到西安的很多事情还是透着一股乡土气息。
比如说，软件园新盖的漂亮大楼，楼顶的排水管从办公室里面走，下雨就可能漏水到办公室里。
比如说，房东搞了伊莱克斯的冰箱和按摩浴缸在屋子里，可是房门和门框总也对不齐。
比如说，在淘宝上买了一台街机，快递只送到火车站，火车站到办公室的这段，不好意思，自己找小货车。
小风同学说，这是成本因素使然。然而我认为，很多时候，把事情做得不那么乡土一点，其实并没有额外的成本。它需要的是思考。站在用户的角度思考，别人会怎么使用这项服务；而不仅仅站在自己的角度思考，我做了多少事来提供这项服务。（当然对于很多人来说思考本身就是一种高昂的成本，这是另一个问题了。）
比如写一个往系统里灌数据的小程序。解析CSV，校验数据，配置数据源，插入出错时的异常处理⋯⋯已经花了三天功夫来做这个功能，测试很全面，代码也经过了重构。可是，没有命令行接口。没有办法用一条指令完成整个灌数据的操作。这时候用户（以及出钱的客户）会怎么看待这个功能？
它不可用。它不能为用户创造任何价值。
程序员表示很委曲。我花了这么多心思来做这个功能，其实差也没差多少，你怎么能对我的努力全都视而不见呢？其实只要站在用户（和客户）的角度想想就会很清楚：如果它不能创造我想要的价值，那么它跟没做又有什么区别呢？
（其实真正开始做“一条指令完成”的时候，更多的问题就开始暴露了，比如性能太差。把事情做完 不是那么容易的。有些时候土贼的解决方案看起来好像成本低，其实是事情没做完。）
所以，首先是要有决心，做事情不要做那么土。这需要两点前提：第一，要养成思考的习惯，不要让“站在用户的角度思考”成为一件困难的、成本很高的事；第二，要站在用户的角度思考，多想想别人会怎么用你的服务，你的工作以什么方式为别人创造价值。做一件事就做到最终可交付/使用/发表的状态，这会让你整个看起来很洋。
ThoughtWorks办公室里的街机
June 8th, 2011
给我看你的博客
June 8th, 2011
小熊写了一个 用户体验设计师招聘广告 。嗯嗯，从转帖广告的角度，如果恰好有设计高手看到，ThoughtWorks中国 正在招聘用户体验设计师哟。
我很喜欢小熊的这个说法：
给我看你的portfolio或者博客,我很不喜欢简历这东西,你的博客就是你的简历,上面把你写得清楚
看到这个就想起 我的偶像 ，这博客写到如此程度，何愁没有工作找上门啊～
所以涅，应聘的童鞋们，最好把你的博客一起告诉我们。看到一个精彩的博客，简历神马的都是浮云～
实话的力量
June 6th, 2011
（本文系《 项目百态 》推荐序）
我对我的客户、一支百人团队的领导说：“你们并不是没有优先级。你们的优先级策略是最后来的事情优先。”
他苦笑不语。因为他知道，这就等于在说，他手下的百十来号人基本是在做布朗运动；更因为他知道，这是实话。只是他自己不能说，他的手下人也不能说。
事情经常是这样：尽管所有人都知道，但谁也不会把它说出口，因为说那样的话是政治不正确的。比如说吧，也许你早就知道你手上那个项目注定是条死鱼，但你敢说出口吗？更多时候，你会让自己变得乐观──乐观程度与最后期限的紧迫程度成正比，直到时间夺走你所有的手牌。
另一些时候，你知道自己碰巧做对了某些事，你不愿意新来的经理改变它：取消每周四晚上的三国杀，把团队从大会议室里搬回格子间以便“释放资源”，把几个模块外包到一千公里外的另一个城市。可你没办法说服领导。“你有度量证据吗？”当然，你没有，而削减成本总是政治正确的。
情况不会自己变好的，如果人们连真实情况都不敢说出来的话。
幸运的是，像Tom DeMarco这样名声和年纪（这很重要）都足够大的人可以不在乎政治正确性──换句话说，他们可以说实话。这本《项目百态》就是他们关于项目管理的实话集。
在这本实话集里，作者们挑选了86个项目管理中常见的模式，从“肾上腺素成瘾”直到“模板僵尸”──从英文书名不难看出，这无非是“从A到Z”的又一个变体。这些模式，诚如一位评论者所说，有良性的，更多的不仅恶性、而且丑陋可笑。读这样一本书，你会笑，更多的时候你会摇头苦笑，甚至如芒在背。“我的团队没有肾上腺素成瘾吗？”很多读者将很难面对这个问题。
那就对了。
我要感谢我的同事金明向我推荐这本书：几位作者帮我们消解了政治正确性的风险，我们就可以放心地说出实话，然后努力进步。下次当同样的模式出现时，我就可以大声地说：“这就是《项目百态》中的xx模式。”或者当我再次面对前面提到这位客户时，我可以把书递给他，对他说：“也许你该看看xx模式。”
也许你也应该看看。
