做业务系统与公众产品的区别
#做业务系统与公众产品的区别 -- 谈谈最近找工作换工作的一些体会 近一段时间找工作，从一个做业务系统的码农，转型为做公众产品的码农，颇有感悟。 ##业务系统 -- 业务业务，还是业务 给政府单位尤其是地级市以上的政府单位做业务系统，真是一个大坑。 ###原因 * 政府单位完全没有利益最大化这一说法，他们就是按照法律法规办事的一个群体。 * 在国内，法律法规说白了就是领导的意志，拍脑袋想出来的规定，而且变化起来没得商量的。 * 另外，区县以上才能称得上是一个合格的行政主体，地级市就是要把各个不同的行政主体统一起来，有时候就是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工具进行细化。
可能有人会说，其实后者也是一个坑，好吧，其实做码农哪里不是坑，只是坑适合不适合自己罢了。
