作业务系统与公众产品的区别

#作业务系统与公众产品的区别
-- 谈谈最近找工做换工做的一些体会

近一段时间找工做，从一个作业务系统的码农，转型为作公众产品的码农，很有感悟。

##业务系统 -- 业务业务，仍是业务
给政府单位尤为是地级市以上的政府单位作业务系统，真是一个大坑。

###缘由
* 政府单位彻底没有利益最大化这一说法，他们就是按照法律法规办事的一个群体。
* 在国内，法律法规说白了就是领导的意志，拍脑壳想出来的规定，并且变化起来没得商量的。
* 另外，区县以上才能称得上是一个合格的行政主体，地级市就是要把各个不一样的行政主体统一块儿来，有时候就是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工具进行细化。

可能有人会说，其实后者也是一个坑，好吧，其实作码农哪里不是坑，只是坑适合不适合本身罢了。