业务需求调研

需求调研作为整个项目的地基，影响着项目是否成功，因此科学进行需求调研、充分挖掘业务需求是重中之重。此次，我们推荐以问卷+直接沟通的形式，通过数知鸟工具实现对业务需求的充分挖掘与具体实施，形成项目的全生命周期管理。

1、通过项目自检表梳理项目内容

通过梳理项目关键信息，辅助判断自己对项目价值的了解程度，如果关键信息空白较多，接下来的分层调研需要更具目的性。

2、分层调研并整理调研内容

不同角色的调研对象，对业务的了解深浅、以及视角都有所不同，因此对战略层、业务管理层、业务实施层分别展开调研，支持相关人员自己填写信息、也支持调研者后续整理调研内容。

3、调研内容确认

内容整理完毕，将相关人员添加为参与者，并流转至【提出方确认】状态，提出方确定调研内容无误后，流转至【内容无误】状态，若提出方觉得内容有误流转至【内容有误，重新沟通】状态，重复该流程，直至内容确定无误。

期间调研内容支持变更，并自动记录变更内容，以便复盘及产生争议时回顾；但内容确认完毕后不支持修改调研内容。

4、拆分具体需求并走需求处理流程

调研内容确认后拆分出设计的具体需求，并走需求评估、方案设计、需求处理等流程。

1、明确调研目的与调研形式

调研开始之前，我们首先要明确本次调研的主要目标是什么。通常的调研目标有以下几个：

1、找全关键用户

2、获取关键用户的需求，明确需求场景，以及是否为业务痛点

3、初步验证我们预想的解决方案思路，能否解决实际问题

4、尽可能多的提前识别风险

接下来需要确定调研的形式。由于其他的需求挖掘的方式（比如数据分析、观察法等）对数据质量、时间投入有一定要求，此次我们将基于最常用的问卷+直接沟通的调研方式展开，同时为保证调研内容收集、修改、确认的规范性，与需求转化、评审到处理的过程性，我们推荐用数知鸟需求管理平台承接整个流程。

2、准备进行一场深度沟通

2.1 提前梳理已知信息，初步判断项目风险（附项目自检模板）

通过梳理项目关键信息，可以判断自己对项目的价值是否了解。可以将关键信息梳理成一份项目自检表，如果在项目启动前，可以独立的填写80%以上的信息，说明该项目的价值比较明确，解决思路较为清晰，后续规划以及实施的动作也会更加明确，减少踩坑的可能性。

这里我们提供一份项目自检模板，以供参考，可以根据自己的业务情况酌情调整。

1）项目自检模板样例：（模板获取方式见文末）

2）内容说明：

2.2 准备解决方案思路，解除沟通误区

调研的时候，往往会发现——用户并不知道自己想要什么，所以对需求进行引导是非常关键的一步。由于领导/业务人员与我们的专业背景和知识结构不同，为了更好的传达自己的想法，可以通过demo、案例，甚至手绘草图等形式简洁直观的展现效果，让对方能够跨越专业词汇，快速理解最终效果。

在这个阶段为了更加快速的呈现效果，可以充分利用帆软提供的已有资料：

① 丰富的demo库（http://demo.finereport.com/）

② 各行各业的客户案例（https://www.fanruan.com/cases ）

③ 提供模板下载复用的模板商城（https://market.fanruan.com/template）

2.3 分层准备结构化的调研问题，有针对性的获取有效信息（附不同角色的调研模板）

不同角色的调研对象，对业务的了解深浅、以及视角都有所不同，所以分层调研可以帮助我们更准确的获取关键信息。而提前准备结构化的调研内容，可以避免在调研过程中被业务提出的想法牵着走，业务主导的调研，就会很容易收获五花八门的“解决方案”，却没有挖掘到真正的痛点业务场景。

一般来说，调研对象可以分为：战略层、业务管理层、业务执行层

    1）战略层：老板、高管

    如果需求来自战略层，我们与之沟通可以了解到一些宏观信息：

• 项目需求是谁提出的，便于进一步识别项目干系人，推进项目的顺利落地

• 是基于什么原因提出的项目需求，以便对需求有全局性的了解，在设计规划阶段有一定的灵活性，能最大程度契合未来业务规划

• 整个系统需要实现什么样的效果，达成何种预期。对用户期望进行全面了解，拉通不同关键人之间的预期。

• 是否有已知的同类系统存在，他们在公司或行业内处境如何

    2）业务管理层：财务、人事等业务负责人

    这一层级的人员，能够清楚业务运作情况，同时能从业务全局协助梳理需求，并识别项目风险。我们从该层级人员的访谈中，需要了解以下内容：

• 业务部门的组织结构如何，是否存在频繁变动的可能

• 当前业务中有什么困境，哪些需要此次项目优先解决

• 业务中可能存在哪些风险

• 业务中有哪些关键角色

• 业务平时是如何运作的，每个业务节点，是由哪个岗位角色负责的

• 业务的流转是否需要审批，审批人员是谁

• 是否已经在使用其他的替代产品，在解决当前的业务问题中有什么问题？有什么可取之处？

• 岗位人员变动之后的业务流程、权限、数据等如何处理

    说明：往往正向的业务流程梳理相对容易，项目风险通常隐藏在异常业务之中，所以需要重点关注业务管理层提出的一些问题，对后期划分需求的优先级比较有帮助

    3）业务执行层：

    该层级的人员最为熟悉业务运作细节，但同时对于业务全局缺乏完整认知，所以容易陷入对个性化需求的阐述。我们的需求调研中，针对这类人员需要增加访谈的样本量，避免被影响需求优先级的评估。我们从该层级人员的访谈中，需要了解以下内容：

• 确认执行层岗位的具体人数，合理规划调研的样本量，避免因样本量过少而调研内容有失客观性

• 每个角色在业务中的具体工作内容是什么

• 业务环节开始、流转、完结的标志节点是什么

• 业务处理的发生频次如何

• 执行中业务的难点或者处理起来最麻烦的地方是什么，为什么很难处理

• 过往是否出现过事故，事故原因是什么，后续是如何处理和规避的

• 了解执行人员希望本次项目能解决的实际问题点

• 是否已经在使用其他的替代产品，在解决当前的业务问题中有什么问题？有什么可取之处？

    说明：哪怕是一样的问题，如果角色不同，我们可以获取的信息也会不一样，所以需要我们信息收集上来之后做合理的整体性评估。有条件的情况下，可以多参与、观察实际业务场景下各个角色的工作流程。

调研模板样例：（模板获取方式见文末）

• 战略层调研

• 业务管理层调研

• 业务执行层调研

3、一些需求调研的技巧，让沟通更加顺畅

1）认真仔细倾听，及时记录。可以使用录音辅助记录、后续整理

2）尽量跟业务使用一套语言系统，避免过于技术的专业词汇，适时拿出demo案例或者画草图

3）根据用户类型应对。以下是部分类型，仅提供一些个人应对建议。

①强势型：强势型业务方经常会提一些比较难实现的需求，可以先进行调研收集，后续规划阶段通过整体评估，以及行业案例、过往数据等客观事实等作为佐证

②随和型：随和型业务方比较好沟通，但可能主动性较差，需要关注挖掘到的需求是否为实际业务痛点诉求

③技术小白型：该类业务大概率很难阐述清楚自己的诉求，可以尽量引导还原业务场景，提供原型等方式辅助沟通

④业务专家型：该类业务会很明确提出自己的想法，甚至是系统实现方式。不能止步于他们提出的功能，要挖掘到原始业务场景，有利于后期给出整体实现方案。

注意：警惕用户直接给出的方案，要还原原始业务场景。多考虑：想要什么？要这干什么用？他为什么这么想？会不会有别的想法？

4）宏观需求很重要，但细节需求也很重要，会影响用户是否愿意使用系统

① 宏观需求

• 功能大块：明确用户要通过系统做哪几件事；

• 业务场景：每个功能模块都有哪些业务场景；

② 细节需求

• 使用习惯

• 样式

5）警惕模糊性词汇，比如：我觉得，我估计。这类意见可能成为风险因素，难以明确的可以先进行标注，积累一定样本量后整体性评估

6）注意需求调研的覆盖面，防止需求不具代表性

7）明确业务侧关键对接人，在精不在多，通常确定1-2人，便于需求调研后解决疑问或遗漏问题

8）没有需求如何引导

① 首先，明确业务部门是不是真的没有需求？

往往业务表现出没有需求，都是假象。

大概率没有需求是因为：

1、不了解系统可以实现什么样的效果，不清楚哪里还可以优化

2、不知道新系统学习成本是不是很高，是不是会增加我的工作难度

② 如何引导

1、已经做过的业务场景讲解，各个部门之前有共同之处可以迁移

2、其他外部行业标杆案例宣导，可以复用成功的经验

3、产品知识扫盲，减少业务对使用成本增加的担忧

4、提供官方的demo让业务用户去体验，直接感受产品使用

4、明确调研起止点，避免“反复无常”

需求调研结束后，一定要及时总结整理已经完成的调研内容，通过流程让受访人员进行确认，如果确认流程中有更改或放弃的需求也需及时变更整理好的调研内容，数知鸟自动记录内容变更，以便复盘以及产生争议时回顾，内容确认无误后不支持修改，此后再将调研内容拆成若干个独立的需求，并正式进入需求评估环节。

另外如果出现对接人众多的情况，可能也会导致过程中需求频繁变更的问题，针对这类问题我们复盘原因、并寻找针对性措施：

① 为什么会导致这类问题

大概率是由于：一，对组织架构不熟悉，找不到关键对接人，最后拉群拉了大几十人；二，对接人本身不具备统筹权，频繁因为执行层或上级建议变更需求；三，关键对接人转岗或离职。

② 如何解决

首先需要保证自己对公司组织架构清晰，至少能够准确找到部门决策人。当对接人模糊时，可以及时和负责人沟通落实；

其次要保证关键对接人是否有确认需求的职能和权力，如果需求汇总并不是当前对接人的主要工作时，需要增加业务执行层的调研样本，以避免调研不够客观；

最后如果判断对接人的在岗状态不稳定时（比如只是上级临时安插），此时对于对接人提出的需求，优先级可做适当程度降低。当对接人无法达到对接要求时（不沟通、执行不到位），需要寻找合适时机，和部门负责人进行确认。

在数知鸟中，我们建议将相关人员都列为该需求的参与者，状态变更时自动通知所有参与者，需求内容局部变更时手动通知全部参与者或部分关键参与者，同时也支持参与者自主查看需求内容及需求状态。