天天看點

4年一輪回(前部)

  上一次寫總結是離開效力4+年(2010年上旬-2014年中下旬)的公司,在需要寫履歷的驅動下完成這4年職業生涯總結,最終這份總結放履歷裡面獲得了很多機會。現在重翻發現這4年太不值當,盡管這份經曆被消費了很多年。

  現在又是一個4+年(2014中下旬-至今),從結婚生子到工作上幾經輾轉後回到老家,中間發生很多事情。也許我命中每4年會有一個轉折,人生就是階段性的調整,希望2019而立之年後會更好。

  不善寫作,有點長,分前後2部,這是前半部。

-------2015年前後約一年(2014中下旬-2015年中下旬)

  在傳統行業公司(TZ)做OTT系統,見證整個行業的沒落。這一年比較折騰,每天上下班一起有3個多小時是在班車路上度過,每天上車第一件事就是找到自己熟悉的位置,然後帶上耳機聽各種書、演說,繼續補覺。

  由于公司遇寒冬轉型,各種調整。A項目做完V1.0被老闆看好,就被其心腹團隊接走了,B項目剛立項設計完成,整個團隊就被轉到子公司做其他業務,期間沒有做過完整的項目。第一次見到股份公司套路,一般比較看好的項目都會被拉到子公司,然後融錢或賣掉。

最後子公司拿概念創業,我們降薪拿技術股,再到拿不到投資,被套路、拖工資無奈走人。

  總結這一年,經曆公司殘酷的轉型、創業失敗,難忘的成長經曆

  技術:熟練使用AxureRP做原型設計、鞏固了Linux基礎并用Shell腳本完成網元系統自動化安裝和MySQL讀寫分離自動化安裝、JDK等基礎元件的自動化安裝。對OTT系統體系有個大緻的概念,算不上真正入這一行。

  期間寫了個類似Jenkins(當時不知道有這貨)的安裝排程系統(Y系統)。

  Y系統主要功能:

    1、配置管理,修改需要更新的網元配置檔案、目标環境資訊和上傳網元包;

    2、安裝,點選“安裝”按鈕後自動解壓網元包,可視化自動安裝完成并啟動服務;

    3、運維,一次配置後,再有更新隻需要上傳更新包,點更新就自動完成安裝和配置。到離開後第二年還有人在咨詢Y系統使用上的疑問,忍住沒告訴他有Jenkins的存在,算是被套路後的報複吧~~~

  管理:沒有具體的項目和自己的團隊,主要是協助部門管理一些具體任務工作,不進則退了。

  生活:第一個孩子出生,自己長到180斤。

---------2016年前後一年多(2015中下旬-2016年中下旬)

  這一年加入了快遞/物流公司(SF)做銷售、傭金、投訴系統,算是離開外包後最有歸屬感的一年,收獲了很多朋友和同僚。雖然管理上各種限制,但也做了不少嘗試,在技術和一些認知上都得到了很大的成長。

  總結這一年,大環境下一定要找到靠山I(心腹),互相拉扯才能生存的很好,反之則事事莫名其妙。

  技術和管理:主要從事公司投訴系統、傭金計算系統、銷售支援平台的開發和管理工作:

    投訴系統,一套ExtJS+Struts2+Spring+ibatis+Oracle比較老的系統,經過N多個人手之後,項目沒有技術文檔沉澱,更沒有什麼架構、資料庫、接口之類的文檔,全部從看代碼開始。同一個資料對象每個人都會寫一個實體類,最終導緻新增或修改需求無從下手的地步。期間完成投訴報表改造、問題件改造、工單重構優化等需求開發,主流程算是梳理清楚,後面由于新系統立項火速撤離;

    公司一個蘿蔔一個坑,不是主導的項目,推行改造勢必無果,有機會要盡快撤出。

    心得:維護項目,特别是架構老舊的系統,一定要組織項目成員(特别是新進來的)梳理項目架構圖、業務流程圖、資料庫文檔和固定歸檔需求設計文檔,這樣後續人員流動、項目重構、設計參考都會過的很舒坦。

    傭金系統,當時銷售部門每個月核算傭金都需要幾個人花2周以上的時間,用Excel計算得出,而且存在很多問題。當時基于此背景需要開發一套銷售傭金核算系統,正好公司有幾個人寫了一套基于Easyui+Shiro+SpringMVC+MySQL的背景管理系統通用架構(N架構),該架構集登陸、權限、基礎背景樣式于一身,架構和技術選型上算是非常省心了。我是帶領外包員工完成銷售傭金系統V1.0和V1.1版本傳遞,負責項目計劃制定、跟蹤、外部溝通和部分功能開發工作,是第一次和使用者部門去談需求,體會到使用者需求的不确定性(估計就是這個時候吃虧太多,導緻心眼變多了~~)。

    主要業務流程,

    1、每個月定時通過ETL(Informatica)從各大倉儲、冷運、物流、供應鍊系統拉取億級别資料;

    2、通過資料清洗、過濾、基礎計算處理得到結算傭金資料;

    3、取銷售系統的人員資訊;

    4、系統背景配置銷售門檻、地區分區等級配置,傭金計算規則、傭金重算等;

    5、定時啟動計算(一般要算1天多),或觸發重算;

    6、Webservice推送計算結果;

    該系統傳遞2個版本後,銷售團隊傭金算法調整,項目被挂起,待新的傭金政策定型後再啟動。

    心得:使用者部門溝通需求不要立馬下結論,所有形成的結論一定要最終郵件确認;使用者未驗證或者實操的業務不要急于做到系統,尤其是涉及到錢的,否則會很折騰;

    銷售系統,之前公司銷售團隊是在外面買了個大系統,隻用了其中CRM管理一小塊功能(整個系統10%不到),其中二次開發各種限制,收費非常高。

    公司也一直想操刀自主開發一套CRM系統,當時我正幫倉配部門那邊開發一套基于Echarts的報表系統(幾天就搞完了沒啥可講的),當時傭金系統停擺,和使用者部門溝通進展不大,就被拉到這個項目。

    這是我第一次接觸到類網際網路模式項目,從前期的使用者故事(角色錄音挺有意思的)、彙報、立項、招人、系統選型等等,之前沒有經曆過(現在想想錯過了很多機會)。

    當時樓上有個部門使用Dubbox架構完成了Basic傳遞,在業界也算比較好的微服務架構了。我和另外一個同僚主導項目背景研發,他去樓上學習微服務架構,我則帶人主導管理系統開發,空降了一個網際網路公司經理做項目管理。

    銷售系統架構,前端是Android+IOS+H5(原生套H5)的方式,背景是Dubbox外加上面的N架構做背景管理,其實微服務架構搭好後主要是服務拆分和業務組合處理費事,其他都是現成的随架構內建就好,開源架構這一塊沒啥可講的。

    心得:項目合适的架構選型會要少走很多彎路,要善于重構和嘗試。持續內建和持續傳遞上還得下功夫。

  生活:這一年生活上非常充實,住在深圳最大的城中村,離公司隻有6公裡,離海邊隻有3公裡不到,在悅跑圈建立了跑團,帶同僚各種跑,基本上每個星期都有跑步活動。

  在淘寶買了個山地車,天天上下班日曬雨淋、淩晨更新職守都騎着它,偶爾從海邊繞路騎回家,非常釋放壓力。

  周末用買的面包機做面包和饅頭,晚上跑步去海邊,這一年我從180斤減到140多斤(不去健身房減掉35斤多)。

4年一輪回(前部)
4年一輪回(前部)
4年一輪回(前部)