04　解决问题，而不是做产品

上一节我们提到，看似完美的“类目+属性”体系，其中蕴藏着更大的问题，有一句玩笑：专家就是擅长解决困扰大家已久的问题，但在解决问题的同时又创造出两个大家闻所未闻的新问题的人。

我们继续拿品牌这个属性来举例。作为淘宝的小二，每个人能说出来的品牌非常有限，一般只有几十个，能说出几百个则已经是行业专家了，但是整个中国乃至全世界汇集起来的品牌至少有几万个，怎么办？让消费者怎么选？这意味着品牌这个属性的属性值一定要再想办法细分。小二当然也很聪明，很快就划分出了“男装品牌”“女装品牌”“手机品牌”等不同的属性。

那么，男装品牌挂在男装的叶子类目——T恤下面，女装品牌挂在女装的叶子类目——T恤下面……不同类目的运营小二因为分工的关系，各自维护各自类目的品牌属性值，这样就带来几个问题。

第一，不同的类目下都是品牌这个属性，但数据库里的ID[18]不一致。

第二，品牌的属性值ID不唯一。比如，男装的“耐克”在数据库里面有一个单独的值，女装的“耐克”在数据库里面又有另外一个值，属性值不归一了。这样就很乱，本来都是耐克，但是男装耐克和女装耐克是没有关系的，对前台导购来说，这是非常怪异的事情。

第三，同样一个品牌，不同小二定义的格式不一样。比如阿迪达斯，不同小二输入的格式也不同，可以是阿迪达斯、阿迪、adidas、Adidas等。

如果放任上述问题存在，小二是没办法做基于品牌的管理的，卖家在发布商品的时候也会碰到选择困难的情况，买家在前台找商品也会受到影响。所以针对这个情况，我们做了“属性归一”。这个事情又要分两个角度来看，一是历史的问题，一是将来的问题。

先说历史问题，当时小二把某些需要归一的属性列出来，比如“品牌”，通过这个关键字找，然后看了一下所有属性里面是“品牌”意思的属性，把这些属性合并到一个ID下，再把下面的属性值也做合并，以解决上述后两个问题。可以想象，小二们先要考虑“哪些属性需要做归一、哪些属性值要做归一”，然后再一步步操作，这是一个非常庞大的人工工作。所以在当时也用了一些技术手段来辅助，比如通过模糊匹配找出哪些属性可能是同一个属性。

但这只能解决历史问题，没有办法解决将来的问题。

当小二把品牌这个属性整理完之后，截至那一刻，品牌和其具体的属性值都是很清爽的。而且为了避免第三个问题，对于品牌的属性值，产品经理还做了一个规范，英文在前面，中文在后面，然后用反斜杠（\）隔开。但是，品牌下面的属性值还是有几万个，让小二在几万个属性值里面挑出来，他会嫌烦，所以很多小二存在“违规”操作。

他可能按照自己的意愿直接输入一个，比如说“Nokia/诺基亚”已经有了，他会直接输入一个诺基亚，然后把这个值挂到了他自己的类目属性里。这也就是说，又有两个诺基亚了，于是产品经理们只能定期去清理。

这个问题很难用产品来彻底解决，原因有很多，比如说因为品牌的复杂性，可能有的品牌并没有英文或是中文的说法。所以，后来权限用了一个看起来很傻的方案——整个淘宝品牌管理里面，允许品牌输入的只有一位小二，后来权限又交给了一个团队（截至2012年年初），从这个例子里我们看到，在特定的场景下，一个问题不一定要用传统意义上的“开发产品功能”来解决，产品经理的责任从根本上来说是解决问题，而不是做产品。

解决问题，或者说满足需求，通常有三种方法——提高现实、降低期望、转移需求，而最常用的“开发产品”是第一种，也是最费劲的一种方法。

有了专职的小二以后，还是需要定期清理属性值。为什么？因为小二添加品牌的操作虽然已经相对规范，但还有大量的品牌是通过枚举可输入的方式输入系统的，这也是为了丰富系统内的品牌库。一旦这些卖家输入的品牌下面的商品达到一定数量，淘宝的小二又需要对这些品牌进行归一，整理到小二认可的品牌值里面，所以这个清理是一个持续的动作，直到2012年还在做。

品牌这个属性比较关键，还可以通过人工操作来完善；而其他的一些属性，很多就乱着放在那里。当然，将来希望有产品经理能够通过系统的方式彻底解决这个问题。

为了方便管理，这里还有必要提一下公共属性的概念。举个例子，服装下面有上衣、裤子，然后再分很多子类目。我们之前提到，在类目树里，非叶子类目是没办法挂属性的，但是品牌、性别这些属性是共用的。因此，每个子类目都有的属性，可以直接挑出来，作为父类目的公共属性，在前台直接展现在非叶子类目下。也就是说，在前台导购路径进展到上衣的时候，就可以进行男女的性别筛选、品牌的筛选。这么做的好处显而易见，就是加大了买家在前台筛选的自由度。

属性虽不完美，但能解决问题。不过，它的出现还引发了一个谁也想不到的问题，那就是——淘宝和卖家的“感情破裂”。