审于音 聋于官

魏文侯和田子方一块喝酒，有乐队伴奏，魏文侯立即指出编钟的音高不一致，左边的高。这时田子方没有像很多下属一样抓住这个拍马屁的机会，大呼“领导英明！！！”，而是泼了一盆凉水，大意是说君王的职责在于了解乐官，不在于审评音调的高低，如果专注于审评具体的音调，就会对疏于对乐官的管理。魏文侯恍然大悟，回应了一个字：“善”。

挺有意思的小故事。想起高中的时候，经常看见校长在校园里努力地弯下挺着啤酒肚的腰去捡地上的废纸。

田子方指出了领导的努力方向错误，投入太多时间做下属应该做的具体事情，就可能忘记自己的本职工作。其结果当然不言而喻。

这也是为什么很多人抨击“技而熟则仕”的原因，即认为技术很好的人当管理者后可能适应不了新的身份，“忘记”不了过去，偏向于撇开属下自己赤膊上阵，忘记了自己指挥官的角色。因为“亲自上阵”是其熟悉的，而“指挥作战”则是陌生的。

还有就是很多技术出身的管理者对自己太自信，只相信自己，不相信属下一样可以完成任务，索性自己出手，或者干预太多。造成属下没有锻炼机会或没有责任感，甚至心怀不满，尤其在管理者已经落伍的情况下。

在软件开发这样的团队中，很多时候是自我管理的，管理者的角色更多地是教练与顾问就可以了。

礼物

这是今天在书城看到的一本书的名字，包装精致的一本小书，说其精致是因为其用硬壳的精装，还包有横幅，上面写着《谁动了我的奶酪》作者5年后出的书，又写着张瑞敏对此书的肯定等等；说其小书是因为的确小，比A4纸的一半还小的小册子，翻开一看不到一百页，看着像一本书就靠着硬纸壳了，另外，在这不足百页的篇幅中还有很多整页的插图与同样占据整页的几句话摘要。

索性快速扫过整个内容。讲了一个场景很熟悉的寓言，很多寓言中都能见到的智慧老人给未化年轻人解惑的故事，而剥掉这个寓言包装，作者想说的其实就是三句话：

1. 把握现在，努力做现在的事，就会集中精力，忘记过去，获得幸福（你感觉幸福吗？）、自信与成功。这就是书的主题：礼物，自己送给自己的礼物。
2. 从过去中学习经验教训，改进不足之处，这样才能有进步。从现在开始做出一些改变。
3. 想象未来，提前分解动作，作计划。从现在开始做可以做的事，向目标靠近。

看来不愧为畅销书的制作者，充其量一篇演讲稿长度的文章就能包装成一本书。

当然，书的价值不在长短，这是不能否认的。对这几句话也是认同的。但是好像很多励志的作品也都是这么说，只是这本小书专门说这个，可能会让人印象更深刻。即使再深刻的哲理，说起来头头是道，做不到也白费。大多数励志信条对我等庸庸之辈都一样，看的时候热血沸腾，看过后待血流回归正常也就过了。这样的事多了都不知道是谁的问题了:(

这本书的附近就是另一本书：《影响力》，翻看了前言与目录，大概的意思就是总结了别人让你说“好”，“是”等顺从行为惯用的6类技巧。当然，“师夷长技以制夷”，等你知道这些技巧后也可以同样施于他人。这六个技巧是：

1. 互惠：先给你一点好处。如商场的免费品尝，尝过以后想不买都不好意思。
2. 承诺与一致性：做出的第一个决定会影响以后的决定，所谓拖下水。如以便宜的价格卖过主件后，再向你高价卖配件。（难以自拔的沉没资本）
3. 喜好：利用你喜好的人来让你办事。如明星广告等。（人之其所亲爱而辟焉）
4. 社会性影响：大家都认为对的一般也不会有错。如即使不喜欢，可是这个流行，于是为了让人看不出落伍也跟风了。据说一自杀会有阶段性的高峰也因为这个，这个时期流行自杀，所以那些平时忧郁这时候也有下决心的理由了。
5. 权威：权威的嘴大，说出的东西往往也不容质疑。药品广告现在往往都拍成访谈形式，里面会有几个白发苍苍的“老教授”从理论上捧这个药效。
6. 短缺：再不行动就没了，于是不管用不用得上先抢来储备着再说。如：坚持了多年的“跳楼甩卖最后一天”。

这六条之所以屡试不爽是因为在大多数情况下由这些心理指导的动作是正确的，这是人类长期的经验总结，最终固化到思维中。而心怀叵测的坏分子正是利用了这些思维定式，伪造触发条件，操控结果。

扫过这本书，立即想到刚才的小书《礼物》，至少用到了“喜好”和“权威”，嘿嘿。

结对工作实例

去了医院一趟。偶然见到了结对工作的实例：收费窗口中，都是两个人一组，一个人把票价录入系统，另一个人在旁边盯着显示器，应该是防止另外一个人出错。这种需要细心，容易出错的工作有两个人一起进行Pair working应该是有效果的。

结对编程的一个重要目的也是通过一个人在旁边同步检查减少出错。但编程和收费毕竟是两码事，编程需要大量的创作，而收费是步骤固定的操作。步骤固定的操作出问题的可能性主要在于疏忽大意，其每一步操作是可以预期的，因此另一个人可以检查是否出错。而编程则不同，实现同一个目标，可以有不同的方法，因此两个人没有一个共同的操作步骤，因此一个人不容易判断另一个人是否正确操作，至少较难立即发现问题，对跨度较大的问题不容易发现，而这恰恰是往后修复成本高的问题。因此在防止错误方面上结对编程的有效性是有限制的。

另外，由于编程是创作性的劳动，很多情况下程序员需要集中精力思考，两个人是否会互相影响呢？在有分歧的时候必然有一人的方案得到执行，而另一个人只能顺着她的思路进行思考，有时候在思路不同的时候很难做到这点，这样发现错误的机会就小了很多。XP的一个理念是代码共同拥有权，即每行code的owner不是某个人，而是整个团队，这样的前提下让两个人一起考虑同一个问题有其基础，而现实工作中，每个工作划分往往是有owner的，非owner有自己的任务，对其他人的工作就不会一样熟悉。因此，这种情况下，编码后的review也许是更有效的手段。

但结对编程在如下方面很有效率：

1. 强化统一编程规范，让老员工和新员工搭配。这样可以帮助新员工尽快进入角色。这也可以看作一个学习方式。

2. 在共用模块的编写上，双方必须达成一致，对这部分的熟悉程度也一样。因此有条件也有需要结对编程。

除了以上的发现，还发现医院好像很挣钱，人们排着队大把大把地塞钱。当身体出现问题时就顾不得用身体挣来的钱了。收费员打开抽屉，里面钞票多多。有个想法闪现：为什么那么多抢匪想不开去抢银行呢？来这里收益不会少多少，风险那可是小多了，呵呵。

绝世武功+宝刀

武侠小说中的高手往往都有两样东西：绝世武功和宝刀（或者宝剑等高效杀伤性武器）。一般模式是，主角一开始都比较菜鸟，被几个小毛贼追得满地跑，跑着跑着就跑到悬崖边，后面又有人追，没办法就跳下去了，结果大难不死，还因祸得福，发现山洞，里面居然有本书，还是武林秘籍，于是在没有其他娱乐选择的极度无聊情况下，只得照着书上小人的动作比划两下，没想到练就了一身绝技，再拿着洞里的被人遗弃的削铁如泥的宝刀，回去找追他跳崖的小毛贼单挑。结果可想而知，用宝刀削小毛贼的脑袋瓜子当然是不费吹灰之力了。渐渐发现还能削以前想都不敢想的人的脑袋瓜子，于是一个独步江河的大侠就这样出炉了。

其实，不管是武林秘籍还是宝刀，那都是法宝，和封神榜里的神人用的法宝一样，打仗得有好法宝，拼得是法宝，真正用法宝的人不重要，可见法宝的重要性。大侠在得到法宝之前什么都不是，人人可得而欺之，一得到法宝立马就翻身做主人了。作为大侠当然不能只靠超强的战斗力，还得有颗仁义之心，这是在检到法宝之前就有的，否则作者也不会让他捡。可是在拥有法宝之前，这颗仁义之心往往是毫无作为的，在以暴力作为游戏规则的江湖中，这颗脆弱的心是跳不起来的。只有等拿到法宝之后，大侠才能实现理想，才能继续读者的童话。

可见，光有美好的理想或目标是不够的，还得有法宝的支持。

软件开发也一样，光有好的目标是不够的，还得有好的工具或技术支持。

多快好省是所有产品开发的目标，不仅仅是软件开发的目标。那么在软件开发中，用什么工具和技术来达到目标呢？好的开发过程当然算是一个法宝了。什么样的开发过程可以称得上法宝呢？和宝刀一样，得使着顺手才能使得溜。因此，没有一个固定的好的开发过程，只有对特定项目情况和组织适合的好的开发过程。

而开发过程是一个大得方面，其本身也需要工具和技术支持，否则也只能是流于形式。比如要达到“好”的目标，需要bug少。从bug生命周期来看，可以在各阶段下功夫：

1. 引入bug

在编码阶段，目标当然是不引入或少引入bug。工具或技术有：聘任优秀的程序员，保持结构清晰的代码，消除重复代码，用SVN进行代码控制，进行review......

2. 发现bug

编写覆盖全面的单元和功能测试案例，使用自动化的测试手段和工具，如JUnit、Cruise Control、Bugzilla......

3. 找出bug

功能强大并且方便的编程环境和调试工具，如Eclipse, M$ VS......，还有纪录详细的log等等

4. 杀死bug

当然要切实杀死bug，最常见的问题是杀不死bug或引入新bug，杀不死是因为可能在其他地方隐藏着同样的bug，为了避免这种情况，在编码阶段就得努力消除重复代码。杀死bug过程也是编码的过程，因此又是下一轮的bug引入阶段，循环开始了。

可见，整个过程就是不断使出法宝的过程，过关斩将。

一件件法宝使出去了，固然制服了bug，达到了“好”的目标，可是“快”、“省”的目标还能达到吗？法宝的使用是要负使用费的，另外需要时间。

得从两个方向看：

1. 横向来看，即在静止的时间片中，多快好省之间是有内在矛盾的，这个不难理解。因此，必然不能全部达到最优。所能做的只能在这四个目标间进行平衡，达到设定的可接受目标即可，认了。

2. 纵向来看，即在前后两个时间片间比较，由于工具的进步和技术的发展，这四个目标是可以同时提升的。

因此，得时刻扫描一下周围，看看法宝从天而降。或者出门转悠一下，说不定就碰到一个恶棍，然后他就追着你跑，跑到悬崖边.......

软件开发之 多、快、好、省

时下是个概念横行的社会，比如各种概念车、绿色空间、新新人类、web2.0.......反正是概念嘛，不管概念包裹下的东西新旧，只要概念新，包装形式稍有改变即可作为创新推出。众人闻风而动，唯恐落后，各种商机也随之显露，放风者自然不会错过亲自制造的东风，不失时机地提供产品或服务，最终满载而归，而众人也在追逐这些概念中得到满足，皆大欢喜。

既然如此，软件开发自然也不免俗。各种开发方法都以个性化的概念涌出，如近几年的CMM、CMMI、RUP、Agile、XP......让人眼花缭乱，每个看起来都是那么诱人，可是又有很多地方互相“矛盾”，该信哪个呢？

既然不知道哪个更好，不妨先自己捉摸捉摸。软件开发要达到的目标是什么呢？以老板们的想法，当然是“多快好省”了。

多：要功能尽量地多，最大化地满足用户需求。

快：开发速度越快越好，早点推出也许就能把收入计入这个财年。同时用户当然也希望早点投入使用，尽早产生效益。

好：质量要好，bug得少。

省：省钱！每月开出的工资越少越好，总成本越少越好。

实际上，老板们一般都是“旧旧古董”，接受能力较低，因此对于种种概念并不感冒。只要能“多快好省”，才不管他东南西北呢。因此，只盯着上面的四个字，其他的随便。虽然有点不讲道理，但也没有错，并且往往还对我们这些geeks有利，这也算是一种授权嘛。

不管这些华丽的概念，先按照基本的主要开发过程罗列一下，看有什么办法能达到目标。

需求分析

为用户设计软件，需求当然来自用户，因此不管哪种开发方法，都强调需求的收集及分析。XP更是达到了极致，在整个开发过程中让用户代表参与，随时获得需求信息，验证是否符合用户需求，快速响应用户需求。和以前的一开始从用户处收集需求，到最终开发完成再让用户验证，当然有进步。

但是这基于一个假设的前提：能找到用户参与到开发过程中。幸运的情况下，也许真的有这样的用户能提供这样的帮助。但是现实情况中这应该是很少见的（开发为软件开发提供支持的软件的除外），因此遇到一次应该去买点彩票，说不定就能顺便中个大奖。另外，用户代表能否代表用户也是有疑问的，单个或几个人总是有个人偏好的，如若不信，看看人大代表能在多大程度上代表民意就知道了:(

因此，更实际的方法可能还是传统的方法，在项目准备或开始的时候认真做需求收集分析，能做原型设计更好。为了控制对用户需求的偏离，如果项目较大，可以分成多个release，每个release完成后邀请用户体验反馈。

由于处于开发的前期，因此出现偏差对以后影响很大，所谓“差之毫厘，谬以千里”。为了减少不必要的返工，并且为以后开发扫除障碍，大家都知道要尽早确定需求。能有确定的需求当然好，但实际情况是大部分用户需求会变，或者说很难获取真实需求，往往到他能用的时候，他才能知道自己想要什么，也才能告诉你这些。因此，之前的努力是否有效就看需求分析人员的功力了，对用户的领域知识越多，以用户的思维考虑越多，越可能往正确方向走。另外，可以把客户化需求多的模块尽量放在后面做。

需求分析的结果形成需求文档。描述用户的需求，最好由一人来写，其他人支持，尽量保持内容的一致性及完整性。多人写的东西往往各部分“独立自主”，没有呼应，甚至因矛盾而“兵戎相见”。另外，多人写的内容，如果没有人通盘考虑，相互依赖，会造成“缺胳膊少腿”。

设计

在需求确定或大致确定后，可以进行设计，包括高层设计HLD和低层设计LLD。在XP中，对设计基本越少越好，因为其对需求的理念是易变，自然对设计不能做的很详细，需求一改变，以前的设计作废了，因此从经济的角度看，自然设计要少做，重要的是快速写出代码，让程序跑起来，然后让用户看是不是想要的东西。

而较传统的设计方法强调设计的详细、周到，恨不能把把伪码都写出来，然后再找几个“印度蓝领”翻译成IF...Else等等。好像日本的公司推崇这种设计程度。

其实这是两个极端，知道中庸这个词的中国人大概都知道走极端是不好的。因此不会有太多人有意采用上面的两个极端，尤其是第二种，估计大家不会犯这个“错误”。但往往有人不自觉地就采用了第一种不设计的方法，这倒并不是因为什么XP，而是不知道软件开发还有设计这一步，于是随心所欲，走哪算哪:(

实际情况往往采用折中，既不过于设计也不缺少设计。一般做到：

1. 模块之间的分割及接口设计

一般由一个人完成

2. 共用类、库的抽取

可以由一个人完成，也可以由相关人员协商

3. 各个模块的主要算法及流程设计

各自完成，无需很详细，能说明问题及其解决方法即可，无需达到UML图级别。

同样，要形成设计文档。同样的原因，建议由一人主笔。

编码

如果从最终产品来看，真正能运行的是编译后的代码，因此编码的重要性就不用多说了。在XP中，很快进入编码阶段，同样，这也是基于需求易变的理念，尽快写出代码好让用户体验反馈。为了支持需求易变，代码于是也不得不变，这样产生的代码会不会越改越滥呢？不用担心，XP有法宝：重构（Refactering），从一行行代码开始，不断改进，自低向上，越改结构越清晰。有了这个法宝后XP才敢不进行设计就恣意妄为。

和那种设计到伪码或画出UML类图相比，我是肯定采用Refactering的。如果在写伪码或画UML类图上花和写代码同样多的时间，当然选择直接写代码，最终要的是可执行的软件而不是这些文档。当然有人会抗议说没有文档难以维护，那只能说明代码写的不够好。好的代码应该对有能力进行维护的人员易读的。这点完全是可以做到的。

XP中还有一个颇受争议的武器：结对编程。即两个人坐在一台电脑前，一个人写，另一个看的同时思考下一步，轮换上阵。虽然很多人很反感这个方式，但是在某些方面还是很有用的：例如相互学习(训练新人)，避免开发过程中某个人离去对项目的影响，发现一些低级bug等等。另外，两个人在一起可以更好地集中注意力，当然相互闲聊除外。

其实，无论有什么武器或法宝，编码还是得靠人。只有优秀的程序员才能写出好代码。优秀的程序员和平庸的程序员写出的代码明显是两个“味道”。

测试

测试其实是个大题目，有很多种测试。至少两种测试需要进行：单元测试和集成测试。

XP中，单元测试被放在很重要的位置。这也是有原因的，因为需求易变代码总改，怎么能保证修改的代码没有影响其它代码呢？当然只能是谁测谁知道了，于是，只要有代码，就得有相应的单元测试来对应上，以便在改任何一行代码都可以通过运行所有的单元测试保证修改没有破坏其他功能。既然单元测试如此重要，干脆在写代码之前就写单元测试得了，于是单元测试代码的编写就放到编码的前面了。

由于本人也是重构的拥护者，因此还是比较认同这种测试先行的理念。但是往往发现写完全的单元测试需要花费太多时间，另外涉及到很多数据库的代码不太容易做单元测试。这方面还需要继续探索。

集成测试是代码完成后各个模块一起做的测试。在Agile开发的Continuum Integration理念中，集成是在编码过程中就需要经常做的，以便能尽早发现bug。于是集成测试也就得一遍遍地重复进行了。这么繁琐的工作当然得有工具支持。于是有很多开源的工具被开发出来，如CruiseControl等，能定时从CVS/SVN等代码库里取出代码进行集成，集成后进行自动测试，把测试结果自动发送到相关人员的邮箱中。当然是好工具，把这些工作都自动化了，保证质量的同时提高效率。当然，前提是集成测试案例得准备好。

综上所述，需求分析、设计、编码、测试每个过程中都存在方法的选择，以实现多快好省的目标。在根据实际情况作出分析后，权衡利弊，择其善者而从之。

教育欠费

从中关村图书大厦回来，发现在图书城附近昨天看到的那个人还在，自行车停在路边，上面支着纸板，写着全国欠教育经费***亿元，义务教育普及率不及70%等等，纸板上还写着“自行车 西安--〉北京”，应该是一路骑着自行车声讨过来的。身上套着一个厚布袋，上面也写着一些标语，既扩大了宣传也防寒，估计北京的冷是始料未及的吧！

和昨天一个人孤孤单单地站在那儿不同，今天围了十来个人，其中有两个老太太，正和那个中年人说话，听了两句，好像是痛斥贪污腐败的社会顽疾，估计是同情这个人以及他所代表的教育受害者，但也表达了一种无奈，就和对付贪官污吏一样，目前情况下没辙。除了这两个老太太说话外，其他的年青人都只是静静地看着，有点好奇但绝不是看热闹的那种好奇，更多的是思考，然后是无奈。

听了不到一分钟，还是决定离开，和昨天经过没有停留的理由一样，不是事不关己，而是无能为力。他在这里的目的应该不是为了向路上募捐，而是引起大家的注意，让更多的人知道这个状况，进而让国家重视这个问题。他作为个人，用这种方式，很不容易，但效果如何呢，每天从那里经过的有多少人呢？几千？几万？有多少是像我这样无足轻重、无能为力的人呢？恐怕绝大多数都是。因此，影响有限。

这时缺席的是谁呢？焦点访谈聚焦到什么地方了？各种媒体呢？都在娱乐选秀？！

一个为娱乐选秀而疯狂，或只能为娱乐选秀而疯狂的社会，要教育作什么用呢？

如果下次路过那里看到他还一个人在那里，我会劝他先回去吧，北京太冷！

合谋

中文吃完饭，在暖暖的阳光下慢悠悠地往公司磨蹭，忽然心中涌出一“志”，继而对旁边的同事口出豪言：“要是能整天这么在阳光下溜达就好了，除了晒太阳走路啥也不干，不想......”

自然，这个理想得不到大家的认可，理由如整天没事也会烦，云云。显得大家都具备共产主义素质似的。但我是不满意这些理由的，人家孔夫子那么高尚还欣赏曾皙的逃课计划：“暮春者，春服既成，冠者五六人，童子六七人，浴乎沂，风乎舞雩，咏而归。”

忽而又有人提房价的话题，讨论到底会不会降。

依鄙人愚见：房价应该不会降，政府不会允许房价下降，GDP还靠这个拉动呢。另外还得保证经济的稳定，一开始有降的势头，大家就会捂住口袋原地观望，于是开发商得像集贸市场摆摊的卖菜的一样，到黄昏时只能甩卖了，大家还要等，于是五彩的肥皂泡最终破灭，随之而来的是各种不安定因素。政府不会允许这个发生，因此不会让房价降下来的。

这是我今天中午以前的想法，梦想整天在太阳下漫无目的溜达的我又发现了另一个理由：

一两个人这样溜达没什么问题，如果大家都整天这么溜达，会不会出乱子呢？应该会，一群群的浑身使不完力气的年轻人在街上逛，总有碰撞的机会，打架斗殴是避免不了的，至于其他刑事犯罪事件也会大量增加，这样岂不是要社会大乱？政府同样不想看到这样的情况。

政府会采取什么行动呢？让大家都去上班啊，整天坐在封闭的办公室里就没事了，累了一天，即使在路上遇见仇人也没有力气去吼，更甭说出手了。好办法，可是凭什么让大家每天乖乖地去上班，老老实实地呆在办公室里呢？房子啊，房价保持在一定高度，于是这些好斗的年轻人不得不从银行借高利贷，然后每个月按时还债。拿什么还贷呢？当然是薪水了，每个月发，每个月还，但有个前提，那就是：老老实实来上班，把在外闲逛的心老老实实放在办公室里。

于是政府又解决了一个问题，办了一件实事。效果显著，上班时间在街上或公园里闲逛的都是老头老太太就是例证。他们为什么能闲逛？因为他们的贷款还清了嘛。

要让鱼鹰不停地捉鱼，必须每次都把它捉到的鱼从嘴里抠出来。一理也。

不能再瞎说了，时间不早了，明天还得早起上班，还等着下月的薪水还贷款呢！

顺应民意

现在几乎每个公司都会把用户需求看作第一位，用户是很重要的，最具说服力也是最具讽刺意味的就是在无神论主导的中国，很多公司把“客户就是上帝”这个口号绣在红布上，悬挂于最明显的地方，以为这就能骗得了“上帝”了。其实我等聪明的“上帝”心里明白得很，没有信仰的人（公司）对上帝是毫无敬畏之心的，表面称你为上帝，心里暗想骗你没商量。

既然用户很重要，那么在设计产品时当然要考虑用户需求，到底什么才是用户想要的？很自然就进一步思考：什么对用户来说是重要的？

于是分歧出现：一部分人认为功能对用户来说很重要，用户希望产品的功能越多越好，越强大越好；另一部分人认为易用性很重要，用户使用产品，需要简单并且能达到目的，复杂的东西会杀死过多的脑细胞。双方谁也说服不了谁，于是争论不休，这也是Don的一篇社论引得江湖大乱的原因。

也有人（Simplicity Does Not Pay Too Early）想趁机一统江湖，说这争斗的两方其实不矛盾，说的是一个理，纯属误会，大水冲了龙王庙。此人亮出的兵刃是“产品接受周期图”，简单说来就是：产品在刚出的时候功能肯定不全，于是越多功能的产品越受欢迎，并且早期的产品使用者都是接受能力强的新潮用户，具有较强的新产品学习能力，因此，对于产品的复杂度不太在意。随着产品生命周期的演进，功能越来越多，以至于达到极值，这时候产品的用户也不断扩展，除了前期的新潮用户，很多保守用户也加入使用者大军，这些用户只是为了某种目的而使用产品，于是更看重其需要的功能，并且不想花时间去学习使用那些高级功能，于是简单的产品会受欢迎。

看起来是很锋利的兵器：分析得很有道理，从逻辑上能讲得通，但是不知实际效果如何，是否经得起现实统计数据的打磨。

无论如何，这些争论都体现了我们作为产品设计者的思维逻辑，在设计的时候会努力思考什么对用户重要，于是按照自己的逻辑做出产品。希望用户能够明白我们的良苦用心，但往往用户并不领情。为什么会这样？Don指出：我们的逻辑对用户来说是无关紧要的，用户有自己行为，不受我们的逻辑控制。

这可能源于作为一个逻辑人对自己认识用户的能力的悲观。但不可否认，有很多偏见左右着我们，让我们自以为了解用户，了解了用户的逻辑，于是一路思考下去，直到发现南辕北辙（人类一思考，上帝就发笑）。

如果不能靠我们已有的了解加上逻辑思考，我们有什么办法呢？只能是顺应民意了，观察用户的行为，而不管我们的逻辑是怎样的。这可能也就是极限编程中让用户代表和开发团队共同工作的原因，最大化地体现真正用户的需求，而不是我们的设计。但一两个用户代表就能体现民意吗？什么是民意呢？

顺应民意，说起来容易，做起来不容易。

可控性与安全感

上面总结的主要是大家对Don Norman文章的争论。而他在文章中想说的是：功能多（可控部件多）的产品更容易被用户接受，因为用户会觉得这样的产品更强大（Powerful）。其有一例证，如果一件产品能把所有的步骤都通过程序自动化了，只设置一个开关，无需其他复杂控制，在潜意识里，用户会认为自动化的产品功能会弱，而认为需要很多手工选择的产品有更强大的功能。

这里可能有个潜在的因素，用户对于自动化的不信任可能源于控制感的丧失，所有的过程都由程序控制了。在此过程中不知道下一步会发生什么，不像自己控制的时候可以清楚地知道每一步的结果，而只能等待最终结果。说到底是对自动化的不信任。

使用产品时的控制感对用户来说是非常重要的，用户需要知道每一步输入后操作的确切结果是什么，并且希望产品实际的操作能够和预设的一样。对于经常有不确定操作结果的产品，用户会没有安全感。例如，对于基于浏览器/服务器模式的应用程序，用户使用的时候会没有安全感，不知道输入一堆数据提交后会发生什么，很多情况下是屏幕无赖地显示一句假惺惺的道歉语，例如超时、重复ID、输入超出范围......接下来，无论出错的是谁，用户都只能重头再来。

比如，写blog，基本上我不在线写，而是使用桌面程序（Microsoft Blog Writer，挺好用，并且免费，广告一下，呵呵）写，完成后再发布。这样在写的时候可以写几句就Ctrl+S一下，避免软件意外关闭导致文件丢失，而在网页上写就做不到这点。另外，写完后如果由于莫名其妙的原因暂时无法发布，桌面程序可以保存下来以后再发，而同样情况下网页上的东西很可能就丢失了，让人捶胸顿足或拿着弹弓去打玻璃。

因此，由控制感的丧失导致的潜意识里的不信任及没有安全感才是用户选择有更多可控制部件的产品的原因。如果一种产品得特性能保证其自动化操作是很自然的，不会有任何差错，我相信没有人会要求多余的控制。例如，没有人会想把打印机的打印过程插入控制，比如双面打印功能提供一个自己插手翻页的控制功能。而对于纸张设置，人们不相信打印机能在任何情况下都能正确地自动识别，所以一般打印机都会提供打印前设置的机会。

另外，可控制给用户带来还有选择的权利.虽然大部分情况下双面打印就可以了，但某些情况下的确需要单面打印，所以打印机应该提供这种选择的权利。也许某一天，打印机可以读懂用户的心思，这时候就可以完全自动了:)

Simplicity V.S. Features

由于Don Norman的文章Simplicity Is Highly Overrated ，网上进行了激烈的讨论，或藏焉或否焉。

其实，争论的主要焦点就在于Simplicity 和Features的选择，既为了保证产品的简单，是否可以减少产品的功能。

由Simplicity这个词，当然想到的反义词是Complexity，于是便把目标对准Features的多少。这是一个误导。真正需要关注的是用户体验，即易用性。

使产品简单易用，这个没有疑义，用户自然喜欢容易使用的产品，但是用户是否愿意用产品功能的简化来换取易用性呢？换句话说，当面临两个同类产品的选择，一个是简单易用但功能不多，一个是操作复杂但功能多，用户会选择哪一个呢？

回想以前买手机、电脑等的斗争过程，好像在价格相近时，考虑更多的是功能。当然，这是我个人的情况，也就是作为一个“逻辑人”的行为，不具有代表性。不过，有研究表明，在人们第一次购买某种产品时，看重的更多的是功能，而当使用一段时间再次购买时，看重的更多的是易用性。

背后的逻辑是，用户第一次购买某种产品，没有使用经验，不知道挑选的标准，而功能比较是很容易获得的信息，所以功能的多少被立为购买的标准。而当积累了大量使用经验后，会根据使用情况发现很多经常使用的功能，再次购买时，会用这些功能作为购买关注点，并且以这些功能是否具有易用性作为标准。当然，这个结论是统计结果，所以也会有很多人再次购买时还是追求一些不会被用到的功能。

上面的讨论还是基于功能少的产品在功能上能满足大部分人要求，依据是20/80规律，即80%的用户只会用到20%的功能，如此则有什么理由需要增加另外80%的功能来取悦另外20%的用户呢？倒不如放弃这80%的功能，一则降低产品成本，二则使产品简洁易于使用。但Joel Spolsky的一篇blog指出了20/80背后隐藏的推理错误，即关注的80%用户的20%功能，对每一个人来说可能是不同的，即80%人中的A、B用户，A用户感兴趣的20%和B用户感兴趣的20%可能不同，于是两个20%的并集大于20%，如此，不可能用20%的功能满足80%的用户，因此，得出结论：靠减少产品的功能来保持易用性是不可行的。

其实，易用性和功能之间并没有必然联系。当功能少时，做到易用相对简单，但不意味着功能多就一定做不到易用。要达到易用，需要好的设计，而不仅仅是功能少就可以达到。好的设计可以屏蔽底层的复杂性，而提供简单的使用界面给用户。对于大多数人，这样的产品才是具有吸引力的。

结论：提供能满足用户的使用需求并且提供好的使用体验的产品才是为人民服务的准则。

道不远人

今天又进行了一次“长征”，从海淀图书城步行回家，花了一个小时五分钟，原定的比上次少用五分钟的目标没有达到，但感觉还是很好的。一路走下来，感觉越走越轻快，锻炼的效果立竿见影 :)

缘起从长春回来的时候，有点感冒，第二天又去看电影，心血来潮，决定步行到电影院，结果发现走的过程很享受.一开始可能感冒的原因，感觉各个关节有点酸痛，但走过两站地后，出了点汗，浑身爽快，正是：腰也不疼了，腿也不酸了......妙不可言。

于是步行上瘾了，元旦出去的时候步行了一次，今天又步行了一次，更决定以后只要有机会就步行。

工作后，体育运动量急剧减少，大学的时候虽说也不怎么打篮球、踢足球，但是经常跑跑步，有段时间还每天晚上睡觉前到操场进行单双杠等锻炼，现在这些优良传统统统丧失，而又有各种借口不树立新的运动习惯，导致赘肉缠身:(

本人现在逃避运动的借口实在太多了，比如：没时间，没条件，没人陪，不方便......各种理由都冠冕堂皇，足以给懒惰的身体一个不运动的理由。而不运动又导致体重进一步增加，或者没有活力，更加懒惰，找来更多借口，更加不运动，于是恶性循环下去......可能得等到某一天懒到不想举筷子吃饭，才能打破这个循环。

要想不进入这个循环，只能找一个上面所有借口都不成立的运动了，而步行就是这样的运动。

没时间：每次出去或回来的时间提前一点就行了，这些时间全部投入到运动中去了，而不像以前得花大量的时间坐车到运动场所，运动一段时间再花和来时同样多的时间回去，往往花在车上的时间要多于运动的时间，够讽刺的。

没条件：只要有路就行了，即使没有路，人走得多便也成路了。

没人陪：人多时说说笑笑当然好，但独行也有独行的好，一个人想走多快就走多快，并且可以在走的过程中浮想联翩，在不对路上行走的车辆构成伤害危险的情况下尽可以大作白日梦，呵呵。

不方便：方便及了，只要认得路。尤其看着各种车辆，无论贵贱，堵成一串的时候，心里很是得意，心理阴暗的一面显露无遗，在阳光下暴晒，有利于心理健康:)

.......

所谓道不远人，步行之谓欤？简单、方便、操作简单、人人可行，还犹豫什么？！

道不远人，人之为道而远人，不可以为道。只有大众化、可执行的道才是大道，任何神秘的、复杂化的、远离群众、可执行性差的注定只能是孤芳自赏的道，或者说根本就不是道。可执行才是硬道理。