转自：产品经理从0到1

产品不是功能的集合，每个产品都存在其精神的部分。一个产品要加多少的功能，才能成为一个垃圾产品啊！——Allen Zhang

初识这句话的时候，没有什么很大的感触，现在却想拍手叫绝，深以为然。

时光退回到一年以前，在当时参与的一个项目中，为了提高用户的使用频次，增加用户黏度，产品上线了一些新功能。然而上线之后却发现新功能使用率惨淡，换言之，我们做了一些对用户没什么价值的功能。

当初以为这只是个别的现象，后来在和其他同行交流的时候发现这种情况其实还是比较常见的，最终导致的结果就是稀里糊涂的做了不少功能，整体的投入产出比却很低。

所以我就在想有些需求能不能根本就不做，或者说在资源排期过满的情况下就适当的砍一些需求。很多情况下资源本身可能就是一直不充足的，排期过满导致的直接结果可能就是要经常加班，那加班如果也解决不了怎么办？通常的做法就是加人，而加人在很多时候可能也解决不了问题…

首先加人是需要额外成本的，其次加人也不一定能够保证效率和进度，而且加人之后团队协作的成本会更高，甚至可能会引发团队内部冲突，那怎么办？所以我就在想，从源头上入手是否可行，也就是合理的去砍掉一些需求。

为什么要砍需求

可能大家都听过一些段子，比如什么这个需求很简单，怎么实现我不管，明天上线。比如砍我可以，不要砍需求…比如这个需求根本实现不了等等，似乎大家听到的大都是关于如何提需求的，而很少听到砍需求的，所以我就阐述一下我认为要砍需求的理由。

二八法则

二八法则指出在任何一个东西中，最重要的部分只占一小部分，约占20%左右，剩下的80%，虽然是多数的，但却是次要的。（PS：不一定是严格的20%与80%的关系，也可能是10%与90%或者30%与70%的关系）

二八法则的核心思想在于少数关键原则，即占比较少的一部分反而可能是比较关键的，其实这种幂律法则是一个具有普适性的规则。不信你可以粗略的去看下全世界80%的财富集中在约几%的人手中，互联网与移动互联网80%以上的市场份额被几%的公司占据，一个公司80%的利润来源于几%的业务…

洋洋洒洒扯了那么多，就是为了引出二八法则这个理论，可以看下你们家的产品的使用情况，是不是约20%的功能占据了用户使用时长的近80%，是不是约20%的用户贡献了近80%的营收呢，前者通常被我们叫做核心功能，后者通常被我们称为核心用户。

既然这样，那我们是不是需要优先打磨这20%的功能，优先满足这20%核心用户的核心需求呢。产品并不是简单的功能堆砌，用户体验也不是简单的功能叠加，我们需要先将核心功能打磨到90分，然后再想办法优化其他的功能，而不是做一堆60分的功能给用户。

在现在这个丰饶经济的时代，产品早就面临着功能/性能过剩的局面，用户不太可能因为你的功能较多而使用你的产品了，最重要的是你能满足用户的哪些需求以及对应需求的满足程度如何…

你是愿意选择一款功能多而齐全，但是样样都不精的瑞士多功能军刀呢，还是愿意选择一款小而美的军刺呢?

限制与聚焦

理论和实际之间有一个非常大的区别，那就是理论通常是建立在各种假设基础之上的，属于非常理想化的情景，而实际情况可能面临着各种各样的制约条件，比如没各种资源、没人力、没物力、没财力、甚至时间窗口都可能也快过了…

此外对于一个项目而言，资源也肯定是有限的，而时间、成本和范围又构成了项目的铁三角。在特定的时间和资源内，想要完成某些任务，那就只能缩减范围或者说牺牲质量。但是从长远的角度来看，牺牲质量带来的危害可能会更大…

从另一个角度来看，用户体验中的“多、快、好、省”本身也是相互制约的，很难同时满足这些。

以淘宝为例，淘宝早期主推的是多和省，所以早年的淘宝经常是假货不断，因为物品数量上去之后就很难保证质量了，也就是说很难同时保证既多又好…后来京东来了，主推的是快与好，成功的实现了与淘宝的差异化竞争，再后来天猫也加入了战场，主推的也是快与好。

用户体验里面的多快好省这几个东西本身是有冲突的，而且不同用户关注的重点肯定是不同的，此外在不同的阶段内我们需要重点关注的东西也肯定是不一样的，但是资源永远都是有限的，这个时候就只能去聚焦。聚焦于什么，聚焦于那20%的核心要素。

从上面两小节我们可以看到，只有少数的要素才是最为关键的，而资源永远是有限的，所以我们优先需要做的是最重要的事情。但是上面提到的都是比较抽象的概念或者说是在我们实际工作中很难感受到的东西，所以下面的小结就谈下我们工作中能够真真切切感受到的东西。

人月神话

之所以会提出来砍需求这种观点，一方面是基于优先级和资源限制的考虑，另一方面是从人的角度来考虑的。基本上开发和设计资源都是很紧张的，一旦协调不充分，就可能面临着延期的风险，即使资源协调的很充分，往往也可能会面临延期的风险。

通常情况下，我们安排的工期都是基于一个错误的假设，那就是一切都会良好的运转，每一项任务都只会花费它应该花费的资源和时间，然而这在很多情况下都只是希望而已。

实际上每一项任务都可能会延期，可能是预估难度不足，也可能是团队成员发生了各种状况，更有甚者可能因为某个人的离职而耽误了整体的进度。而每一个任务的延误，都可能会导致产品整体交付的延误，最终甚至可能会导致产品的失败…

那进度延误了怎么办？常见的手段无外乎加班和加人，前面这种方式大家可能也都习惯了，而且经常也会听到互联网公司说996…所以我们就重点说一下后面的这种方式，仅从人员成本的角度来考虑，不考虑其他的成本。

向进度落后的项目中增加人手，只会使进度更加落后。——《人月神话》

这个观点可能违背大多数人的常识，多数人可能觉得进度落后了多加几个人不就可以解决了么？然而实际上并没有这么简单…根据我的一次教训来看，加人能够在一定程度上推进项目进度，但是效果有限，甚至可能会起到反作用，加入新成员后整体的产出情况可参见下图。

对于加入的新成员而言，需要一定的学习成本，同时也需要能够快速融入到现有的项目团队中来，对于旧成员来说，需要在新成员身上花额外的时间来沟通，来说明项目情况，甚至还可能需要培训新人员，所以刚开始时整体的产出应该是负的，之后才会慢慢增加。

随着项目成员的增加，团队成员之间的沟通成本会成几何倍数增加，由沟通成本增加造成的效率降低甚至可能会大于人员增加带来的效率提升…那就相当于整体的产出还下降了。

另外当任务分解到一定程度时，可能就无法继续分解了，因为有些任务之间会存在依赖关系，没办法并行去做。也就是说，增加人员的效果是有限的，当任务细化到无法分解的地步时，增加新人员是不会带来效率的进一步提升的，甚至还可能会降低效率。

所以，在项目的进度落后时，即使加人也不一定能够赶上进度。

更何况可能根本就没有开发余量，那怎么办？我也很绝望啊…只能看看能不能砍掉一些需求，或者放到下一个版本再来做了，那怎么判断需求的优先级呢，也就是如何去判断哪个不该做、哪个该做、什么时候做、需要投入多少资源来做呢？

需求优先级的定义

首先需要明确优先级是怎么定义的，因为不同团队定义优先级的标准肯定是不同的。我先简单谈下在其他地方看到的优先级定义的方法论或者自己想到的一些判断方法…应该是足以满足日常工作需要的

优先级

主要就是确定判断的维度，可以从很多的维度来定义，比如可以粗略的分为紧急Bug修复>功能优化>新增功能，也可以从用户量与使用频次上来定义，优先满足用户量大且使用频次较高的需求，具体的落地方法可结合四象限法去分析…

性价比

性价比主要是从投入和产出这两个方面来进行评估的，一方面需要从需求的实现成本来出发，一般主要指设计、开发或者运营推广成本，另一方面是从需求的效果，也就是商业价值出发，优先做性价比高的需求。

重要紧急程度

重要紧急程度可以分为两方面，一方面是重要程度，一方面是紧急程度。重要程度又能够从使用人数、使用频次、需求重要性这几个维度来进行量化分析，比如可使用如下公式来量化：

●使用频次=使用总次数/使用人数；

●需求重要性=功能使用用户百分比（用户使用率）×功能使用次数百分比（功能或内容使用率）×类别重要性百分比（期望型需求、兴奋型需求）

紧急程度主要是从时间的角度来考虑的，一方面是基于上线的时间点来倒推，另一方面是基于开发的实现难度，当然还可以加入影响范围，可以做一张表格，让相关人员依次为各维度打分，基于各自的得分情况再来确定最终的优先级。

需求路径

这个主要可以从三方面来考虑，主要是需求大小、需求全过程以及需求一致性。需求大小主要是从量级上来判断的，有多少人有这样的需求、这些用户是不是目标用户，对我们有没有价值。

需求全过程指的是功能能否很好的满足用户需求的全过程，以购票看电影为例，整体流程为在线选座→下单支付→线下取票→观影，对用户而言这就是需求的全部过程。只有掌握了整体的需求流程，才能完成需求的闭环，进而去保证稳定而良好的用户体验。或许这就是美团电影早期愿意自己做线下取票机以及京东自建物流的原因吧…

需求一致性指的是新功能是否与用户的主线需求相一致，是否是必须添加的，依然以购票看电影为例，满足购票流程的就是主线的需求，如果偏离了用户的主线需求，需慎重决策，比如新增一个签到甚至换肤功能什么的（还真有人在类似产品的第一个版本提换肤的需求，手动微笑）。

其他

附一个之前在起点课程上Blues老师分享的一个判断优先级的标准。

基础需求必须做；

影响用户主路径的必须做；

符合项目目标需求的优先做；

覆盖用户面广的优先做；

性价比高的优先做。

我知道的判断优先级标准差不多就这些，日常工作中也基本上就够用了，大家有什么其他的判断标准的也欢迎补充。

方法论和大家分享了，也阐述了为什么我觉得要适当的砍需求了，至于砍还是不砍呢，这就要具体问题具体分析了…

以上就是本文的主要内容，欢迎斧正、指点、拍砖…