从接触G端产品到现在刚好1个月的时间，在这段时间主要的工作内容是学习。学习甲方提供的资料，提炼业务以及业务需求，跟随业务专家学习如何政务部门的业务进行初步的业务调研（以下简称“初调”）。这篇文章主要是讲的是笔者对这一个月的工作的一个复盘。

研读资料

资料不多就一个需求文档，文档内容很丰富，包含有：各业务模块的业务说明，办理该业务的业务流程图（没有按照角色绘制的泳道图），子系统功能需求说明。

仔细的研读资料后，有一下几点是可以确定的：

1. 业务明确，总共有十几个业务模块，每个业务模块的业务都有说明，业务边界也挺清晰的，因为涉及到的业务相差还是挺大的，边界区分很清楚。
2. 业务流程明确，虽然还未细化到角色上，但是也知道到每项业务需要经过几步，每一步需要做什么。
3. 组织架构相对明确，之所以说是相对明确，是因为还没有细化到科室中的人员角色上，只是有一个大的组织结构。具体的每个业务部门有哪些角色还需要通过调研才知道。

不确定的点也有很多，简要罗列一些：

1. 业务模块比较清楚了，还需要细化，细化可供角色参与的程度；
2. 细化到科室角色的完整组织架构，以及对应角色的业务；
3. 泳道流程图，由哪些角色分先后完成哪一步，然后最终把业务完成；
4. 文档是由一个人写的，他的描述是否与真实的用户一致呢：
5. 文档的需求他们是否与真正的业务员调研过，这个没法确定；
6. 领导的想法是怎么样，是否有遗漏；
7. ……

初调

1. 初调需要达到的目标

• 真实需求：深入一线业务员，面对面沟通需求，真实体验他们的工作场景，了解他们的真实需求；
• 组织架构：通过初调完成完整的组织架构图，细化到一线业务员角色；
• 角色流程图：通过初调要摸清他们的在业务模块中是在第几个步骤，扮演的时什么角色，做什么样的操作；
• 现状：他们是否有现成的系统支撑他们的业务，如果有，调研清楚他们的使用情况，如果条件允许还可以直接上手操作体验一下，拍照回来详细分析，也需要调研清楚他们对现有系统的不满意的地方是哪些，回头加以分析，避免我们自己设计的踩同样的坑；
• 集成系统：政务产品，涉及的业务非常广，涉及的科室也很多，因此经常会有某个业务部门会有自己的业务支撑系统，而且还是运行的比较好，使用体验都很好的那种。在这种情况下，就不需要再开发一个系统来支撑业务了，只需要集成到平台。这样的情况下，初调的时候需要了解清楚现有系统的情况，需要做哪些数据的接入准备等；
• 工作场景：我们平常接触到的政务部门有些是在大厅窗口，有些是由独立办公室，有些是在大办公室，有些又是在室外工作，不同的工作场景会影响用户的操作体验；
• 领导的想法：政务产品领导的想法特别重要，直接影响产品最终的验收。

2. 初调的方式

我们初调的方式很原始很粗狂，其实就是业务专家直接带我们就去了要调研的科室，然后就采用疑问——回答的方式进行沟通，将疑惑点记录下来。也许是因为我不懂业务，始终认为这些专家提问很随意，没有逻辑先后，然后提的问题有时候感觉不是平台建设需要的问题。

总结：没有调研大纲，提问没有逻辑现有，想到什么说什么。

建议：

• 在还未进行调研之前，应业务以及科室两条线分开了解详情。从业务上要知道总体涉及到哪些业务，各业务划分到哪些科室。从科室角度出发，各科室涉及哪些业务（至于科室具体负责业务的哪一个环节需要通过调研落实）。
• 进行业务调研之前应该编写调研大纲，将系统建设过程中可能涉及到的点以及针对需求文档不清楚的地方按照一定的逻辑顺序写清楚，并打印出来。做到有针对性的提问，而不是凭经验无逻辑现有的提问。这样也会避免漏掉一些关键问题。

3. 调研文档整理

从调研达到的目标来反推一下，调研文档应该包含哪些内容。

• 调研基本信息交代：时间、调研对象、调研业务主体、参与调研的人员；
• 需求梳理：按照业务的流程的先后顺序梳理出调研对象参与的是哪一个环节的业务，信息系统解决的哪项业务需求；他们对信息信息系统的交互需求有哪些；
• 流程梳理：完整的泳道角色流程图；
• 现状：现在是否有信息系统支撑业务；使用情况；对现有系统不满意的地方；
• 新需求：在需求文档中未提及的需求；
• 解决方案：针对业务需求和新需求，我们标准化产品是否有相应的解决方案；针对差异点（与现有系统匹配度不高）的改造方案；新需求（现有产品没有与之匹配的功能）的解决方案；
• 风险点：针对差异点，新需求的风险在那里，需要向领导交代清楚，方便领导与甲方谈判。

本文由@啤酒配咖啡 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unspalsh, 基于CC0协议