7章 需求 之 需求启发

返回>>

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

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

 

2到第6章的内容都是关于如何思考和建模得到需求模型,但需求模型的质量依赖于需求的素材。如果素材质量不高,需求的质量也高不到哪里去。就像做菜,如果食材是变质的,技艺再高妙的厨师也烹调不出美味的菜肴。厨师的技艺代替不了食材的质量。不过,厨师技艺越高,对食材的要求就会越挑剔。同样,建模技能虽然代替不了素材的质量,但会反向驱动素材质量的提高。从涉众处获取需求素材的工作叫做需求启发。

7.1 启发障碍

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

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

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

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

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

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

如果很好地理解了这两点,需求启发技能就可以上一个台阶。

7.2 需求启发手段

7.2.1 研究资料

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

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

1964年《中国画报》封面刊出的一张照片。大庆油田的“铁人”王进喜握着钻机手柄眺望远方,在他身后散布着高大井架。日本情报专家据此解开了大庆油田的秘密,他们根据照片上王进喜的衣着判断,大庆油田位于齐齐哈尔与哈尔滨之间;并通过照片中王进喜所握手柄的架式,推断出油井的直径;从王进喜所站的钻井与背后油田间的距离和井架密度,推断出油田的大致储量和产量。当我国政府向世界各国征求开采大庆油田的设计方案时,日本人一举中标。

——摘自douban.com

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

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

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

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

7.2.2 问卷调查

当需要调查的人群分布较广时,随意挑选几个人来访谈或观察是不够的。例如,要去调研一个即时消息软件的需求,如果仅在自己公司随便找几个人问,事实上这几个人很可能都属于一类人“软件开发人员”,他们的利益诉求不能代表即时消息软件其他类型的涉众,例如“中学生”、“新闻工作者”,“网络管理部门”。如果涉众的分类尚不明确时,就需要做一些问卷调查(电子的或者纸张的),根据问卷调查的结果来给涉众分出类别,然后再从各类别中选取样本,以便做下一步的启发工作。

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

7.2.3 访谈

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

涉众

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

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

需求工程师

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

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

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

访谈的时候光听肯定是不行的,要想办法记录。可选的方案有:

自己做笔记——手上肯定会有做笔记的动作,但记录的速度是比不上说话的,而且还会因为问答,节奏经常被打断,不能因为低头专注记笔记而影响交流。所以,边问边做笔记只能记住一些关键点和做出尊重涉众的姿态。

录音——现在录音设备越来越小了,放在桌面上基本不会对访谈造成影响,是一种非常好的记录方法,如果说有什么不足之处,就是只记录了声音,回去后无法研究涉众的表情来确定涉众的真实意思。

录像——可以看到肢体语言,但在有一个镜头对准的情况下,受访者往往受到影响。

有可能的话,记录手段应该采取双备份。录音笔会出故障的,因为去一趟不容易,保险一点为好。但要把录音录像当作好像不存在,该倾听倾听,该记笔记记笔记。

问题

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

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

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

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

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

……

问题的形式和新闻记者提问一样:5W1H。谁(Who)、什么(What)、什么时候(When)、什么地点(Where)、为什么(Why)、怎么进行(How)。提问的时候尽量采用领域词汇,不要采用涉及软件实现的专业术语。

问问题的时候,可以跟随涉众的阐述,不断问为什么,深入探索背后的真正需求。

为什么你们要填这个表格?→这样经理就可以知道所发生的事情→为什么经理需要知道所发生的事情?→这样她就可以按需要分配资源

环境

尽可能在涉众的工作环境里访谈。涉众在自己的工作环境中会想起许多工作中的喜怒哀乐,如果把他请到软件公司或者度假山庄的会议室,环境发生变化,一些本来深有感触的东西,因为不在该环境中,一时之间会想不起来。有人嫌在涉众的工作环境里访谈经常会被打断,但那也是一种真实的工作状态。

有些开发过程力捧“在场客户”的好处,确实,有“在场客户”总比没有要好,但在涉众的种类很多而且利益各异的情况下,一个“在场客户”怎么能代表这么多涉众呢?更不用说不是给人直接使用的系统了。“在场客户”其实是一种偷懒的做法,它让开发人员心安理得坐在电脑前面编码,有问题不再深入第一线调研,而是推给“在场客户”。

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

7.2.4 观察

观察就是需求工程师跟在涉众旁边,甚至亲身去体验涉众的工作。这是最直接的需求启发技术,也最费时间。

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

观察的时候,重点关心:完成一项工作所需时间、操作次数、出现的的错误和混乱。所需时间越多、操作次数越多、出现的错误越多,系统如果能在这项工作有所帮助,必将会给涉众带来强烈的改进感觉。

观察的时候,也要观察环境的特殊性,例如牙科医生手里拿着工具无法腾出手来操作电脑、旅客手里提着行李、车厢里光线阴暗等等。

最极限的观察手段就是需求工程师亲身上阵去体验涉众的工作了。这样做会使得涉众感觉被重视,也更信任您能开发出好东西。不过,亲身上阵代价较高,而且很多地方没法亲自上阵,当半天收银员还可以,当半天医生就要惹出麻烦了。

观察对于今天的产品研发越来越重要。在市场竞争激烈的体验经济时代,客户的口味提高了,光是有个东西给他用是不行的。对精益求精的产品开发者来说,观察是不得不花代价去做的启发技术。

Jeff Hawkins在研发Palm Pilot时,把一块木头模型整天揣在口袋里,在工作和生活中不停揣摩应该怎么使用掌上电脑,过滤出最有价值的需求,最终Palm Pilot成为第一款获得成功的掌上电脑。而之前,苹果出品的掌上电脑Newton因过于臃肿,导致市场惨败。

7.2.5 研究竞争对手

研究竞争对手是产品开发最关键的需求启发技术。过去说提供产品或服务时首要原则是“客户是上帝”,开发软件时,把重点放在研究客户想要什么上面,这样做没错,不过很多时候这还不够。在市场经济充分发展的情况下,任何一个领域都会有多款产品供客户选择。2013530日,天空下载(skycn.com)提供的下载列表中仅视频播放”这一类别,就有软件703个;用iPad在苹果应用商店中搜索“播放”,也可以得到一屏又一屏的结果。您的“上帝”同时也会是别人的“上帝”,这个时候客户如何才能从这么多家中选择您?

要为产品添加什么新功能,似乎有着无穷无尽的选择,令决策人头痛。竞争对手的软件上添加了一个“星座运程”的功能,我们要不要加上去?恰好,竞争对手们也有同样的想法――为了领先其他竞争对手,所有公司都试图在自己的产品中加入竞争对手产品的新功能,导致无奈的“军备竞赛”,最终所有的产品趋同化,只能寄望于靠价格战等手段击垮对手。

市场经济之下 ,一个领域可能都会有以下战局:有一个市场领先者,他负责向下防御,不断更新自己,并带领这个领域的弟兄们向外扩张。几家追赶者,它们负责进攻领头羊。还有一批专家型的企业,在某一方面形成突出的特点。其他众多公司想尽办法占据一小块细分市场。只有研究清楚对手和战局,才能了解自己的位置和应该采取的战略。

作为市场领先者,不能把矛头对准追赶者,应该开疆拓土,代表整个领域说话,向其他领域进攻。作为追赶者,则需要研究领先者的优点,但不是简单模仿追赶,而是在关键的地方反其道而行之——攻击领先者强势中的弱点。可以借用齐白石的话,“学我者生,似我者死”,不是“更好”,而是“不同”。

生活就像超级女声,撑到最后的都是纯爷们。

——网络流行语

专家型的软件,只要一直坚持自己的特色,缩窄自己的攻击面,就一直会有市场。软件的集成化确实越来越加剧,但电脑(包括PC、平板、智能手机)里装的软件个数反而越来越多。排在最后的大量“游击队”,需要尽快使自己的产品能有某一方面的特色,成为专家型企业,在顾客的脑子占据一个牢固的位置。

关于如何研究竞争对手来定位自己的产品,市场营销领域的专家研究得更加深刻,我就不便在这里班门弄斧了。这方面的著作,可以看Al RiesJack Trout所著的“Positioning: The Battle for Your Mind”,中译本《定位》。

7.3 需求工程师

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

我把一名优秀需求工程师所需要的素质归纳成一所房屋的样子:

7-1 需求工程师的素质

房屋的根基是好奇心,有三根柱子:探索力、沟通力、表达力,以热情作为屋顶。

7.3.1 好奇心

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

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

7-2 抵制向里探头的诱惑

好奇心可以在日常生活中培养。日常生活充满了各种惊奇:

一大群人,半夜不睡觉,讨论过去一天的各种事情,然后把它们整理成厚厚的一叠纸,送到您的办公室,只收1元钱。

有一种动物很奇怪,每天从壳子钻进钻出,一到晚上,就几个一组钻进一个壳子里盯着一个发出荧光的盒子一动不动。

用另一种心态来观察事物,可以培养好奇心。平时还可以看一些“短路”的电影或动漫,或者做一些不熟悉的事情,例如,如果您喜欢看《南方周末》,不妨偶尔看看《环球时报》;如果您喜欢看《程序员》,不妨偶尔看看《知音》。

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类涉众的利益可能在一定程度上是冲突的,录入人员希望操作步骤尽量少,但如果因此省略了一些确认和验证的步骤,使用这些录入数据的审批人员、施工人员的利益可能就会受到损害。需求工程师需要平衡各方涉众的利益以得出恰当的需求。

沟通力还包括需求工程师在涉众与程序员之间协调的能力。例如,操作员要求“一键完成操作”,却难为了程序员。

7-3 需求工程师要负责各种沟通

而平时程序员更多擅长的是和机器的交流能力。程序员如果要去承担需求工程师的角色,沟通力可能是木桶上最短的板。

如何培养沟通力?开发人员习惯于生活在一群有较高学历、知识结构单一的软件人圈子内,而涉众往往在学历和技术知识上和我们有差距。要能够和涉众有效沟通,有意识地去改进沟通技巧是必要的。参加一些沟通技巧的训练,或者阅读一些人际交往的相关书籍,例如《人性的弱点》,这本书可以说是中国引进的最早的“沟通力”书籍之一,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的光照模型"