为何以降本增效为导向的科技产品很难赚钱

一、上限太低
分析:当产品只能通过降低客户成本来证明价值时,定价就难以突破成本节约的边界。
举例:一件事情,客户成本为1000万,物理极限可以做到800万,那该产品理论最高的天花板就是200万。但总要让利给客户吧,那就收一半100万。
结局:客户第二年还会要你降价,同行也会竞相压价,于是第二年到了80万。一路走低,直接到你的盈亏平衡点,大家都没得赚。

二、投产难以衡量
分析:客户降本第一年看得到,第二年就成了应该。而所谓的效率提升,价值很难量化。再加上软硬件成本,投产并不一定划算。
举例:客户买了一个AI的提效工具,把员工每天10个小时的工作,压缩到了8个小时,那客户获得了什么?同时还要买软件、买云服务器、雇运维人员等,又是一堆投入。
结局:客户没看到收益,但投入增加了。说好的降本增效,结果成了增加成本,公司效益并没实际提升。

三、降的过程,阻力重重
分析:降本往往意味着裁员或削减部门预算,阻力重重
举例:一个软件服务公司,能降的最大成本无非是人和云的费用。降本不裁员、不减少云的投入,根本看不到明显的降幅。
结局:人减少了,云投入减少了。做后大家一总结,有没有这个产品,其实降本都达成了。

四、降的趋势,难以持久
分析:降本增效有物理极限的,接近极限后,就难以有大的成绩了
举例:第一年效果显著,第二年效果尚可,第三年后只能保持,越来越难
结局:客户获得感越来越低,要么降价,要么被扫地出门

一个真实的例子是,一个技术团队,通过大量的努力,用了各种各样的技术和非技术手段,将云费用压降了60%,人力费用压降了75%,很了不起对不对。但到了第三年末,在谈预算的时候,财务对该团队的期望是略有增长、保持现状、还是继续可以看到一个显著的降幅呢?

快速成长的必备软技能25:别造轮子

快速成长的必备软技能25————轻易不要造轮子

我们有些兄弟,对技术和解决问题有极大的热情,但又会有个小问题,有事就容易上头,总想自己去造轮子。

我之前经历过一个项目,做移动互联网挂号的,甲方是一个超级大三家。
为了应对流量冲击,设计的时候势必要引入消息队列,去削峰填谷。
当时整个团队都很有极客精神,技术水平也不错,感觉MQ中间件比较笨重,就花了半天,借用Redis揉了一个。
结果上线不久,消息一扩散,大家都来抢号源,没几天系统就崩了。
于是在这个基础上,越走越远,调优,抗住,崩了,再调优。

甲方的人也坐不住了,用户叫骂声一片,毕竟看着有号但挂不上,过一会儿系统恢复又没了,能不急么。
痛定思痛,用了MQ,好了。。。

复盘时,大家还是七个不服八个不愤,认为自己可以继续调优。
这时候,项目负责人问了一句,这个MQ中间件,别人优化了N年。你们凭啥觉得自己一两周的赶工,能干过别人N年的努力呢?

其实,在业界,如果现有技术如果能满足要求,成本最低的方法,往往是使用现有技术。
当现有技术无法满足要求时,大家会想办法去调优。
如果调优也无法满足时,才会去造轮子。而且造轮子,并不是一般的人和团队能承担的起的。

那些头一热就要造轮子的人,一般都是在开着汽车换轮胎的紧急时候,才会去想造轮子的。
几乎没有时间测试、调优、写文档,只追求能用就行。
但请注意,生娃不养娃,罪过甚于不生娃。
这个轮子造了,为了让轮子活下去,你要不断去完善功能,完善代码,甚至不断的回应社区。
这样,100个轮子,才可能有1个活下来。

否则,就是给后来维护的人,挖了一个巨大的焦油坑,不断造成无尽的浪费。

对了,还有类似的行为,大家可能都遇到过:
这个服务/功能,咱们用XXX语言再写一遍吧
最近XXX技术很火,咱们把YYY换了吧
这个项目,我们可是没有用XXX框架,而是自己从头实现的哦

遇到这种情况,先别上头,先考虑一下三个问题:
1、必要性:确实不造轮子不能解决问题吗
2、投产:公司、团队、个人能得到什么
3、轮子能活下去吗?你和团队能有多少热情,能投入多少资源

快速成长的必备软技能24:化繁为简

快速成长的必备软技能24:化繁为简

在职业生涯中,你会发现两种人
一种能快速的从复杂问题中,找到问题的关键,把事情主要矛盾分析清楚
一种能快速的把问题搞的复杂无比,让事情变得困难,让小事变成大事
而且两种人,在不同的企业文化下,好像都能活得不错

作为技术出身的人员,一般比较直接,不太擅长应对第二种人,更不擅长“没有困难制造困难”
所以多数的,都会逐步演化成第一种人

化繁为简,看起来很难,需要经过大量的训练,但抓住一些点,就会变简单:
1、搞清楚真正要解决的问题是什么
2、为了解决这个问题,至少至少要完成哪几件事情,要投入什么资源
3、搞清楚相关方的利益都是什么
4、做出合理且恰当的安排

经过这些训练后,相信你也可以做到,在千头万绪中,快速抓住主要矛盾,集中精力解决问题。