编辑导语：如果你是一个新项目的产品经理，你应该从哪些方面着手准备你的工作？在一个项目中，产品经理需要做的工作又有哪些呢？相信这是困扰不少产品经理的问题，尤其是对于新人产品经理而言。本文作者以工单系统为例，为我们对以上问题进行了解答。

当接到一个项目时，自然而然来的一个问题是预估研发时长。

通常产品或项目人员基于自己的经验给出预估时长，但这显然是不合理的。项目刚提出时，由于没有研发团队参与项目立项，这个时候项目一般是一句话需求，不完整的，甚至是不合理的。

而这种“拍脑袋”得出的研发时长会导致后续项目开发中资源和时间不够，最后的结果往往不尽人意。这类问题的核心是项目调研，也就是在项目开始前如何尽可能收集多且有效的信息，辅助需求分析，预估研发时间。

本篇文章以工单系统为例，说明需求调研要收集的信息，如何处理信息以及最后得到的结果，辅助给出预估的研发时长。

一、收集信息

1. 定义问题

正确定义问题就是解决问题一半，这句话可以看出定义问题的重要性，同时也说明定义问题具有一定的难度。善用方法可以事半功倍，接下来介绍两种常见的方法。

1）转化

转化是指将未知的问题与已知的问题建立联系，在这里特指将未实现的需求引导到已有的功能上。

业务人员提需求的时候都会提出一种解决方式，这自然是一个新功能，但是如果仔细分析会发现往往已有功能就可以实现业务人员的需求。这就是转化，产品人员做好需求分析工作，将业务人员的需求转化为已有功能，避免增加无谓的工作量。

2）本源

问题的本质往往掩盖在众多表象之下，只有拨开表象才能定义出真正的问题。

2. 寻找原因

在定义问题之后要寻找对应的原因，不但要关注原因还要关注各个原因所占比重，使用鱼骨图和帕累托分析法可以得出以上内容，下面具体介绍鱼骨图和帕累托分析法：

1）鱼骨图

鱼骨图又叫因果图，是一种探寻问题的“根本原因”的分析方法。

鱼骨图实例

绘制鱼骨图的步骤如下：

1. 在鱼头位置标注待解决的问题；
2. 在鱼骨位置标注可能的原因分类；
3. 在鱼刺位置标注可能的具体原因；

需要注意的是，在寻找原因类和具体原因时，要头脑风暴尽可能多地寻找原因类和具体原因。

鱼骨图本质上是定性分析方法，好处是可以尽可能多找到可能的原因，缺点是不知道原因的重要程度，帕累托分析法正好可以解决这个问题。

2）帕累托分析

帕累托图又叫排列图、主次图，是按照发生频率大小顺序绘制的直方图，表示有多少结果是由已确认类型或范畴的原因所造成，是一种定量分析方法。

帕累托分析

如上所示，帕累托分析法的步骤如下：

1. 列出解决问题的原因；
2. 计算每个原因的频率；
3. 以原因为横坐标，以频数，频率作为左右纵坐标分别绘制直方图和折线图；

帕累托分析直观地给出了因素对结果的影响程度大小，针对性采取措施，提高效率降低成本。

3. 人员访谈

需求是有层次的，单独对个人或某类人进行访谈无法得到完整需求，必须要梳理完整的用户群并做针对性访谈。

一种常见的做法是对系统的利益相关者做用户分层，然后针对性做访谈。比如可以把系统的利益相关者分为公司高管，业务管理，一线作业人员，支持人员，合作伙伴，针对分层用户建模分析，为下一步的功能设计做好准备。

4. 确定边界

用于实现系统的资源总是有限的，系统的功能也是有限的，系统能覆盖的范围自然而然也是有限的。如何定义合适的系统范围是调研阶段重要的内容之一。

比如在工单系统中，是自研客户管理系统还是接入外部CRM系统。像这种问题要结合目的和实际情况去思考。我们服务的都是本地客户，没有强竞品公司，而且也没有专业的销售团队；同时预算不充足。

基于以上原因决定暂时不外接专业的CRM系统，只是在系统内部做一个简单的客户管理系统。

5. 常见约束

常见约束是指技术，使用环境，预算，政策等要求。

很多非功能性约束往往会对产品有更大的影响，收集更广泛需求，避免遗漏需求。比如打车软件司机端主要是在行进中的汽车使用，金融类软件需要遵守相关法规。

二、梳理信息

1. 定下目标

好的目标要符合SMART原则，具体来说是目标必须是具体的，可衡量的，可达到的，和其他目标具有相关性，截止时间是确定的。要想清晰地定义目标，原因分析工作必须做好，也就是鱼骨图分析和帕累托要认真对待。

2. 功能拆分

在功能调研期间，功能拆分是为了后续的需求实现分析准备调研主题。

传统的拆分方式按实体拆分，比如将交易系统拆分为商品模块，订单模块，客户模块等。按实体拆分最大的问题是拆解出来的单个功能模块或系统会有多个业务人员参与，由多条业务流程组成。

调研单个功能模块或系统还要调研多种岗位人员，这不但会加大调研工作难度，也为后续的功能实现埋下隐患。

传统划分方式

上述是常见交易系统的传统功能模块划分方法，虽然很好理解，但是产品人员在调研订单模块如何实现时，要同时调研商品管理或客户管理模块的相关内容，这导致重复的工作量，更推荐的方法是按“流程”进行功能划分。

流程划分

如果产品人员按此功能拆解图去调研，那么重复访谈的现象将大大减少。由于单个功能模块不在有多个业务角色参与，也没有交叉业务流程，避免发生了调研时要重复调研多位业务人员的情况，大大降低调研复杂度和工作量。

3. 用户列表

系统的用户往往不是单一的，复杂系统甚至会有十几种用户角色。这一步中需要梳理系统的用户列表，用户列表结合功能模块列表就可以梳理出业务事件列表。

梳理用户列表最重要的是不重复不遗漏，可以先将用户划分为外部用户、内部用户、管理层用户、时间和效果：

• 外部用户是指用户使用系统解决自己问题的角色；
• 内部用户是协调系统或承担一部分系统信息处理的角色；
• 管理层用户关注系统使用效果；
• 时间是指到达特定时间会触发的事件，比如定时器；
• 效果是指到达特定效果会触发的事件，比如实体的状态。

需要注意的是，以上事件是业务事件，系统还有一部分重要事件是系统事件，比如数据安全、修改密码等，要区分看待。

4. 业务事件列表

业务事件列表是系统的目标功能，梳理正确的业务事件列表有助于正确预估产品的研发量以及研发时间。结合功能拆分和用户列表可以梳理业务事件列表，具体做法如下：

1. 用“黑河”视角看待拆分出来的功能模块；
2. 将用户列表中的用户与“黑盒”进行连接；
3. 梳理用户与“黑盒”的完整交互，进而梳理出业务事件；

5. 业务报表列表

根据业务事件可以梳理出业务报表，如果你对业务比较熟悉的话，这个过程可以迅速完成。报表是系统的重要组成部分。梳理完业务报表后相当于完成了大部分的系统功能设计，报表如何快速实现就不在这篇文章中说明了。

三、总结

文章简单梳理了项目调研要收集的信息和产出的内容。项目调研的内容一定程度上决定了项目的实施成本，所以要尽可能在立项时完成，这样才能给出合适的项目资源。

但是由于项目立项大多是管理层决定，缺少执行层参与，执行层在接到项目时必须尽可能详细调研，收集信息，评估成本，如果资源不够，需要申请资源或调整预期功能，这样才能保证项目能够准时完成。

相反的，如果接到项目就开始需求分析，研发等工作，等到临近验收才发现项目实现遥遥无期，那么只能自己背上这个锅了。

作者：宝宝心里苦啊；公众号：宝宝心里苦啊

本文由 @宝宝心里苦啊 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。