“要是当初多问一嘴，也不至于现在这么被动。”
一个做火锅的老板上周找我吐槽，他三年前花了两千多做了一套扫码点餐小程序，最近想加个会员储值功能，结果开发公司告诉他，当初那套系统的架构不支持这个功能，要改就得推翻重做，重新报价四千多起。
他当时就懵了。三年前花了两千多，现在想加个功能还得再花四千多，等于前面的投入全打了水漂。他说自己当初签合同的时候根本不懂这些，对方说什么就是什么，一句都没多问。
他的问题不是个别现象。很多老板做小程序的时候只关心“多少钱”和“多久能上线”，但很少有人问过一句“这系统三年后还能不能用”。今天就把这个问题拆开，告诉你那句话到底该问什么，以及怎么从对方的回答里判断你的系统能活多久。
一、为什么有的系统用了两年就废了？
一个系统能不能长期用，不取决于它刚上线时有多好用，而取决于它的底层架构有没有留好扩展空间。说人话就是：它能不能在你业务变化的时候，方便地改动和升级。
代码写得太死，改不动
有些开发公司为了赶工期和压低报价，会把功能写死在代码里。比如菜单分类，如果开发的时候直接写死了只有五个分类，以后你想加第六个、第七个，就得动底层代码，改动成本跟重做差不多。
这种情况在小程序和网站开发中非常常见。前期为了省钱省时间，牺牲了灵活性，后期业务稍微一变，系统就跟不上了。省下来的那点开发费，后面加倍还回去了。
用的是冷门技术或平台专属方案
有些开发公司为了绑定客户，会用一些比较冷门的技术方案，或者某个平台专属的开发框架。表面上看功能都能用，但当你以后想换一家开发公司做维护的时候，新团队一接手就傻眼了——这东西他们没见过，不敢改，也改不了。
就像你买了辆只能用特定品牌零件的车，哪天这个品牌的配件停产了，你的车也跟着废了。系统也一样，选了一个封闭的技术体系，等于把自己的命脉交到别人手里。
没有考虑后期的维护和升级成本
很多老板签合同的时候只看开发报价，不看维护条款。系统上线之后，微信官方每年都会更新接口规则，你的系统得跟着适配。如果开发公司不提供长期的适配维护，或者维护费高得离谱，你的系统就会随着时间推移越来越难用，最后用不了。
二、决策的时候多问哪一句话？
这句话很简单，但你得当面问，而且要看对方怎么回答。
“如果两三年后我的业务变了，想加功能或者改功能，这套系统怎么扩展？成本大概多少？”
这句话问出去，对方的回答方式决定了你能不能判断出他的水平。
如果对方这样回答，你可以放心一大半
“我们用的是通用的主流框架，代码结构是模块化的，功能之间互相独立。以后你想加会员、改菜单、接别的平台，在现有基础上改就行，不用推翻重做。维护升级我们都有标准的流程和报价，这些都写在合同里。”
这种回答说明对方在架构设计时就考虑到了长期的可维护性，不是做完就跑的心态。模块化意味着以后改一个地方不会影响其他功能，主流的框架意味着以后换别的团队也能接手。
如果对方这样回答，你就要多个心眼
“你放心，以后想改肯定能改，到时候再说。”或者“这个功能我们没做过，得研究一下，到时候再报价。”
这种回答的潜台词是：要么他没想过长远的事，要么他想用信息差拿捏你。现在不给你一个明确的说法，以后你再找他的时候，主动权就全在对方手里了。
三、除了那句话，还有几个事决策前就问清楚
光问那一句还不够，几个关联问题一起问了，才能把风险降到最低。
问清楚系统的技术框架是什么
你不用懂技术名词，但要让对方用你能听懂的话解释一下。比如问他“这套系统以后别的开发公司能不能接手维护”，如果对方支支吾吾说“最好还是找我们”，那就说明这个技术方案可能不够通用，有被绑定的风险。
问清楚维护和升级的收费标准
不要只问“有没有维护”，要问清楚维护包含什么、不包含什么，以后的升级费用怎么算。一个好的习惯是把这些写到合同里，别只停留在口头承诺。
问清楚数据以后能不能导出
三年后如果你想把会员数据、订单记录导出做分析，或者换系统的时候把数据带走，你的系统能做到吗？这个问题问出去，能筛掉一大批只管做不管后的开发团队。
四、总结一下
今天做的小程序三年后还能不能用，不取决于你做的时候花了多少钱，而取决于你做决策的时候有没有多问一句。问清楚了系统的扩展性、维护成本和数据归属，三年后你想怎么改都行。没问清楚，三年后你想改一个小功能都可能面临推翻重做的尴尬。
靠谱的开发方不会回避这些问题，反而会主动跟你讲清楚系统的长期规划。
像鑫时带科技在给客户做小程序开发的时候，会在前期就沟通清楚未来的扩展可能性，采用通用的框架和模块化的结构，确保以后客户想加功能、想换人维护、想导出数据都不受限制。维护和升级的收费标准也明码标价，不靠信息差拿捏客户。
一句话的事，问在前面是保护自己，问在后面是给自己添堵。
