#做业务系统与公众产品的区别
-- 谈谈最近找工作换工作的一些体会
近一段时间找工作,从一个做业务系统的码农,转型为做公众产品的码农,颇有感悟。
##业务系统 -- 业务业务,还是业务
给政府单位尤其是地级市以上的政府单位做业务系统,真是一个大坑。
###原因
* 政府单位完全没有利益最大化这一说法,他们就是按照法律法规办事的一个群体。
* 在国内,法律法规说白了就是领导的意志,拍脑袋想出来的规定,而且变化起来没得商量的。
* 另外,区县以上才能称得上是一个合格的行政主体,地级市就是要把各个不同的行政主体统一起来,有时候就是N套不同的业务系统要集合在一个系统里面。
###细化分析
一般的企业软件,举个例子,我要做“销售额”,那我只需要描述一个实体,就是“销售额”,业务量是1。
当我们要做业务系统时,要把每一个步骤都描述清楚,所以我们会有这样的描述,业务量是n
|实体|
|-|
|销售额步骤1|
|销售额步骤2|
|销售额步骤3|
|销售额步骤4|
|……|
要做地级市以上的业务系统,就是这么一个表格,做**笛卡尔积**,业务量n^2
|实体|地区|
|-|-|
|销售额步骤1|A区|
|销售额步骤2|B区|
|销售额步骤3|C区|
|销售额步骤4|D区|
|……|……|
领导明天突然拍脑袋,把前面的工作量否定了,那么得加上一个时间维度,变成n^3。不要说什么需求把控,你客户只是一个地级市行政单位,收到国家那边发下来的变化,他也是无能为力的。
再加上**政府单位完全没有利益最大化这一说法**,故他们的“销售额”是不能按常理去描述的。然后再加各种细问题,如没有先前的成熟案例,比较奇葩的上司,比较奇葩的客户……
其实后面的不是根本问题,属个体现象,第一个是不能撼动的根本。导致工作上除了业务、业务还是业务。
###结果
* 星期一开会,定下来本周的工作量,然后周二就告诉你有一个突然增加的工作量,要周四前做完。到了周三,然后有一个更更紧急的工作量……
* 开发紧急,测试不重视,导致开发的质量问题,然后又赶紧上线,客户当然各种投诉了,这产生的很多紧急的BUG又会反过来加重开发,一个恶性循环
* 这样的公司不会重视技术人员,他们只会重视PM,能把客户忽悠下来,就OK了。
##公众产品 -- 比较可控的进度与质量
回过头去,一个公众产品,工作量基本上就是1左右,再多一点可能就是n左右,我不太相信博客园对于推荐博客和一般博客开发不同写博流程,不太相信github上1000星以上的项目就另外一个通讯协议。做一个公众产品,是要把这样一个1或者n的工作量做好,去吸引符合那个产品当初定义的客户去使用。
##从前者转变为后者
本人2月3月写的几十篇博客,就是从繁杂的工作量中抽取出自己的积累。当时我只知道前者是一个坑,当时我也没有想到从这个坑跳出来能到哪里去。工作量的减少,做公众产品的公司当然是要把更加多的精力集中在产品质量上了,而技术是提升产品质量的根本。记得当时面试时有一个面试官问我:**你之前做的这些项目中都用到了哪些技术?**当时我就懵了,“技术”这么抽象的词,到底有什么内容?深陷在业务中太久,只知道把业务功能做出来,用什么技术根本就不管,所以连这个问题都答不出来。
`可怕的不是你有没有这个能力去掌握技术,而是你根本不知道原来要去掌握技术`
感谢互联网的开放,当我们知道有么一个点之后,能够很方便地去查找到资料。前端工程师都要掌握哪些技术,这里有两个总结。第三张图是针对前端所要掌握的JS工具进行细化。
做业务系统与公众产品的区别
-- 谈谈最近找工作换工作的一些体会
近一段时间找工作,从一个做业务系统的码农,转型为做公众产品的码农,颇有感悟。
业务系统 -- 业务业务,还是业务
给政府单位尤其是地级市以上的政府单位做业务系统,真是一个大坑。
原因
- 政府单位完全没有利益最大化这一说法,他们就是按照法律法规办事的一个群体。
- 在国内,法律法规说白了就是领导的意志,拍脑袋想出来的规定,而且变化起来没得商量的。
- 另外,区县以上才能称得上是一个合格的行政主体,地级市就是要把各个不同的行政主体统一起来,有时候就是N套不同的业务系统要集合在一个系统里面。
细化分析
一般的企业软件,举个例子,我要做“销售额”,那我只需要描述一个实体,就是“销售额”,业务量是1。
当我们要做业务系统时,要把每一个步骤都描述清楚,所以我们会有这样的描述,业务量是n
实体 |
销售额步骤1 |
销售额步骤2 |
销售额步骤3 |
销售额步骤4 |
…… |
要做地级市以上的业务系统,就是这么一个表格,做笛卡尔积,业务量n^2
实体 |
地区 |
销售额步骤1 |
A区 |
销售额步骤2 |
B区 |
销售额步骤3 |
C区 |
销售额步骤4 |
D区 |
…… |
…… |
领导明天突然拍脑袋,把前面的工作量否定了,那么得加上一个时间维度,变成n^3。不要说什么需求把控,你客户只是一个地级市行政单位,收到国家那边发下来的变化,他也是无能为力的。
再加上政府单位完全没有利益最大化这一说法,故他们的“销售额”是不能按常理去描述的。然后再加各种细问题,如没有先前的成熟案例,比较奇葩的上司,比较奇葩的客户……
其实后面的不是根本问题,属个体现象,第一个是不能撼动的根本。导致工作上除了业务、业务还是业务。
结果
- 星期一开会,定下来本周的工作量,然后周二就告诉你有一个突然增加的工作量,要周四前做完。到了周三,然后有一个更更紧急的工作量……
- 开发紧急,测试不重视,导致开发的质量问题,然后又赶紧上线,客户当然各种投诉了,这产生的很多紧急的BUG又会反过来加重开发,一个恶性循环
- 这样的公司不会重视技术人员,他们只会重视PM,能把客户忽悠下来,就OK了。
公众产品 -- 比较可控的进度与质量
回过头去,一个公众产品,工作量基本上就是1左右,再多一点可能就是n左右,我不太相信博客园对于推荐博客和一般博客开发不同写博流程,不太相信github上1000星以上的项目就另外一个通讯协议。做一个公众产品,是要把这样一个1或者n的工作量做好,去吸引符合那个产品当初定义的客户去使用。
从前者转变为后者
本人2月3月写的几十篇博客,就是从繁杂的工作量中抽取出自己的积累。当时我只知道前者是一个坑,当时我也没有想到从这个坑跳出来能到哪里去。工作量的减少,做公众产品的公司当然是要把更加多的精力集中在产品质量上了,而技术是提升产品质量的根本。记得当时面试时有一个面试官问我:你之前做的这些项目中都用到了哪些技术?当时我就懵了,“技术”这么抽象的词,到底有什么内容?深陷在业务中太久,只知道把业务功能做出来,用什么技术根本就不管,所以连这个问题都答不出来。
可怕的不是你有没有这个能力去掌握技术,而是你根本不知道原来要去掌握技术
感谢互联网的开放,当我们知道有么一个点之后,能够很方便地去查找到资料。前端工程师都要掌握哪些技术,这里有两个总结。第三张图是针对前端所要掌握的JS工具进行细化。



可能有人会说,其实后者也是一个坑,好吧,其实做码农哪里不是坑,只是坑适合不适合自己罢了。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步