作为一名产品经理，收集需求是一件很常见但非常重要的工作。
不同的需求并不是平等的，因为其产生的价值是不同的，我们一般把需求分为4类
A类需求：全新的业务，能够产生单独的商业价值
B类需求：在现有的业务上，提供新的功能，虽然不能产生额外的商业价值，但是能大大提高用户的体验
C类需求：对现有业务的现有功能进行优化，改善原有的体验
D类需求：价值较小的功能
有了以上的分类，可以看到ABCD四类需求，价值由高到低，我们都希望能够发现和实现AB类的需求。
这时，有的产品部就会定下需求的数量的KPI，比如每年或者每个季度，每个人要收集多少个需求，尤其是B类及以上的需求要有多少个等等。
这时候就会出现一个问题，前面的需求分类的定义还算是挺明确的，但是在实际工作中，他们的边界并不是很明显的，我们对需求的分类往往是定性的而不是定量的，因为难以有一个数据指标来衡量一个需求的价值程度。
如果规定了需求收集数量的硬性KPI指标，就会导致不好的现象：人们为了完成KPI，将原本低级别的需求升级为高级别的需求，强行去证明自己的需求更加有价值。
例如，原本的一个B类需求，在有的软件程序中增加一个功能就行，但是产品经理为了完成KPI，就强行把这个需求定义为A类需求，并鼓吹其拥有独立的商业价值，可以将它从原有的软件中剥离，单独售卖赚钱。
而由于往往管理层对业务的理解并没有一线作业人员那么清楚，如果产品经理再巧舌如簧一点，很有可能申请到单独的资源，成立新的产品部，然后去进行研发，等到产品上市后，才发现没有独立的市场空间，那时已经浪费掉的资源，已经无法收回，是不是很可惜。
再如，原本一个整体的需求，产品经理为了完成数量的指标，将这个需求拆成多个小需求，需求场景被切割得支离破碎，对后续场景分析的完整性有很坏的影响。
所以管理层在定产品经理需求收集的KPI的时候，最好还是规定需求收集的质量，而不是数量。
当然需求的质量又是一个新的话题，择日再聊聊这个话题。
今天的这个话题又让我想起另外两个追求数量引发负面效应的案例：
案例一：英国在印度殖民期间，曾经为了鼓励大家消灭眼镜蛇，提出了一个悬赏方案，谁杀的眼镜蛇多谁得奖就多，结果眼镜蛇的数目不减反增。为什么呢？因为大家都去饲养眼镜蛇去了。
案例二：民国时期，考古学家在殷墟中发现甲骨文，最开始是按片收购，于是农民就把完整的大块的甲骨破坏成数片，来换取更多的钱，导致很多甲骨被分散收藏，后来开始按字的数量收购，于是农民又在无字甲骨上刻甲骨文。被分散收藏的甲骨和伪造的甲骨都大大增大了甲骨文研究的难度。
题图：Photo by Arlington Research on Unsplash
