【PM】【需求】项目管理-需求：业务需求调研经验分享

在平常需求分析阶段你们以哪些方式与客户进行交流 和反馈
      最常见的一个办法就是合同约定，将客户需要的功能以白纸黑字的形式描述在纸上，这种情况下客户对将来交付的产品仅仅限于我们的描述，不过一旦客户签字之后 即使客户发现最终交付的产品与自己所期望的产品不一致也不能有什么办法，毕竟这些都在白纸黑字上写明了并且客户签字确认了的。这样做的坏处是这次可能会交付成功（哑巴吃黄连），但是客户与公司之间不会再有下次合作机会了。（这正是我想说的，客户尤其是不是领导的客户，他没那么傻，他只管说，自己不会签字，让你找领导签字）
      在实际中我们还用过一种办法，那就是界面原型法。对于网站，那就是设计一套静态页面形成的网站，客户可以通过我方人员的演示看到各个页面之间如何跳转及每 个页面的功能；对于软件，也是设计出各个界面，客户可以通过演示看出各个界面之间如何交互及每个界面的功能。通过原型法，客户可以直观感受将来交付的产品 是什么样子的，避免仅通过语言交流而带来的理解误差。一般情况下我都是采用这种发发和客户交流的。（成本较高）
在客户不能描述自己期望的产品的情况下， 你应该如何和客户进行交流和反馈
      在有些情况下我们会遇到一些客户，他们很希望借组软件来改变目前落后的操作和管理方式，但是客户也无法用语言来描述自己所期望的产品的功能和样子，这种情 况下我们该怎么做呢？
      首先看市面上是否有类似于客户所需要的产品，如果有，可以借鉴这些产品并结合我们的理解做出界面原型来与客户进行进一步的交流（朋友说我这样有抄袭的嫌 疑，呵呵）。
      如果不使用上面的方式，那我们还可以采用引导的方式和客户交流。通过对客户的引导，可以进一步发掘需求，并且将客户的一些不太合理的要求化解，使我们能在尽量满足客户 要求的基础上开发出比较理想的产品。
      事实上针对软件的开发和管理有很多办法，我们不能实际也不可能纸上谈兵式对这些问题进行阐述。就像 在数据库设计时我们可以尽可能遵循一些范式，但是并不是满足了这些范式的系统就是一个好的系统，我们也不是一定要满足所有的范式，我们可以结合具体情况进 行分析，最终我们的产品是一个在各种因素影响之下的产品。

 如何做好需求调研准备工作？

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

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

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

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

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

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

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

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

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

10. 在交流完被访谈对象所属专业的内容之后，尝试引导客户进行跨专业的需求交流。例如：访谈管理层时，可针对本项目需求和目标，探讨管理层对业务部门、技术部门等有何要求和建议；访谈业务部门时，可引导被访谈者根据项目需求提出对管理部门、技术部门的要求和建议；访谈技术部门时，可与被访谈者沟通从技术实现和项目建设、管理的角度，建议管理部门如何规范管理、业务流程制定，既利于系统建设维护，又利于项目实施。【但要注意，需求访谈阶段，需求信息收集基本原则是尽可能充分、完整；如果需求收集不充分，开发的软件产品不能满足用户需求的可能性就越大。但需求是否超出本期系统建设范围、本期商务合同功能需求范围，是另外一个层面的问题。