7章 需求启发

我不知道应该说些什么,哦……爱你在心口难开。

《爱你在心口难开》;词:佚名,曲:Sonny CurtisJerry Allison,唱:凤飞飞;1981

 

2到第6章的内容都是关于如何思考和建模得到需求模型,但需求模型的质量依赖于需求的素材。从涉众处获取需求素材的工作叫做需求启发。

需求启发和需求建模互相影响。需求启发得到的素材质量越高,得到高质量需求模型的可能性就越大;需求建模能力越强,越能指导需求启发工作,从涉众处得到高质量的素材。拿做菜类比,如果采购的食材质量很差,技艺再高超的厨师也烹调不出美味的菜肴;不过,厨师技艺越高超,对食材的要求就会越严格,越能推动买菜的人去采购更好的食材。

7.1 需求启发要点

许多时候,需求人员把需求启发想得太容易。经常可以听到“采集需求”这样的表述,好像需求是蘑菇,乖乖地躺在森林里,开发人员需要时,就像采蘑菇的小姑娘一样,一个,两个,三个,四个……把它们都采回来。哪有这么容易!需求不是蘑菇。需求人员要能够像猎人一样,用锐利的眼睛发现隐藏在丛林中的猎物;像侦探一样,用慎密的思维判断出伪装成好人的凶手。

需求的一个启发障碍是知识的诅咒(Curse of Knowledge),意思是:一旦知道某个东西,就很难想像不知道它会是什么样子。1990年,斯坦福大学研究生Elizabeth Newton做了一个著名的心理学实验:让敲击者在桌子上敲击最常见的歌曲,听众根据听到的节奏回答是什么歌曲,然后让敲击者估计听众答对了多少。120次的实验中,敲击者预测听众猜对的比率会大于50%,真实的结果是听众猜对的比率只有2.5%。因为听众听的是敲出来的声音,敲击者听的是大脑里已有的歌曲。

知识的诅咒在需求启发中体现为沟通的困难。需求人员懂得许多软件实现的知识,这些知识会有意无意地引导开发人员从实现的角度看需求;涉众在领域里面工作多年,许多事情在他看来一目了然,很难用开发人员能理解的言语表达出来。

需求启发的另一个障碍是做和定义的不同。涉众会做一件事情,不代表他能够把这件事定义出来教给其他人。在足球领域,贝利和马拉多纳号称球王,但他们的执教经历并不成功,最近十年的世界最佳主教练穆里尼奥踢球水平却很一般。

理解以下两个要点,有助于克服需求启发中的障碍:

和涉众交流的形式应该采用视图,而不是模型。

经常有人问:客户看不懂UML怎么办?这个问题本身就存在问题。提问者潜意识里可能认为“客户”是一个人。所谓“客户”其实是一大堆“涉众”,他们从事的工种不同,学历职位有高有低,年龄有大有小,健康有好有坏,关注的利益更是各自不同,怎么能寄望用一种介质和所有的涉众沟通?

1章说过UML的优点是提高沟通的效率,还拿五线谱做了类比。五线谱是音乐专业人士交流的工具,作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂(注意:是懂五线谱,不是人人都要用五线谱作曲),但听音乐的不需要懂五线谱。同样的,UML只是在“软件开发人员”圈子里面的统一表示法,基于UML的沟通主要是发生在开发团队内部,不能强行拿着UML模型和涉众沟通

那么,和涉众交流的介质是什么呢?不是需求模型本身,而是需求模型的各种视图。面对大领导,我们可以给他放幻灯片交流愿景;中层干部喜欢看文档,我们可以按照他喜欢的格式给他炮制文档;一线操作工只关心他那一小块工作,我们可以制作界面原型和他交流;有时候甚至有的涉众根本不喜欢看任何东西,我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意,我们也可以通过观察来获取素材。需求启发的技能有许多种,不仅仅是浅薄的“画个界面草图给用户看”,“问用户想要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下,观察涉众的行为得到的。

如果不了解这个区分,直接拿UML模型去和涉众交流,很容易导致“四不像”。为了迁就不同涉众的知识水平,开发团队只好损害模型的严谨性,即使是这样,涉众也不一定接受,交流效果还是不好,而且还会因为涉众的交流形式多变而影响开发团队开发过程的稳定——双方都受害。客户的领导说,我不习惯看UML模型,就知道以前看的是××标准格式的文档,我只在这个格式的文档上签字,难道我们就不用UML建模了?下一个项目的客户领导喜欢另一种格式怎么办?下下个项目根本不需要签字怎么办?大众产品没有“客户领导”签字确认需求怎么办?不少开发团队十年如一日没有进步和积累,“交流影响开发”是原因之一。

开发人员有意无意把建模的目的理解成和涉众交流,有时背后的思想还是“懒”字,因为这样想,就有了推卸责任的机会:不是我不想建模,就算我建模了,客户不想看啊。

需求视图和需求模型分离,交流和建模分离。在面对不同涉众时,需求人员可以灵活使用各种启发方式,见人说人话,见鬼说鬼话;回到开发团队内部时,则改用专业手段交流,这样团队才能慢慢形成稳定、严谨的开发过程。

7-1 交流和建模分离

和涉众交流的内容应该聚焦涉众利益,而不是需求。

软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供,而是由编剧根据不同观众的口味编出来的。同样,软件需求不是由涉众直接提供,而是由需求人员综合不同涉众的利益来决定的。涉众没有资格、也没有责任提供需求。

首先,涉众没有资格提供需求。系统的需求是平衡各种涉众利益得到的,不由单一涉众决定。以ATM机为例,如果需求人员询问ATM机的执行者储户“取款机应该怎么做你觉得最好,储户回答大实话“最好像我家抽屉一样拉开就拿,喏,把我家里的抽屉拿去做原型”,需求人员显然不能把这个“抽屉”当真,只需要把“抽屉”背后的涉众利益提炼出来——储户希望操作次数尽可能少一些。最终系统的需求是否尊重这个利益,看储户在涉众排行榜上的排位了。

其次,涉众没有责任提供需求。涉众可能很忙,可能没有能力。说得极端一点,婴儿只会哭会笑,婴儿产品的需求就不用做了?需求人员还是要把责任揽过来,涉众只需会表达高兴不高兴就行了。

不了解“交流的内容聚焦于涉众利益,需求人员很容易把涉众提出的解决方案当成需求,或者抱怨涉众没有说清楚需求

拿患者和医生类比可以帮助理解上面说的这两点。患者喜欢和医生交流自己的磁共振成像,医生就给他多做磁共振检查?患者懒得看甚至昏迷不醒,医生就干脆不做?患者说“我腿疼,可能得了腿癌,我要做放疗”,医生就给他做放疗?

显然不是这样,医生应该按照成熟的治疗套路,该做什么检查就做什么检查,该如何治疗就如何治疗。医生哄不肯吃药的小患者来,叔叔给你吃颗糖糖,但回到办公室和护士却要说我刚给某某患者用了多少量的某某药,你记一下

7.2 需求启发手段

7.2.1 研究资料

研究资料往往是需求启发的第一步,目的是为了获取核心域的初步知识,为下一步的启发工作作知识准备。

研究资料的工作容易被开发团队忽视。很多时候,需求人员匆匆忙忙去找涉众调研,由于没有知识准备,问的问题很肤浅,也观察不到有价值的信息。时间花了,效果并不好。需求人员到客户那里去半个月,也许得到的信息还不如客户的竞争对手去半天,因为客户的竞争对手有充足的知识准备,知道该看什么,该问什么。

就像学生做作业一样,接近于零分的作业对老师来说没有批改和纠错的价值,还不如打回去让学生好好复习,重新做了交上来。需求人员要是问了接近零分的问题,涉众这个“老师”也是一样的感受。

对于目标组织是正式机构的情况更是如此。现在软件行业不再像过去的年代一样是香饽饽,优秀人才越来越往“甲方”聚集。各种行业组织不再像过去一样,对信息化一知半解,而是要求信息系统确实能给自己的组织带来价值。如果需求人员没有做好知识准备就和客户打交道,很可能会损害公司的声誉,让涉众认为“××公司水平不过如此,这口饭是我赏你的”,以后生意就不好做了。

研究的资料可以是涉众的工作手册、行业手册,工作中的表格、文件、便函、工作报告、作业日志、来往Email,以及当前运行系统及其文档等等。在网络越来越发达的今天,在网上查找资料也是知识准备的高效手段。

研究资料的时候要注意尽可能研究实际使用中的资料,尽量不要空白的。很多时候涉众在表格和文档里填的东西,和表格文档各项标题所标示的名称不一样。

资料往往会比较多,有价值内容的相对比例较少,如果碰到有价值的信息,随时做笔记,或者把该页面拍下来。在研究资料时,可以一边阅读一边通过一些建模手段整理知识,例如画领域类图和业务序列图。

7.2.2 问卷调查

问卷调查的目的是给人群分类,挑出样本。例如,开发团队的初步想法是做一个面向中学教师的辅助教学产品,但是中学教师人群内的个体非常多,需求人员一开始甚至不知道应该从哪些角度来划分人群。随意挑选身边能接触到的中学教师来作为需求启发对象是不行的。这时可以做一些问卷调查,根据问卷调查的结果来给人群分出子集,然后再从各子集中选取样本,以便做下一步的启发工作。

问卷调查可以是纸面的,也可以是电子的。现在借助互联网的优势可以比以往得到范围更广、人数更多的调查对象,缺点是容易鱼目混珠。应对手段是埋藏一些很难犯错误的钉子,如果被调查者敷衍回答,很可能就会答错,从而可以判断这份答卷是无效的。

7.2.3 访谈

访谈是最重要也最常用的需求启发技术。需求人员和涉众直接交流以收集信息。访谈并非一定要见面,电话、微信、QQEmail等也可以作为访谈的手段。下面分几个方面来谈。

7.2.3.1 涉众

访谈时,选择的涉众代表必须名副其实,不要把“代表”等同于“主管”。例如,要访谈车间的操作工,那就要选真正的操作工,不能用车间主任来做代表。操作工岗位的酸甜苦辣,只有操作工自己最清楚。应该把车间主任看作另外一类涉众单独访谈。实际工作中常见的错误还有把目标机构中挂“信息中心主任”头衔的人作为主要的调研对象,认为他们既懂电脑,又懂业务,其实大谬。

要挑选经验丰富的涉众来观察。经验丰富的“老师傅”在长期的工作经历中归纳出了一套行之有效的经验,系统可以学习他的经验(然后一脚把他踹开),这就是第4章所说的改进点封装领域逻辑。所以即使“老师傅”不懂电脑不支持信息化,也要选他作为访谈对象。这里经常犯的错误就是需求人员喜欢选择爱玩电脑和手机的小年轻作为访谈对象,因为他们支持信息化,而且崇拜软件开发人员。

不同类型的涉众,应该尽量单独访谈,如果图省事把有利益冲突的两类涉众集中到一起访谈,受访者言辞之间可能就会有顾忌。

7.2.3.2 需求人员

需求人员的态度要让涉众觉得自己被尊重。

首先是言语上的礼貌。例如,不能表露出“你不懂软件!我才是专家”的意思,“懂得软件”不是涉众必须的素质,涉众只需要清楚自己的利益和关注点。另外,访谈的涉众如果处在一个从业人员平均学历和能力都比软件业低得多的行业,涉众可能在接受访谈时潜意识中有一种自卑感,如果需求人员的态度不礼貌,更容易引起抵触心理。

不可忽略这个事实:系统的出现可能对受访者不利。因为这意味着涉众头脑里的经验可能会因为信息系统的出现不再那么重要,甚至职位还可能会取消。所以在言语中暗示“我们来这里是为了让你下岗”的意思是不适当的。即使是表示“我们来这里是为了帮助您把工作做得更好”也不合适。他的工作做得很好!并不需要我们帮助。应该把自己摆在一个低姿态的位置上“我们来这里是为了帮助您更方便地完成工作”。

其次在行动上要有尊重的表现,访谈的时候身体应前倾,不时点头并发出声音,手上做一些笔记(表明重视),适当的时候作两句总结。这样,涉众的心里会大为受用,更容易向您倾出心中所想。

访谈的时候光听肯定是不行的,要想办法记录。笔记是肯定要做的,但记录的速度肯定比不上说话的速度,另外在访谈过程中还要思考将提问的问题,记笔记的节奏经常被打乱。所以,记笔记的目的主要是记住关键点以帮助思考向涉众提问的问题以及上面提到的——做出尊重涉众的姿态,绝不能因为低头专注记笔记而影响交流。

真正的记录还是要靠录音或录像。录音一般不会对涉众形成压力,不过只记录了声音,无法通过研究涉众的表情来揣摩涉众的真实意思;录像可以记录肢体语言,但在镜头前面,涉众可能会受到影响。

有可能的话,录音或录像应该采取双备份。毕竟访谈一次不容易,保险一点为好。不过,在访谈过程中要把录音录像当作不存在,该倾听倾听,该记笔记记笔记。

访谈记录回来要用上。这句话似乎是废话,其实不然。有的开发团队访谈完毕,长吁一口气,赶紧投入到向往已久的编码事业,访谈记录看也不看,听也不听,全凭脑子里的印象往下做。

7.2.3.3 问题

问题的内容聚焦于业务流程和涉众利益,而非直接的系统需求。例如:

这个工作需要哪些材料,哪个人或者部门提供的?

这个工作产生什么结果,这些结果谁会关注?

这件事情,您最烦的是什么?

这件事情要是做得不好,会影响到谁?

……

问题的形式和新闻记者提问一样:5W1H。谁(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 RiesJack Trout“Marketing Warfare”(中译本《营销战》)一书中模仿克劳塞维茨的《战争论》描述了顾客大脑里竞争的态势。

防御战。一个领域有一个市场领先者,他负责向下防御,不断更新自己,并带领这个领域的弟兄们向外扩张。作为市场领先者,不能把矛头对准追赶者,应该开疆拓土,代表整个领域说话,向其他领域进攻。

进攻战:领域里有几家追赶者,它们负责进攻领先者。它需要研究领先者的优点,但不是简单模仿,而是在关键的地方反其道而行之——攻击领先者强势背后的弱点。

侧翼战。有的产品在某一方面形成突出的特点,从侧翼攻击占据一小块细分市场。许多创新来自这样的产品。只要一直坚持特色,缩窄自己的攻击面,就一直会有市场

游击战。产品无进攻他人的竞争力,仅依靠地域割据、熟人关系等苟且生存。这些“游击队”需要尽快使自己的产品具有某一方面的特色,成为专家型产品,在顾客的脑子占据一个位置。

了解战场的态势和自己产品的位置,才能采取合适的竞争策略。关于这方面的内容,市场营销领域的专家研究得更加深刻,可以阅读他们的著作,我就不在这里班门弄斧了。

7.3 需求人员的素质培养

前面的章节讨论需求的各种技能。最后,我们来讨论一下这些技能的拥有者——需求人员。

我把一名优秀需求人员所需要的素质归纳成一所房屋的样子。房屋以好奇心为根基,有探索力、沟通力、表达力三根柱子,以热情作为屋顶。

7-2 需求人员的素质

7.3.1 好奇心

好奇心,首先指对不熟悉的事物提起兴趣的能力。在做项目时,有的开发人员只对项目将要用到的新实现技术感到兴奋,对项目所涉及的领域知识则不感兴趣。为什么调研过程总是流于形式?为什么更喜欢在办公室“编写”需求,而不是深入第一线?为什么更喜欢和客户的信息中心人员打交道,而不是不懂电脑却至关重要的涉众?这就是原因之一。

好奇心,更重要的是从熟悉中发现惊奇的能力。很多时候对具体的业务太熟悉或者存在已有系统,也是捕获需求的一种阻碍。这种情况下很容易就想到系统里有哪几张表,怎么调用,反而钳制住了思维。必须要学会抵制各种想要向里探头的诱惑,尽量跳出来看,从熟悉中发现惊奇。这样才能从涉众提供的素材中,超越涉众的目光,探索出在局中人无法察觉的需求。

用外来者的心态来观察,我们司空见惯的日常生活其实充满了各种惊奇:

有一种动物很奇怪,每天钻进钻出各种壳子,很多时间都盯着各种发出荧光的扁盒子看,有大盒子,有小盒子。

一大群人24小时不间断监控各种事情,整理成文章,不停地把你可能感兴趣的内容推送到你的手机上,而且免费。

只要动几根手指,东北的大米、阿根廷的虾、澳洲的牛肉会乖乖送上门。

为了培养好奇心,平时还可以看一些“短路”的视频或动漫,或者做一些不熟悉的事情。例如,如果您喜欢看《南方周末》,不妨偶尔看看《环球时报》;如果您喜欢看《权力的游戏》,不妨偶尔看看《三生三世十里桃花》。

7.3.2 探索力

探索力包括寻找线索的能力和从线索中归纳问题的能力。需求人员就像侦探一样,需要从涉众提供的各种信息碎片中拼出真正的问题。这种探索力更强调的是“合成”,类似于出题,而开发人员擅长的是“分解”——针对问题,采用某种软件技术解题。出题的思路和解题的思路是有区别的。

日常生活中随处可以培养探索力。例如针对消息“NASAJames Webb太空望远镜使用Rose Realtime建模”,如果一开始只是知道这么一个事件,并不了解其中细节,可以尝试针对各个环节的信息,通过“反转”、“取代”等手法来探索:

为什么是NASA,还有没有其他类似单位使用Rose Realtime建模?

为什么是Rose RealtimeNASA有没有考虑过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的《图形程序开发人员指南》(原书名:Michael Abrash's Graphics Programming Black Book),虽然书中大部分内容和我的工作无关而且我也看不太懂,但作者讲的一个故事深深地打动了我。很多年后,我专门找到了这本书,把当年打动我的、关于“热情”的故事片断用键盘敲下来分享给大家,作为本书上册的结尾。

一天晚上,当我正浏览代码时,另一个终端上一个真正可爱的女孩要求我帮助她使一个程序运行。我帮助她以后,渴望进一步了解她,我说:“想看什么东西吗?这是‘Star Trek’的真正源代码!”并且继续浏览整个代码,描述每个子函数。我们开始交谈,最后我鼓起勇气邀请她出去走走。她同意了,我们过得很愉快,虽然由于她的两个或三个其他男朋友我们不久就分开了。然而,有趣的事情是当我最后终于鼓起勇气邀请她出去走走时她的反应。她说:“到时间了。”当我问她这是什么意思时,她说:“整个晚上我一直在努力让你邀请我出去走走,但你花了这么长时间!你并不真正认为我对‘Star Trek’程序感兴趣,是吗?”

确实如此,我是这么想的,因为我对这个程序很感兴趣。从那次经历中我认识到的一件事(并且从那以后我不断加深这种认识),就是我们(指任何一个因为喜爱而编程的人,如果需要他将无偿地工作)是一群不同的人。

我们是不同的,因此也很幸运,当每一个人正担心裁员时,我们正处在世界上最热门的行业。并且,我想,我们处于这样好的一个位置的最大原因不是智力、努力工作、或所受的教育,尽管这也是部分原因,原因在于我们真正喜爱这种工作。

——Michael Abrash,《图形程序开发人员指南》,第68"Quake的光照模型"

 

本书不提供练习题答案,请扫码或访问http://www.umlchina.com/book/quiz7_1.htm完成在线测试,做到全对,自然就知道答案了。

1. 如果涉众要求需求人员拿着用例图、序列图和他交流,对于需求人员来说,以下做法正确的是:

A) 拿着用例图、序列图和涉众交流。

B) 委婉拒绝,涉众没有资格看UML模型。

C) 委婉拒绝,涉众没有责任看UML模型。

D) 指导涉众,一起绘制用例图、序列图。

2. 如果涉众对需求人员画的UML模型不感兴趣,对于需求人员来说,以下做法正确的是:

A) 为该涉众讲解基本的UML知识。

B) 放弃该涉众,转向能看得懂UML模型的涉众。

C) 通过其他介质及手段和涉众交流。

D) 请涉众签字表明不看UML模型后果自负。

3. 如果涉众说数据库模型也是需求,请放在需求规约里面让我确认, 对于需求人员来说,以下做法正确的是:

A) 尊重涉众要求,把数据库模型纳入开发团队需求规约模板中。

B) 认为这不合理,婉言拒绝。

C) UML建模本质上是类建模,把数据库模型改为类模型。

D) 炮制一份涉众想要的需求规约让他确认。

4. 关于“界面原型”,以下说法正确的是:

A) 它是一种需求视图。

B) 它是一种表达界面的需求。

C) 它属于设计工作流的产物。

D) 它是互联网时代新的需求模板。

5. 开会商议时,客户的领导很健谈,从国际形势国内形势到系统界面的细节都谈到了,而且说得很清楚我就要一个像Excel这样的!开发团队按照该领导说的做了一个东西出来,结果他一看“这什么东东,不是我想要的啊!针对以上描述,以下说法正确的是:

A) 需求人员应该继续问清楚,最好让该领导自己画出来想要的东西什么样子。

B) 需求人员应该学习知识点涉众没有资格提供需求”。

C) 需求人员应该拿出开会时的录音和该领导对质,证明自己没做错。

D) 需求人员应该先画用例图和该领导交流得到确认再做。

6. 某汽车配件制造厂。产品在成品之前要经过车间每个工位的加工和处理。每个工位针对配件做完自己的工作后,需要把一些工作数据记下来。厂里想搞一个生产管理系统,当需求人员访谈一些车间操作工时,这些操作工都觉得“搞什么电脑,像现在用手写挺好的”。从需求的角度,我们应该怎么去思考这样的情况?

A) 没有必要去找操作工调研。

B) 提炼涉众利益,尽量兼顾。

C) 教育操作工要接受电脑系统。

D) 没有得到操作工支持,系统暂缓开发。