产品方法论之需求挖掘员工计件小功能原来也不简单？

身边总有同事问，你每天怎么有那么多问题，大概是常常用到5Why法吧。

恰好最近打算做些输出，本日就结合日常事情，分享下自己平时如何做需求挖掘。
这个也是产品日常事情、求职高频问题了，希望对看到文章的你有所帮助。
全文篇幅2000字旁边~

产品日常事情都是环绕需求展开的，从需求网络、需求挖掘与剖析、需求方案、优先级排序、需求设计、需求评审、需求开拓、测试到终极产品上线，一个完全的产品生命周期，需求贯穿始终。
前期的需求挖掘与剖析至关主要，可以说需求挖掘剖析如果错了，全体产品会错的离谱、很难挽救。

挖掘用户需求：自己平时紧张是需求调研＋5Why法来结合进行。
至于需求调研，理解用户在什么场景，想办理什么问题，现在碰着的问题和难点，现有办理方案等。
所谓5Why剖析法，又称”5问法”。
最早由丰田汽车创始人父亲——丰田佐吉提出，在丰田汽车制造方法学得到运用，也是常见是问题求解方法，并且在丰田之外也得到了广泛采取，紧张用于根本缘故原由深挖。

在实际挖掘需求事情中，我紧张环绕这6步进行：识别确认需求、需求现状理解、需求分解、查找要点、把握需求边界、需求缘故原由目的理解、需求办理方案。
结合之前做服装供应链SAAS系统一个小功能进行展开。

一、识别确认需求：明确需求及提出方

公司的种子客户，XX服装厂老板提出员工计件功能需求，希望办理给员工发人为需求。

这里特殊把稳：不论需求大小，所有需求都要明确到详细提出人，而不是转述方。
需求池日常掩护中，须要直接记录详细需求提出人。
才能深入调研、挖掘需求，纵然低级产品、产品助理，都要把稳这点，当然这一步需求还是很粗糙的。

二、需求现状理解：业务现状，如何运转，碰着的问题、难点

这里通过一个业务流程图来大略表示，理解到梭织面料生产流程（此处只截取裁剪开始的部分流程）。

这一步通过需求提出方可以初步理解，在后期需求沟通时会逐步细化。

三、需求分解、查找要点

拆分需求，梳理调研大纲，查找要点。
我一样平常从需求涉及的角色/业务方出发，梳理对应业务问题，带着问题去理解需求和业务。
显然这里涉及的角色有：工厂老板/生产卖力人、财务、详细业务职员（流水线工人/小组长/主管）。

业务问题可以通过线上线下理解行业知识、借鉴精良办理方案、结合自己理解等，通过头脑风暴的办法进行思维发散。
对应到员工计件，显然须要理解服装生产流程、MES系统常见地决方案，行业家当都要进行理解。

不推举上来就贴脸开大直接沟通，业务方自己讲述，很随意马虎遗漏关键信息、揪着一个点跑偏等，自己很难对问题延伸、思路被带走。
最好带着梳理好的问题去沟通，先勾引业务方自己讲述，再根据调研大纲做针对性补充提问。

四、把握需求边界

需求现状理解、需求分解查找要点、把握需求边界，这3步实际操作中基本结合进行。
涉及隐私，根据员工计件需求大略写了一些调研问题供参考，自己整理只需列出问题即可，沟通完成后对沟通结果做记录。
问题目的可以帮助自己，在业务方理解无法理解问题时，进行问题纵深追问。
此处实在还要往业务前后延伸，像服装行业，条码天生、打印就考虑到跟裁床单结合了，篇幅有限不再赘述。

五、需求缘故原由、目的理解

通过前边反复沟通确认，需求缘故原由、目的实在基本摸透了，只要把调研大纲的沟通记录进行补充提炼。
偷个

六、需求办理方案

在这一步，我一样平常会先梳理出业务流程图，需求办理方案，实际的功能点解释等。
这一步完成后，会根据实际情形做需求内评（这里根据实际可能是跟CTO、客户等），再之后才是原型设计，PRD输出。

1、需求办理方案

这个一样平常都是思维导图去梳理，涉及隐私这里把自己做过的多个别系糅杂在一起来贴图了，结合员工计件大略写了一个方案参考。

a、员工计件办理方案

初阶：只是系统上大略做申报请示计数中阶：扫码单件计件高阶：扫包码计件、合格/不合格数审核、除了业务功能

关联功能有员工计数统计，计件人为打算，订单生产进度统计等

b、扫码方案：哪个环节天生条码，哪个环节贴条码，如何贴条码

2、扫码方案：条码须要包含什么信息

通过需求调研、流程梳理，创造员工计件这个功能，计数只是最根本的需求，还涉及到质检，以是会有合格/不合格数延伸。
不同工序须要技能、加工韶光、繁芜程度等不一致，以是工价不同，此处理解的信息，便是工序后期可扩展延伸的属性信息。
结合统计干系需求，条码须要包含产品规格信息、加工韶光等。

3、功能点解释示例

涉及隐私，附图其他的系统功能点解释。
这里除了表格，有时候也会用例图形式展现

用例图展现形式：

这里输出的需求办理方案，一样平常会有多种，末了须要结合实际产品方案、资源等，综合考虑选择现阶段最适宜的方案即可。
前边需求挖掘也确保对需求足够理解，当下、未来的办理方案，而不但是专一做功能，稍有变动就要重新调度全体设计逻辑，避免对需求知其然，而不知其以是然。
市情上已经有太多成熟办理方案了，但是好的产品经理，一定不是只会抄软件功能。

篇幅有限，就不进行过多展开了，欢迎大家一起磋商互换，坐标杭州，欢迎来撩~

本文由 @木子gee 原创发布于大家都是产品经理，未经容许，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。