新年许愿帖
December 31st, 2010
咳咳～首先回顾 去年的愿望 ：
我想亲身经历一家重要企业的精益变迁，并且在其中扮演重要的角色。
这件事，正在发生，几乎超出了事前最大胆的设想。只是，现在还不能畅所欲言地谈论它。
我想把已有的技术磨练得更精熟，又学会新的技术做出新的东西。
学到了一些技术，主要是在咨询方面，而且在墨尔本看到更多想学的东西。不过，并没有变成“post technical”。学懂了编译原理，补上了多年的一个缺憾。还用HTML5做了 Jungling （请用Safari访问），虽然只得了比赛的最后一名。
我想变得更可靠更教人安心，同时更自信而不恐慌。
大概是吧。
2011年，还想继续做这几件事，做得更好。
之外，还想开始学会帮助别人。帮助别人找到成长的方向和坚持成长，在帮助别人的过程中学会帮助并且让自己变得更好。
就是这样。
我的五个特质
December 18th, 2010
胡凯说他有 五个优势 。处女座的事儿逼不会说这是优势。它就是特质，可能是优势也可能是劣势。嗯嗯，总之，我的五个特质：
- Deliberative，俗称事儿逼。所有的决策都可以想出负面因素。选择障碍的一种症状。
- Restorative，俗称搞定。扯那么多干啥，搞定它不就完了。
- Intellection，俗称瞎琢磨。为点小事就能挠墙半天，到底是为啥涅为啥涅～～
- Context，俗称爱打听。到底是啥精神刺激造就了今天的你呢？告诉我嘛～～
- Harmony…啊啊啊～～郭晓嘲笑我这个～～
话说，一个对所有决策都会挑毛病的事儿逼居然被人们评价为“勇敢”，这事情还真是令我介怀啊…
了解你的客户
December 18th, 2010
为什么你在兴致勃勃地做着演讲，而你的客户不像你期望的那样？为什么他不断看表？为什么他盯着你却没有真正在看你？为什么他似乎另有心事？
你真的了解坐在你对面的这个人吗？你知道他到底关心什么吗？
（ All For One 似乎是一本好书。）
问题解决型沟通（贰）：分析
December 9th, 2010
经过倾听、记录和回讲，你已经得到了大量的信息。现在你需要分析这些信息，找出问题是什么、以及如何解决。
分析
首先要记住：“分析”不是叫你躲在自己的格子间里凭空想。分析同样要跟最初提出问题的人一起来做，用可视的方法做，随时确认成果。
差距
一个简单的等式：差距 = 目标 – 现实
这个等式的意义在于，让有些人承认是他自己没把事情做好似乎比让他去死还要难，而偏偏只有他自己才是真正能解决问题的那个人。有时候你就是得把事情说得非常明白：既然你对现实有那么多不满，既然你有一个期望的目标，既然差距等于目标减去现实，那么差距就在这里，如果你不想承认差距的存在，也许你可以停止对现状的抱怨和对梦中美丽新世界的憧憬？
但是，差距 != 任务。仅仅弄清楚差距在哪里，是不足以弥补差距的。（否则我们现在就应该生活在共产主义社会。）你还需要继续分析。
根因
根因分析的一个办法是“5个Why”。要小心，使用这个方法有两个必要条件：第一你要确定对方愿意配合你的节奏来挖掘根因，一直问“为什么”很容易激怒有防卫心理的人；第二你应该有一个大致的方向，每个“为什么”都应该有导向性。之所以是“5个Why”而不是“28个Why”，部分是因为如果你问了5个“为什么”还没得到点有价值的东西，对方即使没有防卫心理也差不多被你激怒了。
另一个方法是 鱼骨图 。这个方法的缺点是导向性比较差，但适合头脑风暴。把每个差距都按照“人-机-料-法”这几个维度来分析一下，大差不差总能有些发现。
你可能还需要用 系统反馈图 来总结根因分析的成果。如果能找到符合直觉的反馈环，那么所有人都能更清晰地看到解决方案将会以何种方式生效。
计划
找到根因以后，解决方案应该已经呼之欲出了。你需要做的就是把它具体化。
解决方案中的每个措施需要两部分的具体内容：行动计划，和验收条件。让要动手做这件事的人自己来讲：每个步骤怎么做，如何验收；让负责验收这件事的人来确认，验收条件是否符合他的要求。如果说不清一件事的验收条件，那就等于说不清这件事该怎么做。如果对方说“要不你先做一个我看看再说”，也许你可以说“要不我什么都不做你看看是不是已经没问题了”。
所有东西都应该是相关人在一起讨论出来的，所以现在共识应该已经达成。确认你拍下了所有的照片，现在你已经得到一个清晰并且可操作的解决方案了。
（未完待续）
读《建设全功能团队》后感
December 4th, 2010
胡凯在InfoQ发表了 两篇 文章 。读后，简单的感想是：追求卓越的团队，就得所有人会做所有事。
所有人都得会编程。所谓编程，是指在离散的数字世界中输入信息量以建模连续的真实世界之某一局部方面的智力活动。如果不会编程，如何知道用户的价值应该怎样以数字方式建模？如果不会编程，如何知道数字模型的哪些部分可能存在潜在错误？不会编程的人做不好软件需求，也做不好测试。
所有人都得会测试。所谓测试，是指提前发现和消除用户可能在真实使用中发现的软件缺陷的智力活动。如果不站在最终用户、最终生产环境的角度思考，“质量内建”从何谈起？不会做测试的人做不好软件需求，也做不好软件开发。
当然，常见的角色还有需求和管理。不过，“所有人都要了解需求”是敏捷软件开发中的老生常谈。而管理，私以为它就是一种浪费。如果团队每个人都会编程、会测试、会跟客户沟通需求，我们真的需要项目经理吗？
其中最难的部分是“所有人都得会编程”。因此每个追求卓越的软件企业招聘和人才培养以及每个追求卓越的软件从业者的个人成长都应该将编程能力作为一个重点。
以上。
问题解决型沟通（壹）：获得信息
December 3rd, 2010
沟通有很多目的，例如解决问题、帮助个人成长、交流感情、杀时间等等。本文针对问题解决型沟通。
获得信息
专业人士的工作是解决问题，而解决问题的第一步是知道问题是什么。在动手（甚至动脑）尝试解决问题之前，首先要获得足够的信息。
倾听
首先学会倾听。耐心，让带着问题来找你的人慢慢把话说完。其中最重要但经常被忽视的信息是：提出问题者的目标和价值。提出问题的人往往会直接告诉你应该怎么做。告诉他不要急于进入解决方案，先讲清楚自己想要达到的目标和价值，然后你会和他一起寻找解决方案。
不光是对方的解决方案，还要学会放下自己的解决方案。专业人士都有多拉A梦情结，总希望自己能从百宝袋里掏出法宝让康夫破涕为笑。这个时候别去想你有什么法宝，那会让你听不清对方的问题。
有时候（如果你对面的是一个同样训练有素的思考者）只是倾听就可以解决问题。有时候对方只是需要平静地把问题从脑子里过一遍就能找到办法。如果对方正在一点点整理思路，不要打断他，可能他自己就能搞定。而他同样会感谢你。
记录
大多数时候坐在你对面的不是和你一样训练有素的思考者。所以他需要你帮助他整理思路──通过把他告诉你的信息记录下来。不仅记录“现在是什么样”，还要记录“我希望将来是怎么样”。只对现状不满而没有期望的人不是在请你解决问题，他只是需要一点情感抚慰；只讲期望而不说现状的人，嗯，他还没睡醒。
重复一遍：记录是为了帮助对方整理思路，而不是给你自己备忘。所以，不要在你自己的笔记本上做记录。用白板，或者其他水平相当的可视的工具来记录。把记录的过程变成一个共同创作的过程。随时问对方反馈“你看这样画对不对？”。如果他这个时候说“画得不对”，你就为自己避免了几个小时甚至几天的返工。
因为是共同创作，请注意记录的美观。有很多图示方法可以用，或者最简单的逐条记录也不坏。关键在于两点：（1）字体写小一点，字体大了就显得草率和难看；（2）手握住白板笔的前半，手掌贴在白板上写。漂亮（或者至少整洁）的白板才会让人有与你共同创作的欲望。这有一部分能力问题，主要是态度问题。
顺便附赠一个对“敏捷难道不写文档吗”这个问题的标准答案：一个好的沟通者会在信息还热乎的时候就把它可视化出来，立即与相关者达成共识，而不是开会时闷头记笔记回到办公室抓耳挠腮炮制出一个尽管漂亮但充满含糊和误解的文档。共识达成，然后把这个漂亮（或者至少整洁）的白板拍下来，文档也有了。
回讲
画好了现状和目标的可视图形，现在转过身来，给在场的所有人讲一遍，问他们“我画得对不对”。作为倾听者，如果你主动把沟通过程中的所有困难都揽到自己身上（“我画得对不对”），对方会感谢你，会愿意给你讲清楚。
另一方面，如果你是那个要给别人讲事情的人，请丢掉一句 口头禅 ：“你明白我的意思吗？（笨蛋！）”讲完以后问对方“我讲明白了吗”，然后请对方复述一遍，最好是以可视化的方式。
最后别忘了，拍照。
（未完待续）
阅读之2010秋冬季
December 2nd, 2010
（这次从西安出来以后读的一些书。）
《 反潮流 》。睿智而敏锐的以赛亚·伯林。我喜欢他关于马基雅维利的那一篇。只有当你不仅了解某人说过什么、而且了解某人何时何地说与谁听、而且了解当时的人对某人说的这些会如何反应，你才会更接近于了解某人是一个怎样的人、为何要说那些话。同样，关于犹太人的。
《 编程的本质 》。Stepanov是在向我们展现，科学家和工程师是以多么不同的方式编写程序。大量近世代数的概念。让我对自己进行严肃阅读的能力产生了怀疑。于是想要好好补习一下基础。
《 语言本能 》。语言是一种被继承的本能而非纯粹后天习得的技能。大量的实证。有新鲜感。
《 玫瑰的秘密 》。很可爱的小故事。
《 iPhone SDK Development 》。不错的入门书。我会写iPhone程序了～～虽然都是在模拟器上。
《 玫瑰的名字注 》。人物依据他们生活在其中世界的法则，不得不做某些事，而叙述者成了他的预设前提的俘虏。可是艾柯又不甘心做俘虏，所以他要再来注解一把。关于小说环境的设定，令人拍案叫绝。
《 精益企业 》。关于企业转型中领导者的角色部分论述精辟。但我产生了一个联想：每一句简单告诫的背后，都是一家（或许好多家）企业数十数百人的惨痛经历。不禁有点悲怆。另外，翻译太差。
《 Agile Testing 》。佳作。脉络清晰，内容详实。对于“如何做敏捷测试”的标准答案从此应该是“读这本书”。每一章的开头有本章内容脑图提供，省了我大把时间。
《 All For One 》和 《 True Professionalism 》。正在读，两本关于专业服务的书。后者提出了几个很好的问题：你想成为谁？你想为谁服务？你想和谁一起工作？
如果你不爱你的客户，你很难真的那么专业。
