一家做本地生鲜的客户，最初预算两万八。聊需求时，分销、直播、社区团购、积分商城、签到，恨不得全要。最后我们劝他砍到只剩下单、配送、优惠券三样核心，一万六上线，三个月回本，钱花在了刀刃上。半年后他主动加回了积分功能。小程序制作的功能取舍，砍得下才做得成，加法人人会做，减法才是真功夫。会砍需求的人，才是懂生意的人。
砍功能的刀，怎么下
判断标准就一条：砍掉它，用户还能不能完成从进来到付款的主流程？能，就砍。分销体系要做三级关系链和佣金结算，直播要推流和回放，每一样都是几万级的工程，而上线头三个月，你的问题不是缺这些功能，是没几个人知道你有小程序。功能堆得越多，界面越乱，开发费越高，测试面越广，出问题的机会也越多。四样东西一起上，每样都可能半生不熟，客人的耐心只够你做好一件事。先做好一件事，再谈下一件。
预留接口，不是预留开发
砍掉不等于不想。正确的做法是砍之前问一句：以后加回来，要不要推倒重来？架构上预留扩展空间，比如会员体系的数据结构先埋好，积分以后加上去不用迁数据；商品模型把规格、标签字段留足，以后做团购不用改底层，底子打好了，加东西是装修不是重建。但这只是留门，不是盖房——有些团队会劝你把框架全搭好，将来加功能方便，账面上多花的每一分钱，都是为还没发生的需求买单，说不定这需求永远不会来。
上线后的数据，替你做决定
功能要不要加回，别拍脑袋，看三个数：用户在现有流程里反复问什么，客服记录和留言里找；同行靠什么功能拉走了你的客；后台哪个环节流失最狠。客服记录和留言翻一遍，用户嘴里反复提的，就是下一个功能。用户排好的队，照着走就行。三项里占两项的，排进下一期；一项都不占的，继续放需求池里晾着。迭代的预算按季规划，一次加一个功能，做透一个再看下一个，钱和精力都花在明处，一期一个功能，做完就看数据。
需求会上敢砍功能的项目，上线时间平均能提前三四周，预算省下两三成，这些省下来的钱花在首月推广上，回报比堆功能高得多。做小程序制作方案时，让服务方按主流程优先给你排一版功能分级表，必做、缓做、不做三档标清楚，比格网络出方案一向这么排，先让生意跑起来，再谈锦上添花，顺序反了，两头都落空。生意先立住，功能才有人用。
