Appearance
第7章 需求启发
第2章到第6章的内容都是关于如何思考和建模得到需求模型，但需求模 型的质量依赖于需求的素材。从涉众处获取需求素材的工作叫做需求启 发。
需求启发和需求建模互相影响。需求启发得到的素材质量越高，得到高 质量需求模型的可能性就越大；需求建模能力越强，越能指导需求启发 工作，从涉众处得到高质量的素材。拿做菜类比，如果采购的食材质量 很差，技艺再高超的厨师也烹调不出美味的菜肴；不过，厨师技艺越高 超，对食材的要求就会越严格，越能推动买菜的人去采购更好的食材。
7.1 需求启发要点
许多时候，需求人员把需求启发想得太容易。经常可以听到“采集需 求”这样的表述，好像需求是蘑菇，乖乖地躺在森林里，开发人员需要 时，就像采蘑菇的小姑娘一样，一个，两个，三个，四个……把它们都 采回来。哪有这么容易！需求不是蘑菇。需求人员要能够像猎人一样， 用锐利的眼睛发现隐藏在丛林中的猎物；像侦探一样，用缜密的思维判 断出伪装成好人的凶手。
需求的一个启发障碍是知识的诅咒（Curse of Knowledge），意思是：一 旦知道某个东西，就很难想像不知道它会是什么样子。1990年，斯坦福 大学研究生Elizabeth Newton做了一个著名的心理学实验：让敲击者在桌 子上敲击最常见的歌曲，听众根据听到的节奏回答是什么歌曲，然后让 敲击者估计听众答对了多少。120次的实验中，敲击者预测听众猜对的比 率会大于50%，真实的结果是听众猜对的比率只有2.5%。因为听众听的 是敲出来的声音，敲击者听的是大脑里已有的歌曲。
知识的诅咒在需求启发中体现为沟通的困难。需求人员懂得许多软件实 现的知识，这些知识会有意无意地引导开发人员从实现的角度看需求； 涉众在领域里面工作多年，许多事情在他看来一目了然，很难用开发人 员能理解的言语表达出来。
需求启发的另一个障碍是做和定义的不同。涉众会做一件事情，不代表 他能够把这件事定义出来教给其他人。在足球领域，贝利和马拉多纳号 称球王，但他们的执教经历并不成功，最近十年的世界最佳主教练穆里 尼奥踢球水平却很一般。
理解以下两个要点，有助于克服需求启发中的障碍。
- （1）和涉众交流的形式应该采用视图，而不是模型
经常有人问：客户看不懂UML怎么办？这个问题本身就存在问题。提问 者潜意识里可能认为“客户”是一个人。所谓“客户”其实是一大堆“涉众”， 他们从事的工种不同，学历职位有高有低，年龄有大有小，健康有好有 坏，关注的利益更是各自不同，怎么能寄望用一种介质和所有的涉众沟 通？
第1章说过UML的优点是提高沟通的效率，还拿五线谱做了类比。五线谱 是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要 懂、歌手要懂（注意：是懂五线谱，不是人人都要用五线谱作曲），但 听音乐的不需要懂五线谱。同样地，UML只是在“软件开发人员”圈子里 面的统一表示法，基于UML的沟通主要是发生在开发团队内部，不能强 行拿着UML模型和涉众沟通。
那么，和涉众交流的介质是什么呢？不是需求模型本身，而是需求模型 的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部 喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只 关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有 的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交 流。涉众连谈话都不乐意，我们也可以通过观察来获取素材。需求启发 的技能有许多种，不仅仅是浅薄的“画个界面草图给用户看”，“问用户想 要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下，观察 涉众的行为得到的。
如果不了解这个区分，直接拿UML模型去和涉众交流，很容易导致“四不 像”。为了迁就不同涉众的知识水平，开发团队只好损害模型的严谨性， 即使是这样，涉众也不一定接受，交流效果还是不好，而且还会因为涉 众的交流形式多变而影响开发团队开发过程的稳定——双方都受害。客 户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文 档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一 个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字 怎么办？大众产品没有“客户领导”签字确认需求怎么办？不少开发团队 十年如一日没有进步和积累，“交流影响开发”是原因之一。
开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还 是“懒”字，因为这样想，就有了推卸责任的机会：不是我不想建模，就 算我建模了，客户不想看啊。
需求视图和需求模型分离，交流和建模分离。在面对不同涉众时，需求 人员可以灵活使用各种启发方式，见人说人话，见鬼说鬼话；回到开发 团队内部时，则改用专业手段交流，这样团队才能慢慢形成稳定、严谨 的开发过程.
- （2）和涉众交流的内容应该聚焦涉众利益，而不是需求
软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供，而是 由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接 提供的，而是由需求人员综合不同涉众的利益来决定的。涉众没有资 格，也没有责任提供需求。 首先，涉众没有资格提供需求。系统的需求是平衡各种涉众利益得到 的，不由单一涉众决定。以ATM机为例，如果需求人员询问ATM机的执 行者储户“取款机应该怎么做你觉得最好”，储户回答大实话“最好像我家 抽屉一样拉开就拿，喏，把我家里的抽屉拿去做原型”，需求人员显然不 能把这个“抽屉”当真，只需要把“抽屉”背后的涉众利益提炼出来——储户 希望操作次数尽可能少一些。最终系统的需求是否尊重这个利益，就要 看储户在涉众排行榜上的排位了。
其次，涉众没有责任提供需求。涉众可能很忙，可能没有能力。说得极 端一点，婴儿只会哭会笑，婴儿产品的需求就不用做了？需求人员还是 要把责任揽过来，涉众只需表达高兴不高兴就行了。
不了解“交流的内容聚焦于涉众利益”，需求人员很容易把涉众提出的解 决方案当成需求，或者抱怨涉众没有“说清楚需求”。
拿患者和医生类比可以帮助理解上面说的这两点。患者喜欢和医生交流 自己的磁共振成像，医生就给他多做磁共振检查？患者懒得看甚至昏迷 不醒，医生就干脆不做？患者说“我腿疼，可能得了腿癌，我要做放 疗”，医生就给他做放疗？
显然不是这样，医生应该按照成熟的治疗套路，该做什么检查就做什么 检查，该如何治疗就如何治疗。医生哄不肯吃药的小患者“来，叔叔给你 吃颗糖糖”，但回到办公室和护士却要说“我刚给某某患者用了多少量的 某某药，你记一下”。
7.2 需求启发手段
7.2.1 研究资料
研究资料往往是需求启发的第一步，目的是为了获取核心域的初步知 识，为下一步的启发工作做知识准备。
研究资料的工作容易被开发团队忽视。很多时候，需求人员匆匆忙忙去 找涉众调研，由于没有知识准备，问的问题很肤浅，也观察不到有价值 的信息。时间花了，效果并不好。需求人员到客户那里去半个月，也许 得到的信息还不如客户的竞争对手去半天，因为客户的竞争对手有充足 的知识准备，知道该看什么，该问什么。 就像学生做作业一样，接近于零分的作业对老师来说没有批改和纠错的 价值，还不如打回去让学生好好复习，重新做了交上来。需求人员要是 问了接近零分的问题，涉众这个“老师”也是一样的感受。
对于目标组织是正式机构的情况更是如此。现在软件行业不再像过去的 年代一样是香饽饽，优秀人才越来越往“甲方”聚集。各种行业组织不再 像过去一样，对信息化一知半解，而是要求信息系统确实能给自己的组 织带来价值。如果需求人员没有做好知识准备就和客户打交道，很可能 会损害公司的声誉，让涉众认为“××公司水平不过如此，这口饭是我赏你 的”，以后生意就不好做了。
研究的资料可以是涉众的工作手册、行业手册，工作中的表格、文件、 便函、工作报告、作业日志、来往Email，以及当前运行系统及其文档 等。在网络越来越发达的今天，在网上查找资料也是知识准备的高效手 段。
研究资料的时候要注意尽可能研究实际使用中的资料，尽量不要是空白 的。很多时候涉众在表格和文档里填的东西，和表格文档各项标题所标 示的名称不一样。
资料往往会比较多，有价值内容的相对比例较少，如果碰到有价值的信 息，随时做笔记，或者把该页面拍下来。在研究资料时，可以一边阅 读，一边通过一些建模手段整理知识，例如画领域类图和业务序列图。
7.2.2 问卷调查
问卷调查的目的是给人群分类，挑出样本。例如，开发团队的初步想法 是做一个面向中学教师的辅助教学产品，但是中学教师人群内的个体非 常多，需求人员一开始甚至不知道应该从哪些角度来划分人群。随意挑 选身边能接触到的中学教师来作为需求启发对象是不行的。这时可以做 一些问卷调查，根据问卷调查的结果来给人群分出子集，然后再从各子 集中选取样本，以便做下一步的启发工作。
问卷调查可以是纸面的，也可以是电子的。现在借助互联网的优势可以 比以往得到范围更广、人数更多的调查对象，缺点是容易鱼目混珠。应 对手段是埋藏一些很难犯错误的钉子，如果被调查者敷衍回答，很可能 就会答错，从而可以判断这份答卷是无效的。
7.2.3 访谈
访谈是最重要也最常用的需求启发技术。需求人员和涉众直接交流以收 集信息。访谈并非一定要见面，电话、微信、QQ、Email等也可以作为访 谈的手段。下面分几个方面来谈。
7.2.3.1 涉众
访谈时，选择的涉众代表必须名副其实，不要把“代表”等同于“主管”。例 如，要访谈车间的操作工，那就要选真正的操作工，不能用车间主任来 做代表。操作工岗位的酸甜苦辣，只有操作工自己最清楚。应该把车间 主任看作另外一类涉众单独访谈。实际工作中常见的错误还有把目标机 构中挂“信息中心主任”头衔的人作为主要的调研对象，认为他们既懂电 脑，又懂业务，其实大谬。
要挑选经验丰富的涉众来观察。经验丰富的“老师傅”在长期的工作经历 中归纳出了一套行之有效的经验，系统可以学习他的经验（然后一脚把 他踹开），这就是第4章所说的改进点“封装领域逻辑”。所以即使“老师 傅”不懂电脑不支持信息化，也要选他作为访谈对象。这里经常犯的错误 就是需求人员喜欢选择爱玩电脑和手机的小年轻作为访谈对象，因为他 们支持信息化，而且崇拜软件开发人员。
不同类型的涉众，应该尽量单独访谈，如果图省事把有利益冲突的两类 涉众集中到一起访谈，受访者言辞之间可能就会有顾忌。
7.2.3.2 需求人员
需求人员的态度要让涉众觉得自己被尊重。
首先是言语上的礼貌。例如，不能表露出“你不懂软件，我才是专家”的 意思，“懂得软件”不是涉众必须的素质，涉众只需要清楚自己的利益和 关注点。另外，访谈的涉众如果处在一个从业人员平均学历和能力都比 软件业低得多的行业，涉众可能在接受访谈时潜意识中有一种自卑感， 如果需求人员的态度不礼貌，更容易引起抵触心理。
不可忽略这个事实：系统的出现可能对受访者不利。因为这意味着涉众 头脑里的经验可能会因为信息系统的出现不再那么重要，甚至职位还可 能会取消。所以在言语中暗示“我们来这里是为了让你下岗”的意思是不 适当的。即使是表示“我们来这里是为了帮助您把工作做得更好”也不合 适。他的工作做得很好，并不需要我们帮助。应该把自己摆在一个低姿 态的位置，“我们来这里是为了帮助您更方便地完成工作”。
其次在行动上要有尊重的表现，访谈的时候身体应前倾，不时点头并发 出声音，手上做一些笔记（表明重视），适当的时候作两句总结。这 样，涉众的心里会大为受用，更容易向您倾出心中所想。
访谈的时候光听肯定是不行的，要想办法记录。笔记是肯定要做的，但 记录的速度肯定比不上说话的速度，另外在访谈过程中还要思考将提问 的问题，记笔记的节奏经常被打乱。所以，记笔记的目的主要是记住关 键点以帮助思考向涉众提问的问题以及上面提到的——做出尊重涉众的 姿态，绝不能因为低头专注记笔记而影响交流。
真正的记录还是要靠录音或录像。录音一般不会对涉众形成压力，不过 只记录了声音，无法通过研究涉众的表情来揣摩涉众的真实意思；录像 可以记录肢体语言，但在镜头前面，涉众可能会受到影响。
有可能的话，录音或录像应该采取双备份。毕竟访谈一次不容易，保险 一点为好。不过，在访谈过程中要把录音录像当作不存在，该倾听倾 听，该记笔记记笔记。
访谈记录回来要用上。这句话似乎是废话，其实不然。有的开发团队访 谈完毕，长吁一口气，赶紧投入到向往已久的编码事业，访谈记录看也 不看，听也不听，全凭脑子里的印象往下做。
7.2.3.3 问题
问题的内容聚焦于业务流程和涉众利益，而非直接的系统需求。例如：
这个工作需要哪些材料，哪个人或者部门提供的？ 这个工作产生什么结果，这些结果谁会关注？ 这件事情，您最烦的是什么？ 这件事情要是做得不好，会影响到谁？
…… 问题的形式和新闻记者提问一样：5W＋1H。谁（ Who ）、什 么 （What）、什么时候（When）、什么地点（Where）、为什么（Why）、 怎么进行（How）。提问的时候尽量采用领域词汇，不要采用涉及软件 实现的专业术语。
问问题的时候，可以跟随涉众的阐述，不断问为什么，深入探索背后的 真正需求。
为什么你们要填这个表格？→这样经理就可以知道所发生的事情→为什 么经理需要知道所发生的事情？→这样她就可以按需要分配资源
7.2.3.4 环境
尽可能在涉众的工作环境里访谈。涉众在自己的工作环境中会想起许多 工作中的喜怒哀乐，如果把他请到软件公司或者度假山庄的会议室，环 境发生变化，一些本来深有感触的东西，因为不在该环境中，一时之间 会想不起来。有人嫌在涉众的工作环境里访谈经常会被打断，但那也是 一种真实的工作状态。
有些开发过程力捧“现场客户”的好处，确实，有“现场客户”总比没有要 好，但在涉众的种类很多而且利益各异的情况下，一个“现场客户”怎么 能代表这么多涉众呢？更不用说有些系统根本不是直接和人打交道 的。“现场客户”其实是一种偷懒的做法，它让开发人员心安理得坐在电 脑前面编码，有问题不再深入第一线调研，而是推给“现场客户”。
7.2.4 观察
观察就是需求人员跟在涉众旁边观察他的工作，甚至亲身去体验涉众的 工作。这是最直接的需求启发技术，也最费时间。
观察可以看作访谈的加强版。访谈的各种要点也适用于观察。
观察的时候，需求人员可以结合第4章中提到的改进模式，重点关心涉众 完成一项工作所需时间、操作次数以及出现的错误和混乱。某个点所需 时间多，或者操作次数多，或者出现错误多，系统要是能在这个点上有 所帮助，必定会给涉众带来强烈的改进感觉。
观察的时候，也要观察环境的特殊性，例如牙科医生手里拿着工具无法 腾出手来操作电脑，旅客手里提着行李，车厢里光线阴暗，等等。 最极限的观察手段就是需求人员亲身上阵去体验涉众的工作。这样做会 使得涉众感觉被重视，也更信任您能做出好东西。不过，亲身上阵代价 较高，而且很多地方没法亲自上阵，当半天收银员还可以，当半天医生 就要惹出麻烦了。
观察对于今天的产品研发越来越重要。在市场竞争激烈的体验经济时 代，客户的口味提高了，光是有个东西给他用是不行的。对精益求精的 产品开发者来说，观察是不得不花代价去做的启发技术。
Jeff Hawkins在研发Palm Pilot时，把一块木头模型整天揣在口袋里，在工 作和生活中不停揣摩应该怎么使用掌上电脑，过滤出最有价值的需求， 最终Palm Pilot成为第一款获得成功的掌上电脑。而之前，苹果出品的掌 上电脑Newton因过于臃肿，导致市场惨败。
7.2.5 研究竞争对手
用关键字“播放”搜索您手机里的应用商店，看看有多少款“播放”相关的应 用？过去说提供产品或服务时首要原则是“客户是上帝”，但我们产品 的“上帝”同时也会是别人产品的“上帝”，这个时候客户如何才能从这么多 家中选择我们的产品？
研究竞争对手是产品开发最关键的需求启发技术。第2章讲述的老大和愿 景可以看作是通过研究竞争对手得到的。研究竞争对手，才能知道哪一 块是合适进攻的战场，才能知道我们的产品应该提供什么才能打败战场 上的敌人——很多很多的敌人。
研究竞争对手不是看对手有什么我们也加什么。有的人看到竞争对手的 软件上添加了一个“星座运程”的功能，就想着我们也要加上去。恰好， 竞争对手也有同样的想法，结果导致所有公司都试图在自己的产品中加 入竞争对手产品的功能，导致无奈的“军备竞赛”，最终所有的产品趋同 化，只能寄望于靠价格战或烧钱等手段挤垮对手。
Al Ries和Jack Trout在Marketing Warfare（中译本《营销战》）一书中模 仿克劳塞维茨的《战争论》描述了顾客大脑里竞争的态势。
防御战。一个领域有一个市场领先者，他负责向下防御，不断更新自 己，并带领这个领域的弟兄们向外扩张。作为市场领先者，不能把矛头 对准追赶者，应该开疆拓土，代表整个领域说话，向其他领域进攻。 进攻战：领域里有几家追赶者，它们负责进攻领先者。它需要研究领先 者的优点，但不是简单模仿，而是在关键的地方反其道而行之——攻击 领先者强势背后的弱点。
侧翼战：有的产品在某一方面形成突出的特点，从侧翼攻击占据一小块 细分市场。许多创新来自这样的产品。只要一直坚持特色，缩窄自己的 攻击面，就一直会有市场。
游击战：产品无进攻他人的竞争力，仅依靠地域割据、熟人关系等苟且 生存。这些“游击队”需要尽快使自己的产品具有某一方面的特色，成为 专家型产品，在顾客的大脑中占据一个位置。
了解战场的态势和自己产品的位置，才能采取合适的竞争策略。关于这 方面的内容，市场营销领域的专家研究得更加深刻，可以阅读他们的著 作，我就不在这里班门弄斧了。
7.3 需求人员的素质培养
前面的章节讨论需求的各种技能。最后，我们来讨论一下这些技能的拥 有者——需求人员。
我把一名优秀需求人员所需要的素质归纳成一所房屋的样子。房屋以好 奇心为根基，有探索力、沟通力、表达力三根柱子，以热情作为屋顶.
7.3.1 好奇心
好奇心，首先指对不熟悉的事物提起兴趣的能力。在做项目时，有的开 发人员只对项目将要用到的新实现技术感到兴奋，对项目所涉及的领域 知识则不感兴趣。为什么调研过程总是流于形式？为什么更喜欢在办公 室“编写”需求，而不是深入第一线？为什么更喜欢和客户的信息中心人 员打交道，而不是不懂电脑却至关重要的涉众？这就是原因之一。
好奇心，更重要的是从熟悉中发现惊奇的能力。很多时候对具体的业务 太熟悉或者存在已有系统，也是捕获需求的一种阻碍。在这种情况下， 很容易就想到系统里有哪几张表，怎么调用，反而钳制住了思维。必须 要学会抵制各种想要向里探头的诱惑，尽量跳出来看，从熟悉中发现惊 奇。这样才能从涉众提供的素材中，超越涉众的目光，探索出在局中人 无法察觉的需求。
用外来者的心态来观察，我们司空见惯的日常生活其实充满了各种惊 奇：
有一种动物很奇怪，每天钻进钻出各种壳子，很多时间都盯着各种 发出荧光的扁盒子看，有大盒子，有小盒子。
一大群人24小时不间断监控各种事情，整理成文章，不停地把你可 能感兴趣的内容推送到你的手机上，而且免费。
只要动几根手指，东北的大米、阿根廷的虾、澳洲的牛肉会乖乖送 上门。
为了培养好奇心，平时还可以看一些“短路”的视频或动漫，或者做一些 不熟悉的事情。例如，如果您喜欢看《南方周末》，不妨偶尔看看《环 球时报》；如果您喜欢看《权力的游戏》，不妨偶尔看看《三生三世十 里桃花》。
7.3.2 探索力
探索力包括寻找线索的能力和从线索中归纳问题的能力。需求人员就像 侦探一样，需要从涉众提供的各种信息碎片中拼出真正的问题。这种探 索力更强调的是“合成”，类似于出题，而开发人员擅长的是“分解”——针 对问题，采用某种软件技术解题。出题的思路和解题的思路是有区别 的。 日常生活中随处可以培养探索力。例如针对消息“NASA的James Webb太 空望远镜使用Rose Realtime建模”，如果一开始只是知道这么一个事件， 并不了解其中细节，可以尝试针对各个环节的信息，通过“反转”“取代”等 手法来探索：
为什么是NASA，还有没有其他类似单位使用Rose Realtime建模？ 为什么是Rose Realtime，NASA有没有考虑过Rhapsody？ James Webb太空望远镜用Rose Realtime，其他项目用什么？
探索力的培养方面，Edward de Bono写的《六顶思考帽》《严肃的创造 力》等书籍虽然与软件不直接相关，但很有参考价值。
7.3.3 沟通力
沟通力包括需求人员和涉众沟通的能力。例如，操作员说系统要简单易 用。但“简单易用”并不能直接成为需求。需求人员要耐心和涉众沟通， 了解涉众是以什么标准来度量“简单”和“易用”的。
沟通力还包括需求人员在不同涉众之间协调的能力。涉众往往有很多 类，A类涉众的利益和B类涉众的利益可能在一定程度上是冲突的。录入 人员希望操作步骤尽量少，但如果因此省略了一些确认和验证的步骤， 使用这些录入数据的审批人员、施工人员的利益可能就会受到损害。需 求人员需要平衡各方涉众的利益以得出恰当的需求。
沟通力还包括需求人员在涉众与程序员之间协调的能力。例如，操作员 要求“一键完成操作”，却难为了程序员。
平时程序员更多擅长的是和机器的交流能力。程序员如果要去充当需求 人员的角色，沟通力可能是木桶上最短的板。
要改进沟通力，可以参加一些沟通技巧的训练，或者阅读一些人际交往 的相关书籍，例如卡耐基的《人性的弱点》。《人性的弱点》可以说是 中国引进的最早的“沟通力”书籍之一，20多年前曾经大热。书中关于倾 听和赞赏的道理到今天依然没有过时。
7.3.4 表达力
表达力在这里着重指自然语言的表达和组织的能力。需求最常见的形式 是以自然语言的方式表达出来的。开发人员平时更习惯的是编程语言的 表达能力，写个注释有时也想偷懒，更不用说自然语言表达的其他工件 了。项目主管向涉众介绍项目，用词中经常充斥着“伸缩性”之类的字 眼，明明只是一个小小的管理系统，却起名叫“××平台”，似乎大家听不 懂才说明高深。
提高自然语言的表达力，可以阅读Barbara Minto的《金字塔原理》。
7.3.5 热情
有好奇心，有探索力，有沟通力，有表达力，也掌握了各种具体的需求 技能，不意味着需求人员会尽其所能去向涉众探索需求。没有热情作为 屋顶，上面提到的各种“力”都无法贯彻。
1998年，我在北京做我的第一份程序员工作。公司地点在公主坟，所以 下班后我经常到翠微大厦一楼的新华书店随便翻书。有一天，我看到了 一个新引进的大厚本，Michael Abrash的《图形程序开发人员指南》（原 书名：MichaelAbrash'sGraphicsProgrammingBlackBook），虽然书中 大部分内容和我的工作无关而且我也看不太懂，但作者讲的一个故事深 深地打动了我。很多年后，我专门找到了这本书，把当年打动我的、关 于“热情”的故事片断用键盘敲下来分享给大家，作为本书上册的结尾。
一天晚上，当我正浏览代码时，另一个终端上一个真正可爱的女孩 要求我帮助她使一个程序运行。我帮助她以后，渴望进一步了解 她，我说：“想看什么东西吗？这是‘Star Trek’的真正源代码！”并且 继续浏览整个代码，描述每个子函数。我们开始交谈，最后我鼓起 勇气邀请她出去走走。她同意了，我们过得很愉快，虽然由于她的 两个或三个其他男朋友，我们不久就分开了。然而，有趣的事情是 当我最后终于鼓起勇气邀请她出去走走时她的反应，她说“到时间 了”。当我问她这是什么意思时，她说：“整个晚上我一直在努力让 你邀请我出去走走，但你花了这么长时间！你并不真正认为我 对‘Star Trek’程序感兴趣，是吗？” 确实如此，我是这么想的，因为我对这个程序很感兴趣。从那次经 历中我认识到了一件事（并且从那以后，我不断加深这种认识）， 就是我们（指任何一个因为喜爱而编程的人，如果需要，他将无偿 地工作）是一群不同的人。
我们是不同的，因此也很幸运，当每一个人正担心裁员时，我们正 处在世界上最热门的行业。并且，我想，我们处于这样好的一个位 置的最大原因不是智力、努力工作或所受的教育，尽管这也是部分 原因，原因在于我们真正喜爱这种工作。
——Michael Abrash，《图形程序开发人员指南》，第68章“Quake的 光照模型”