第7章 需求启发
我不知道应该说些什么，哦……爱你在心口难开。
《爱你在心口难开》；词：佚名，曲：Sonny Curtis、Jerry 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 访谈
访谈是最重要也最常用的需求启发技术。需求人员和涉众直接交流以收集信息。访谈并非一定要见面，电话、微信、QQ、Email等也可以作为访谈的手段。下面分几个方面来谈。
7.2.3.1 涉众
访谈时，选择的涉众代表必须名副其实，不要把“代表”等同于“主管”。例如，要访谈车间的操作工，那就要选真正的操作工，不能用车间主任来做代表。操作工岗位的酸甜苦辣，只有操作工自己最清楚。应该把车间主任看作另外一类涉众单独访谈。实际工作中常见的错误还有把目标机构中挂“信息中心主任”头衔的人作为主要的调研对象，认为他们既懂电脑，又懂业务，其实大谬。
要挑选经验丰富的涉众来观察。经验丰富的“老师傅”在长期的工作经历中归纳出了一套行之有效的经验，系统可以学习他的经验（然后一脚把他踹开），这就是第4章所说的改进点“封装领域逻辑”。所以即使“老师傅”不懂电脑不支持信息化，也要选他作为访谈对象。这里经常犯的错误就是需求人员喜欢选择爱玩电脑和手机的小年轻作为访谈对象，因为他们支持信息化，而且崇拜软件开发人员。
不同类型的涉众，应该尽量单独访谈，如果图省事把有利益冲突的两类涉众集中到一起访谈，受访者言辞之间可能就会有顾忌。
本书不提供练习题答案，请扫码或访问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) 需求人员应该先画用例图和该领导交流得到确认再做。
祝各位节日快乐，有空下载阅读！
《软件方法（上）业务建模和需求》第二版草稿pdf文件下载（适合手机屏幕），更新日期：2017.9.30
https://pan.baidu.com/s/1eSlcdsY
《软件方法（上）业务建模和需求》第二版草稿pdf文件下载（适合PC屏幕），更新日期：2017.9.30
https://pan.baidu.com/s/1nuXqDlf
您在阅读《软件方法》时如果发现错误，欢迎在群里告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，将付给您5.12元报酬，并在书中说明您的贡献。报酬通过支付宝或微信支付。
（1）任何您认为的错误都可以，包括错别字。
（2）同一错误仅支付最先指正者报酬。
（3）请根据最新版本作指正。
目前挑错记录：
第五元素：找出142个错误，获得奖金727.04元
Lihongzhou：找出26个错误，获得奖金133.12元
半导体：找出21个错误，获得奖金107.52元
......
最新挑错
龙志超：找出6个错误，获得奖金30.72元
邹盛荣：找出3个错误，获得奖金15.36元