《极客与团队》 书摘

极客与团队

从内心深处来讲我们都默默地希望自己是天才。极客的终极梦想就是得到一个激动人心的灵感,然后闭关数周甚至数月将它完美地实现出来,最后向全世界发布自己的作品,名动天下。同行们会折服于你的聪明才智,人们会排着队来买你的软件,名望和财富更是唾手可得。

不好意思先等一下:醒醒吧,你很可能不是什么天才。

事实上所谓的天才传说只是我们缺乏安全感的一种表象罢了。很多程序员都害怕和别人分享他刚刚开始做的东西,因为这意味着同行会看到他们的错误,从而知道这些代码背后的作者并非天才。这里引用本的博客上某位程序员的留言:

假如你一直都是单打独斗的话,你其实是增加了自己失败的风险,而且浪费了自己成长的可能性。

这里我们可以得到好几个教训。真正做出产品之前不愿分享好创意实际上是一场很大的赌博,你很容易在一开始就犯下很基本的错误,你有可能是在重新发明轮子。还有你完全丧失了合作的好处。注意到你的邻居和别人合作后进展有多快了吗?这正是为什么人们在跳进泳池前会拿脚趾试试水的原因:你需要确定自己在做的事情是对的,方法也是对的,而且不是重复劳动。一开始就踏错步的概率总是很高的,越早征求意见和反馈,就越能把风险降低。

记住这句久经考验的原则——“确保失败尽早发生,尽快发生,经常发生”——我们会在本书稍后详细讨论失败的重要性。

而我们却认为把绝大多数工程师关在独立办公室里不但毫无必要而且还很危险。今时今日,软件业已经不是个人英雄的行业了,它需要团队的合作,保持沟通渠道的通畅甚至比随时在线的网络连接更重要。虽然得到了不受干扰的环境,但如果方向错了,那也只是在浪费时间罢了。走进任何一家21世纪以来创建的、快速成长的高科技公司,你会发现工程师都是围坐在共享的小格间(也叫“牛棚”)里,或是共用一张桌子,很少见到各自把自己锁在办公室里的情况。

谦虚 没有人是宇宙中心。谁也不是万能的,谁都会犯错。你必须不断地提高自己。

尊重 你必须真心实意地关心同事。他们都是活生生的人,他们的能力和成绩都需要得到肯定。

信任 要相信别人的能力和判断力,在适当的时候懂得放权。

好一点的版本可以是这样“:嗨~我有点看不懂这段代码的控制流程。要是用xyzzy代码模式的话会不会更清楚一点?维护起来也方便?”注意这里,你谦虚地把问题归到自己头上,而不是他。他没有错,只是你理解代码有困难而已。另外提出的建议也只是提供了一种方法让可怜的你能理解代码,或许还能在项目长期维护上有所助益。你也没有提出任何要求——你的同事完全可以谢绝这个建议。讨论的范围被限定在代码上,没有涉及任何人的价值观或是编程技术。

我们来分析一下:成为人群中最睿智的人的确很让人高兴,而且能够指导别人绝对可以带来了不起的成就感。但是问题在于一旦攀至顶峰,人们往往就会停止学习了。而当一个人不再学习的时候,她就会开始觉得厌倦,一不小心还会变得落伍。虽然当领导很过瘾,但是只要能放下一点骄傲,你就能开阔眼界,接触新鲜事物。这说穿了其实还是谦逊的问题和是不是愿意像指导别人一样接受别人的指导。偶尔应该跳出自己的舒适区,在更大的舞台上接受各种挑战。这样你才能长久地保持愉快的心情。

对影响保持开放的态度 你越是容易受影响,你就越能影响别人你越是示弱,你就越强壮。这两句话看起来有点自相矛盾。但是每个人都碰到过某个同事,固执到叫人恼火。无论怎么试图说服他都没用,越劝越不听。最后怎么样?就我们的经验来讲,大家最后就会自然而然地把他当成障碍物“绕道而行”,再也不会有人听取他们的观点或反驳。没人希望这种事情发生在自己身上吧?所以请记住这一点:接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了,要别人听你说话,首先是要学会当一个听众。注意在被影响的时候,如果你要听取意见,一定要在你下定决心或是确定宣布你已经做好决定之前——要是你的主意老是改来改去的,别人会觉得你这个人没什么立场。

团队文化就像是一块含有酵母的面团:酵母(团队创始人)能将菌群培养物植入生面团(团队新人),从而变出一块好吃的面包(团队)。如果团队本身具有很强的风格,它就能压过新人带来的任何“坏习惯”。如果团队文化不够强势,团队就会被新人带来的风气所影响。由于未知的文化往往伴随着未知的结果,因此一个团队最好拥有自己的熟悉的团队文化。

撰写任务宗旨强迫他们在产品的走向上求同存异,否则到时候一定会拖缓(甚至停滞)开发进度。在网上公开任务宗旨后,不但整个团队自己可以完全专注在那些必须完成的事情上面,而且也不需要再浪费口舌去和潜在的贡献者争论产品方向——他们只需要让新人去读一读“让GWT更出色”这篇文章就可以了,很多问题都能迎刃而解。

绝大多数工程师都把会议归类为必不可少的恶魔。如果利用得当,开会是很有用的,但是人们经常会滥开会,组织不当,而且几乎一定会把会议拉得很长。我们期望的会议应该像污水处理厂一样:数量要少,位置要远,还要在下风口。所以这一节也非常精练,只讨论小组会议。

有关开会的五条小贴士: 1.只邀请一定要参加的人; 2.开会前要决定好议程,而且要事先通知所有人; 3.达成目的后应提早散会; 4.注意别跑题;5.尽量把会议安排在休息时间前后(比如午饭时间,下班前等)。

设计文档一般由一个人负责,两到三个人撰写,审核的人数则更多一些。它不但勾勒出整个项目的前景,也直白地告诉整个团队你想做什么以及打算怎么做。而且这时你还没有花费几周(甚至数月)编写代码,比较容易接受意见和建议,帮助你改进产品和优化实现。

强制统一代码的风格是保持代码可控的一种方法。让别人快速看懂、理解代码是非常重要的。

没有船长的船和一间浮在海上的等候室没什么区别——如果没人站出来执掌轮舵启动引擎的话,它只会漫无目的地随波逐流罢了。软件项目就和船一样:如果没人领航,那群极客只会闲坐在那里无所事事。

成为“主管”并不意味着你要为所有的事情负最重要的责任。领导的方法有很多,有的偏技术,有的偏情感。Google为领导团队的人准备了两种截然不同的职位(和头衔):TL(技术主管,tech lead)和TLM(技术主管经理,tech lead manager)。TL通常负责产品整体(或者部分)的技术走向,而TLM除了负责产品的整体(或者部分)技术走向外,还要关心手下工程师的职业发展和愉快程度。这样就可以把那些不想涉及主管工作中人员管理那部分琐事的工程师解放出来,让他们可以专心带队做产品。

要治好这种“管理”病,就应该采用宽松的方式,我们称之为“仆人式领导”,这个名字很好地表达了经理最重要的工作就是为团队服务,如同管家之于一个运转良好的家庭一样。作为仆人式领导,你应该努力去营造一种谦虚、尊重和信任(HRT)的氛围。这意味着消除工程师自己无法消除的像官僚作风这类障碍,帮助团队达成一致,甚至还包括加班的时候帮大家买晚饭等。仆人式领导要为团队填补前进道路上的裂缝,并在必要的时候给予建议,同时还要勇于冲到第一线。仆人式领导唯一要做的管理工作就是对团队的技术和人事健康状况负责。尽管完全把注意力放到团队的技术层面上是个很有诱惑力的想法,但是人事方面的状况也是同样重要的(但管理起来往往要困难无数倍)。

其实,你应该努力去雇佣那些比你聪明、可以替代你的人。这对很多人来说难以接受,因为这些人会经常挑战你(还会在你出错的时候毫不留情地指出来)。但同样是这些工程师,他们还会不断地给你惊喜,交出漂亮的工作。他们能引导自己更上一层楼,有些人还会主动想要去带领团队。你不应该视此为意图篡夺权位,而应该把它看作是让你多领导一支团队的机会,让你可以去探索新的机会,甚至可以放心去度假,而不必每天盯着团队的进度。

那么怎么才能有效地调教表现不好的人呢?我们两个(不幸)在这方面有不少经验,都是从经验教训里摔打出来的。有个比喻再恰当不过,就是帮助一个腿脚不便的人学着再走路,然后慢跑,最后赶上大家的步伐。这肯定要用上一些暂时性的微管理手段——同时还不能忘了大量的HRT,特别是尊重。规定好一个期限(比如两到三个月),然后设定一些你希望他达成的目标。目标要设得小一点,循序渐进,这样才有机会累积很多小成功。每周都要跟他碰个头检查一下进展情况,每个里程碑的目标都要清楚无误,这样才能轻易衡量成功和失败。如果他跟不上,双方也都能在一开始就意识到。这样,他也能认识到不足,自觉退出。反之,他会鼓起雄心不辜负期望。无论如何,只要手把手地帮助表现不佳的员工,你都可以借此激发必要的重大改变。

其实帕布罗原本是有很多更好的方式来处理这件事的:他原本可以对杰克希望在家多陪陪妻子的愿望表示理解,如果他的生产力的确没有降低,团队也没有因此受到影响的话,不妨让他这样继续工作一段时间。他原本可以和杰克商量一下,让他每周到办公室来一两天,直到宝宝和家里安顿下来为止。无论结果如何,只要稍微表示出一点同情心,杰克就会很开心了,长远来讲对大家都有好处。

记住,在领导团队以及达成共识的时候并不需要站到团队的对立面去(或是搞一言堂)。同样,你可以在成为强悍的领袖的同时保住和大家的友谊。我们发现和大家一起吃午饭是拉近距离的好办法,还不会让大家不舒服——这样你就有机会在正式的工作环境之外聊一些随性的东西。

史提夫·乔布斯曾经说过:“顶尖的人会雇佣和自己一样优秀的人才,而差一点的人只雇得到更差的人。”在招聘过程中一不小心就会在这句格言上栽跟头,特别是求贤若渴的时候很容易饥不择食。

只要把你公司的组织结构图想象成一系列齿轮,就可以轻松地看到它的效果。写代码的工程师是一边那个小小的齿轮,只有几个轮齿,他上面每一级的经理都是一个更大一点的齿轮,而最末端的大齿轮是CEO,拥有几百个轮齿。这样,工程师之上的“经理齿轮”(可能有十几个轮齿)转一圈,“工程师齿轮”就要转两到三圈。而CEO只要动一点点,就能让六七层之外的工程师齿轮飞速旋转!你转动的齿轮离底端越远,就能让下面的齿轮转得越快,不管是不是本意如此。

这引出了禅式管理的另一个秘诀:提问。当队员来向你寻求建议的时候,通常都是很让人兴奋的,终于有机会来修复点什么东西了!在担任领导职务前,你已经在这行干了好多年了,所以很多时候你会直接跳到解题模式,但是其实最不应该的就是这么做。工程师来问你建议通常不是要你去解决他的问题,而是要你帮助他解决问题,所以最简单的方法应该是问问题。这不是说要你把自己变成魔法八号球,这反而会适得其反。正确的做法应该是在HRT的原则下,帮助他解析分析问题,从而达到让他自己解决问题的目的。这通常能引导工程师得出答案,最重要的是,这是他自己想出来的答案,因此也就回到了本章开头所讲的主人翁精神和责任感。不管你是不是知道答案,这种办法几乎总是能让工程师觉得其实你早就知道答案了。是不是很难相信?苏格拉底会为你骄傲的。

有时候你的团队已经就下一步的行动达成了共识,结果却碰到了障碍。这可以是技术上的障碍,也可以是组织性的障碍,不管是哪种,出手帮助团队越过障碍继续前进是必不可少的领导技能。有些障碍对于你的队员来说几乎无法逾越,对你来说却是小菜一碟,让你的团队了解到你帮助他们解决障碍的意愿和能力是非常有价值的事情。

催化团队的另一种方法是给予他们安全感,这样他们就愿意接受更高的风险。风险是一种很迷人的东西——大多数人都很不会判断风险,而大多数公司都会不惜一切代价规避风险。因此常规的运营方式都是非常保守的,专注于小富即安,哪怕高风险可能意味着指数级的巨大成功。在Google我们常说的一句话就是,若明知不可为而为之,那么成功的机会肯定是渺茫的,但即使失败了,你的收获也比只尝试那些你知道自己肯定能完成的事情所得到的要多得多。如果要培养起敢于冒风险的氛围,就一定要让团队明白,失败没什么了不起的。

只要帮助团队设定好方向和目标,你就可以放手给他们更多的自主性,只要定期检查看他们有没有偏离方向就可以了。这样你不但可以有更多的时间来处理其他管理事务,还能大幅提升团队的效率。虽然在缺乏清晰目标的情况下团队也能够取得成功,但是这样通常会浪费很多精力,因为每个人努力的方向会略有差异。这会让人觉得很沮丧,导致团队进展缓慢,还会迫使你耗费越来越多的精力来纠正这些偏差。

我们强烈反对这种三明治赞美法,这不是说你可以无端地欺凌或者苛责别人,而是因为大多数人听不到谈话里关键的部分,也就是那些有关需要改进的部分他们是听不进去的。另外不要忽略HRT:只要表现出亲和力和同情心,无需诉诸三明治赞美法,同样可以提出建设性的批评。事实上,亲和力和同情心是让你的批评对象不会立即表现出防御心态的法宝。

想要知道团队快乐程度最有用的一招就是每次在一对一会议结束的时候问问你的队员“你还有什么要求吗”。这个问题很简单,非常适合用在会议结束的时候,它能帮助发现每个人保持生产力和心情愉快的需求,当然,你还需要小心探索才能获得更多的细节。只要你坚持在一对一的时候问,最后你的团队一定会记在心里,有事甚至还会主动来找你,告诉你他们需要什么才能把工作做到更好。

此外还有一个重要的部分就是要关心他们的职业生涯。如果你问你的队员五年后对自己有什么展望,绝大多数时候他们都只会耸耸肩表示没想过。其实这种情况下大多数工程师都不会说太多,但是每个工程师心里总有一些想要在未来五年之内完成的东西,比方说升职、学一点新东西、发布重要的产品,或者是和牛人一起工作等。不管有没有说出来,大多数工程师心里都会有抱负的。要是你想当一个好领导,就应该考虑一下怎么帮忙才能够实现这些愿望,让你的团队知道你真的放在心上了。最重要的就是了解这些没有说出来的目标,让它们显现出来,这样才能在给出职业建议的时候有可以依赖的标准来评估不同情况和机会。

寻找接班人。除非这辈子都不打算再换工作,否则你就应该为自己寻找接班人。之前也提到过,这件事要从招聘的那一刻开始做起:如果你打算在团队里挑选接班人,那么在招聘的时候就应该雇佣有能力接替你的人,这就是我们常常挂在嘴边的那句话,你应该“雇佣比自己聪明的人”。

保护团队不受混乱干扰。担任领导职务后,通常第一件让你注意到的事情就是团队之外的世界混乱不堪,充满了不确定性(甚至还有点疯狂),以前还是工程师的时候是看不到这些的。傅攀勃第一次当经理是20世纪90年代(之后他又回到工程师岗位上去过),他完全被公司里大量的不确定因素以及各种组织上的混乱给震惊了。于是他跑去问另一个经理,公司里到底发生了什么事情,怎么会突然一下子变得这样天崩地裂的。那经理听了大笑傅攀勃的幼稚:这些混乱情况并不是突然出现的,只是傅攀勃之前的经理保护了他和他的团队不受这些东西的干扰罢了。

要让所有人都落在“兴奋点”那一格里,你就需要鼓励那些属于“一潭死水”的工程师,给属于“看!小松鼠!”那一格里的工程师提供明确的方向。当然,那些属于“漫无目标”的工程师则两者都需要。因此,水和阳光在这里是没有用的,激励和方向的组合才是你需要提供给工程师的东西,这样他们才能开心起来,进而提高生产力。但是也不要给得太多——假如某个工程师不需要激励和方向,你再去激励他、指导他的话,只会造成反效果。

一般来说,一个人总是让自己沉浸在负面情绪里是不健康的行为——长远来讲,它会侵蚀你的一切,制造更多麻烦。“害群之马”是很大的帽子,一下子就把“我们”(也就是好人)和“他们”(捣乱的坏蛋)对立了起来。其实完全可以换一个思路来看这个问题。在带领团队的时候,不要把自己想成是一帮精英,众志成城地要把所有的烂人都轰走,而是要培养一种拒绝容忍负面行为的文化氛围,这才是正确的态度。要剔走的是行为本身,而不是人,单纯地区分好人和坏人是很幼稚的想法。规定好哪些是不可容忍的行为,然后予以惩戒,才是更有建设性的务实态度。

写一份明明白白的任务宗旨。这样可以随时保持专注,知道哪些是目标,哪些不是。

的巨大成功——至少在企业级的软件开发上Subversion做得很好。这里关键的地方不在于谁对谁错,而是能否和而不同,以及争论是否有继续的必要。一定要提醒自己注意这些问题,有时候你必须作出决定,舍弃一些东西,继续向前。

几年前我们手下有一个非常出色的工程师,但是他有一个致命的缺点,就是有时候会惹到团队里的其他人。我们没有直接轰走他,而是把他拉到一边问他有没有意识到自己的言论会让别人对他敬而远之。他表现得很吃惊,完全不能理解为什么自己说的话会造成这种效果,但是答应说会调整自己以适应团队。事实证明效果非常好,随着他的转变,问题也就自然消失了。

这个办法非常好用,Subversion 就是这样解决完美主义者的难题的。当时实在是没办法了,我们只好把帕特里克叫到一边,告诉他说:“我们决定以这个设计为起点开始工作,看看效果如何。希望你能帮助我们继续解决在这个过程中出现的各种问题。”出人意料的是,帕特里克对此完全没有异议,转身就继续研究其他难题去了。气氛相当融洽,帕特里克也一直在贡献自己的力量。

在完成自己工作的前提下,要求更多的责任。我们最爱用的比喻就是把你比作一个刚入行的守林人,受命于一个资深守林人去砍掉一棵生病受损的树。如果你只是抱着完成任务的心态,那么一定会径直走进森林,砍倒那棵病树,然后就洋洋得意地回来交差了。但如果你能把眼光放大一点,就应该把路上看到的其他病树也都记录下来,再准备好一个能迅速把它们全部解决的方案,让资深守林人看一下是不是可行。这样,下次守林人再碰到这种任务的时候,她就会首先想到把这份责任交给你。这不单是因为她了解你的能力,更因为比较轻松——她的工作量减小了。

你的经理不是千里眼,公司里几乎不存在沟通过多的情况,所以别犹豫,一定要在经理问你进展之前,就向她汇报自己在干什么。在遇到困难、完成任务、需要帮助,或是希望看到什么事情发生的时候,不妨给她写张条子。这样不但你的经理很清楚你在干嘛,同时也是对付微管理的绝佳办法:假如你的经理不断催你进度,那么主动以同样的频率给她发E-mail汇报就是让她收手的好办法。

害怕失败是糟糕的经理身上最常见的特征。缺乏安全感会把他们变得非常保守,这和一般工程师的工作风格南辕北辙。

坏经理通过藏匿消息,硬是成为信息和沟通的渠道的办法,来达到窃取胜利果实3以及让你背黑锅(有时候,甚至是她们自己的错误)的目的。很多时候,这种坏经理只是把你当作她往上爬的垫脚石,根本不关心你的职业发展,更不用说团队的幸福指数了。

随着公司的成长壮大,往往会滋生出各种官僚政治和流程,以便管理利润、降低风险、提高预期,以及支撑公司庞大的自重,而这种官僚机构到了一定时候会逐渐变成公司成功道路上的阻碍。和糟糕的经理一样,市面上有关糟糕组织的文章也是数不胜数,所以这里我们只谈一些经常会影响到工程师的组织性问题。

首先最简单的一个现实就是,大多数公司都不是以工程师为核心的。这就是说,工程师只是实现商业目标的工具,而商业目标本身通常不是技术性的。

创意是非常吸引人的东西,如果你不在意是不是一定要让别人知道是你原创的话,创意往往能变得非常有活力!有时候你会发现人们谈论创意只是想要让人觉得这是他想出来的,这时你就要作出选择,到底是要原创还是要让创意传播。尽管听到自己的想法从别人(可能这个人还有点让你看不起)的口中说出来会叫人很痛苦,但很多时候这是唯一让创意传播的办法。无论在大公司还是在小公司,这种事情我们已经见怪不怪了:公司高层口中的那些高深玄妙的概念和创意其实都是来自公司里的其他人。但请想一下,这些原本无人喝彩的创意在这种情况下能得到多少听众吧!

坏习惯总是很难改的。本小时候有一个老师曾经这样说道:“坏习惯是停不下来的,你只有用一个好习惯去替换掉它。”任何尝试过戒烟的人肯定都非常熟悉这种情况。公司也是一样——如果你想要消灭一个坏习惯,最好是用一个好习惯去代替它。比如你不喜欢现在的周会,那把它换成另一种不同形式的会议或是其他什么(更有效的)活动。不喜欢现在毫无意义的汇报流程?别抱怨,干嘛不自己动手写一份更漂亮的、好到没人可以忽略的流程?

有了这次糟糕的经验后,本开始把所有的工作分成“进取性”和“防御性”两大类。进取性的工作通常是指用户看得见的新功能——在外人眼里这些都是很炫、很令人兴奋的东西,或是能展现产品优势的地方(比如,界面改进、速度提升,或是互操作性的增强等)。而防御性的工作主要是着重产品长期的健康状况(比如,代码重构、特性重写、修改数据库模式、数据迁移,或是改进紧急监控等)。

不妨把这些好处想象成一系列的小赌博:有些人永远也不会回报你,而有些人会回报你同等的好处,另外还有一些人会涌泉相报。虽然事先很难知道对方是否会回报你,但是有一件事情是肯定的,那就是人们会记住你曾经在他们遇到困难的时候出手相助,而不是甩下一句“这不关我的事”。

和有能量的人交朋友 每家公司里都有一个“影子”组织,它没有任何文献记录,却有权有势,能产生极大的影响力,而只有少数几类人能在其中占有一席之地。 联络人是指那种认识公司里方方面面人物的人,就算他们不直接认识某个团队里的某个人,他们也能设法帮你找对人。有时候要办成一件事,只要托对人就行了,而联络人就是那种可以帮你找对人的人。

我们管这种技巧叫“三个论点和一个行动”,无论你向谁求助(不只是高管),无论你求助什么,这都能大大增加你成功的概率——至少也能得到一个答复 。 写得好的三个论点和一个行动的邮件(最多)包含三个点,让你解释问题的细节,然后一个(只能有一个)行动请求,绝不能有其他的内容。这份E-mail应该可以被轻易转发,要是你啰哩啰嗦,或者在邮件里写了四件完全不相干的事情,那么就会给对方造成很大的心理负担,其结果就是你的邮件会被丢弃掉。罗列要点一定要用简短的句子(每句话最长不能超过一行),行动请求也应该越短越好。你的E-mail应该谨守HRT的原则:有礼有节,避免出现语法错误和拼写错误。如果你实在忍不住或者真地需要在E-mail里描述背景或者包含更多信息,也应该把它们放在E-mail的最后(哪怕放到你的签名后面也无妨),然后清楚地注明这些是“详细信息”或者“背景信息”。

的新员工(我们称之为“Nooglers”)常常会问我,为什么我的工作这么有效率。我总是半开玩笑地答道,很简单,我只做对 Google和这个世界来说正确的事,做完之后我就等着被炒鱿鱼。要是没有被炒,那说明我做的事情对大家都有好处;要是真地被炒了,那说明这不是我想要服务的雇主。无论如何,我都不吃亏。这就是我的职业理念。

我们说了这么多选择辞职或是等着被炒的话题,不是要让你觉得如果你不喜欢现在的工作就应该马上准备简历想办法跳槽。相反,你的首要任务应该是做出必要的改变,让自己变得高兴起来,努力完成工作目标,而这一章讨论了好多可以帮助你做到这一点的方法。如果你不努力去学习、了解引导公司的方法,那就等于是拿自己的命运去赌博。

对新手来说,你的软件好用吗?界面是否友善,是不是方便尝试不同的选择?或者反过来,找个专家坐下来用上几分钟你的软件,有没有一种熟悉的感觉?对于刚上手的人来说,你的软件是立刻能让人投入呢?还是要面对一个陡峭地学习曲线,让人欲哭无泪呢?说得再具体一点,即用户在软件启动后30 秒能体验到了什么?光有一个技术上的答案(“她会看到一个选择菜单,还有一个登录框”)是不够的,还要有一个情感上的答案。新用户在一分钟之内的感受是怎么样的?是感到有用呢,还是觉得很迷惑?你要怎么做才能改善这种体验?回过头来再看看产品的网站,它是不是够专业、够友好,就像是一个漂亮的店面一样?这些东西都需要你非常认真地去对待,这样用户才会把你的软件当回事儿。

如果我们将“成功的软件”定义为“有很多人用,而且他们都喜欢你的软件”,那么你一定要把注意力放在用户身上。Google有一句非常著名的格言: 关注用户,其他的东西自会随之而来。

隐藏复杂性 “但是我的软件本身就很复杂啊”,你可能会想,“它解决的就是一个复杂的问题。既然如此我为什么要把它隐藏起来?”这的确是一个合理的质疑,但这也是优秀软件设计里最大的挑战之一。优雅的设计应该保持简洁,化困难为可能。即便你的软件在处理复杂的逻辑,它也应该让人觉得流畅简洁(我们关注的是用户的情绪)。 这就是所谓的“隐藏复杂性”。将复杂的问题分解开来,然后隐藏住复杂性,或者至少也要设法让软件看起来很简单。

结果发现原来那台Mac和他祖母的电动削铅笔机接在同一块排插上,他的祖母每周都会跑去那间房间,打开排插电源来削铅笔。这时Mac就会滴一声地开始启动,削完铅笔后,祖母就会切断电源离开房间,这等于强行关机,Mac还来不及启动就被关掉了5。这是一个非常经典的例子,不懂技术的人会设法用有限的词汇和各种当下和电脑有关的现象来解释发生了什么。

看看你周围的朋友和家里人吧。他们中间有几个人真正信任修车师傅?今时今日,这个数字几乎可以说为零。因为我们多年来已经饱受这种“mail boxing”的困扰:每次去定期保养(比如说换机油)的时候,都会莫名其妙地多做一堆其他的保养,所以大家都不再相信修车师傅,他们只知道抓住一切机会赚钱。而信任这种东西,一旦失去,就再也变不回来了。

谁也不知道自己的真正使命是什么,或许是在教堂里写布道词也未可知。不过现在我们还是先专注在编写软件,尽量与人合作上面吧。而且,现在你也有能力做好它们了。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s