做为一个PM，我们常常在想要加什么功能，但你有没有固定回过头检视，什么功能已经可以砍掉呢？

功能不断叠加的危害

什么？为什么要砍掉？即使没人用，放在那边也不亏呀？

当然亏，功能一直加上去的结果，产品会变得越来越复杂，其实还会造成一些问题：

1、吃掉开发资源：每次规划新功能时，都要考虑新功能对既有功能的影响，要考虑相容性问题，也要思考系统资源会不会越吃越多，甚至光是文档越长越大，都可能遇到问题

例如我待过的某A公司，做硬体产品，功能写在软件，用户可以藉由升级软件，获得新功能，但常常遇到的问题是，功能越做越多，软件包越长越大，但是旧有机种的硬体规格不变啊！升级就会爆掉了，所以每次都要花很多开发资源做软件瘦身。功能越多，后续的开发与维护越不容易。

2、测试大发散：由于增加新的功能，也可能影响到既有的功能，所以每一次回归测试，都不能只测试新增的功能，而是要从头到尾测试一次，现在的平台又越来越多种，有网页、电脑版、iOS、Android、H5等等，所以会有测试项目越加越多的状况。一般如果没有发现这样的状况，测试人员人数不变，要测的越来越多，那就只有哭了啊！

3、营运维护超费力：由于前面的问题，导致潜在的bug，或是所谓的技术债，会越累积越多，前端客服、营运要解决的问题也越来越多，可能是客户不懂新功能就来问、乱按回不去原本要操作的页面就来问、有bug就来问、看到界面复杂不会用就来问……各种疑难杂症，会成指数型增长，而新的客服人员要学的东西也会越来越多，要面对的状况越来越複杂……。

接著，bug反馈给工程师时要理清的东西越来越多，解决bug要考虑的状况越来越多，修改与测试越来越久，反馈用户的时间越来越长，用户满意度越来越低……一切形成恶性循环。

所以，如果一个功能已经没有什么人在用了，没有带来价值，还要花一大堆力气维护，其实是一种资源的浪费。

常见的应对方式

传统上，解决以上问题的几种方法

1、加资源：用更好的硬体规格来解决系统资源不足的问题，例如电脑CPU i5跑不动，换i7就更顺、更快，或者是不升级硬体的话，做程序重构，让程式运作起来更有效率。

也就是说，我必须升级我自己的系统能力，例如之前写一篇公众号文章要五小时，只要我有办法写一篇只花两小时，我的人生不就多出三小时了吗？

但是升级硬体要花很多钱，做程序重构要花很多时间，而且这段期间看起来没啥产出，常遭到老板的质疑。必须思考，我有这样的时间做这件事吗？

2. 开发自动化测试：也就是尽量减少手动测试的项目，像一些功能测试，其实可以由程序这边运作就好，这可以解决测试人员不足的问题，维护程序的品质。

其实，上面解法的前提，是你的功能还有价值，所以有维护的必要，才要花钱花时间，让他能继续运作。真的没有人用、没有带来太大价值的产品，为什么要为它花钱花时间呢？各方确认沟通之后，勇敢地砍掉吧！

如何判断是否该砍

怎麽判断该不该砍？这就是数据的重要性了。

你的产品应该设计一个方法，让你可以知道使用者到底都使用什么功能、不使用什么功能、死在什么功能。

1、很少人用的功能，就是没有需求、没有价值的功能，这应该是最好砍的

但如果有少数用户用，砍了他们会抱怨怎么办？

这就好像你在生活中要拒绝事情，总是会得罪人，如果用户很少，你维护这个功能要花的力气很大，那还是好好跟用户沟通，然后勇敢地砍吧！Google砍掉这么多人用的Inbox，很多人骂，最终还是砍了！

必须先认清，没有什么功能是必要的，用户总是找得到替代方案，或者就干脆舍弃掉不适合的少数用户！

2、如果是很多人在用的功能，但是bug很多，要花很多力气维护，那怎么办？

很多人在用，代表有需求，有需求就有价值，我不会砍它，但我会集中火力把它的bug解决，因为很多人用还bug很多，这个影响很大。这就是消耗组织资源的大怪兽，解决这种问题，可以最大幅度拉高运作效率。

3、定期评估要不要继续做

资源这么珍贵，要让自己的投资更高效，我的思维是，既然投了资源就一定要看到回报。宁可在做每件事情时，累一点但有回报，也不要轻松，但是没有让人眼睛一亮的结果。而且，要建立检查点，定期检视成效，然后很快地决定要不要往下投资，不适合就砍掉。

看完这篇文章，可以来一个自我检测，你砍过你的产品功能嘛？