“创业”之所以打上了双引号,是因为我要讲的这些工作,都是利用业余时间,契而不舍一点一点肝出来的成果。
有时我也会庆幸对于IT业来说,创业的门槛没有传统行业那么高,一台电脑一个车库,再加上一个人就可以开始了。从我接触编程开始,我就想做自己的“东西”,希望有一天能够做一款受到大家认可和喜爱的软件。在那个时候,“mp3 cd maker”、“fox mail”、“超级解霸”、“网络蚂蚁”之类的软件作者,都是我和许多同时代程序员崇拜和追求的目标。
相比于一些程序员痴迷于代码本身的魅力,我更看重产出的成果,更看重产品。从那个时候走过来的程序员,基本上自己就是产品经理。初期做过许多小工具,小软件,用 VB 做过播放器、用 Delphi 做过 Zip 工具,便签工具等等有的没的小玩意,略过不提。
我正真想做自己的企业级的产品,有三次经历。
Github:
https://github.com/iccb1013/Sheng.Winform.IDE
这个系统没有正式的名子,只有一个开发代号:Sheng.Winform.IDE。
第一次是想做一款 IDE,大约在 2010 年前后,是各类 ERP 软件最流行的时候,我在公司做了许多管理软件类的项目,从程序员到项目经理,做了没两年,就发现基本是重复劳动了。
我就想能不能开发一款工具软件,把底层逻辑抽象出来,上层业务部分通过配置的方式生成呢?市场上有一些类似的产品,但是在我看来做的远远不够,基本是围绕自家原有产品做的部分页面表单自定义,功能比较薄弱并且无法脱离原有产品框架。我当时想需要实现一种中间描述机制,通过 XML 之类的方式,产生针对业务而脱离技术框架的中间描述语言,我开发出对应的 IDE 开发工具,导出 XML 。另外再根据平台和基础产品的不同,开发出不同的表述框架来解析和实现最终业务功能。
我在业余时间,花了大量的时间思考这样的一款产品应该怎样设计,坐公交坐地铁的时候,都一直在想,想到了新的问题或者灵感,就马上拿出手机记录下来。在当时要做这样一款工具,本身是有一定技术难度的,另外对于我当时的技术水平来说,也是很大的一个挑战。有时想想一个问题逻辑上应该怎样解决,却不知道怎样编码实现,就只好带着各种问题去查资料,看书学习。有许多本书我是在地铁上,在车上一天一天看完的。为什么要这样看书呢?因为要解决的问题要实现的功能一是复杂,二是基本是体系性结构性的问题,不是非常具体的一个问题点,搜索都不知道搜索什么。
当时有一款开源 C# IDE 叫“SharpDeveloper”,我仔细阅读了它至少一半的源代码,后来也借鉴了许多它的设计模式和理念。
最终我做这件事,大约历时了两到三年,几乎所有的业余时间,得到了这么一个东西:
详细介绍:
https://blog.shengxunwei.com/Home/Post/30bcf36f-5ff7-412b-bb47-763ce9218bce
这里自夸一下,这个系统里有太多太多的技术细节,对编程基础和设计能力有很大考验。
最终这个产品,在初具雏形的时候,我放弃了。
我在开发这个软件的过程中,犯了许多的错误,这些错误未必是技术上的,但都是严重错误。
首当其冲:闭门造车。
活在自己的技术宅世界里,从来不去想,也不愿意去想这个东西有多少实际价值,谁会去用它,到了后来,我明明潜意识里知道这个软件没有太大市场价值,就是不愿意去想这个问题,一门心思去开发。但是这么辛苦的意义是什么呢?我当时没有认真的思考。
目标非常的不明确。
看上去有目标,我要做一个什么什么样的东西,但是太宏大,太宽泛,太遥远。没有认真的考量我要的到底是个什么,所以完全没有详细的计划,里程碑什么都没有。
缺少与外界沟通。
这个沟通除了技术,更多的是市场对技术的需求到底是什么,如果回到当初,我会抽自己一巴掌,你睁开眼睛,走出去看看别人的世界好吗!做技术不是高新技术行业,更多的是服务业,我们需要利用手中的技术去为他人服务,这是技术存在的意义。
不懂快速迭代,最小可用集。
这个概念现在应该大家都知道了,在当年好像并不是很流行,也可能和我长期做企业级开发有关系,项目周期都非常长。做产品如果不懂得快速迭代是非常危险的,最小可用集就是只要达到最低可用的限度,就立马拿出去见人,当然范围可以是有限的。根据 真正 用户的反馈,快速调整。这个说起来简单,技术人员做起来很容易失控,我做这款软件,就是花了大量的时间精力去研究技术方面的问题,以至于在某些方面挖的非常深,但是这个东西和我的 大目标 其实没有必然关系,不管技术好不好,差一点就差一点,先做出东西来,先用起来,功能先实现,业务先转起来,论证了这东西基本的可行性,再通过迭代去优化。
做东西尽量不要藏着掖着。
没意义,藏着掖着无非怕别人剽窃了自己的创意,想法,这个先不论创意想法有多大实际价值,就算你的想法真的很厉害,如果你没有其它门槛,别人看了就会抄去,那你这个东西一定是会出问题的。门槛这么低,怎么就你想到了?别算别人确实一时没想到,你没有其它门槛,被抄了是迟早的事情,藏着掖着没有用。做了东西就要勇敢拿出来和人交流,正面的就吸纳,负面的就多反思自己。
学习
我看完了《人月神话》,《代码大全》,《设计模式》,和其它一些不是那么有名的书籍,一半以上 SharpDeveloper 源代码。很多是在地铁,长途车,火车里看的,当时好像没有平板,有一次在火车上抱着笔记本电脑看《设计模式》,被旁边妹子主动搭讪:“你是程序员吧”,想像一下,绿皮车,一堆人…… 上面讲的几本书我推荐有时间就看一看,特别特别是《代码大全》,一定要看。我的体会是如果没有目标,没有目的的看书学习,很难深切领会,很容易泛泛而谈,我当时看这些书大部分原因是被逼的,因为我总是遇到我搞不定的问题,我必须去寻求解决方案,比如设计模式,我当时也是被逼急了,有结构上的问题搞不定,就到处查资料,看书,一边看一边带着目的的去想,这样行不行,那样行不行,这样成长确实比较快。
一个偶然的机会,我了解到了在线客服系统的业务需求和业务场景,我决定自己开发一套这样的软件。
虽然我当时基本了解了这个系统所需具备的基本功能和目的,但是我需要自己一个人从头开始设计和实现它,包括推理它的服务器部分是怎样设计和实现的,客服端软件是怎么做的。我花了大量的时间对同类软件做分析和调查,自己编写相关的文档资料(给自己看),尝试解决其中的技术问题。和之前做 Winform.IDE 一样,几乎所有的业余时间都在思考关于这个系统的问题,从产品设计到技术实现,凌晨 2 点以后休息是常态,大概从我做 Wiinform.IDE 开始就已经是常态了。
持续了大约两年左右,开发出了初步可用的版本,我开始尝试推广它,我这次克服了第一次“创业”中的一些错误,但是又犯了新的错误,好了,我又要开始总结反思了:
开通试用的门槛太高
我当时偷了个懒,没有开发用户自主注册开通的 Web 管理后台。有兴趣的用户必须通过给我留言的方式,我手工开通再回复对方登录信息。可想而知这种方式用户量肯定是很难积累的。
系统架构设计太复杂,调子定的太高
这可能是一个程序员骨子里最难克服的障碍,在系统设计时,定位很高,瞄着集团用户去的那种。在系统架构上,设计了负载均衡、路由服务、分布式服务架构、关系型数据库(还做了分库)、内存缓存数据库,消息队列,还有什么的全用上了。可以说花了大量的时间和精力在这些事情上,却没有把面向用户侧的体验细节做好,连自主注册都没有。
时间来到了 2015 年前后,微信一天比一天火起来,“公众号”这个新鲜事物也越来越流行。狗熊掰棒子的故事来了,我丢下了客服系统,开始研究微信公众号了。
GitHub:
https://github.com/iccb1013/Sheng.WeixinConstruction
随着微信公众号的流行,我留意到了一个新的方向,公众号运营平台。当时大大小小的商家,企业,都愿意尝试开通一个自己的微信公众号,当时主流的公众号平台功能都偏重于线上活动营销,而我留意到的方向是线下实体商家,当时原有的公众号营销平台在功能上并不特别关注“线下”场景,线上线下的营销活动往往是脱离的,比如商场、超市、影城等等。
当时还没有微信小程序,回过头来看,我当时想做的东西,正和后来的微信小程序有类似的理念,到店扫码即用,线上线下场景打通。
于是我打开 Visual Studio ,点击新建解决方案,又开始肝了。
详细介绍:
https://blog.shengxunwei.com/Home/Post/0fb606f8-5def-4c10-9896-c53f1c7cb8ea
大概经过小半年的时间,产品有了雏形,我开始试着推广,这次我汲取了教训,开始边推广边开发,试了百度关键词(地域定向投放),也自己跑地推,跑了很多商家,包括展览馆,电影院,百货公司商业中心等,我们这里的电影院和百货公司基本我都跑遍了,电影院跑到了县一级,我自己上门陌拜,跑销售就是不要怕,虽然会吃闭门羹,但总会有人愿意接纳你,有一家电影院和我“重度”合作了一把,专门为上我的这个系统做了大幅画的户外广告。
很快我发现,这不是一个好的方向,这次我得到的心得和体会:
产品的方向和形态非常重要
产品的方向不用说,决定了产品是否有前(钱)景,这个大家都知道,但是要特别注意的是你的产品的形态,拿微信第三方平台来说,这是一个很难取得高客单价的一个产品,往往对方的预算只是一年小几千块钱,甚至更少,觉得这些东西应该免费的商家也不在少数。竞争是一方面原因,更重要的就是产品的形态造成的。
云平台是否是银弹
从技术角度来说,云平台有诸多优点,甚至我们会觉得,云平台对客户来说也是有巨大优势的,比如成本和价格优势。但是,对于企业来说,对方是否愿意,是否放心把数据全部交给你?如果你是一家创业公司,这个就更悬念了,因为你没有足够的实力为你背书,有客户直接和我说,如果你不能把产品和数据库部署到我的服务器上,我宁愿不用。 这种情况我们不能单纯的认为是客户观念老还是怎么样,应该去适应这个市场和客户,客户不是那么容易说服的,信任不是一朝一夕能够建立的。
做产品还是做项目
技术人员都希望能做产品,也许没有人不想做产品,做出来卖授权坐在家里收钱,但是我的建议是创业型公司慎做产品,产品化程度越高的,你越不要去做,当然,除非你掌握了某种复杂的业务,是一般软件公司很难掌握的,或者你有什么门槛是别人根本不可能有的,这个不在我现在讨论的范围之内。
一般而言产品化的东西,意味着竞争的激烈,价格的下探,客户预期的不断提高,这些是创业型公司难以承受之重。我现在更推荐走项目之路,很多项目虽然看上去辛苦不堪,技术上缝缝补补,但是一年的项目经费能够吊打你脑海中想像的产品能带来的营收。而且做项目一般会有一些天然的门槛,比如特殊的业务逻辑,特殊的使用场景,你一旦一期二期做下来,基本这就是你的客户别人很难抢走了。2017年我只带着做了2个项目,收入就已经几十倍于过去所谓的产品收入。也是我现在丢弃微信产品全部开源的原因之一吧。
如果做产品遇到竞争,是打价格战,还是寻找差异化
过去我看过一些文章,都会告诉你寻找差异化,我也是这么过来的,吃了一些亏有了自己的想法。我的想法是在竞争激烈的市场,如果遇到了价格战,而你又打不起,就及早退出,改变方向,千万不要死撑去寻找所谓的差异化,会让你更加陷入泥潭,亏损更大。在充分竞争的市场,有什么差异化等着你去找呢?也不要寻求技术的先进性,技术的先进会使你投入更多的成本,但不会有任何实质性的作用。
所以,打价格战,打不起,及时止损,退出竞争,不要心存幻想,不要等。
做项目的关键是什么
就一点:优质客户资源。
在我意识到微信公众号平台不是一个好方向之后,我消停了一段时间,工作上的事情也越来越忙,业余时间越来越想让自己休息休息,荒废了一段时间。
很快到了 2020 年,疫情加经济下行,公司的信息化业务毫无起色,我只好主动找老板说:在这块业务能挣钱之前,别考虑给我加薪和奖金了。
话是这么说,精神上的压力还是很大,想想还是得把业余时间用起来,不能这么荒着,一时没有好的方向,就把客服系统捡起来继续做吧。
这次我痛定思痛,好好回顾了之前的经验教训,重新开始审视这件事,我做了以下这些工作:
我推翻了之前 .Net 框架的服务端全部设计,用 .Net Core 又重写了一遍,取消了暂时用不到的各种复杂设计,只保留下未来可扩展的空间,轻装上阵。对于网络通信这块,做了大量工作,保证用户使用时的稳定性,甚至做到了断线时的会话保持,自动重连。
由过去的只支持 SQL Server 改进为同时支持 SQL Server 和 MySQL。服务器也实现了 Linux 支持。
重构了 Web 访问端的全部代码,取消取款 IE6 的支持,仅保留对 IE8 以上的支持。取消了一些非常啰嗦却不太重要的功能设计,同时在稳定性和速度上做了重点攻关。
用 VUE 开发了 Web 管理后台,有兴趣的用户可以自主注册开通试用了,不用联系我提前预约了。
在技术之外,我积极和朋友交流这件事,不论是技术层面的还是产品层面的,都毫无保留的和朋友交流想法,不但获得了很多有意义的见解,也为我积累到了一些种子用户。
最终得到了:
详细介绍:
https://blog.shengxunwei.com/Home/Post/44a31a32-d4e1-4ddd-8526-8a2bcd2e22be
可能是因为这次准备的比较充分,前期积累也多,系统上线以后,收获了一些实际用户,得到了许多积极的反馈,这是做 Winform.IDE 和 微信营销系统 都没有的。
其实做了这么多,钱是没挣着,都是免费开源的在做,核心还是兴趣在支撑吧。
客服系统算是折腾这么久,第一个没有虎头蛇尾坚持把它做上线的产品,达到了有实际用户在用的水平,这一点让我比较欣慰。
我想如果不久我离开了IT业了,我也会继续维护这个产品,一直保持免费,只要有用户要用就好。至少也是我做过这么多年IT,做过这么多年技术的一个遗产是吧。