当前位置：首页 >新闻动态 >快手号出售

产品经理就在每条商品详情页增加了一键打印功能

2020-07-14

给某个超市做一个纸质价签管理功能，客户提出的需求就是能够查看并根据商品价格打印价签，这是一个看得见的需求。

于是，产品经理就在每条商品详情页增加了一键打印功能。按说客户提出的点满足了，但交付后客户反馈系统没法用，非常不满意。

如果我们深入挖掘一下，就会发现至少有以下几个看不见的和进一步的需求：

一般便利店都会有上千个SKU，假设每次10%变价，也会有100个价签需要打印，而每次进入商品页面打印价签的操作时间至少5秒，打印100次，再加上等待打印时间，可能半个小时都搞不定，这个过程对于店员来说非常煎熬，降低人效不说，而且会极大影响工作热情；最好的解决方案就是提供批量打印功能，在等待打印同时还可以做别的事情；
线下门店打印价签通常是提前为促销做准备，或者是促销后恢复原价，这个反应速度越快越好，为了做到无缝衔接，价签打印要前置，也就是在系统真正变价之前就准备好物料，所以要有按变价时间维度筛选商品并打印价签的功能；
促销是变价的主场景，所以应该有预先知道门店促销活动的功能，这就需要营销日历，让店员清晰明确的了解到接下来的活动及变价情况，并且联动打印价签；
促销活动的种类繁多，那么在价签样式上要予以区分，尤其是与普通商品的价签样式，那么是不是可以考虑增加各种活动的价签模板，并给出不同的默认颜色和样式，额外再提供编辑功能；
我们发现经常变价的门店人力成本非常高，除了打印还有核对、陈列，偶尔的操作失误还会引来客诉，基于ROI考虑，是不是可以改用电子价签呢？这就是进一步的需求了。

综上，如果每一个产品都能向前一步说话，从行业“降本增效”的本质出发，设身处地的为客户思考，获取全量的真实需求，也就避免了无从下手及费力不讨好的窘境。

价签管理只是一个很简单的功能，当我们面对复杂功能的需求调研和分析时该如何下手，还是要有一套方法论。

1.1 业务流程梳理

业务流程是分层的，尤其是当我们把目标客户定位为中大型企业时问题尤其复杂：

第一层：是组织级，集团视角，关注分工、管理和大方向的业务流向。比如在零售企业中，就会存在供应链、门店、售后，客服、财务等几个不同的部门。这一层的调研内容主要是确认企业的组织构成，流转方式，目前存在的经营问题，寻找潜在的机会点；
第二层：是业务级，部门视角，关注每个岗位具体负责什么，产出什么，以及这些活动之间的关联。例如门店部门要销售商品，需要库管、销售运营、导购的配合才能完成，产出就是销售额，这是业务流程梳理的主线索，也是主要输出。这一层的调研内容主要是确认部门内岗位分工，每个业务事件的流程，参与者，事件及关注的产出物，通常是报表形式；
第三层：是操作级，通常是某个岗位的视角，实现某个业务场景需要的具体操作步骤，可能由某个或几个岗位的人操作，属于需求细节。这一层的调研内容主要是确认每个角色参与的业务流，日常的操作流程，了解功能、数据、用户体验等方面的问题。

业务流程分析起来很多很复杂，还会有子流程嵌套，很难用文字描述清楚，因此这一步的产出最好采用跨部门和岗位的泳道图，下边以线下销售场景为例说明：

线下门店销售业务流程横跨3个部门7个岗位角色，而每一个步骤又包括若干的子流程，输出这个流程的目的是确认各个部门之间的关系，及各个角色应该承担的工作内容。

1.2 角色与场景分析

基于步骤1输出的角色应承担的工作内容，再具体看某个角色在特定场景中都需要做什么事，那么就拆分成两个基本要素：

参与者：这个流程中与系统进行有意义交互的任何事物，可以是某个岗位的人，也可能是一个硬件或系统，比如门店销售可以是导购，也可以是自助结账机，线上销售就是APP或者小程序；
做什么事：是指系统执行的一系列动作，是一个动词+名词的组合，且必须是有意义的，产生实际结果的动作，比如，操作收银机执行一系列动作，生成销售订单，这就是一个完整的场景了，但只是添加一个商品到购物车，这不能叫完整场景。

主要因为以往很多技术性产品经理在分析和设计产品时，总是以功能的视角去思考，既这个系统应该有什么功能，这样做出来的产品就是一系列功能的堆积，用户常常抱怨太难用。

看到一堆“xx管理”的菜单，根本不知道干什么用，即使看了天书一样的手册，要完成一个场景，可能需要切换若干个菜单模块，合上天书，又不知道该去哪找需要的功能了。

而以角色+场景方式驱动的分析方法，是一种侧重于“用户视角”的分析，将系统做成一个黑盒子，不仅可以有效指导最终展现的菜单形式，避免上述问题，还有利于梳理场景时发现那些看不见的问题。

下边以“导购”角色的“销售”场景为例进行分析：

步骤2分析的角色+场景只输出了一个核心路径，是主流程，还要补充拓展流程、完善前置条件、后置条件、特殊规则。

将多个角色场景进行抽象整合输出系统用例，系统用例作为最小需求单位指导系统开发。

这里说的抽象整合就是技术层面的复用逻辑，好比软件开发中“类”和“对象”的关系，系统用例是一类的抽象，角色场景是一个具体的行为。