直通车点击



经常频繁的被客户询问系统开发的事情,现在对方一开口我就知道他是不懂还是不懂但又怕被忽悠。比如前几年那个最经典的问题:开发一个APP多少钱?现在变成了开发一个小程序多少钱?

根据阿拉丁发布的《2020 年 2 月小程序互联网发展研究报告》显示,微信小程序数量达到 390 万,过去两个月新增了 60 万个,而且新增速度还在猛涨。作为对比,苹果应用商店发展 11 年里积累的 APP 数量为 260 万。从数据上来看,小程序已经成为商家的标配,对普通商家触网来说,移动互联网就是小程序互联网。

现在不管是谁问我这个问题,我立马有种不想说话的感觉,相信同行都一样,哈哈。今天我把这个问题的核心整理出来,再有人问,直接把这篇文章丢给他,然后不做任何解释,相信双方都会满意多了。

首先,普及一个概念,开发一个小程序/APP的价格和建一座桥的价格是差不多的。为什么这么说呢?

比如下面下图左边的桥和右边的小程序,建设成本属于一个数量级:

往大里说,淘宝APP这么多年累计投入的开发成本应该建一座长江大桥绰绰有余,所以说任何不谈需求来谈价格的要么是耍流氓、要么是无知、要么只是以此敲开双方进一步沟通的大门。

因为佛系销售的原因,我的客户里面有很大一部分都是跟之前的公司合作不愉快的,结论都是对方技术不行做不出来,被坑被骗之类,我就经常纳闷了,开发业务型的小程序/APP有什么技术含量?不就是术业有专攻吗?曾经跟一个包工头朋友打比喻,他说看到我们用手指敲出一段段代码简直太佩服了,他一辈子做不到。我说我更羡慕他们,能站在几十米高的脚手架上砌砖头,那更是技术活,我更做不到。工种不同、术业有专攻而已,问题的核心还是你要建什么样的桥和实现什么功能的系统,可喜的是大部分人开工造桥之前都很明确要什么,遗憾的是大部分客户要建系统之前不知道要什么?这在一开始就决定了结果走向。

在明确了建桥或开发系统的需求之后(通常客户都说他对系统的需求很清楚,也简单,那极有可能是不知道自己不知道),其实建造过程也是一样的:

以造桥为例,先找机构、相关部门调研可行性,再出设计图纸,然后找施工单位、监工单位、建设验收。其实就是软件工程的瀑布/敏捷模型:可行性设计→需求分析→UI设计/编码→测试→验收→运营维护,只不过对于中小企业开发软件来说,甲乙双方都不愿意把时间花在需求的整理,因为甲方不愿烧脑与花钱,乙方不愿免费还要冒给同行做嫁衣的风险。大家都想快速跳跃过去进入下一阶段,对于中小甲乙方来说,通常把可行性和需求分析默认打包到开发工作里面去了,甲方不想花钱不想花时间,乙方想快点拿到项目不白做嫁衣,那又是一开始就决定了结果走向。

再说开发过程,最常见的风险不是技术风险,而是需求的不确定性与变化以及双方沟通不通畅到不信任造成的问题。还好我们在2016年全面结束软件外包开发业务(2013-2016主要做外包开发为主),坚定的走通用产品策略,幸运的是成功转过来了,其实没有侥幸。这条路,据说90%的公司都无法转型成功。因为从外包开发转向自有产品开发的跨度其实一点不比转行去修桥小,这个不展开,懂的人一看就懂,不懂的人呵呵,讲也没用。

那么对于标准通用产品,一次开发反复卖,是不是没有开发成本了呢?相信做产品的人经常会被客户问:这个功能都有了,稍微调整下很简单吧?

我就举一个例子吧:给系统加个购物车要多少开发成本?

说到这里我最羡慕的就是拼多多,他丫的居然没有购物车,全是包邮,一次拼团只能拼一个东西,而我为了给客户加个购物车,花了几十万和无数个日日夜夜调试。

市场需求1.0: 加个购物车,可以把商品暂存在里面,以后再下单。

市场需求1.1:购物车需要支持存放多件商品、每件商品可以设置数量。

市场需求1.2:购物车里面商品超过一屏要增加滚动翻屏功能。

市场需求1.3:购物车里要对已下架、无库存的商品打特殊标记显示,并拦截下单。

市场需求2.0:购物车里面的商品需要按客户不同地区单独计算运费,江浙沪包邮、华中地区除某地级市外Y元,西北偏远地区Z元,港澳台不接受。

市场需求2.1:购物车里商品运费要按数量计算,1件运费X元,自第1件起每增加1件加Y元,满多少件包邮。

市场需求2.2:购物车里商品运费按重量计算,首重X克运费Y元,每增加Z克A元,满多少重量包邮。

市场需求3.0:购物车里支持不同商家的商品(因为现在很多客户在卖自己产品的时候又一件代发卖别人家的商品),要求在购物车里进行拆单,按产品归属不同的发货商家形成不同的子订单。

市场需求3.1:不同商家的邮费策略不一样,需要用上面的按重量、按数量规则单独计算。

市场需求3.2:运费支持按不同发货地不同规则算,比如收货地址在上海,发货地在北京还是杭州要求运费不一样,按以上规则单独计算。(对不起,100万已经花了,这一点需求我们现在还没实现)。

市场需求3.3:如果客户购买多件商品发生部分退货,邮费可以选择退还或不退还或均摊退还。

市场需求4.0:购物车商品支持各自的优惠券抵扣,比如有优惠券仅适合A产品,有优惠券仅适合B产品,要在购物车分别扣减。

市场需求4.1:购物车商品支持优惠叠加,比如全部商品9折后部分商品有单独的优惠券再次抵扣。

市场需求4.2:如果发生部分退货,按照优惠券的使用途径原路返回折算。

市场需求4.2.1:如果购物车存在满X元减Y元优惠,如果发生部分退货,退完货总金额低于X元,要均摊减掉的Y元在退款里面折算抵扣。

市场需求5.0:购物车里增加分类、排序、按供应商排列商品。

。。。。。。

以下需求正在评估中,不在已经投入的几十万之列:

市场需求10.0:购物车里空白处增加广告区域,可以推荐爆款商品吸引凑单。

市场需求10.1:购物车里广告区域增加人工智能算法,根据客户历史的购物行为、后台大数据标签进行智能推荐,做到千人千面。

。。。。。。

所以现实中的冲突很多来源于甲乙方谈的是3.0版购物车,但由于没有做需求详细沟通和确定,然后3种可能性:

甲方期望的是4.0,乙方做的是2.0,这种就看双方沟通和协调了;遇到甲乙方星座相克的项目失败率很高。

甲方期望5.0,乙方做的1.0的,双方在一开始都有不真诚的成分在,结果看造化。

甲方期望10.0,乙方做出的是0.1,这种奇葩的案例不讨论。

软件开发就是这个样子,一入开发深似海,微软自1986年发布操作系统软件到今天,还在不停的开发,bug不断。微信自2011年发布以来还在不停的开发,还没完没了。所以那些我就是要一个小程序,实现淘宝的基本功能的人,我看没一个业务做的成功的(如果谁有引荐下)。。。

看到这里,大家心里应该大概有数了吧,最后给需要系统开发的人一点经验参考:

明确你需要什么,注意是现在需要什么(9年前张小龙向马化腾申请微信开发预算时一定不包含视频号功能的开发预算),然后再谈多少开发成本才有意义。

便宜的未必是好的,比如小程序商城,有花几百万开发的,也有淘宝上300块还送你几个G源代码的,功能还多很多。还有免费的,当然现在最牛的是那些你花钱买了,然后还要你把你的客户带过去的那种。

清楚背后的限制,比如你是否在意你的资金是可能要通过系统方过一手,将来是否具备二次开发升级的扩展性

微信咨询:jurenqi001 qq:874345023 电话:400-018-7928
Copyright © 2020www.zping.com.cn 渝ICP备08001062号-4 营业执照