1

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

 1 month ago
source link: https://www.woshipm.com/pd/6024116.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

2024-04-01
0 评论 0 浏览 0 收藏 10 分钟

产品的日常工作都是围绕着需求展开的,那么在实际挖掘需求中,需要围绕着六步走。本文结合服装供应链SaaS系统的一个小功能展开,探讨需求的挖掘和解决方案,希望对你有所启发。

a1997136-da9e-11ed-aee8-00163e0b5ff3.png

身边总有同事问,你每天怎么有那么多问题,大概是经常用到5Why法吧。正好最近打算做些输出,今天就结合日常工作,分享下自己平时如何做需求挖掘。这个也是产品日常工作、求职高频问题了,希望对看到文章的你有所帮助。全文篇幅2000字左右~

产品日常工作都是围绕需求展开的,从需求收集、需求挖掘与分析、需求规划、优先级排序、需求设计、需求评审、需求开发、测试到最终产品上线,一个完整的产品生命周期,需求贯穿始终。前期的需求挖掘与分析至关重要,可以说需求挖掘分析如果错了,整个产品会错的离谱、很难挽救。

挖掘用户需求:自己平时主要是需求调研+5Why法来结合进行。至于需求调研,了解用户在什么场景,想解决什么问题,现在遇到的问题和难点,现有解决方案等。所谓5Why分析法,又称”5问法”。最早由丰田汽车创始人父亲——丰田佐吉提出,在丰田汽车制造方法学得到应用,也是常见是问题求解方法,并且在丰田之外也得到了广泛采用,主要用于根本原因深挖。

在实际挖掘需求工作中,我主要围绕这6步进行:识别确认需求、需求现状了解、需求分解、查找要点、把握需求边界、需求原因目的了解、需求解决方案。结合之前做服装供应链SAAS系统一个小功能进行展开。

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

公司的种子客户,XX服装厂老板提出员工计件功能需求,希望解决给员工发工资需求。

这里特别注意:不论需求大小,所有需求都要明确到具体提出人,而不是转述方。需求池日常维护中,需要直接记录具体需求提出人。才能深入调研、挖掘需求,即使初级产品、产品助理,都要注意这点,当然这一步需求还是很粗糙的。

二、需求现状了解:业务现状,如何运转,遇到的问题、难点

这里通过一个业务流程图来简单体现,了解到梭织面料生产流程(此处只截取裁剪开始的部分流程)。

员工计件,小功能原来也不简单?

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

三、需求分解、查找要点

拆分需求,梳理调研大纲,查找要点。我一般从需求涉及的角色/业务方出发,梳理对应业务问题,带着问题去了解需求和业务。显然这里涉及的角色有:工厂老板/生产负责人、财务、具体业务人员(流水线工人/小组长/主管)。

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

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

四、把握需求边界

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

员工计件,小功能原来也不简单?

五、需求原因、目的了解

通过前边反复沟通确认,需求原因、目的其实基本摸透了,只要把调研大纲的沟通记录进行补充提炼。偷个懒这里就略过啦~

六、需求解决方案

在这一步,我一般会先梳理出业务流程图,需求解决方案,实际的功能点说明等。这一步完成后,会根据实际情况做需求内评(这里根据实际可能是跟CTO、客户等),再之后才是原型设计,PRD输出。

1、需求解决方案

这个一般都是思维导图去梳理,涉及隐私这里把自己做过的多个系统糅杂在一起来贴图了,结合员工计件简单写了一个方案参考。

a、员工计件解决方案

  1. 初阶:只是系统上简单做汇报计数
  2. 中阶:扫码单件计件
  3. 高阶:扫包码计件、合格/不合格数审核、除了业务功能

关联功能有员工计数统计,计件工资计算,订单生产进度统计等

b、扫码方案:哪个环节生成条码,哪个环节贴条码,如何贴条码

员工计件,小功能原来也不简单?

2、扫码方案:条码需要包含什么信息

通过需求调研、流程梳理,发现员工计件这个功能,计数只是最基础的需求,还涉及到质检,所以会有合格/不合格数延伸。不同工序需要技能、加工时间、复杂程度等不一致,所以工价不同,此处了解的信息,就是工序后期可扩展延伸的属性信息。结合统计相关需求,条码需要包含产品规格信息、加工时间等。

员工计件,小功能原来也不简单?

3、功能点说明示例

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

员工计件,小功能原来也不简单?

用例图展现形式:

员工计件,小功能原来也不简单?

这里输出的需求解决方案,一般会有多种,最后需要结合实际产品规划、资源等,综合考虑选择现阶段最适合的方案即可。前边需求挖掘也确保对需求足够了解,当下、未来的解决方案,而不只是埋头做功能,稍有变动就要重新调整整个设计逻辑,避免对需求知其然,而不知其所以然。市面上已经有太多成熟解决方案了,但是好的产品经理,一定不是只会抄软件功能。

篇幅有限,就不进行过多展开了,欢迎大家一起探讨交流,坐标杭州,欢迎来撩~

本文由 @木子gee 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App

format,webp

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK