【2012】关于“分类”的一些简单思考

导语

上帝创造世界,将世间万物做了各自各样的分类,大地上的生命可以通过各自特征,梳理对世界结构的认知。

今天我想说的是“分类”,政企有分类,商场的店铺也有分类,商品也有自己的分类。

分类的目的是什么

为什么需要分类?东西多了乱了,就要分类,所以分类就是为了能更好的进行管理。

很多小型的垂直电商平台或者直营品牌,都喜欢直接使用“瀑布流”的商品展示方式,对于“分类”和“筛选”这些功能相对弱化。原因在于他们的体量小,当他们的SKU多起来了,自然而然的,分类功能也会得到一定的优化。

在通用型的平台环境中,我们通常会看到另外一种情况。国内用户比较喜欢用底部导航栏,一般通用型的电商平台,底部导航的ICON都会有一个是“分类”,大平台如淘宝京东这些,因为体积很大,承载的东西很多,“分类”可能只是二级目录的一个小ICON。

类目树的层级

一般来说,类目树分三个层级就够用了。可能有人会问,为什么是三个层级?我个人认为两级或三级都够用了。毕竟,若层级太少,容易导致一个类目底下商品太多,而找不到目标商品;若层级太多,容易导致因为类目太多,因为找错类目而找不到商品。

可能这时候有人会想起“搜索”这个功能,搜索应该归类在推荐管理,而不是在商品分类管理。当然,一个商品,存在类目的层级以及类目的类型的不同,肯定也会对它的曝光度造成影响,这里就不做展开。

在只能设备普及的今天,终端屏幕的特点及尺寸都不一样,上图为例,Mobile端的分类层级展示就和PC端的有区别,所以在设计时,需要考虑各种设备的前端进行展示考虑。例如:手机、电脑、电视、平板……

类目的定义

用生活中的便利店举例,仓库商品的归类摆放与店面商品的货架摆放,位置是有可能不一样的。在货架上,不同的品牌的薯片放在同一个位置,在仓库中,不同品牌的薯片可能也是摆在差不多的位置。在货架上,啤酒和尿片摆在相邻的位置,在仓库中,啤酒可能在饮料区,尿片可能在生活用品区。

我举的这个例子不一定真实就是这样,但想告诉大家的是这个逻辑。作为用户,在电商平台看到的类目,不一定就是操作人员在后台的数据库类目。因为让用户看的类目有可能是经过运营人员的打磨加工。

所以,类目应该分为“前台类目”和“后台类目”。他们可以是一样的,也可以是不一样的。

商品的属性

上文提到“前台类目”,要做到“前台类目”的个性化,就必须要从商品的属性入手。先说说定义:

  • 【属性】就是商品存在的特性;
  • 【属性项】就是商品的品牌、尺寸、颜色、大小、型号等;
  • 【属性值】用品牌举例,手机品牌中的属性值为小米、华为、OPPO、VIVO、诺基亚等。

“后台类目”的分类其实也是商品属性的一种,只是将某个维度系统化,容易寻找。有时候一些特殊定义的分类,比较个性化,就是将不同类目层级的商品混合放在一齐,形成“组”,然后将这“组”分类展示给用户浏览。

一个简单的例子:“掌柜推荐”下可以放8个商品,这8个商品可以是平台商品库中的任意商品,来自不同的分类。站在运营策略的角度,将这些商品推送给用户,达到曝光效果。

个性化属性的一些思路

公共属性

公共属性指的是可以多个类目共用的属性。

用衣服举例,属性项可以是很多的,例如:颜色、品牌、尺寸、性别、类型等,而颜色和性别这类型的属性,都具有公共特性。颜色的红、黄、蓝、绿;性别的男、女、中性。

销售属性

销售属性一般都是规格属性,主要用于SKU/SPU的特殊属性,可以直接影响商品详情页的商品展示管理。通过考虑用户购买的场景,映射出属性归类。

关键属性

关键属性一般是能一眼看出是什么的属性,可以是一个属性,也可以是一群属性的集合体,就如品牌“大疆”,都会想到无人机,设计关键属性的目的也是未了让用户能更好的找到想要的商品。这个与推荐管理也有很大联系,这里不作展开。

属性优化

这块只能靠日积月累,在属性设置一段时间后,会出现大量的长尾属性和属性值,如何去优化这个库,就要看具体的定位和方向,尽可能的将属性进行系统化管理,降低操作人员的复杂度,降低用户的查询成本。

小结

方法论的作用只是归纳总结,实际操作是灵活变通,怎么使用“分类”,我认为定位和方向很重要。

【4004】单项需求卡片

导语

不知道大家是否有这样的经历,每天的时间也就24小时,事情也有缓急轻重之分,不可能同时间处理很多事情。但协同部门又有很多需要解决的大需求,小需求,小建议和漏洞bug等,需要跟进解决。一般来说,都会将信息列入需求池的待处理需求中。

需求池的详细程度也决定了需求池的维护成本,在这里,我推荐一种“单项需求卡片”的记录方式,搭配需求池进行使用。可以有效解决同时间解决不过来的需求事物,并能在日后启动需求时,快速的找到相关人员及相关内容等。

当然了,一句话能描述清楚的事情,也没必要动用“单项需求卡片”这么重的东西,灵活变通,切勿浪费大家的时间。

“单项需求卡片”是干什么的?

“单项需求卡片”类似我们去银行办理业务,领个号后,开始填写的业务相关表格。到柜台时,方便柜员进行一系列的资料录入工作。回到工作的场景,就是让需要提需求的同学填写一份表,然后自己根据表上的内容就可大概了解这位同学需要提个什么需求。

“单项需求卡片”需要什么内容?

需求编号

一般需求编号使用大家都懂编写,且看到都能快速转译的方式比较合适。

如:年月日(YYYYMMDD)+姓名。可根据实际需要添加其他大家都懂编写的标签。

需求类型

  • 功能需求
  • 非功能需求

填写的人不一定都非常熟悉产品结构,尽量的易懂即可。

来源

此信息比较重要,方便追溯根源。

产生需求的用户和该用户的相关信息,描述清楚即可。

场景

产生该需求的时间,地点和环境等场景信息。

描述

尽可能使用(主语+谓语+宾语)的表达形式,不要加主观修饰语句。

原因

这也是非常重要的信息,作为产品经理,此时此刻必须保持怀疑的心态,因为有很多的理由是假想出来的。

为什么会有这样的需求?发起者的解释是什么?

验收标准

这个需求要怎样才算是满足了,定义一个标准,好让产品同学和开发同学以及设计同学有个底

  • 尽可能使用可量化的语言;
  • 无法量化的标准要举例解释。

需求的生命周期

这个属于需求的紧迫度和可持续性内容。

  • 需求的紧迫程度;
  • 上线后使用周期和持续性等。

参考材料

对此需求有一定参考价值的材料及有用的相关资料,不一定需要封装压缩,引用说明,能找到即可。

需求关联

与此需求有关联关系的各种

  • 人:与此需求相关联的任何人;
  • 事:与此需求相关的业务、相关功能及事件等;
  • 物:与此需求相关的系统,设备和其他产品等。

竞品对比

  • 竞争对手是如何实现该功能的
  • 竞争对手该功能获得的评价。(大众用户角度,公司内部角度,产品设计角度等层面进行考虑)

给出规范定义“1分”差到“10分”好,有个评分概念。

需求重要性

需求的重要性建议产品经理自己内部团队定义,开放填写此栏目,容易造成所有需求都是紧急需求,重要需求。

除非公司有个提交需求系统,可以针对系统设定一些规则,去制衡乱填需求重要性。

小结

还是那句,一切的模板,套路都是死的,灵活应用即可。在不同的团队,不同的公司,甚至不同的时间周期,可能模板都会纯正各种变异和差异,只要问题能解决,这东西甚至没有存在的意义。在此,希望此单项需求卡片能对大家有帮助。

【3006】5W2H分析法

5W2H分析法又叫七问分析法,是二战中美国陆军兵器修理部首创。简单、方便,易于理解、使用,富有启发意义,广泛用于企业管理和技术活动,对于决策和执行性的活动措施也非常有帮助,也有助于弥补考虑问题的疏漏。

具体内容

发明者用五个以W开头的英语单词和两个以H开头的英语单词进行设问,发现解决问题的线索,寻找发明思路,进行设计构思,从而搞出新的发明项目,这就叫做5W2H法。

  • WHAT——是什么?目的是什么?做什么工作?
  • WHY——为什么要做?可不可以不做?有没有替代方案?
  • WHO——谁?由谁来做?
  • WHEN——何时?什么时间做?什么时机最适宜?
  • WHERE——何处?在哪里做?
  • HOW ——怎么做?如何提高效率?如何实施?方法是什么?HOW MUCH——多少?做到什么程度?数量如何?质量水平如何?费用产出如何?

应用程序

检查原产品的合理性

步骤(1)做什么(What)?

条件是什么?哪一部分工作要做?目的是什么?重点是什么?与什么有关系?功能是什么?规范是什么?工作对象是什么?

步骤(2) 怎样(How)?

怎样做省力?怎样做最快?怎样做效率最高?怎样改进?怎样得到?怎样避免失败?怎样求发展?怎样增加销路?怎样达到效率?怎样才能使产品更加美观大方?怎样使产品用起来方便?

步骤(3)为什么(why)?

为什么采用这个技术参数?为什么不能有响声?为什么停用?为什么变成红色:为什么要做成这个形状?为什么采用机器代替人力?为什么产品的制造要经过这么多环节?为什么非做不可?

步骤(4)何时(when)?

何时要完成?何时安装?何时销售?何时是最佳营业时间?何时工作人员容易疲劳?何时产量最高?何时完成最为时宜?需要几天才算合理?

步骤(5)何地(where)?

何地最适宜某物生长?何处生产最经济?从何处买?还有什么地方可以作销售点?安装在什么地方最合适?何地有资源?

步骤(6) 谁(who)

谁来办最方便?谁会生产?谁可以办?谁是顾客?谁被忽略了?谁是决策人?谁会受益?

步骤(7)多少(How much)?

功能指标达到多少?销售多少?成本多少?输出功率多少?效率多高?尺寸多少?重量多少?

优势

如果现行的做法或产品经过七个问题的审核已无懈可击,便可认为这一做法或产品可取。如果七个问题中有一个答复不能令人满意,则表示这方面有改进余地。如果哪方面的答复有独创的优点,则可以扩大产品这方面的效用。新产品已经克服原产品的缺点,扩大原产品独特优点的效用。

  • 可以准确界定、清晰表述问题,提高工作效率。
  • 有效掌控事件的本质,完全地抓住了事件的主骨架,把事件打回原形思考。
  • 简单、方便,易于理解、使用,富有启发意义。
  • 有助于思路的条理化,杜绝盲目性。有助于全面思考问题,从而避免在流程设计中遗漏项目。

【3005】四象限法则

四象限法则又叫十字法则艾森豪威尔法则。创始人艾森豪威尔,源自艾森豪威尔的十字时间计划:画一个十字,分成四个象限,分别是重要紧急的,重要不紧急的,不重要紧急的,不重要不紧急的,把自己要做的事都放进去,然后先做最重要而紧急那一象限中的事,这样以来,艾森豪威尔的工作生活效率大大提高。此事成为美国成功学家们所津津乐道的美谈。

四象限法则.jpg

历史渊源

德怀特·戴维·艾森豪威尔(Dwight David Eisenhower18901014日—1969328日)美国第34任总统,陆军五星上将。他是格兰特总统之后第二位职业军人出身的总统。艾森豪威尔是一个充满戏剧性的传奇人物,曾获得很多个第一。为了应付纷繁的事务,并且争取迅速处理而不贻误,他发明了著名的“十”字法则,也被称之为“十”字时间计划。画一个“十”字,分成四个象限,分别是重要紧急的,重要不紧急的,不重要紧急的,不重要不紧急的,把自己要做的事都放进去,然后先做紧急重要那一象限中的事,以此类推。这样一来,艾森豪威尔的工作生活效率大大提高。

主要特点

以下是四个象限的具体说明:

1、第一象限是重要又急迫的事。

举例:诸如应付难缠的客户、准时完成工作、住院开刀等等。

这是考验我们的经验、判断力的时刻,也是可以用心耕耘的园地。如果荒废了,我们很会可能变成行尸走肉。但我们也不能忘记,很多重要的事都是因为一拖再拖或事前准备不足,而变成迫在眉睫。

该象限的本质是缺乏有效的工作计划导致本处于“重要但不紧急”第二象限的事情转变过来的,这也是传统思维状态下的管理者的通常状况,就是“忙”。

2、第二象限是重要但不紧急的事。

案例:主要是与生活品质有关,包括长期的规划、问题的发掘与预防、参加培训、向上级提出问题处理的建议等等事项。

荒废这个领域将使第一象限日益扩大,使我们陷入更大的压力,在危机中疲于应付。反之,多投入一些时间在这个领域有利于提高实践能力,缩小第一象限的范围。做好事先的规划、准备与预防措施,很多急事将无从产生。这个领域的事情不会对我们造成催促力量,所以必须主动去做,这是发挥个人领导力的领域。

这更是传统低效管理者与高效卓越管理者的重要区别标志,建议管理者要把80%的精力投入到该象限的工作,以使第一象限的“急”事无限变少,不再瞎“忙”。

3、第三象限是紧急但不重要的事。

举例:电话、会议、突来访客都属于这一类。

表面看似第一象限,因为迫切的呼声会让我们产生“这件事很重要”的错觉——实际上就算重要也是对别人而言。我们花很多时间在这个里面打转,自以为是在第一象限,其实不过是在满足别人的期望与标准。

4、第四象限属于不紧急也不重要的事。

举例:阅读令人上瘾的无聊小说、毫无内容的电视节目、办公室聊天等。世界经理人管家

简而言之就是浪费生命,所以根本不值得花半点时间在这个象限。但我们往往在一、三象限来回奔走,忙得焦头烂额,不得不到第四象限去疗养一番再出发。这部分范围倒不见得都是休闲活动,因为真正有创造意义的休闲活动是很有价值的。然而像阅读令人上瘾的无聊小说、毫无内容的电视节目、办公室聊天等。这样的休息不但不是为了走更长的路,反而是对身心的毁损,刚开始时也许有滋有味,到后来你就会发现其实是很空虚的。

 

【2001】关于“验证码”的下发机制

今天在使用招商银行的【掌上生活】app时,碰到这样一个情况,某个业务场景,需要输入手机号,填写下发的验证码。或许是网络原因,验证码几分钟没到,作为用户,肯定会多按几次,这是非常正常的操作行为。然而,坑爹的事情发生了,试了两三次,几分钟过去了,在某次请求后,验证码来了,但输入后是错的,大概过了30秒,又来了一条,我再次输入,还是错的。使用返回再进入,又重新获取了一次,来信息了,但还是错的,瞬间心好累。

为什么会出现这个情况?因为他们的验证码下发机制没有考虑到一些特殊场景,例如网络延误,短时间内多次下发的输入等。他们的机制很简单,就是请求一次,生成一个不一样的验证码,需要输入最新的,或许有最大下发次数保护机制,这个是另外的话题,这里不发散说。然而,不知道是哪边服务器的原因,延误的验证码不是连续来,而是隔十几秒来一个,还要让人在当前页面等到最新的验证码进行输入才是正确的,想到就心好累。

这里就引出了一个问题:验证码的下发是否应该使用相同的验证码?

在一定时间内(10-30分钟),向同一个手机号下发相同的验证码会比较好,超过一定时间,下发不同的验证码。这样在短时间内,用户看到多个相同的验证码,不会出现疑虑,对需要输入的验证码非常明确,若短时间内的验证码不同,就会产生“哪个才是我需要输入的?”这个疑问烦恼,可能产生多次输入的试错成本。

那么,如果在迭代需求中,需要描述这个功能,怎么说比较好呢?

用户发起一个验证码请求时,去库里查该账号/ID最近一次下发验证码和下发时间,若在30分钟内,则把该验证码再下发一次,并进行记录(30分钟是否需要重新计时,根据各个业务的情况自行调整,没有标准答案),若是超过30分钟,则重新生成新的验证码进行下发。

小结

虽然只是一个触发验证码的动作,里面也涉及到很多小细节,这里主要是讲述的是验证码多次下发的使用场景。在整个流程当中,其实还涉及什么时候触发下发请求的相关问题,倒计时控制连续下发验证码的时间问题,每个功能都需要多思考,尽可能的严谨和人性化,这些细节不一定能让产品带来飞跃性的成功,但肯定能提高产品的下限。

【1002】如何应对“别人有这个功能”

做产品经理,肯定曾经被多次提问这个问题:

“别人有这个功能,我们什么时候做?”

出现这个问题,大部分是需求方提出的,他们一般的理由都是:BAT哪个不是这么搞的,同行竞品都有这个功能,我要用这个功能。或者这么说吧,很多时候,大部分需求都是这么产生出来的。

作为产品经理,我相信同样的问题肯定有考虑过,并且比其他部门的人想的更深入,当然,有时候也会出现长期高强度的快速迭代,有些功能缺失看漏眼了,或者缺乏思考时间,没想到。在这个情况下,只要少用时间进行分析思考,相信你的见解也会比提问者更深入。

需求方有这个诉求,总要看看背后的原因是什么,凡事都是有原因的,你可以问:

“这个功能你想用来做什么?”

    “你想做这个功能背后的原因是什么?”

一般情况下,你听到的回答是:“这个功能能干这个这个这个……”

这里其实有个误区,功能提供的是方法和结果,一定是某个事情引出了他们的诉求,提出这个需求。我们要知道的并不是简单的这个功能能帮助他们干什么,而是他们要干什么,我们用什么方法去协助完成,或许这个功能可以,或许用别的方法也可以。同时也要考虑整个产品的整体结构性,既然原来没有这个功能,也是有原因的,要告诉他们原来没有这个功能的原因是什么,如果有,会产生什么关联的影响和效应。再之,要告诉他们这些功能别人虽然都存在,但具有一定的差异性,差异性背后的战略逻辑和政策思路是什么,如果真的要做,希望达到什么样的效果。

小结

在这个沟通过程中,尽可能的保持和睦,大家肯定都是为公司好,为团队好。但各自也有自己的立场,只要解决了事情就行,尽可能不要拔刀相见。只要把上述的关键点都问清楚了,最好把自己对这个需求的想法和思路描述表达,柔和的给予建议。这样,多来几次,别人就会觉得你考虑的比他们深入且长远,久而久之,既可以降低无效开发成本,又可以提升沟通效率,并在团队中建立良好的印象,话语中有一定的说服力。