软件方法笔记7-需求启发

1,如何思考和建模得到需求模型，但需求模型的质量依赖于需求的素材。如果素材质量不高，需求的质量也高不到哪里去。就像做菜，如果食材是变质的，技艺再高妙的厨师也烹调不出美味的菜肴。厨师的技艺代替不了食材的质量。不过，厨师技艺越高，对食材的要求就会越挑剔。同样，建模技能虽然代替不了素材的质量，但会反向驱动素材质量的提高。从涉众处获取需求素材的工作叫做需求启发。
2,许多时候，开发人员把需求启发想得太容易。经常可以听到“采集需求”这样的表述，好像需求是蘑菇，乖乖地躺在森林里，开发人员需要时，就像采蘑菇的小姑娘一样，一个，两个，三个，四个……把它们都采回来。哪有这么容易！需求不是蘑菇。开发人员要能够像猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；像侦探一样，用慎密的思维判断出伪装成好人的凶手。


需求的一个启发障碍是知识的诅咒（Curse of Knowledge），意思是：一旦知道某个东西，就很难想像不知道它会是什么样子
3,知识的诅咒在需求启发中体现为沟通的困难。开发人员懂得许多软件设计和实现的知识，这些知识会有意无意地引导开发人员从实现的角度看需求；涉众在领域里面工作多年，许多事情在他看来一目了然，很难用开发人员能理解的言语表达出来。


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


和涉众交流的形式应该采用视图，而不是模型
和涉众交流的内容应该聚焦涉众利益，而不是需求。
4,需求启发手段 
a,研究资料
研究资料往往是需求启发的第一步，目的是为了获取领域的初步知识，为下一步的启发工作作知识准备.研究资料的工作容易被开发团队忽视。很多时候，开发人员没有知识准备，就匆匆忙忙去找涉众调研，问的问题很肤浅，也观察不到有价值的信息。时间花了，效果并不好。开发团队到客户那里去半个月，也许得到的信息还不如客户的竞争对手去半天，因为竞争对手有充足的知识准备，知道该看什么，该问什么。研究的资料可以是涉众的工作手册、行业手册，工作中的表格、文件、便函、工作报告、作业日志、来往Email，以及当前运行系统及其文档等等。在网络越来越发达的今天，在网上查找资料也是知识准备的高效手段。研究资料的时候要注意尽可能研究实际使用中的资料，尽量不要空白的。很多时候涉众在表格和文档里填的东西，和表格文档各项标题所标示的名称不一样。
b,问卷调查
当需要调查的人群分布较广时，随意挑选几个人来访谈或观察是不够的。例如，要去调研一个即时消息软件的需求，如果仅在自己公司随便找几个人问，事实上这几个人很可能都属于一类人“软件开发人员”，他们的利益诉求不能代表即时消息软件其他类型的涉众，例如“中学生”、“新闻工作者”，“网络管理部门”。如果涉众的分类尚不明确时，就需要做一些问卷调查（电子的或者纸张的），根据问卷调查的结果来给涉众分出类别，然后再从各类别中选取样本，以便做下一步的启发工作。


借助互联网的优势，可以比以往得到范围更广、人数更多的调查对象，缺点是容易鱼目混珠。应对手段是埋藏一些不可能错误的钉子，如果被调查者敷衍回答，很可能就会答错，从而可以判断这份答卷是无效的。
c,访谈
访谈是最重要也最常用的需求启发技术。需求工程师和涉众直接交流以收集信息。访谈并非一定要见面，电话、QQ、Email、微信等也可以作为访谈的手段
访谈时，选择的涉众代表必须名副其实，不要把“代表”等同于“主管”。需求工程师的态度要让涉众觉得自己被尊重。首先是言语上的礼貌.其次在行动上，访谈的时候身体应前倾，不时点头，发出声音“嗯－嗯”，手上做一些笔记（表明重视），适当的时候作两句总结录音——现在录音设备越来越小了，放在桌面上基本不会对访谈造成影响，是一种非常好的记录方法，如果说有什么不足之处，就是只记录了声音，回去后无法研究涉众的表情来确定涉众的真实意思。录像——可以看到肢体语言，但在有一个镜头对准的情况下，受访者往往受到影响。
问题的内容聚焦于业务流程和涉众利益，而非直接的系统需求。例如：


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


这个工作产生什么结果，这些结果谁会关注？


这件事情，您最烦的是什么？


这件事情要是做得不好，会影响到谁？


问题的形式和新闻记者提问一样：5W＋1H。谁（Who）、什么（What）、什么时候（When）、什么地点（Where）、为什么（Why）、怎么进行（How）。提问的时候尽量采用领域词汇，不要采用涉及软件实现的专业术语。
问问题的时候，可以跟随涉众的阐述，不断问为什么，深入探索背后的真正需求。


为什么你们要填这个表格？→这样经理就可以知道所发生的事情→为什么经理需要知道所发生的事情？→这样她就可以按需要分配资源
尽可能在涉众的工作环境里访谈。涉众在自己的工作环境中会想起许多工作中的喜怒哀乐


研究竞争对手
研究竞争对手是产品开发最关键的需求启发技术。过去说提供产品或服务时首要原则是“客户是上帝”，开发软件时，把重点放在研究客户想要什么上面，这样做没错，不过很多时候这还不够。在市场经济充分发展的情况下，任何一个领域都会有多款产品供客户选择.要为产品添加什么新功能，似乎有着无穷无尽的选择，令决策人头痛。竞争对手的软件上添加了一个“星座运程”的功能，我们要不要加上去？恰好，竞争对手们也有同样的想法――为了领先其他竞争对手，所有公司都试图在自己的产品中加入竞争对手产品的新功能，导致无奈的“军备竞赛”，最终所有的产品趋同化，只能寄望于靠价格战等手段击垮对手。
市场经济之下 ，一个领域可能都会有以下战局：有一个市场领先者，他负责向下防御，不断更新自己，并带领这个领域的弟兄们向外扩张。几家追赶者，它们负责进攻领头羊。还有一批专家型的企业，在某一方面形成突出的特点。其他众多公司想尽办法占据一小块细分市场。只有研究清楚对手和战局，才能了解自己的位置和应该采取的战略。
作为市场领先者，不能把矛头对准追赶者，应该开疆拓土，代表整个领域说话，向其他领域进攻。作为追赶者，则需要研究领先者的优点，但不是简单模仿追赶，而是在关键的地方反其道而行之——攻击领先者强势中的弱点。可以借用齐白石的话，“学我者生，似我者死”，不是“更好”，而是“不同”。
5,素质:房屋的根基是好奇心，有三根柱子：探索力、沟通力、表达力，以热情作为屋顶。
好奇心，首先指对不熟悉的事物提起兴趣的能力
好奇心，更重要的是从熟悉中发现惊奇的能力


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


沟通力包括需求工程师和涉众沟通的能力。例如，操作员说系统要简单易用。但“简单易用”并不能直接成为需求。需求工程师要耐心和涉众沟通，了解涉众是以什么标准来度量“简单”和“易用”的。


沟通力还包括需求工程师在不同涉众之间协调的能力。涉众往往有很多类，A类涉众的利益和B类涉众的利益可能在一定程度上是冲突的，录入人员希望操作步骤尽量少，但如果因此省略了一些确认和验证的步骤，使用这些录入数据的审批人员、施工人员的利益可能就会受到损害。需求工程师需要平衡各方涉众的利益以得出恰当的需求。


沟通力还包括需求工程师在涉众与程序员之间协调的能力
6,而平时程序员更多擅长的是和机器的交流能力。程序员如果要去承担需求工程师的角色，沟通力可能是木桶上最短的板。如何培养沟通力？开发人员习惯于生活在一群有较高学历、知识结构单一的软件人圈子内，而涉众往往在学历和技术知识上和我们有差距。要能够和涉众有效沟通，有意识地去改进沟通技巧是必要的。参加一些沟通技巧的训练，或者阅读一些人际交往的相关书籍，例如《人性的弱点》，这本书可以说是中国引进的最早的“沟通力”书籍之一，20多年前曾经大热。书中关于倾听和赞赏的道理到今天依然没有过时。
7,表达力在这里着重指自然语言的表达和组织的能力。需求最常见的形式是以自然语言的方式表达出来的。开发人员平时更习惯的是编程语言的表达能力，写个注释有时也想偷懒，更不用说自然语言表达的其他工件了。项目主管向涉众介绍项目，用词中经常充斥着“伸缩性”之类的字眼，明明只是一个小小的管理系统，却起名叫“××平台”，似乎大家听不懂才说明高深。


提高自然语言的表达力，可以阅读Barbara Minto的《金字塔原理》。
8,有好奇心，有探索力，有沟通力，有表达力，也掌握了各种具体的需求技能，不意味着需求工程师会尽其所能去向涉众探索需求。没有热情作为屋顶，上面提到的各种“力”不能得到贯彻。