从接触G端产品到现在刚好1个月的时间，在这段时间主要的工作内容是学习。学习甲方提供的资料，提炼业务以及业务需求，跟随业务专家学习如何政务部门的业务进行初步的业务调研（以下简称“初调”）。这篇文章主要是讲的是笔者对这一个月的工作的一个复盘。
研读资料
资料不多就一个需求文档，文档内容很丰富，包含有：各业务模块的业务说明，办理该业务的业务流程图（没有按照角色绘制的泳道图），子系统功能需求说明。
仔细的研读资料后，有一下几点是可以确定的：
业务明确，总共有十几个业务模块，每个业务模块的业务都有说明，业务边界也挺清晰的，因为涉及到的业务相差还是挺大的，边界区分很清楚。
业务流程明确，虽然还未细化到角色上，但是也知道到每项业务需要经过几步，每一步需要做什么。
组织架构相对明确，之所以说是相对明确，是因为还没有细化到科室中的人员角色上，只是有一个大的组织结构。具体的每个业务部门有哪些角色还需要通过调研才知道。
不确定的点也有很多，简要罗列一些：
业务模块比较清楚了，还需要细化，细化可供角色参与的程度；
细化到科室角色的完整组织架构，以及对应角色的业务；
泳道流程图，由哪些角色分先后完成哪一步，然后最终把业务完成；
文档是由一个人写的，他的描述是否与真实的用户一致呢：
文档的需求他们是否与真正的业务员调研过，这个没法确定；
领导的想法是怎么样，是否有遗漏；
……
初调
1. 初调需要达到的目标
2. 初调的方式
我们初调的方式很原始很粗狂，其实就是业务专家直接带我们就去了要调研的科室，然后就采用疑问——回答的方式进行沟通，将疑惑点记录下来。也许是因为我不懂业务，始终认为这些专家提问很随意，没有逻辑先后，然后提的问题有时候感觉不是平台建设需要的问题。
总结： 没有调研大纲，提问没有逻辑现有，想到什么说什么。
建议：
3. 调研文档整理
从调研达到的目标来反推一下，调研文档应该包含哪些内容。
