展望未来，关心则乱
July 30th, 2011
（商业读书会第九期的题目突然变得很难： 拆弹滞与胀 | 财经杂志 和 Growth prospects: Beware the middle-income trap | The Economist ）
其实主题本身并不复杂：按人均GDP，中国正在进入中等收入水平国家行列；但过去几年保持经济增速，主要靠的是4万亿投资尤其是基础设施建设的拉动。尽管有家电下乡、汽车下乡等等政策，居民消费仍然不见起色。将GDP的50%投资到新的固定资产建设，这不是可以长期维持的成长方式。投资拉动的成长和中小企业在货币政策紧缩环境下的产销两滞，在财经杂志这篇文章看来，是已经响起的警钟。
解决方案其实也很明显。中国的消费市场潜力巨大，基本上就是保持增速的救命稻草。如果消费市场不能自行启动，就继续拉动。财经杂志提到的4万亿水利投资、Economist提到的55个新机场，都是在十二五延续基础设施建设拉动内需的标志。（居民收入一增加，就意味着大量的“传统企业”要走向互联网，因为这是接触大量消费者最直接最便宜的途径；就意味着这些企业需要人告诉他们怎么做互联网上的生意、怎么投资和运营互联网上的IT系统。嗯，跑题了～）
但是正如Economist这篇文章暗示的，中国人不消费，不是缺钱，而是缺安全感，所以居民储蓄居高不下：未来生老病死买房失业都没保障，没辙，只好攒钱。所以拉动消费市场还得靠社会保障。Economist这篇文章提到的3600万套保障性住房就是朝这个方向迈出的一步，还有财经杂志这篇提到的减税措施。今天跟徐昊聊的：改革开放三十年，又回到房管所排队分房，大家感到有组织管着真有幸福感。这倒也符合人类固有的认知偏差。
问题和办法都明显，之所以说这个题目很难，还是关心则乱：发生在身边的事，跟自己有关的事，就很难平平淡淡地看。形势本身就是前有狼后有虎，既怕增速放缓工人失业，又怕通胀过速怨声载道，再加上各种与形势无关与人有关的丑事，就愈发觉得事情真是难办。大抵事情真做起来都是复杂的、困难的、需要权衡取舍的，不会像书上写的那样简单明了。
对比这两篇文章，有几个关于阅读本身的心得：
- 萨缪尔森说，宏观经济都是扯淡，经纪人假设、边际效用递减、交易成本，三条原理解释一切。
- 看材料要看到人的想法。没有一个抽象的“政府”，各级官员的想法是不一样的，官员和央企的想法是不一样的。在这一点上，Economist显得不如财经杂志了解中国国情；当然大面的预测本来也不需要太多国情。
- 严肃的文章不要感情色彩太重，诉诸于感情反而教人看不懂了。财经杂志这篇文章看着总觉得有点悲壮（可能作者要的就是这效果），反而不如英文的文章易懂。
其实也不用太悲壮。不管最终消费市场是拉动还是拉不动，起码十二五期间还有几年好日子可以过。即便Economist文章里那几位“熊人”，预测撞墙的时间也是三五年后。三五年后的事⋯⋯不如就三五年后再说吧。
从南京到东京
July 20th, 2011
从新修好的南京南站坐了个动车，就开始向东走啦。走的时候南京突然开始下大雨。好像每次我要换个地方都会下雨啊。
折腾折腾折腾，折腾到位于东京站旁边的酒店住下已经凌晨一点多了。
一觉睡到早上起来吃了早餐才恢复精神。Martin和Jez留了一个信息，已经先吃过了。
一起去到 Agile Tokyo 的会场，Yoko san在做准备，来了很多客人。想起前几年组织会议，真是辛苦的事啊。
主持人小姐很漂亮，Jez san很有型。
Martin和Jez的演讲都做完了以后，就一起坐山手线去秋叶原啊秋叶原～
Martin san伟岸的背影在秋叶原啊秋叶原～（还有张更有型的照片但是我不会贴出来啦～）
逛了大量的漫画和萌之女仆咖啡店。
Jez san明显有点high（其实我也是）。
晚上又很happy滴喝了不少的Asahi和清酒，聊了很多的敏捷和持续交付。于是Agile Tokyo 2011的一天就这样过去啦～
至于Martin san和Jez san讲的内容⋯⋯嗯，我已经做了笔记并且拿到了胶片，待到回头再说吧～
生态系统 重于 经济合作
July 16th, 2011
（商业读书会第八期的题目： A Rush to Failure | HBR ）
首先这是一个破除迷思的案例：据说某些特定领域（例如航天、军事、通信）仍然适于用瀑布方法开发软件应用而不适用敏捷方法，据说一个重要的原因是这些领域中软件的可靠性要求是如此之高以至于必须首先做好一切设计然后编码然后进行长时间的测试。但这个案例告诉我们：即使在航天领域，瀑布方法也不工作。
不过再去长篇累牍谈论敏捷已经没什么意思了。越是要求高可靠性，越是不能在生产环境下失败，你就越是需要尽早验证、尽早失败。这是一个如此显而易见的道理，只不过在90年代之前人们没有足够丰富的计算能力将其变成现实。就连航天领域也会追求速度，但速度和质量并不必须是互斥的，“ 可工作的软件 重于 求全责备的文档 ”讲的就是这件事。
相比之下，文章末尾处关于合同的对话更有意思。当然这也可以归结为“客户合作 重于 合同谈判”，但在我看来，这更多的是一个社会视角（而非软件开发视角）的问题——我听过客户这样说：“我们会尽力与你们合作，我们的共同目标是履行合同。”这是将企业间的合作完全视为经济活动所带来的必然结果：在项目进展中我会尽力跟你合作，但这并不妨碍我在合同谈判时尽力占你的便宜，因为“合作”被视为个人的态度，而“谈判”才是企业间的关系。
老师讲到另一个客户跟外包商（如果一定要用这个词的话）合作的方式是完全不同的。这个客户在合同谈判时努力讨价还价，然后在敲定价格之前问：“你们确定这个价格能保证足够的利润？你们确定不会难做？”得到肯定的答复后他才放心签合同。他们派人到中国外包商的办公室一起工作，来自两个公司的人融成同一支团队；他们不仅关心进度而且关心外包商的人员培养，乃至帮助建设基础设施和买书。这都是基于一个朴素的道理：找到共赢的方式，然后让上下游企业都变强，那么所有人都会因此而获利。
所以就像德鲁克说的：企业要赚钱，这是不言自明的事；惟其为消费者、为社会做出了什么贡献，才是定义一家企业的方式。构建和维护一个共生共赢的生态系统，清晰自己在其中的定位，帮助生态系统中的其他玩家（甚至竞争对手）共同成长。这样超越经济合作的生态系统将使得“合同谈判”最终成为一项无关紧要的例行程序，因为双方都知道对方会全力以赴而不需合同的约束。
百年老店的基因
July 8th, 2011
（商业读书会第七期的题目又是两篇： IBM’s centenary: The test of time | The Economist 和 IBM- 1100100 and counting | The Economist ）
老师说：“小心哦，第二篇很长的～”其实第二篇无非是《 谁说大象不能跳舞 》的缩写，读起来很快。第一篇里讲到成为百年老店需要的企业基因，并且对几家现在的热门企业做了比对，颇有点意思。
尤其是在IT这种日新月异的行业里，要想做一家长存的企业，就不能让自己绑定在某个产品、某个平台、某个技术，而是“致力于一项超越任何具体产品或技术的事业”。把这作为百年老店的基因，作者认为苹果、亚马逊和Facebook看起来有百年老店的潜质；戴尔、思科和微软的长存能力很成问题，尽管它们现在很强大；Oracle正在努力建立一个超越性的使命，而Google尽管从来就有超越性的使命但从来就太过依赖单一产品（搜索和广告），所以这两家的长存性还是个问号。
联想到今天开始读的 德鲁克 讲：定义一家企业的，不是企业生产和销售什么，而是客户对企业需要什么。是以，关注自己生产和销售什么的企业，只能在一时恰好赶上客户的需要；关注客户需要什么的企业，才能基业常青。即便是大热门的通信行业，也有走向 日用品化 的一天，而且这一天好像已经不远了——核心网和接入网会变成日用品甚至被 收归国有 ，习惯了用技术语言描述产品的厂商学着笨拙地 面对消费者市场 ，这都是一年中亲眼所见。
德鲁克还讲，企业只有两个基本职能：市场营销和创新。德鲁克还讲，只有管理才使得知识和知识分子得以发挥他们的作用。那么我相信，这种作用主要不是体现在市场营销上，而是体现在创新上。上个周末老师讲了企业发展的波浪：现有业务上升的时候，就是创新的最佳时机；而现有业务进入平稳期的时候，创新的压力会变得巨大。
（德鲁克还讲，管理的三件根本任务：经济绩效；员工的成就；社会责任。介个～不知道松哥和胡凯看了有何感想？）
对于企业如此，对于个人亦如此：绑定于某种特定的技能、特定的行业，放在长期来看都有日用品化的趋势。致力于一件超越任何“我能做什么”的事业，把眼下的利益、能力的成长和对社会的贡献同样重视，保持学习并总在顺境时寻找新的增长点，这也是让自己变得强大的基因吧。
不知不觉写到深夜，想起了 信长公唱起敦盛 ：
人間五十年、下天のうちを比ぶれば夢幻の如くなり。一度生を享け、滅せぬもののあるべきか。
往积极的方面想，既然“岂有长生不灭者”，怎可不抓紧时间尝试直到发现自己的极限呢？
职业规划中的“我想要”和“我需要”
July 7th, 2011
最近听到一些年轻的同事纷纷想转职，想从程序员转做业务分析师。尤其是年轻的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进入，每天参加code review，并且学着写Chef脚本。从项目管理的角度，我希望所有人能做所有事这样项目就不会有瓶颈；从人的角度，我不想看到“ThoughtWorks PM”、“ThoughtWorks QA”，我想看到一个个Perryn的复刻，随时准备踢别人屁股并且搞定任何事。
然而，关键在于⋯⋯
正如我一再强调的，所有这些能力，都不需要得到一个专门的职位或者头衔才能开始获得。因为它们有一个共同的特点：它们都基于人类语言。
软件开发从根本上来说，是将人类可理解的连续的物理世界，以图灵机可计算的方式建模为离散的数字模型的过程。而整个软件行业的各种行为中，只有编程（即：以图灵机可计算的方式建模）这一行为不是基于人类语言，而是基于机器语言的。换句话说，即使不戴BA/PM的帽子，你永远可以和那些只懂人类语言的麻瓜们练习其他能力；一旦你脱下了程序员这顶帽子，你将没有机会练习严肃的编程。这一根本性的分野决定了一个事实：程序员可以转向其他职位，而其他职位无法转成程序员——所有post-technical的人，无论多么努力保持自己的技术水平，最多也只能停留在转职之前的水准。
因为这是一条不归路，所以在说“我想要做⋯⋯”之前请想清楚：离开编程的键盘，你所追求的可能只是一种很简单（尽管不容易）就能学到的能力；但与机器对话——整个软件开发的根本——的能力，当你发现自己需要的时候，就再也找不回来了。
