为什么我们总在做加法，却很少做减法？_最新动态_新闻资讯_程序员俱乐部

　　每个人都知道产品有一大堆功能其实不是什么好事，也有几百篇文章在讨论产品管理，告诉我们为什么避免功能臃肿如此重要。

　　你的公司也可能像我的公司（HubSpot）一样，有着一支优秀的产品团队，由一群智商过人、目标明确的同事组成，他们关心用户体验，对产品管理中的取舍问题有自己的见解。

　　那么，为什么还有这么多的产品会出现功能臃肿的情况？我们又该如何降低自己陷入这种情况之中的可能性？

　　我们可以分析一下关于臃肿功能的五个“为什么”，看看它到底是如何将我们带入死胡同的。

　　1. 我们为什么会有臃肿功能？

　　因为我们一直在添加新功能，却很少删除旧功能。随着时间的增长，产品累积了越来越多的功能。这是个很简单的数学问题：我们只做加法，不做减法。

　　2. 为什么我们一直在添加新功能，却很少删除旧功能？

　　因为添加新功能比较容易。作为产品部门，我们的任务是创造一个优秀的产品，吸引一批愉快的用户。给产品添加新功能是改善产品的一个普遍办法。我们之中大多数人都有一个单子，上面写满了来自用户、潜在用户、销售团队、营销团队、客户团队还有创始人的各种改进建议。

　　大部分时间里，我们都在思考单子上的哪一个功能能够带来更多的影响和资源，接着就把它添加进去。产品部门总是在受到各种批评，批评我们采用了这个创意却没有采用那个。我们的使命似乎就是不断完善产品、添加功能，好让我们满足用户的期待。

　　但似乎没有哪个产品团队会因为添加了太多新功能而受到批评。因此，我们不断地、匀速地添加新功能。但更有趣的问题是，我们为什么不删除功能呢？

　　因为删除功能比添加功能要难太多了。

　　3. 为什么删除功能这么困难？

　　因为我们很难判断哪个功能该被删除。通常没有人会要求我们把功能删除，但总是有人在推荐某些特定的功能。他们表达支持、不断游说，还往办公室送来蛋糕和饼干。

　　但我敢打赌，没有人会送你点心来劝你删除一个功能。如果你正打算删除一个大限将至的功能，你更可能会像是一个为荣誉奋战的孤胆英雄。和其它那些孤胆英雄一样，英勇的战斗并不会给你带来名声、荣誉和饼干。事实上，你还可能不得不和公司内部的成员（比如销售团队）决斗，出于对不良影响的考虑，他们是断然不会让你轻轻松松删除功能的。

　　4. 为什么判断哪个功能该被删除这么困难？

　　因为你很难判断删除这个功能是否值得。

　　有些用户可能还在用着这个功能，有些可能还特别喜欢这个功能，有些甚至是冲着这个功能才买了这个产品。如果你要删除这个功能，有些人可能会扬言不再购买你的产品。

　　这就是产品管理如此困难的原因。你得试着在不同的时期中平衡不同群体的不同需求。有些决定从长期来看是完全合理的，但从短期来看就很难解释。

　　5. 为什么你很难判断删除这个功能是否值得？

　　因为删除一个功能带来的好处需要过段时间才会显现，但这个行为带来的痛苦则是立等可取的。

　　况且，这个功能也不能说是“不好”。毕竟这个功能背后的理念是从一长串备选中脱颖而出的。既然添加了这个功能，就有添加它的理由，它也确实能给一些人带来好处。

　　为了能被实施，理念们必须经历残酷的竞争来争夺资源，可谓是千军万马过独木桥。

　　同时，我们也会认为添加这个功能所用的资源已经是沉没成本了。我们也认为沉没成本既然已经“沉没”，就应该把它清除出我们的脑子。

　　那么，既然我们已经得出了这样一套理论，我们要如何解决臃肿功能的问题？

　　以下是我的一些看法：

　　作为产品部门，我们手中的数据是不完整的。我们努力工作，为的是所谓的“惊叹率”（利用最少的资源获得了最多用户影响的工作比率）。我们凭借着当下手头的数据和资源做出选择。但我们的选择不一定总是正确的，也不应该苛求它永远正确。

　　因此，我们首先该做的，是接受这个事实：我们都会犯错，我们添加的某些功能到最后其实是臃肿无用的。

　　另外，既然我们无法预知哪个功能会沦为臃肿功能，我们要如何在之后的实施中发现这个事实呢？

　　答案当然是利用数据！在这个时代，我们拥有无数的数据来分析用户行为，我们应该跟踪产品中的各个功能（特别是新功能），并且分析它们的实际使用率。

　　举个例子。我们都知道“设置”的作用。当我们无法决定一个功能应该这样操作还是那样实施时，我们放弃无谓的争吵，把决定权交到用户手里，这就是“设置”的作用。

　　且不评论设置的这种“妥协”性质。就假设我们已经为产品添加了一个新的设置值来供用户选择。这个设置值通常有一个“默认”属性，还有一些其它不同于默认的可调整项目。

　　你应该判断的标准就在于：在一个统一的前提下（新设定已经添加），有多少用户会将它从默认值调整为其它数值？撑死了也只有 10%。当然并不会真的有 10%，但我们姑且就算它是 10%。这意味着，为了方便一个想要改变设定的用户，我们让其它 9 个用户的生活都复杂了一些。更别说在你的团队里，还有一大批人需要记录、支持、修正这一设定。

　　从长期来看，这个行为是否值得？有可能值，更可能不值。

　　但是我们就这样把它放着，想着“这是沉没成本啦，别管它了……”

　　这其实是一个巨大的谬论。一个功能的大多数成本并非在于其开发早期，而是在于发布后那段长长的时光里。

我认为，你应该做的有这些：

　　确定一个“使用率／价值最小值”作为门槛，所有功能都必须超过这个门槛才能留下来，那些在一定时期内没能达到要求的新功能？删掉。

　　只要删除合理，就要支持这个举动。要清楚虽然删除功能会带来短期的疼痛，但从长远来看是完全值得的。

　　创造一个文化，鼓励“英雄”们像添加功能时一样奋斗于删除功能的战役之中。