业务需求调研经验分享

 1. 针对具体的工作内容，召集专题访谈启动会、访谈沟通会。由客户的项目负责人向涉及的相关部门或者受访对象进行情况介绍和工作任务安排，并注意在会上详细、正式的介绍需要参与的具体访谈的人员，并收集被访谈对象的基本信息（包括：姓名、部门、联系电话、email等）。

2. 在正式访谈之前，给访谈对象提供访谈提纲或需求调研表，并告知客户需要根据提纲进行准备。即使客户未填写调研表，但通过访谈提纲可以让访谈对象提前思考，整理应答思路、收集相关资料，或者提前准备、预约更合适的访谈对象。

3. 正式访谈前，先向被访谈者介绍访谈议程。介绍访谈总体过程、各环节主要内容、大致时间。务必先给被访谈者建立一个全局整体印象，也便于双方共同掌握访谈时间和节奏。

4. 开始具体工作内容的访谈前，概要性介绍项目的背景及其他相关情况，快速拉齐与访谈对象的思路基线。但要注意：针对不同类型的对象介绍的侧重点应有所不同。管理类重点介绍全局的、宏观、整体性的目标和架构；业务类对象重点介绍业务相关的背景、行业发展情况等；技术类对象重点介绍目前了解的客户系统的现状、本项目的期望、业界相关应用及发展趋势等等。

5. 访谈内容在议程等大框架方面宜统一规范，而在具体交谈内容等细节方面则尽量发散。交谈过程以发散为主，引导为辅。如果被访谈对象对访谈内容熟悉，且有一定准备，能够主动、系统、清晰的交流，则尽量以被访谈者发言为主。因为，从访谈对象不经意的一些细节描述信息中，可能发现很有价值的重要信息(如果引导式交流则往往容易限制被访谈者思路，造成一问一答的局面)；当客户谈到意料之外的重要信息时，要抓住时机主动深入挖掘，充分收集这些在前期准备阶段未考虑到的需求。如果被访谈对象交流内容匮乏，不知从何谈起，则需要系统化的引导，此时一问一答胜过无话可说。

6. 访谈过程中的快速、准确的、原原本本的笔录非常重要。好记性不如烂笔头，将客户访谈时说的尽可能完整的记录下来，并且务必使原原本本的记录，不要增加任何的个人理解。对需求的理解、整理应该是访谈之后的结合全局的需求进行综合分析和全面理解工作。需求分析的最后环节一般会对分析结果进行印证，而印证的唯一证据就来自访谈记录，此时客户访谈时原始的记录就非常、非常、非常重要。如果缺乏原始的访谈记录作为素材，在后续的需求分析结果有可能偏离客户的实际需求，对项目整体工作的都会造成不利影响。

7. 对于多人参与访谈一个被访对象时，访谈提问建议分工明确、各司其职。可以以一个人为主，其他人补充；或者每个人有其他的分工方式，例如有人负责业务需求部分、有人负责技术部分、有人负责管理部分等等。

8. 记录笔记时要主次分明，记录者与提问者保持默契。若多人同时参与访谈，在记录笔记时尽量多人同时记录。并且，提问者在提问时一般不宜做详细的记录，此刻辅助者升级为是主要的记录者，让提问者有足够的思路时间，考虑问题、理解客户描述的内容、及时发现疑虑当面澄清等等。

9. 对于访谈内容的疑问、顾虑应尽量做到当面澄清，减少事后增补，杜绝二次访谈。一次成功的访谈，能有效降低思维切换成本，确保交流双方在特定场景下思维的严密性、完整性，从而确保需求访谈质量。如果在访谈的自己担心没有准确理解被访谈者的意图，尽量当面沟通、澄清；事后一般是需求确认、证实性工作，而需求的增补、或者重新调研时，被访谈者的思维往往不如正式访谈那样完善和严密，容易对项目造成误导和偏见。

10. 在交流完被访谈对象所属专业的内容之后，尝试引导客户进行跨专业的需求交流。例如：访谈管理层时，可针对本项目需求和目标，探讨管理层对业务部门、技术部门等有何要求和建议；访谈业务部门时，可引导被访谈者根据项目需求提出对管理部门、技术部门的要求和建议；访谈技术部门时，可与被访谈者沟通从技术实现和项目建设、管理的角度，建议管理部门如何规范管理、业务流程制定，既利于系统建设维护，又利于项目实施。

 

【但要注意，需求访谈阶段，需求信息收集基本原则是尽可能充分、完整；如果需求收集不充分，开发的软件产品不能满足用户需求的可能性就越大。但需求是否超出本期系统建设范围、本期商务合同功能需求范围，是另外一个层面的问题。需求访谈时，被访者提出的需求超出范围的情况在所难免，这方面，将在后续的文章中专门阐述】