-
职业规划中的“我想要”和“我需要”
最近听到一些年轻的同事纷纷想转职，想从程序员转做业务分析师。尤其是年轻的ZY也有这样想法，让我感到有点触动。很多时候，尤其是年轻的时候，我们分不清“我想要”和“我需要”。在一句“我想要做BA”的背后，需要的是什么？
人际交往能力
据说程序员是一个死板孤僻有人际交往障碍的族群。因为不愿成为头上长草脚下生根的孤老程序员，所以我想要做BA。
但是，没有人阻止你在写好程序的同时练习人际交往（尤其是在ThoughtWorks这样的公司）。实际上，现代商业软件开发根本没有什么火箭科学，作为一个程序员大部分时间本身就是在进行人际交往。你能把设计思路讲得明明白白让队友信服吗？你能列出各种实现选择的优劣说服客户不要做愚蠢的选择吗？你能面对五十个同事做一次落落大方的技术演讲让大家欢声笑语同时学到知识吗？练习人际交往的机会俯拾皆是，不要等到自己被冠以“业务分析师”的名头才把脑袋从屏幕前移开。
对商业的了解
每天给客户写的代码为什么值那么多钱？为了理解客户的商业运作，所以我想要做BA。
同样，没有人阻止你去了解。尤其是这个网络时代，让学习这些知识变得前所未有的简单。你只要订阅Economist和McKinsey Quarterly的RSS，每天花两个小时读完所有的更新（并且用1.HourFor.Me来监督自己），很快你就会发现：你能跟上各种“高端的”商业对话。这些文章里会有不时提到的引用书目，到豆瓣加上这些书，每周一本，一年读完50本，你对商业的了解会超过你的客户——他所知道的大多只与某个行业相关，而你学到的将是全景。
请注意，我说的是简单，不是容易。每天坚持两个小时做一件事、每周读完一本书，这永远不会容易。戴上“业务分析师”的名头也不会让这件事变得容易。
交互设计能力
总是写这些枯燥的代码太没意思了。为了像小熊那样画出酷炫的手绘，所以我想要做BA。
买这本书，开始练习素描。每天一小时，两个月以后你就能画得有模有样。然后订阅Smashing Magazine的RSS，到网上找手绘和简笔画素材，不断练习。同样，你并不需要一个名头、一个工作才能学习这些。
管理能力
我不想总是跟着别人屁股后面，我想别人都听我的，所以我想要做PM（为此先做BA，因为据说BA更容易变成PM）。
记得在决定加入ThoughtWorks的那一天，老师对我说：“leadership”和“management”是不同的东西。要别人跟从你，你需要的是leadership，而不是一个manager的头衔。所以还是这句话：不要等待某个头衔，现在就开始练习你的leadership。想想你的代码会被别人如何使用，想想你开发的软件会被如何部署，在所有人都妥协的时候鼓励团队坚持写测试和重构，这些都是leadership的表现形式。郑大大展现leadership的方式很简单：“在我的项目里不容忍烂代码。”很简单，但一点也不容易，也许你可以问问郑大大是怎么做的。
更少的压力/更多的钱
为什么每次出bug都要我来修？为什么我的薪水不够买房？我要做PM，我要出人头地，我要有钱⋯⋯
你知道我会说什么。去变得更强，然后来踢我的屁股吧。
ThoughtWorks的真实故事
也许在如今的某些大团队中，“多能工化”已经成了一个传说。在我的第一个ThoughtWorks项目中，Perryn Fowler既是架构师又是tech lead还是PM有时兼任BA并且每天写程序。当他满脸怒气地对我说“我的项目里不允许有没测试的代码”时，我就认定：ThoughtWorks的leadership就应该是这样的——他让你感到你应该听他的，并且如果你不听，他会一脚踢在你屁股上然后自己搞定所有事。
郑大大现在的项目有同样的气味。LY作为BA+PM进入，我从第一天开始就告诉他：你要写代码，你要了解所有事，如果出了问题你就顶上。ZQ作为QA进入，每天参加codereview，并且学着写Chef脚本。从项目管理的角度，我希望所有人能做所有事这样项目就不会有瓶颈；从人的角度，我不想看到“ThoughtWorks PM”、“ThoughtWorks QA”，我想看到一个个Perryn的复刻，随时准备踢别人屁股并且搞定任何事。
然而，关键在于⋯⋯
正如我一再强调的，所有这些能力，都不需要得到一个专门的职位或者头衔才能开始获得。因为它们有一个共同的特点：它们都基于人类语言。
软件开发从根本上来说，是将人类可理解的连续的物理世界，以图灵机可计算的方式建模为离散的数字模型的过程。而整个软件行业的各种行为中，只有编程（即：以图灵机可计算的方式建模）这一行为不是基于人类语言，而是基于机器语言的。换句话说，即使不戴BA/PM的帽子，你永远可以和那些只懂人类语言的麻瓜们练习其他能力；一旦你脱下了程序员这顶帽子，你将没有机会练习严肃的编程。这一根本性的分野决定了一个事实：程序员可以转向其他职位，而其他职位无法转成程序员——所有post-technical的人，无论多么努力保持自己的技术水平，最多也只能停留在转职之前的水准。
因为这是一条不归路，所以在说“我想要做⋯⋯”之前请想清楚：离开编程的键盘，你所追求的可能只是一种很简单（尽管不容易）就能学到的能力；但与机器对话——整个软件开发的根本——的能力，当你发现自己需要的时候，就再也找不回来了。
-
从成功中学习
（商业读书会第六期的题目：Why Leaders Don’tLearn fromSuccess|HBRApril 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服务，不失为及早获得真实用户反馈的一个好办法。
从业务和技术两方面来说，云计算都是一个全新的领域；但云计算平台也是一款软件，而软件开发最基本的设计原则仍然是保持不变的。充分利用已有的软件开发最佳实践（例如敏捷软件开发），并保持开放的心态学习最新技术，传统通信行业的软件开发者和企业也能很快找到自己在云端的定位。
-
当通信业遇到云计算（上）：行业
移动有“大云”，电信有“星云”，联通有“沃云”。三家运营商都推出了自己的云战略，通信业和云计算是如何拉上关系的？运营商要如何转变自我定位？
根源：用户的诉求
我们正处于一个信息加速爆炸的时代。根据Hadoop引用的一份调查，截至2009年底，全世界有超过2亿台web服务器、超过8千万个域名在为超过17亿互联网用户服务，让他们每天发出超过2千万条tweet、在Youtube上浏览10亿个视频、并制造超过2千亿封电子邮件（尽管其中81%是垃圾邮件）。而且有人声称到2020年人类在互联网上创造的信息量将是现在的270倍。
除了其他的各种影响，对于提供互联网服务的企业（以及个人）来说，这意味着他们需要新的计算能力（即：消费、存储和生产信息的能力）报价：不仅是更便宜的计算能力，而且是弹性的计算能力——根据对计算能力的使用付费，而非预先购买昂贵的服务器和网络带宽，并且当业务量上升时能得到充足的计算能力。
作为信息和计算服务的重要提供商之一，通信运营商希望满足这种诉求。但他们发现这并不容易。
困局：运营商的局限
不难看到，现在最成功的“出租计算能力”供应商其实是亚马逊。其实作为一家互联网企业，亚马逊提供这种服务有一些难以克服的障碍，例如QoS：亚马逊没有办法保证用户一定能连接到EC2的机房，更没办法保证连接速度，因为它没有端到端的网络接入。运营商有。
但运营商有自己的问题。运营商（以及通信厂商）太习惯于用技术眼光来看待通信网络，核心网、接入网、路由器、交换机⋯⋯在整个数据通信网络之上，通信服务与用户真正体验到的网络服务却是完全隔离的。从网络协议栈设计的角度这当然是正确的，但从服务的角度这就体现出通信业一直是个供方市场——就好像从前计划经济时代润肤霜属于“日化产品”，现在叫“BeautyIndustry”，供方市场上描述产品是从生产（而非消费）的视角出发的。
随着数据通信服务的日用品化，运营商必须到网络服务这块市场来寻找增长点了。把手上的优势资源（接入、网络、IDC）充分利用起来提供客户需要的计算能力（而不仅仅是通信服务），把亚马逊赚的钱变成运营商自己来赚，这是国内外运营商都在走的一条路。
转型：迈向云端
帝国主义老巢的运营商步子迈得稍微早一点。BT在2009年和微软一起给企业客户提供基于云的商业协作软件，大致属于SAAS；AT&T的Synaptic提供了存储和计算的出租，就应该算是IAAS；Verizon把这种业务叫做CAAS，说白了还是抢亚马逊的生意。
国内的三大运营商盯上的也是IAAS。移动资深研究员杜宇健认为运营商切入云计算从基础设施这个层面落地比较好一些：IAAS技术门槛不算高，需要的是大量的基础设施，而后者正是运营商手中已经掌握的。
首先把手中已有的计算能力云化（我颇喜欢“Cloudify”这个词，但好像已经被某公司使用了），将云化的计算能力以私有云的形式出租给企业用户，为将来提供SAAS铺路架桥。这个大概就是运营商向云端转型的策略了。
（讲完行业，下一篇讲实施。未完待续⋯⋯）
-
我怎么使用GMail
最近经常瞟到同事的收件箱赫然列着千多个未读邮件。自从胡凯向我推荐空收件箱模式之后，我渐渐养成了这个习惯，并且感到很有效。下面是我用GMail的几个技巧。
- 清空收件箱。读完邮件立即点“Archive”回到收件箱首页，不用读的邮件批量archive。
- 用好Tag。按项目/客户/工作性质给邮件打tag，创建对应的filter自动tag，把当前要关注的几个tag（例如当前在工作的项目）显示在左边栏里，其他的tag隐藏。
- 标记重要邮件。有些人喜欢用Priority Inbox，我更喜欢用MultipleInboxes，然后结合Starred Messages，把需要后续处理的邮件标上星号，专门用一个inbox来显示带星号的邮件，有时间就逐一处理。
- 使用Unread Message Icon。因为收件箱始终是空的，这个功能会在GMail的浏览器tab上显示当前有几个邮件未读，当我有空的时候如果没有新邮件，我根本不用去查看。
- 使用Default ‘Reply to all’。我自己留意一下，大部分时候我都会回复所有人，所以缺省回复所有人好了。
- 使用Better Gmail。这个插件可以在附件图标上显示文件类型，更容易找到想要的附件。
邮件是每天最重要的工作环境，不搞干净是不行滴～
-
创新的张力
（商业读书会第五期的题目：TheCEO’s Role In Business Model Reinvention|HBRJanuary–February 2011。我又延伸了一篇：Stop the Innovation Wars|HBRJuly–August 2010。）
这两篇文章都是关于“现在”与“将来”的平衡：绝大多数取得成功的企业都拥有一个运转良好的效能引擎（performanceengine），它是稳定的收入来源，它确保当前的成熟业务持续正常运行。但效能引擎的问题在于：它从本质上不是面向剧变的。而现代企业越来越多地需要面对剧变，例如新技术的发明，例如全球化带来的超低价格，例如互联网企业得到了所有潜在用户之后的增长瓶颈。效能引擎在面对剧变时，表现出的是温水煮青蛙的痛苦和无力。
作者的观点是：在最大化利用今天的同时，为了应对剧变的明天，企业必须有意识地打破昨天的习惯。另一方面，昨天的习惯往往是效能引擎在今天运转良好的重要原因。在三者之间做好平衡，就是CEO需要扮演的角色。
以InfoSys的咨询业务为例，作者提到了商业模型创新中需要注意的三个方面：策略制定，责任明晰，组织设计。在这三个方面，创新工作需要体现与效能引擎的极大不同。如何应对这种差异带来的张力，是第二篇文章的主题，也是我更关心的主题，因为它的视角出发点是创新领导者而非CEO。
从创新领导者的角度，同一位作者用Westlaw的例子阐述了业务创新的一个根本原则：创新不能脱离效能引擎进行。游离于运行良好的效能引擎之外去“一心搞创新”，实际上就是在浪费企业过去积累的经验和资产。创新领导者的挑战就在于促成创新团队与效能引擎之间的协作关系。这需要创新领导者做好三件事：
- 划分任务。哪些事是效能引擎善于达成的？哪些事是必须在创新团队中实现的？如果一件任务需要超出现有人员的能力、或者要求不同的协作方式，它很可能应该在创新团队中实现。
- 组建团队。创新团队需要尽量借助于效能引擎，但又不能全无变化。通过引入空降兵、设立不同的团队结构和考核标准，创新团队必定要在某些方面差异于效能引擎。“如果来自效能引擎的员工全都对在创新团队中工作感到舒服，那只能说明这是又一个具体而微的效能引擎。”诚哉斯言。
- 管理两者之间的张力。通过前两个环节建立创新团队的独特性，随之而来的问题是如何保持协作和企业文化的连贯性。两个团队互相尊重吗？他们在面对资源争用时是在积极地协作解决问题吗？跨团队的成员对创新行动有足够的重视吗？创新团队与效能引擎之间的冲突很容易被升级为企业文化的断裂，保持平衡是一件微妙并且需要持续努力的事。
在做好现在的同时关注未来，在积极创新的同时给予效能引擎充分的尊重，这是谈到业务创新时战略和执行层面的两个基本原则。InfoSys和Westlaw遵循这些基本原则成功地实现了业务创新。在固有文化中就不去极端强调可预测、可控制的企业，业务创新时的张力可能相对较小；但在保持创新团队的独特性同时保持企业文化的连贯性，这对于创新领导者而言始终都是一个挑战。
-
遇到了好学的小孩
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，这本书关于计算本质的介绍是你的书单（以及整个中国的计算机教育）所缺少的。
如果能用两三年把这些书读完（不一定”吃透”，吃个七八分透就够了），对自己的水平提升是非常有好处的。另外记着读万卷书行万里路，多读书同时多写代码，学以致用是长进最快的。
不由得想起十年前在学校里，跟虫虫、孟岩等人一起读书的时光。好学的年轻人总是让人看着充满希望。
-
可以不要那么土吗？
最近在西安认真住一段时间，除了仍然很享受凉皮肉夹馍和羊肉墩子之外，感到西安的很多事情还是透着一股乡土气息。
比如说，软件园新盖的漂亮大楼，楼顶的排水管从办公室里面走，下雨就可能漏水到办公室里。
比如说，房东搞了伊莱克斯的冰箱和按摩浴缸在屋子里，可是房门和门框总也对不齐。
比如说，在淘宝上买了一台街机，快递只送到火车站，火车站到办公室的这段，不好意思，自己找小货车。
小风同学说，这是成本因素使然。然而我认为，很多时候，把事情做得不那么乡土一点，其实并没有额外的成本。它需要的是思考。站在用户的角度思考，别人会怎么使用这项服务；而不仅仅站在自己的角度思考，我做了多少事来提供这项服务。（当然对于很多人来说思考本身就是一种高昂的成本，这是另一个问题了。）
比如写一个往系统里灌数据的小程序。解析CSV，校验数据，配置数据源，插入出错时的异常处理⋯⋯已经花了三天功夫来做这个功能，测试很全面，代码也经过了重构。可是，没有命令行接口。没有办法用一条指令完成整个灌数据的操作。这时候用户（以及出钱的客户）会怎么看待这个功能？
它不可用。它不能为用户创造任何价值。
程序员表示很委曲。我花了这么多心思来做这个功能，其实差也没差多少，你怎么能对我的努力全都视而不见呢？其实只要站在用户（和客户）的角度想想就会很清楚：如果它不能创造我想要的价值，那么它跟没做又有什么区别呢？
（其实真正开始做“一条指令完成”的时候，更多的问题就开始暴露了，比如性能太差。把事情做完不是那么容易的。有些时候土贼的解决方案看起来好像成本低，其实是事情没做完。）
所以，首先是要有决心，做事情不要做那么土。这需要两点前提：第一，要养成思考的习惯，不要让“站在用户的角度思考”成为一件困难的、成本很高的事；第二，要站在用户的角度思考，多想想别人会怎么用你的服务，你的工作以什么方式为别人创造价值。做一件事就做到最终可交付/使用/发表的状态，这会让你整个看起来很洋。
-
ThoughtWorks办公室里的街机
招聘广告继续发～我们在西安办公室里搞了一台街机。游戏很多，街霸，侍魂，名将，圆桌，拳皇⋯⋯
-
给我看你的博客
小熊写了一个用户体验设计师招聘广告。嗯嗯，从转帖广告的角度，如果恰好有设计高手看到，ThoughtWorks中国正在招聘用户体验设计师哟。
我很喜欢小熊的这个说法：
给我看你的portfolio或者博客,我很不喜欢简历这东西,你的博客就是你的简历,上面把你写得清楚
看到这个就想起我的偶像，这博客写到如此程度，何愁没有工作找上门啊～
所以涅，应聘的童鞋们，最好把你的博客一起告诉我们。看到一个精彩的博客，简历神马的都是浮云～
