Problem-solving life

去年Agile China我听Mary Poppendieck的一个session，题目我已经不记得了，但有一个一点非常深的inspire我。
她说：一个好的管理者，应该把团队视为由volunteers构成的组织来管理。对于管理volunteers团队来说，你可用的约束手段和激励手段都很少。Volunteers团队的组织边界更模糊。因为大家是志愿加入的，做得开心、能够创造价值，就愿意继续做，否则随时就会离开。你所能做的就是不断给这个团队指引方向，然后激励他们往那个方向走。
 
我时常会在很多场合想起Mary的这个观点，每一次我都会再一次深表认同。
 
最近看一本Seth Godin（一个geek，创建过几十个公司，做过Yahoo的营销副总裁）写的书叫《部落》。我发现他的说法和Mary的有异曲同工之妙。
这本书不是讲管理，而是讲营销，他说由于科技的发展，人更容易的回归到以前那种部落聚集的方式（mentally, not physically），这是人的本性。他做了一些分析，谈到为什么你可以并且要去lead一个部落，谈到你怎么样去lead一个部落。
一旦你能够lead好一个部落，营销就是很容易的事情（比如你摄影很牛，你吸引了一大群人围观，那么你推荐一个摄影器材，在这些人当中是会很有说服力的）。这种部落与志愿者团队有很多相似性。Seth在这本书里面讲了很多关于如何去lead一个部落的内容。我觉得很多是观念上的提点，很有启发，虽然看起来有点散。
 
ThoughtWorks的组织结构相比很多大公司而言很不一样，它是非常扁平的，这也是我喜欢TW的一个原因之一。不过这种扁平也会带来一些挑战：作为team lead，你会发现在这里你权力很有限：既没有行政权，又没有人事权，而且TW文化很看重平等和open，很多时候你的team member和你有同样的话语权。你面临的局面和领导一个志愿者团队差不多，你扮演的绝不会是一个manager，更多的是一个leader和facilitater。没有人喜欢被管理，但人们喜欢被lead。
 
Seth提到lead一个部落时，你需要构建一个四个维度的沟通体系：

•     leader->member

          你需要一个渠道来向你的team member来传播你的想法，去guide他们，去影响他们。

•     member->leader

          你的team member需要有一个很容易的渠道来向你表达他们的想法，或者说你需要有一个畅通的渠道来知道你的team member的想法

•     member<->member

          你需要建立一个机制，让team member之间能够很容易的进行沟通，让他们之间能够相互影响、相互激发。

•     tribe<->tribe

          你需要一个渠道，让你的team member能够和其他team的人进行沟通，以便影响更多的人，也被更多的人影响。
 
对于一个自组织、自学习的团队而言，第三点尤其重要。如果你只是告诉你的团队他们需要做这个做那个，而没有建立起来这个团队自己的分析解决问题的机制，这样团队的能力很大程度上都没有被发挥出来。
在团队里面建立一种相互学习、鼓励分享的机制对于团队的成长是非常重要的。作为team lead来说，这值得你花很多心思和代价。否则，你充其量就是一个特种兵，只能自己往前面冲，你的团队一直会被远远的落在后面。
 
让你的team meber不断的看见team的vision。一群人聚在一起，是因为他们有共同的目标和vision。但目标和vision往往很远，现实的工作往往是细碎的，你的team member很容易就会迷失在每天的细碎当中。你会需要不断的帮助他们看见vision，给他们指明前进的方向。让他们虽然干着采石工的活，却当作是在建设雄伟的大教堂。这样他们自己就会有动力跟着你往前走。
 
除了让你的team member能够经常看见前景之外，你需要不断的激励他们。我认为TW中国一件非常amazing的事情是招聘到的员工都是非常优秀的，直到现在还是这样。他们都非常聪明、好学、有激情、有理性、有个性、有创意。剩下来的事情就看作为team lead的你能不能很好的培养他们。不断的鼓励他们，去了解他们，陪伴他们度过困难的时候，经常给他们一些提点和指引，不断的认可他们哪怕微小的成就。别人说乔布斯把他的team members当作自己的孩子。
 
这其实不仅仅是team member的需要，也是你自己的需要。人会改变环境，同时也受环境影响。如果你周围人的能力始终不能够提高，你也不会有很大的进步。你的团队能实现的价值会被限制，你能实现的价值也会被限制。

天下没有不散的筵席，乔布斯终于还是走了，一个时代要结束了，我很难过。

为什么这世上只有一个乔布斯？他究竟有什么样的能力和特点，以至于他退了之后，给人的感觉就是一个时代的结束呢？

首先乔布斯是一个非常非常懂人的人，甚至比你自己还了解你，了解你想要什么。乔布斯说他从来不做用户调查，因为很多用户并不知道自己需要什么。他所做的不是满足用户的需求，而是深刻的理解和挖掘用户的心理之后，结合时势的发展，创造了用户的需求。按说具备这样能力的人应该不少，但是他们大多在搞心理学，剩下的一小部分和乔布斯一样，在做产品。

在这能深刻理解人心理需求的做产品的一小部分，乔布斯又是非常善于使用技术的一个。乔布斯历来做的东西都非常有技术含量。能做出有技术含量的东西的人非常多，但是能够根据用户心理用简洁的界面设计和交互设计把高技术含量包裹起来的人，少而又少。使用苹果的产品，经常会让你有一种心领神会的感觉。乔布斯把他的产品摆在了一个技术实现和用户心理恰好平衡的位置，让用户基本凭借common sense就能使用非常有技术含量的产品。

有这样能力的人按说也不应该只有一个，但是具备这样的能力而又能够站到一个足够高的平台上的人，少之又少。苹果公司成立以后，一直就非常耀眼，乔布斯从来都不是默默无闻的。他有足够的资源来实现他的想法。

即便有能够深刻理解用户心理又善于使用技术且站在足够高平台上的人，也没有乔布斯的偏执。苹果的产品，乔布斯一个人说了算。他说不行，再多人说行也没用。

所以，这世上只会有一个乔布斯。

结对编程（Pair programming)是敏捷开发提倡的一个实践。目的有几个方面，一是知识共享，不同的人对于不同的技术理解不一样，对业务理解不一样，结对编程有利于在团队里面传播和分享知识；而是能力培养，通过手把手的教，实际的坐在一起写每一行代码，新人或者能力相对较低的成员可以很快的从能力较强的成员身上学到很多东西，包括对代码的理解，代码的设计，写代码的有效方式，甚至快捷键；三是减少犯错，两个脑袋、四只眼睛，很多时候能及时纠正一个脑袋两只眼睛犯的错误。

在一个团队成员能力有一定差距的时候，通过老人和新人pair是一个有效提供团队整体能力的方式。但是前提是：团队里面的老人多过新人。否则呢，我以为会很糟。

但实际发现，未必那么糟，新人和新人pair能带来不一样的好处。

我现在所在的项目，有三个刚入职的dev，两个入职一年左右的dev，还有我这个入职三年的dev。本来勉强是能够以老带新进行pair的，不过最近有个老dev休假两周，问题就来了，老dev匀不过来了，不得已，只能让新人自己pair了。结果发现新人在一起pair的时候挺欢乐的。为什么呢？因为新人水平都差不多，每个人都有更大的话语权和主动权，不会顾及能否抢键盘，能否主导开发等问题。总的说来就是，新人和新人pair的时候，他们会更放松，更容易让他们建立起自信。新人和老人pair的时候，通常都是老人在主导（尤其是项目交付压力大的时候（你见过交付压力不大的项目么？）），新人从思维上是被动的跟随，被动的去理解和分析问题。新人一边理解业务问题，一边在脑中将其和代码进行映射，又要学习代码设计，又要学习分析业务问题，又要学习写测试用框架重构代码等等。因而，新人在和老人pair的时候不可避免的或多或少会有压力，具体情况依新老人情况而定。想起我当年刚pair的时候，敲键盘的时候，手指都发抖，键盘不熟，快捷键不熟，代码也是勉强跟过来理解的，真到自己写，还得仔细琢磨前前后后到底怎么回事，老人在一边看着着急，在他看来很明显的几行代码就能搞定的，我需要研究半天。

新人和新人pair则可以缓解很多这方面的压力，而且新人在和老人pair学习的过程，每个人的收获和领会不一样。当他和别的新人pair的时候，他们可以相互教授相互学习，新人自己也能时不时的当老师，把自己学到的好方法在别人面前卖弄，自信心很快就涨起来了。同时，在他教授别人的时候，对自己刚学到的东西也是一个梳理和总结的机会。这样的过程会让他有更深入的思考，因为他需要跟他的pair讲明白这个问题，甚至说服他的pair，首先他自己要想明白。

当然，长期让新人和新人pair是不合适的，还是需要以老带新提供团队整体能力。

把解决方案当成问题本身，这听起来是一个非常明显的错误，但如果你留心的话，你会发现绝大多数人都是这么干的。在花了几个小时跟我媳妇分析和梳理她所面临的问题的时候，让我也整理清楚了问题中心和解决方案中心的差别。

大家都知道把解决方案当成问题本身是不对的，但究竟为什么不对呢？明知不对的事情，为什么会发生呢？

在面对问题的起初，当没有占主导地位的解决方案出现的时候，大家还能够集中注意力在问题本身上面，围绕如何有效的解决问题这个中心去探索各种可能的方案。其间慢慢的就会有占优势的解决方案浮现出来，这个时候，这个解决方案就会获得更多的关注，人们会为了这个看起来比较好的解决方案投入更多的时间、精力和资源，因为它在一开始的时候优于其他解决方案一点点。就是这一点点，在马太效应的作用下让它最终胜出。到了一定的时候，它所吸引的关注就会超过对问题本身的关注，就会出现各种所谓的解决方案专家，而非问题解决专家。例如，你一定听过Spring Framework专家，你有听过依赖倒置专家么，有没有？你一定听说过敏捷开发专家，你有听说过软件交付专家么，有没有？你一定听说过Oracle数据库专家，你有听说过数据访问和存储专家么，有没有？

抢了关注的解决方案本身对解决问题而言通常都还是有价值的。但以解决方案为中心的坏处是容易造成僵化。一开始有优势的解决方案通常都是针对特定时间、特定范围、特定上下文的问题。一旦这些特定的因素发生变化之后，原来那个占优势的解决方案可能就不是最优的解决方案了。但如果以解决方案为中心，往往就会造成生搬硬套，通过扩大和完善这个解决方案来解决新环境下的问题。于是，这个原来产生出来的精干简单的方案，就一步一步的走向庞大臃肿的复杂化。进步力量就逐步演变成阻碍进步的保守势力。Hibernate就是一个典型的例子。它诞生于EJB横行的年代，在那个年代，它是一股清新的、自由进步的技术，轻量、简洁、直观，很快获得了被规范压迫得苦不堪言的劳苦大众的青睐，以至于逐渐占领了ORM领域内的主导地位。看看它现在的样子，已经是个肥头大耳的monster了。啥叫二级缓存？啥叫lazy load？啥叫open session in view？啥叫N+1问题？这些在sql年代闻所未闻的问题就变成了这个monster可供研究的资本。看看市面上有多少书讲hibernate你就明白了。ORM就那么点东西，再怎么深奥，这个问题本身几页纸就能说得明明白白了。这种解决简单问题不简单，解决复杂问题很复杂的技术，迟早要被下一个hibernate打败并取代的，就像当年它取代EJB一样。SpringFramework是另外一个典型的例子。

所以，始终保持清醒的头脑，以问题为中心，以解决问题为目的，避免以解决方案为中心，才能与时俱进。同样的问题在不同的时间、不同的环境、不同的背景之下，最优的解决方案是不一样的。总是保持以问题为中心才能够以一种开放的心态去探索最优的解决方案，而不是固守一个过去曾经成功的解决方案。从这个层面上来说，过去的成功会成功下一个成功的阻碍，过去越巨大的成功会成为下一个成功越巨大的阻碍。

不懂人的人，充其量能够把事情做到优秀;
唯有懂人的人才能把事情做到卓越。

诺基亚和苹果的差别在哪呢？

这两个企业毫无疑问都可以称作是优秀的企业，但在我看来，唯有苹果能够算得上是卓越的。诺基亚这个曾经牢牢占据用户心智地位的手机业霸主，为什么已经显露出颓老之势了呢？诺基亚在技术层面可算是相当成功的了。它家的手机曾经是品质的代名词，当年无论是通话质量、外观设计还是软件平台，都堪称是业界的风向标。可没想到被近几年才进入手机制造领域的苹果给狠狠的撞了下腰。更糟糕的是，苹果俨然取代其充当其了新的业界风向标。

诺基亚的技术、生成和制造都是非常优秀的，因此也成就了这样一个全球知名的大企业，但苹果开始做手机的时候，一对比就显露出优秀与卓越的区别。诺基亚不懂人，不懂得用户真正的需要，不懂得按照用户的需要来生产和设计。他们更多的是按自己的观点、按技术的方式来设计产品，这让他们“以人为本”的口号只是悬在了空中和人们的耳边。

不懂得人真正的需要，抓不住人内心深处的欲望，只是用各种还没有想明白的新技术来吸引人的眼球，激起一种短暂而又莫名的兴奋。苹果的手机只有一款，它似乎并不担心人们寻求差异化个性化的需要。而事实证明，它的理解是对的，人除了个性化的需求之外，也有同质化的需求，而这些相比真正内心的需求和欲望而言，都算不得什么。人们并不介意满大街的人都拿着和自己一样的手机，只要这个手机对自己真正有用，真正满足自己的欲望。诺基亚的产品线很全，高、中、低档都有，智能的、非智能的，音乐手机、照相手机、商务手机、运动手机，各型各款，满足各种不同需要的人。抓住的是人深层次欲望的外层表象，而苹果则是直接抓住了外层表象背后的深层次欲望，这就是差别。

这就是为什么苹果是卓越的，而诺基亚只是优秀的。

为人提供价值，就要懂人。

昨天看到一篇讲Agile Contracts的帖子，勾起了我前阵子对于敏捷定制项目的一些思考。

话说敏捷这个含着金钥匙诞生的霹雳娇娃应该是软件开发行业的救星，应该是假定可以将买卖双方拖出焦油坑的一颗银弹，从头到脚、从里到外无不闪着金光，透着与众不同。但即便是在自认为血统很正，对敏捷的理念、原则理解很清楚，对敏捷开发的诸多实践不折不扣执行着的，团队人员素质超过业界平均水平的TW，做起定制开发项目来，也是一点都不轻松。表面上的原因有很多，从客户关系、团队沟通、分工协作、知识共享到技术实践、架构设计等等方面，似乎都有造成这种困境的因素存在，不过似乎应该有更深层次的原因才会导致这些表面现象或者中间问题的产生。因为在理想的精神世界里面，敏捷开发的这套方式应该是挺完美的，她的产生就是源自反思传统软件开发模式的诸多弊病的基础之上。为什么她在现实世界里面的运行的时候并不像想象和描述得那么给力呢？

因为她并不是纯粹的抽象方法论，她要落地，来到这个喧嚣的尘世，进到焦油坑里，自然，会裹一身泥然后继续挣扎。

软件开发过程的一个天性（nature)就是风险，这个风险源自不确定性，源自人类认知过程的渐进性这一无法改变的现实。这一天性使得软件开发与任何其他工程行为都有差别，以至于很难从其他工程实践中直接借鉴方法论和实践。建筑工程算是曾经以为与软件开发工程非常类似的过程，软件开发工程也确实从建筑业借鉴了很多实践，但建筑业的认知过程较之软件开发过程而已，简直就是确定的。在图纸上设计好，拿去实施，最后得到成品，这个过程本身没有太多不确定因素，事先的设计与最终交付的产品以及客户的期望之间通常不会有太大的差距，因为建筑的专业性远远超过客户的理解和认识，客户所能评价的指标有限，他们脑子里的野猴子蹦跶的空间也有限。

而软件开发过程则不同，尤其是定制软件开发，它是一个随着认识的深入加上其他外在因素变化（例如市场、人事）不断变化的过程，高风险从来就没有离开过任何一个软件开发项目。就好比客户租了你的船在漆黑的夜里没有任何有效探测设备要试图共同穿越布满暗礁和激流的海洋。这个过程必然要求买卖双方更紧密的合作、更高度的信任，共同渡过难关。

出于对风险的了解，为了保障能够最终到达目的地，买卖双方需要某种形式的约定，以便风险变成现实之后，第三方能有个裁决的依据。

这种约定的设计与软件设计一样，很有意思，所不同的是软件设计是由机器执行的，约定的设计则是有人在现实世界里执行的。

前面所说的那篇帖子里提到约定分两大类，一类是fix bid，另一类是其他。

Fix bid是指约定好三个维度：fix scope, fix budge, fix schedule，其结果套用原帖作者的话：所见过的任何成功项目最终必然在一个以上的维度上不是fix的。为什么？因为不可能，中国的俗话叫掩耳盗铃。

其他方式就是不约定这样fix。作者列了4种，我只经历过他没细说的各种可能组合模式的一种，想象过他提到过的第三种。

本质上，这些约定的设计都是围绕一个问题：风险如何分配。风险这东西大家都讨厌，都希望尽可能的转嫁给别人，但是转的太多，对自己约束太少，也不是好事，因此是一个博弈的过程。不过原帖作者自认为所列的四种约定已经涵盖了现实中的绝大多数类型的软件开发约定。

第一种：hide it。忘了说了，这里还是在说敏捷开发（免得你像Matin Flower那样对我问道，这和敏捷有什么关系？）这种模式的意思是：不告诉客户你在用敏捷开发方式开发，外表上看就是传统软件开发模式，毕竟最终结果总要是一样的。原帖作者说这样做的问题就于客户会plan来monitor你，而你实际上内部又不是恪守原来制定的计划，就会导致要不赶工，要不走歪，要不作假。

第二种：no cure, no pay. 风险全放在开发商这边，不治好，不收钱。听起来挺吓人的。这样设计的问题在于，缺乏对于客户参与积极性的激励。因为风险更大的倾倒在开发商一边。

第三种：rolling contacts。签小合同，做完一个签下一个，随时可以停，双方都承担差不多的风险。开发商有提供产品转变为提供服务。这种设计的问题在于客户的风险变高了，如何衡量开发商提供的服务是一个很大的问题：按人月？按所谓的velocity point？

第四种听起来就很绕，而且比较扯淡：Money for Nothing, Change for Free。客户要改随便改，不另外收钱，但是如果做到一半客户想不做了，那得额外付一笔钱给开发商作为损失补偿。其结果会如何，我没想过。

就快说到要点了，下篇接着说...

看完了前任，该看现任了，外形是这样的：

按钮似乎少了些，而且多了块液晶屏，显得更现代了些。接下来还是来看看控制面板吧。

界面比以前更清爽了，而且克服了前任的好几个问题。首先，按钮的功能职责很单一，并且很明显：第一个是卡布奇诺咖啡，第二个是浓咖啡，第三个是淡咖啡，第四个是关机（这是个败笔，回头再说）。软件设计里面有一个原则叫单一职责原则，我发现这个原则适用于非常多的场合，包括UX设计。《设计心理学》这本书里面有提到两个例子，一个是电话的按键面板，另一个是汽车的控制面板。据统计，通常汽车控制面板上的按键按钮多达百个，而电话的按键总共就十几个，但是相比之下汽车控制面板上的按键使用起来更少让人困扰。为什么呢？你知道你们公司的电话如果要转到其他分机是怎么操作的吗？每种电话可能不太一样，大致可能是要先按一连串约定的键，例如R+341，然后几声铃响，然后挂机。为什么汽车面板上的键反而更容易使用呢？因为职责单一，一个键只管一个功能，一个功能也之需要一个键来开启，不需要更多的键相互配合，说到底就是：各司其职，不复用。

回到我们的现任咖啡机，打一杯咖啡通常只需要按一个键就好了，简单明了。

第二个部分是一排按钮下面的这个水量调节旋钮。暂且不说这个功能本身是否有必要，需求可能是因人而异的。除此之外，还是有些地方是值得商榷的。首先，这个文字标的是“Water Control”，会让人联想跟上面的Strong、Light按钮是否会有互动关系。水量大的时候，Strong模式下的咖啡是否没有水量小的时候浓度那么高呢？还是咖啡浓度都是一样的，只是水量更大咖啡粉更多呢？（答案我没有尝试出来）如果浓度随水量变化，那么Strong模式和Light模式的区分就比较难区分了。如果浓度不随水量变化，那么这个功能的职责倒是挺清楚的。只是是否需要采用这种无极连续变化的方式，这个需要考虑。最直接的问题就是，旋转到最小水量是，水量是多少？最大水量又是多少呢？第一次使用的时候心里多少都会犯怵，只能先旋到最小水量试试。另外这种无极变化的方式跟分段变化的方式比起来，一个好处是可以微调。但有多少场合下真正会需要这种微调呢？我看倒不如把这个旋钮换成三挡或者五挡的拨动片，每挡标明多少毫升，虽然降低了些灵活性，但更加清楚明了。

回到前面说的Power键，明明已经标了Power字样在按键上面，为什么按键本身还印了个电源开关的图标呢？原因很简单，因为需要表示它与其他按钮是不一样的。既然如此，应该在视觉上更加的突出这种差别，例如让其他三个咖啡相关的按钮靠得更近些，电源按钮离得更远些，或者干脆放到咖啡机顶上，毕竟这个对于最典型的使用场景下是没用的。

最后的一点，也是一个败笔，或许你已经看出来了，就是右边贴着的这个小纸条上说的内容。当Cake满了之后，需要进行一个系列操作，甚至要把咖啡机关掉，才能处理。Cake盒通常也就是一两天就要倒一次，这样需要频繁处理的问题，设计一个需要小纸条描述的系列动作来完成，本身就不妥。更糟糕的是，Cake盒藏在机身内部，我第一次倒cake的时候，几个人看完小纸条后大约花了一两分钟才找到如何打开机身，取出cake盒。

不过，尽管有些小败笔，整体来说，现任咖啡机的交互设计比前任要改进了不少。另外，现任打的卡布奇诺真的挺不错，泡沫极为丰富，个人感觉快赶上星巴克的了，没喝过的一定要尝尝。

公司最近新换了咖啡机，前任的长相如下。

既然被换掉，总有些被换掉的原因，一部分原因是因为前任老出毛病（其实也没有老出，只不过一次出毛病的坏影响会超过kill掉100次不出毛病的好印象）。但对我而言，更重要的原因是不太会用。为什么不太会用？看看它的面板就知道了。

首先，最吸引注意的是占面积最大的深色圆圈部分，很容易就引导用户按这里。不过很遗憾，在这个面积最大的区域的中心，放置的是典型使用场景中用户根本不关心的一个按钮：“开机/关机”按钮。这是第一个败笔。有人（包括我自己）在一开始的时候都有错按这个按钮的经历，你可以想象当你怀着好奇和些许紧张按下那个按钮的时候，期待机器按你预期进行响应的时候，机器七七咔咔响了一会，就不动了，连灯都不亮了，那种手忙脚乱、沮丧和些许难堪的感觉将在你心里留下何等的印象。

接下来看“开关按钮”外围这一圈，有三个按钮，凭这三个按钮上的图标，作为来打咖啡的你，能明白是什么意思吗？我想这几个图标没法让你map到你对打咖啡的场景中的行为。作为咖啡机的vendor已经意识到这个问题了，于是他们在每台咖啡机旁边贴了一个说明，如下：

一点代表普通咖啡、二点代表浓缩咖啡、三点代表冰咖啡。

感觉如何？完全不靠谱，三种咖啡跟它们各自按钮上的图标完全没有逻辑或者视觉上的联系。唯一能让你用好这个咖啡机的方式，是死记硬背，记住这几个按钮所对应的咖啡类型。也就是要求在你已经装的很满的脑子里面再塞点完全没有逻辑关系（连推理都没法做）的知识。在这个信息过剩的年代，每个人都有他应对扑面而来的信息的过滤方式。我自己把这个咖啡机的类型简化成：总是按I，其他不管。

第三个大按钮是标有“Washing”字样的按钮。作为打咖啡的场景来说，"Washing"不是这个场景里面的词汇。这个功能应该是属于系统维护的场景。将两个不同场景的功能不加区分的混在一起，只会加深理解和使用的难度。

另外，打一杯咖啡需要先选择模式，再按开关生成咖啡，这是典型的把实现模式（implementation model）不经转换直接呈现给用户的毛病，应当考虑把实现模式包装成用户脑中对应场景的mental model。

现在，如果你来设计的话，你会怎么改进呢？