软件项目如何调研（二）

2.7.2 常见错误六：聆听，而不是提供解决方案

有的人在用户提出一个疑难点的时候，很希望把自己的产品特色展示出来，花了大量时间讲自己的卖点和特色，给用户做了大量启蒙工作。

当然有些用户还会对一些特色功能念念不忘，并拿来要求其它供应商提供。

其实在调研过程不是做解决方案的过程，调研就是为解决方案奠定基础的，过早在调研过程中提供问题的答案有如下坏处。

没有经过精心准备的演示可以有几个亮点，但很难形成整体打动别人决定性力量，反而浪费了调研的时间，影响了为有价值解决方案制作的调研时间。

提供解决方案往往是临时思考没有经过全面分析，难免偏颇，为了表现能力而承诺一定可行的内容发现实际上并不是那么容易，导致后期实施骑虎难下。

做项目不是一个人在做，而是一个团队在做，如果没有沟通就向用户提供了自己的思路，可能会给整个团队的思路带来干扰，解决方案一定要在内部达成一致才能提供给用户。

一些的确非常成熟有特色的业务解决方案可能会提前泄露给竞争对手，对手可以针对性进行准备，导致杀手锏失灵。

所以调研过程中不要过多花费精力介绍我们的产品，而是做一个好的发问者和聆听者，用耳朵去听，用心去想，用大脑去分析用户的信息，去发现有价值的内容。

2.8.1 常见错误七：没有开业务分析会

很多人做完调研，就按计划打道回府，准备后续工作，其实有经验的调研人员还会多做一个工作，就是开一个针对企业领导、项目负责人和主要业务层面的调研工作汇报会。

我们说调研目的是让用户让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程。

单个用户是否建立这种认识我们是通过复述技巧实现的。但对于企业领导又如何知道我们了解企业业务呢？

有人说这些将在解决方案中完整体现，不过说实话，有几个人相信我们这些管理供应商写的多达百页的文档企业里会有三个以上的人看一遍？

都是在浪费纸张而已！

所以在调研完成之前，在调研计划中调研者应主动安排或者创造这么一次汇报的机会，专门陈述我们对企业业务和要解决关键问题的认识，这个认识陈述好了，企业自然对供应商刮目相看，就算有一些偏差，也可以立即得到纠偏的机会。

这个汇报会时间不一定要很长，但可以让企业领导真切感到我们调研工作的成效，我们对事实把握可靠程度，我们对企业业务了解深入程度，我们对问题分析细致程度，我们在该领域的专业程度即可。

有了这个阶段性总结，调研工作就可以说顺利完成了，可以进入下一阶段准备工作了。

不过在业务分析会上一定要注意一点，不能用过高的姿态切入。

有的人经过调研确实发现了企业一些问题，也想到一些很好的解决思路。于是其在业务分析会上企图指点天下，痛陈不足，确有严加改进必要的时候，就有可能犯一个大错误的时候。

有了表现欲，就容易昏头。

业务分析会一个铁的原则就是不要轻易说自己用户的不足，即使要说，也应用一种委婉的方式表达；指出可进步的地方，而不是指出落后的地方。指出不受控的地方，而不是失控的地方，指出实现不方便的地方，而不是指出无业务管理覆盖的地方。

这些都是做业务分析会要替自己客户考虑到地方，不要随意批评别人不足，也不要以为企业没有人知道这些毛病，更不要以为他们不知道这些毛病该如何解决，有时候无非是外来的和尚无牵挂，好念经而已。

2.9.1 常见错误八：只重视正式沟通，不重视非正式沟通

调研工作特别是在正式调研活动中有些问题并不方便了解，所以调研工作还包括一些非正式场合，这些场合适合调研者问一些相对敏感或者自己有看法但没有把握的问题。

所以调研不仅仅在工作计划中所列走访，座谈，会议等形式中，也在和用户一起聚餐等非正式沟通活动中。

只要调研计划没有结束，所有的时间都是为调研而准备的，走路，闲谈，吃饭都是可以进行调研的机会，不一定要正式场合才能开始调研。

这种非正式沟通信息一样很重要，而且往往是真实运行企业的信息，和正式调研得到的信息正好可以互相印证。

在非正式沟通中调研者还可以和企业一些人建立友好的关系，为今后工作也奠定了良好的基础。

所以好的调研者不仅仅是一个专业人员，在非正式场合也是一个可以让别人说话的人，这样的调研行为才是完整的。

2.9.2 常见错误九：关键业务只询问了个别人意见

一些业务在整个调研工作中是占据很重要分量，而且涉及多个业务部门，这个时候调研就要记住“兼听则明，偏听则暗”，一定要把业务涉及不同部门意见都听到，也要把不同人对同一业务描述进行对比调研，从中能发现很多错误。

此时不可因为觉得调研内容很饱满或者时间紧张而只做单点调研，关键业务一定要从其它人那里不断得到印证。

不过再问第二个人的时候，就可以用主动复述业务的方式，请其重点指出不对的地方，加快调研进度。

2.9.3 常见错误十：调研时有选择问问题

有的调研者在调研阶段就非常小心，特别是在其对自己软件不足的地方有足够了解的时候，总想在调研阶段引导用户，接受自己的系统，绕过这些自己产品不足的地方，这也是一种错误的做法。

首先如果调研发现用户迫切需要很有价值的问题是公司目前不能解决的问题，并不等于不调研就可以回避，无论将来在技术答辩还是售后实施，这个问题总是要冒出来，与其回避，不如主动搞清楚，汇报给公司，看看到底有什么办法可以解决。

真正的问题都是回避不了，绕不过去的。

我个人意见，越是有公司明显不能解决的问题，越要调研清楚，搞清楚来龙去脉，为公司今后产品发展提供完整的需求建议，作为一家负责任的软件公司，首先要承认自己的软件不可能解决所有的问题，但一定要在发展过程中逐步解决更多的问题，调研时都回避了，不就失去了公司产品发展的机会了吗？

其次如果有选择性问问题，就会遗漏一些关键性业务，这样对调研整体质量有影响，在后续工作中容易被动。

至于不想将用户一些天马行空问题，或者的确不想引发他们高度兴趣的问题回避的方法，不是不通过调研，而是认真记录，但不提供在正式文档的方式规避。

很多人很多需求都是一时灵感，没有经过认真思考，所以口舌之快，过了也就过了，不形成文字记录，他自己也不记得自己说过什么了。如果是真的关键问题，在后续复述，确认调研记录还有业务分析会上还会提出来的，这个时候再确定写入正式文件也不迟。

对于这些暂时不能满足的需求和超出范围的需求，可以另外整理一份内部文档给公司分析。

2.10.1 常见错误十一：一次调研就企图锁定需求

很多项目启动后轰轰烈烈进行了一次深入调研，然后开始配置开发实施，忙得不亦乐乎。好象把企业问题搞清楚了，就应该是实现和解决的阶段。

实际上很少有人能够在短短几天内把企业的问题搞清楚，即使你努力进行了半个月甚至一个月的调研，在实施过程中你还是会发现对很多问题认识我们依然不够深入，不够完整。

这个时候我们应该意识到，我们依然还需要进行调研，切不可因为是大规模调研完成了，对此时的调研就随意了，不留记录，不进行确认了。

事实上这些调研信息要随时记录确认并最终完善到项目解决方案中，可以这样说，信息化项目中始终要有随时开始调研的意识，如果我们承认信息化需求是无止境的话，那么调研也是无止境的。

为什么不能通过一次调研锁定需求呢？

正确的需求是系统成功的关键。预先锁定需求的假设前提是用户不经过系统上实践的过程，用户就能预先精确的提出所有的系统需求。

某些简单软件或者具有极高技术水平的用户可能可以，但是一般情况是用户只对其目标和需求最初只有模糊笼统的认识，许多细节都不清楚。要求一个只有初步设想的用户或个别用户负责人准确无误地说出全部需求，显然是不切实际的。

用户为了证实和细化他们的设想，往往需要在某个系统上持续不断学习和实践的过程。特别是在大型管理系统软件上。

即使经过深入细致的预先锁定需求的工作，当人们实地观察和使用了目标系统以后，也常常会改变原来的某些想法，对系统提出一些新的要求，以使系统更加符合他们要求，事先锁定需求的方式其实也会经过多次反复，甚至完全失败。

大型软件的开发需要系统分析员、软件工程师、程序员、实施经理、用户领导、用户负责人、具体用户等众多各类不同层次不同技术水平人员的一致协调努力，因此良好的通信和相互理解对于保证工程成功至关重要，传统的需求锁定方法假设使用适当的文档可以做到项目参加者之间清晰、准确、有效的沟通。但是各种文档本质上是被动、静止的通信工具，通过它们来理解一个动态系统是困难的。

用户变更需求是正常的，用户没有实际操作过软件之前无论你怎样描述都会有对软件功能理解不一致的地方，可能是技术协议上书面文字表达一致但对实际软件操作理解不一致，可能根本就是不用不知道哪里不适合自己的需求。

打个比方，就象买衣服，无论别人怎样推销，客人一般都会试一试觉得合身再买，我们一般比较大的项目都没有让用户体验过而且在推销时说了很多动听的话，自然期待高，失望也高，而且用户为适应ISO认证或PDM/ERP系统必然伴随组织机构和业务流程重组，这里面有很多反复的过程，对应的文档，设计流程，对软件操作提出变更是正常的。

我们的问题不再于要用户不变更需求，而在于找到一种方法让用户认识到我们的软件能发挥作用，当有新的需求时通过使用我们软件建立的信任关系重新形成新的业务，这也是调研时要保持一种理念。

2.10.2 常见错误十二：调研工作表现不职业

有的调研人员工作很努力，但在现场很难得到用户的认可，就是因为经常表现出一些职业不成熟的缘故，甚至有的表现是不道德的。

常见不成熟职业表现有：

1、 不征求用户同意就翻看其资料(如果有的竞争对手敏感资料想获得，也一定不要给别人看到)；

2、 调研过程中电话短消息不断；

3、 在用户现场上网工作时顺便聊天看和工作无关的内容；

4、 没有征求用户同意使用用户电话；

5、 用户同意使用电话讲起来没完没了；

6、 对用户现有各方面状态流露轻视的态度，例如认为用户条件不成熟，管理不到位，表现出眼界高人一等的想法。

2．11 调研工作方法推荐

2.11.1 每日调研流程

1、提出调研内容，请企业项目组成员配合预约人员时间安排访谈；

2、访谈

3、当场复述内容，确认理解对方表达的问题

4、立即将整理访谈结果形成文档记录，确认需要继续了解的内容和未清楚的内容

5、如果需要，安排时间请被访谈对象确认访谈文档记录，特别是一些关键名词定义部分

6、和企业项目组成员配合约定下一时间段访谈安排。

2.11.2 访谈成功的九个要点

让访谈者上司安排会面

调研前应向调研者介绍调研内容和时间大概安排，让其心中有数

聆听，不要发表指导意见，要靠和用户交流发现问题核心所在

随时收集和记录事实，寻找异常现象，发掘管理改进需求，认真记录并探讨原因

尽量两个人一起采访，最好一个是企业项目组的成员

复述、复述再复述

一次不要问得太多

在结束会谈后又提出一个问题

访谈结束后一定要表示感谢

2.11.3 良好的结构化调研顺序

先了解企业基本情况和项目组成员情况，由此建立对企业初步认识，对项目有个初步判断；

再了解企业组织结构和岗位设计，由此确定访谈对象；

再逐个按照业务口了解业务流，业务流要关心业务可以划分为哪些阶段，每个阶段应该是相互独立，彼此穷尽的。

每个业务阶段要问清楚业务目的，输入数据和输出数据，过程步骤，每个步骤的负责人，什么时候开始，什么时候结束。

输入数据其什么作用，有哪些信息传递到输出数据中。输出数据又起什么作用，是指导下游还是反馈上游。

业务流程调研质量评判标准就是能否清晰简明画出企业业务流程图和数据流程图。

2.11.4 售前和售后调研的不同

售前调研一般是为产品演示，技术交流做准备，同时调研过程要注意突出自己强项，给竞争对手制造门槛。

售后调研一般是为解决方案，项目实施做准备，同时调研过程中要注意寻求项目价值点，利用价值点置换项目边界，尽量把项目边界最小化，项目才容易成功和受控。

售前调研一般由商务主动和用户协商时机，根据实际情况确定先调研还是后调研。售后调研必须尽快启动，而且应该在项目启动大会后展开调研。

售后调研前一般要和企业高管亲密接触，取得支持。在启动大会上对调研方法和需要取得支持告诉企业配合人员后进行。

售前调研一般要协助拿项目，所以不要轻易发表对问题倾向性看法，要了解事实，用比较文饰的语言表达对问题的认识，通过对事物认识深度获取支持。售后调研可以相对直接提出问题，摆事实，陈厉害，争取最大范围重视，进而获得支持。

2.11.5 如何写调研日志

调研日志有三个要求：工作过程清晰化，调研内容结构化，不明内容有后续计划。

首先调研日志上要看出本调研了哪些部门，走访了哪些人，用了多少时间，获取了哪些业务的信息，这就叫工作过程清晰化。

然后调研内容不能是流水帐记录，必须将被调研者的话组织成一个个合理的单元，这些单元独立可以反映某个业务层面的情况，然后整体上构成一个业务调研报告的部分。

不同的信息结构化方法可能不太一样，有的适合用表格，有的适合用文字段落，有的适合绘制图形(例如框图，鱼骨图等等)。

调研日志最后要说明今天调研中还有哪些问题，需要进一步明确，并有认真记录。

2.11.6 如何写调研备忘录

调研备忘录一般情况下并不是把自己调研日志的内容汇总重新罗列，因为调研日志和业务调研报告就是做这个工作的。

调研备忘录和一般的备忘录一样，主要是说明本次现场工作进行了哪些工作内容，达到了怎样的目的，和企业约定的下一步工作安排是什么，并得到企业负责人签字认可。

备忘录主要让用户看到我们做事的规范性，而且在今后合作中将不断用同一格式备忘录强化我们在规范上的一致性，同时备忘录要让用户感觉到我们本次现场调研工作时间紧凑，内容丰富，层次清晰，让用户对我们形成良好的印象。

2．12接口调研背景知识

现在管理软件项目中接口需求很多，很多项目接口实现得并不理想，原因就在于接口协议质量不高，而接口协议是和接口调研紧密相关的。一般接口调研和其它调研方法是一样的，但要做好接口调研就必须具备一定的专业知识，这可能是能否做好接口调研的关键。

接口协议除一般性协议要素外，应该包括如下内容：

2.12.1 接口技术实现方式

接口方式最高级一种是主动式。

即通过直接对其它软件的数据库进行操作。这种方式因为涉及到对用户数据读写操作，对于对方软件而言，安全性是最大的问题，验证的复杂程度也最高。主动式基本有两种方式：

1)DATA方式，通过数据库语言对数据库进行直接读写。这种情况要求对对方数据有详细认识。需要对方的人员可以提供数据库的详细资料。为了保障数据的安全，要界定对读写要求。一般和用户自行开发的系统会比较多出现此类要求，商品化ERP很少提出这种方式。

2)利用其它软件提供的工具。除了直接对数据进行读写外，有些软件也提供了一些工具(可能是控件，函数，脚本等)。可以通过这些工具对数据库进行操作。例如现在神州数码易飞ERP就全部采用控件方式接口。

这种情况下要提供这些工具的详细使用说明。

接口方式相对主动式的就是被动式开放。

同主动式对应，即开放软件商自己的数据库或开发接口给其它供应商读取数据。这种方式涉及到软件商提供的数据或开发程序。对方要我们的哪些数据，将成为了解需求的重点。按提供方式的不同可以分为以下四种。

1)DATA方式。即开方我们的文件或数据库格式给对方。由对方软件直接读取数据。这样的情况一般在企业有开发能力，而且只需要信息提取(不是写入)时才使用。这种情况很少。

2)脚本方式。早期的脚本语言，多是一种专用高级编程语言。实现了基本的程序流程语句，简单的数据结构，在此基础上，提供访问软件内部数据的语句。通过这类专用语言，用户可以对程序进行界面配置，实现简单的功能扩展，给用户提供了一定的灵活性。而只需用户懂一点程序设计知识即可。这类语言的缺点是没有通用性，功能有限，由于解释执行，速度受到很大限制，并且应用软件开发商实现专用编程语言及调试环境有较大难度。对于应用程序，需实现三个要求，就可拥有脚本语言编程接口：

A)应用程序的对象模型

B)适合应用程序对象模型的对象

C)脚本语言编程引擎

前面两个方面，需要应用程序用组件对象模型的方式构造。采用组件方式，是软件开发的发展方向，提供对象模型是一件很自然的事情。第三个方面，有通用脚本语言编程引擎供选择，微软的ActiveX脚本编程引擎可以免费使用，VBA脚本引擎需要购买。 ActiveX脚本引擎实现了基本功能，没有调试环境。VBA是一种通用编程语言，其核心就是应用广泛的VB，拥有大量函数支持，窗口编辑能力，强大的调试环境。很明显，微软希望VBA成为应用软件二次开发的通用语言。例如CAPP和国外PDM的接口就属于这种开放方式。

3)链接库方式。基于结构化的软件，可以提供软件内部使用的动态连接库，供用户使用。动态连接库是速度最快的接口，应该说是一种很好的选择，CAPP目前的二次开发接口就属于动态连接库方式。

但是动态连接库在接口升级时会遇到麻烦，用户程序难以和正在运行的应用程序进行数据交换。用户也难以使自己的模块(用户实现的动态连接库)嵌入应用程序。因为动态连接库的通常首先实现的(至少要定义输出函数接口)，而后才能使用动态库。但应用软件开发时，用户实现的动态库根本不存在，AutoCAD的ObjectARX用一种特殊的机制，才使AutoCAD可以使用用户开发的动态库。目前国内很多 AutoCAD二次开发软件，就是使用ObjectARX开发的，可以完全的嵌入AutoCAD。

4)COM组件方式。COM对象接口：基于组件对象模型的软件，可以提供软件的COM对象接口。组件应用程序由多个组件打包而成，组件之间的联系是一种松散耦合，使其中某个组件的改变不影响其他组件，应用程序修改，改进变得方便。这就如同一台复杂的机械设备的各种零部件用螺栓连接起来，零部件可以轻易更换。而传统应用程序就像所有零部件都通过焊接连接的，如果要改进，只能重新做一个新的。组件程序由于由许多具有位置透明性(无需知道组件的位置)的组件构成，可以很容易实现分布式应用。组件架构强调实现对象模型，开发接口是基于对象的，符合用户的思维方式，比动态库提供的API，更易于理解，使用。组件是完全与语言无关的,任何过程性语言够可以用来开发组件，根据不同的需求，可以轻易的用不同语言开发应用程序的不同部分，用户可以选择任何过程性语言做二次开发。通过COM的底层机制，可以访问运行中的应用程序对象，实现与运行中程序交换数据。用户组件也可以易于嵌入应用程序中。COM的主要问题是，运行速度比动态库慢，特别是自动化接口；对系统稳定性要求高于动态库，要求系统的COM平台能正常工作。

最常用也是最安全，成本最低的接口方式是中间文件接口。

双方的数据交流通过中间文件进行。这种方式由于比较灵活，接口双方都比较明确工作。而且重要是的，接口双方的软件升级，对于接口本身(对方软件本身)可以说没有影响。是目前采用较多的接口方式。

如果是中间文件的还需要确定是全量式接口还是增量式接口。

接口本身是为了双方数据可以保持交流和数据一致性进行的。一方提供数据，另一方根据对方的数据来更新自己的系统的数据。所以对于哪些信息是新加，哪些是删，哪些是更新要进行判断。从数据提供方而言可以提供以下几种：

全量：按软件数据内的数据提供全部的数据，不进行区分哪些是增，哪些是删。这种方式需要用户对比自己内部的数据进行区分哪些是增，哪些是删。

增量：由数据提供方进行对比后，区分哪些数据是要更改的，哪些是要删除的。对方软件根据数据提供方提供的文件直接更新数据库。这种方式的重点是要掌握同什么数据对比，得出增减记录。另外，对不不同的记录(增/减记录)是提供不同的文件，还是在同一文件内对于不同的记录做上标记也是要定义的。此时可能就要在接口字段上定义更改标识，更改单号，版本号等信息。

2.13.1 接口内容

接口方式一旦确定，就需要确定接口的内容。

接口内容首先要确定接口入口，从哪里开始汇总接口数据，接口数据每次包含多少对象，这些对象是如何联系在一起的。例如接口数据每次都从一个完整的产品上开始汇总，或者从一个完整的工程任务上开始汇总，或者从任意零部件上都可以发起汇总。

第二接口内容要确定接口时机，要明确哪些字段由数据提供方(其它系统)写，那些读，在什么时候进行。也就是约定当数据达到怎样的规定后才可以启动接口输出，此时也可以约定接口输出负责人员。例如当产品结构发布，相关工艺数据也发布后才能启动接口，如果有明确接口时机要求，接口程序应适当做校验性判断，防止提供不正确的数据给下游系统。

第三接口内容要确定接口格式。

接口格式包括明确数据交换提交的方式：是文件级还是数据库级，然后明确交换文件的名字，存盘路径。

明确文件的格式，包括文件或数据表包含的字段名，字段次序，字段类型，字段长度，分隔符(如是文本文件)，是否必填，默认值，下游系统对应含义，实际数据样例，接口对应数据来源，该字段在实际操作中填写规则。

第三接口内容要确定接口样例。

接口技术协议附件必须包括用户方提供的样例数据，样例数据必须具备典型特性，能够覆盖企业各种可能的实际数据情况，保证验证样例数据对接口测试的完整性；

如果一个样例不能覆盖可以提供足够样例数据，用户方可提供多个样例，直到可覆盖各种可能情况为止。

用户方要保证样例数据的规范性。此时可能还需要针对接口样例提供数据规范性录入操作说明。

依据所提供样例最终得到的接口中间文件将以完整实例作为验证标准依据。如果有多个样例，则需提供多个完整的接口中间文件实例。准备接口样例将大大加快验证时间和接口程序调整反复时间，也有利于企业，供应商快速就接口协议达成一致性理解，是看起来慢，实际上最快的有效接口方式。

2.13.2 接口数据一致性握手方式

接口数据的一致性通握手方式来保障。一致性分为静态一致性，动态一致性，双向一致性。

静态一致性：如物料编码信息，原始工艺设计信息。

动态一致性：如设计更改信息，在一个系统内的数据更新后，要求另一个系统内的数据也要进行相应的处理。握手方式即明确如何让对方系统得到要进行更改的信息(也可能是依靠人员来进行手工操作)，这样对方系统对接口文件进行处理。

双向一致性：复杂的系统甚至要求，对方系统处理的数据结果要进行反馈。从而更新本身系统的数据。这里面也要对反馈进行定义。

2．14调研后续工作落实阶段

2.14.1 如何写业务调研报告

调研结束后第一个必须尽快整理出业务调研报告，业务调研报告主体内容可以在业务分析会上得到用户确认。

写业务调研报告应该结合软件供应商特点形成一个比较统一的汇报目录模板，有了模板整理起来就快，不同软件关心业务内容不同，模板也应该不一样。

一般而言业务调研报告目录可以分为三个大的部分，第一部分是业务基本情况介绍，第二部分是企业业务流程图和数据流图，第三部分是项目关键价值点。

凡是不设计业务流和数据流，但必须要描述的内容，例如企业的一些基础数据情况，我们把其作为企业的基本情况介绍，例如企业概况，企业设计数据统计情况，企业工艺数据统计情况，企业标准化编码规定等等，做基本情况介绍时要把握两个原则：

第一是结构化，不要散乱，将相关性强的一组基本情况设计成表格填写，这样既方便填写，又不容易遗漏。

第二是按照调研先后顺序组织，和业务流顺序尽量一致。这样不但层次清晰，而且可以直接将每天调研日志内容复制修改就可以得到最终结果，大大提高工作效率。

业务流程图和数据流图有大量标准工具和方法指导，建议这里大家去找相关专门知识学习，本文不在这里展开。

第三部分项目关键价值点是非常重要的，项目价值点组织也必须符合结构化层次，不要将很大的价值和很小的价值并列排放，应该将最大的价值，可以相互独立做为一层，然后将小价值分别归类到不同大价值下，形成一个价值支撑体系，这个支撑体系也是解决方案的实现思路。

2.14.2 业务调研报告完成后续工作

业务调研报告完成后必须赶紧去找后续工作同伴，按照约定的工作计划把调研报告交给他们，如果有时间，还可以安排一个内部业务分析会议，做一个全面的介绍。

帮助团队成员可以准确理解调研报告，启动后续工作才是一个调研的工作结束。

如果你能按照以上方法进行调研，相信你的调研质量一定很棒，这样的话，不管后续工作是什么，我相信你都会得心应手的去完成，或者帮助你的团队成员去完成。

这也就是调研最大乐趣所在。