作为G端产品经理，在展开需求调研的时候需要注意些什么以及相关步骤如何？本文进行了相关总结，希望对你有所帮助。

一、背景

本指南，基于数字政府建设的要求和趋势，从多个角度阐述数字政府建设的行业经验和方式方法，包含涵义篇、体系篇、建设篇、经验篇等内容,供各位想从事了解或者已经从事政务行业的人士参考。

本篇为经验篇的其中一个章节，错误或不完善的地方，还请指正。

项目调研，是做好信息化项目建设中非常关键的一环。对于供应商而言，越充分的调研分析越能提升客户的信任度、满意度以及产品的质量和价值。

项目调研分售前调研和需求调研，售前调研聚焦于立项前的调研工作，需求调研聚焦于实施前后的调研工作。本文主要讲述需求调研。

二、项目调研

1. 需求调研

需求调研，也称为实施调研，通常是在项目实施过程中，对项目的实际需求以及产品落地进行深入了解和分析的过程。

关于需求调研原则，笔者总结如下：

• 复用性原则。一个好的项目，通常会在前期的方案调研工作中为项目打好了基础。因此，在进行需求调研之前，可以通过和前期的方案调研人员沟通以及查阅建设方案等方式，提前了解和熟悉项目内容，梳理需求调研方案。
• 可控性原则。需求调研并不是毫无目的，一定是基于合同建设内容范围内容的模块进行相关细节方面的调研，控制好项目的建设边界，具备成本意识，尽量避免项目验收时合同建设内容和实际落地需求差异太大的情况。
• 主动性原则。要打有准备的仗，需求调研前，一定要先准备好调研提纲或者问题清单，主动和客户确认调研的时间、地点、人数等信息，必要时提前思考客户在调研过程中会重点关注的问题或者想要借鉴的内容并做好准备。
• 精确性原则。需求调研一定要有针对性和逻辑性，并不是让客户越发散越好。发散的需求不是我们和客户的狂欢，是为团队埋坑，完整且准确的需求才是调研的价值。因此，需求调研时要集中精力，具备需求边界意识，随时引导客户回到调研主题。
• 变通性原则。不同客户类型的性格和做事风格是不一样的，要根据不同客户类型的特征应对需求调研中提出的需求或建议，避免无效沟通。

关于需求调研方式，笔者总结如下：

• 用户访谈。是最常用也是最直接的调研方式，适用于在客户现场的小范围需求确认。如果是和客户首次访谈，需要简单地交代下本次调研的背景和目的，便于客户确认当前调研的对象是否合适以及方便接下来调研工作的顺利进行；当和客户有一定的熟悉度时，每次访谈可直接切入主题，讲究调研效率，快速确认内容。
• 问卷调查。适用于大范围需求方向的确认，目的类似于互联网应用中的A/B测试，判断哪一种需求设计更好。也会用于收集用户使用意见，以便于为接下来的产品提升提供改进方向。
• 公函征询。是一种正式的、官方的调研方式，适用于项目主导单位对各业务单位征求需求建议、意见的场景。各业务单位需在规定的时间内反馈需求，并提供联系方式。该方式调研的内容，具有一定的权威性和可信度。但也正因为它的正式性，出于政府的严谨性考虑，被征询对象并不会全方位的提出需求建议。
• 电话微信。作为一种交流沟通工具，电话和微信（或其他即时通讯工具）是最便捷的调研方式，可根据调研事项的紧急性选择，微信（或其他即时通讯工具）交流优先。
• 场景参演。是一种直观的调研方式，通常是直接参与到业务人员的工作中，观察和记录用户的业务场景，挖掘用户的实际需求，为产品的建设和改进提供支撑。
• 在线会议。是一种新颖的调研方式，适用于各方人员不方便到现场参会调研的场景。
• 资料查询。是一种实用的调研方式，可以通过行业公众号、行业网站、行业标准、法律法规、论文期刊、专业书籍、单位内部材料等多种方式获取调研需求。

关于需求调研过程，笔者总结如下：

调研工作动员会。正式启动调研工作之前，通常由项目主导单位组织召开调研工作动员会议，会议需要邀请各相关方领导成员和业务工作人员参与，并在会议中明确项目背景、工作思路、工作计划以及调研内容，确认各方对接人，建立沟通途径（拉沟通群等）。并非所有的项目都会召开动员会，部分项目会将项目启动会和工作动员会一并召开。

识别调研对象。政府项目中，不同部门、人员之间的职责关系、等级关系是比较清晰的，每个对接人代表的角色和关系都有所不同。

因此，在进行需求调研时，要识别调研对象的定位，即判断对接人是处于哪一个角色的代表（决策？管理？执行？），明确对接人是否为真正的需求调研对象（即真实用户）；其次，要识别调研对象的做事风格，不同做事风格的客户也有不同的应对策略。

• 强势型客户，这类客户通常有自己的主见，可能会提出一些超出我们认知或者理解的需求。应对这类客户，要给予足够尊重的同时，要体现自己的专业和自信，过程中尽量少用到代表“不确定”的词语，论事必须有理有据，讲事实、讲数据、讲案例，若有不明确的点，先记录下来，事后充分研究分析后再拿出来讨论沟通。
• 温和型客户，这类客户容易沟通，但不代表可以随意沟通，每一次的调研都要做足准备，充分沟通，尽量一次性把所有疑问和细节都确认好，达成共识。
• 随意型客户，这类客户通常对项目不大上心，甚至有抵触心理。应对这类客户，一方面是借助局方领导的力量推动工作的进行，另一方面是靠自己尽可能详细全面地输出调研内容，仅让客户点个头确认即可。

当然，如果可以避开的话，最好申请换个调研对象。

学会借助工具。调研的表达方式并不只是局限于口头的交流，可根据不同的调研场景选择不同的工具。

比如：正式的调研会议中，可采用PPT的方式汇报；讨论框架、层级等全局性内容设计时，可采用思维导图的方式确认；讨论具体实现效果时，可采用原型或者高保真的方式确认。

调研过程中，特别是节奏较快且需要自己主持的调研会议，由于需要全程专注，很难抽出其他的精力记录调研，一般搭配一个记录的队友或者使用录音帮助自己记录。

学会需求博弈。

一方面，是避免“错误的正确”，即被牵着鼻子走。需求调研过程中，当客户侃侃而谈时，很容易出现自我迷失的现象，调研看似进展的很顺利，同时也记录了很多内容，但是回过头仔细分析，发现全是发散性或者表面性的需求，根本不具备落地参考价值；同样地，当我们汇报调研内容时，若客户并没有反馈任何建议时，也容易出现调研无效的情况，因为这个客户的建议可能仅仅只是一个参考，并非是决策性的建议。

另一方面， 是避免全盘接受，规避不合理或者很难实现的需求。

拒绝是一种艺术，尽量不要直接和客户对立，要以客户的角度思考问题的出发点并提供解决建议。若当下无法提供有效的沟通回复，可以采用迂回的方式处理需求。即：先接收需求，延缓答复周期，不定时提供处理反馈或者选择性忘记。切忌当下答应不合理或很难实现的需求并提供具体的方案解决时间。

调研记录留痕。调研结束后，要及时整理调研的内容，输出调研报告，发送至双方约定的沟通渠道中（邮箱、沟通群等），必要时还可以找客户签字确认，作为未来实施和验收的依据，避免出现扯皮现象。若存在进一步确认的问题，在报告中写明并及时约客户沟通确认。

有自己的风格。客户有风格，作为承接方也需要有自己的处事风格。真诚永远是必杀技，因此对客户真诚、对项目真诚，能够一定程度上获得客户的信任。做事可靠、信守承诺也是一种处事风格，客户非常喜欢这类承接方，有时还会给予一定的决策授权。

专业性也是客户比较看重的点，专业的承建方，不仅能主导调研，还能够为客户提供业务优化建议，非常有利于项目的顺利进行。总的来说，找到适合自己的方法，给客户留下专属于你的印象，会有利于工作的开展。

关于需求调研内容，笔者总结如下：

需求调研内容，在讲述实施调研时有提到一部分，由于并不是所有的项目都有完备的实施调研过程，因此，在此处对需求调研内容做一个全面性地总结阐述。

客户基本情况。

一是了解组织结构，组织机构的设置能够体现职能定位和工作分工，帮助我们快速了解和区分不同的调研方向；

二是区分干系人的角色，一个是干系人的岗位职级，另一个是干系人的项目层级，不同角色的调研侧重点有所不同。

三是了解客户对项目的期望值，客户的期望主要分为积极型、消极型和务实型。

• 积极型的客户，除了调研基础的需求设计方案以外，还可以发散性的提出一些创新点或亮点，为项目增添光彩；
• 消极型的客户，可借助考核的压力主动推进调研工作，多多向上级汇报项目调研进展，避免项目压力全部都在承建方；务实型的客户，言简意赅，切入主题，避免加入其他无关联的内容，以客户的习惯为准。

项目背景情况。一是了解项目的建设类型，是属于新建的项目还是优化提升的项目，是属于建设类项目还是运营运维服务类的项目；二是了解项目核心解决的问题，通过问题洞察项目希望达成的目标；三是了解项目建设的计划，比如建设周期、关键节点、项目预算等内容。

信息化建设情况。

一是系统建设情况调研，梳理客户自建信息化系统和其他信息化系统的情况。系统内容具体包含系统名称、系统状态（规划中、建设中、已建设等）、系统概述、使用情况、部署类型（国垂、省垂、市级等）。

二是单位网络情况调研，包含单位网络拓扑图、系统运行网络分布、政务外网接入情况等。三是服务集成情况，即梳理项目需要对接的系统（如国家系统、省级系统等）或能力（如电子签名、身份认证、电子证照等）。

资源使用情况。提前梳理项目建设所需的服务资源信息，尽早确认并提交资源申请单，避免耽误项目进度。

业务基本情况。

一是梳理业务框架，厘清项目存在哪些业务模块以及不同业务之间的从属关系等。

以智慧执法为例，通过公众号（行政执法研究，市场律法谈）、政策法规（《行政处罚法》，《行政强制法》，《三项制度》）、专业书籍（《中华人民共和国行政处罚法理解与适用》）、调研分析等途径，梳理得出智慧执法的业务架构包含行政执法主体、执法机构、人员、依据、行政相对人、事前业务、事中业务、事后业务、监督业务以及其他业务，每个业务模块包含多个细分板块，如执法机构业务模块包含内设机构、派出机构以及下属事业单位板块。

二是梳理业务流程，厘清每个业务是如何流转的，涉及哪些信息要素。以智慧执法的行政处罚业务为例，通过公开门户、内部文件、报告研究、调研分析等途径，梳理得出行政处罚普通程序的业务流程为立案→调查取证→告知权利→法制审核与集体讨论→决定→送达、公示→执行→结案。

每一个环节都有特定的流转文件（文书为主）、用户角色、流转逻辑等内容，如《行政处罚法》第二十九条规定：对当事人的同一个违法行为，不得给予两次以上罚款的行政处罚。同一个违法行为违反多个法律规范应当给予罚款处罚的，按照罚款数额高的规定处罚。针对同一个违法行为，系统上就需要做一些限制，提示用户该行为已有处罚，避免重复处罚的现象。

三是梳理数据架构，主要是梳理产品信息架构图和各数据之间的输入输出关系。

以智慧执法为例，参考司法部最新发布的行业标准文件《行政执法综合管理监 督信息系统数据元和代码集》，梳理得出共有四大类数据元，分别为组织机构类、人员类、事项清单类和执法行为类，每个大类含有小类数据元，如人员类数据元包含执法人员数据元和监督人员数据元，每个数据元都有具体的信息项及要求。除了内部的数据源之外，还需要考虑向外部输送数据和从外部获取数据这两大数据交换场景，明确外部数据来源、数据内容、对接环境、对接方式、更新方式等内容。

四是梳理用户角色，厘清产品的使用角色有哪些，具备什么属性。以智慧执法为例，角色主要包含公众，行政相对人（也称为执法对象，包含公民、法人及其他组织），执法人员（也称为办案人员），监督人员，领导（包含科（处）室、局、厅、市等层级领导，负责监管、指导、审批和分析案件）。值得一提的是，政务客户的使用角色，属性跨度可能很大。因此，产品尽量采用通用性设计，即不同环境、不同能力的用户都可以使用。

五是梳理产品架构，根据项目方案和调研需求等内容的梳理，罗列产品模块。

以智慧执法为例，产品架构包含展示层（PC端、移动端、小程序…），应用层（公示应用、办案应用、监督应用、分析应用…），支撑层（权限、用户、电子证照、电子签名…），数据层（法规库、事项库、人员库…），基础层（云服务、政务网络…）。根据产品架构，进一步梳理功能结构，细分功能模块，制定产品路线，逐步完成产品的上线。

总的来说，政务项目切忌操之过急，要把握好节奏，厘清各阶段所需内容，做好项目调研，才能更好地保障产品的质量，获得客户的认可，助力项目顺利验收。