作業務系統與公衆產品的區別

#作業務系統與公衆產品的區別
-- 談談最近找工做換工做的一些體會

近一段時間找工做，從一個作業務系統的碼農，轉型爲作公衆產品的碼農，很有感悟。

##業務系統 -- 業務業務，仍是業務
給政府單位尤爲是地級市以上的政府單位作業務系統，真是一個大坑。

###緣由
* 政府單位徹底沒有利益最大化這一說法，他們就是按照法律法規辦事的一個羣體。
* 在國內，法律法規說白了就是領導的意志，拍腦殼想出來的規定，並且變化起來沒得商量的。
* 另外，區縣以上才能稱得上是一個合格的行政主體，地級市就是要把各個不一樣的行政主體統一塊兒來，有時候就是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工具進行細化。

可能有人會說，其實後者也是一個坑，好吧，其實作碼農哪裏不是坑，只是坑適合不適合本身罷了。