十年風雨,一個普通程式設計師的成長之路(五)

妖生發表於2019-06-10

十年風雨,一個普通程式設計師的成長之路(五)

author 妖生
date 2019.06.09

成長、抉擇與失去(上)

一、前言:生活的演變

在14年到18年間,我的生活中經歷了喜樂悲喪,結婚、生子,爺爺的去世,老趙的病逝。
在個人職位上,則從開發組長到專案經理,慚愧的是,是老趙因病離職才給了我這個機會。
專案經歷上,在這幾年裡,歷經核心徵管、管理決策、金三改造、資料遷移、大資料開發、稅警交換等各種專案。
專案型別有OLTP、OLAP,有接手維護的,有重構的,還有從零開始的。

其中涉及的技術棧則讓我見證了公司從遠古到近代的演變:

  • ORM從datawindown、ormap到ibatis、Mybaits
  • framework從自研的sm@rtFrame到spring、springboot
  • 打包工具從ant到maven、gradle
  • 前端渲染從HTC到freemark、jQuery+layui、antdesign
  • 資料儲存從Oracle11g到12c、mpp、noSql、hadoop、elasticsearch
  • 資料處理從kettle、ogg到sqlloader、kafka、flum、mapreduce、storm、spark
  • 系統架構從SOA的垂直分離到整合服務又到微服務
  • 服務管理從ESB到API閘道器

那麼,在這些年裡,主要做了些什麼?又學到了些什麼呢?

現在想想,好像大多都記不得了。只挑印象最深的幾件事來說吧。
有正面,也有反例。
總結一下,便是得到與教訓吧。

二、成長:得到與教訓

2.1 計劃制定與執行

有意識地參與工作計劃的制定,分解里程碑計劃與每週計劃,正確認識團隊協作中每個人能力的不同,合理安排人員計劃,並跟蹤執行a。

為什麼推薦周計劃?

這裡說說為什麼是周計劃,而不是天計劃、月計劃?按天的計劃太有壓迫性,容易讓開發人員思維緊張,每日跟蹤也太浪費時間;而超過一週的計劃則太過寬鬆,會在中途導致不可預估的風險,增加調整難度。

怎樣為不同的成員分配合理的工作量?

在工作計劃的制定中,很多技術人員在做team leader 後有一個通病,總是以自己的能力來衡量他人,導致產生不可預知的風險。

為什麼一定要跟蹤計劃?

計劃制定後,對於計劃的執行則需要隨時跟蹤,監控前後變化,預估風險。計劃在週五晚彙總,但並不意味著中途不予過問,最好的時間應該在週三時跟蹤下計劃執行情況,對於開發人員沒有比較大的壓迫感,又能及時溝通不能按時完成的風險,進行調整。

吐槽
  • 站立會
    在有些公司的最佳實踐中,還包含了早(晚)站立會,實際上我是有些看不起的,因為一個teamleader連十人內的人員進度情況都不能隨時掌握,有點脫離群眾了。

  • 屁股與腦袋
    在職位晉升後,有些人的腦袋似乎便被屁股所掌握,忘記了曾經在所吐槽的人和制度。

得到

在每次周計劃的跟蹤中,摸清團隊成員的能力上限,給團隊人員多一點點但不要超過太多的工作量。
在里程碑的進度跟蹤上,需要在專案進度與人員成長、工作強度(加班)之間作平衡,考驗team leader的內部帶團能力。
在位置調換後,你有時會理解以前吐槽段子中的領導為何有這樣那樣的安排。
只是,不忘初心,砥礪前行。

教訓

如果有資源缺失的情況,千萬不要自己背,例如這個成員能力差了點、那個技術路線有點風險,特別涉及到外部資源協調的情況,要及時上報,爭取資源。

不要覺得這算什麼,我自己加班搞兩個小時就搞定了。一是把自己累死,二是有苦勞沒功勞。

事情壓在手裡萬一沒解決的情況下,導致進度受挫,損失的是公司的錢、領導的信任、團隊的士氣。

2.2 個人能力提升

從前端到後端,從業務系統的開發到服務部署,從需求溝通到資料模型設計,從專案售前到專案立項。不知不覺就成了所謂的全棧工程師。

得到
專業技能上的廣度與深度有什麼提升?

廣度

  • 語言
    JavaScript、java、python
  • 前端
    中臺web、移動H5、小程式;
  • 交付
    CI/CD概念及工具、ant/maven/gradle
  • 服務容器
    weblogic、tomcat、nginx;
  • linux系統
    redhat、centOS、Ubuntu
  • 虛擬化
    OpenStack、KVM、VMware、docker
  • 測試
    用例、計劃與報告,冒煙、覆蓋與迴歸,人工、自動化,功能、安全與效能
  • 效能
    CPU、記憶體與IO,程式、執行緒與管道,QPS、TPS與PV,壓力、負載、穩定性

深度
而深度上,對我提升最大的應該是Oracle,這也是得益於老趙對我們的技術分享,記得那次分享還推薦了一本書——《收貨,不只是oracle》。
掌握了例項、表空間、使用者、表結構設計、索引優化、系統表、redo、flush、DBF檔案及IMPDP/EXPDP、AWR報告等oracle的理論及相關工具並予以實踐,此時再去看諸如mysql等其他結構及非結構化的資料庫,easy。

掌握了哪些業務能力?

歷經申報、徵收、登記、發票、文書等核心徵管業務,又掌握了些後設資料、資料倉儲、資料處理、資料質量、資料分析的理念設計以及相關的一些工具。
與客戶溝通的時候什麼都能說上一點吧。

專案管理的一些軟技能

參與並主導專案售前、投標、立項到專案啟動、執行、上線、運維等一系列專案活動。
從一開始的專案意向溝通,原始需求的收集、分析到編寫需求規格說明書,設計介面原型,然後是投標書中的技術指標編寫與稽核,專案立項與公司流程的稽核,專案中途的程式碼與文件審計,專案上線前的等保評測、安全加固等等,不一而足。

  • 效率工具

這裡用到的幾個專業工具倒是可以說下,office2016套裝且不說了。
介面原型設計推薦Axure + antDesign,
流程及架構設計則推薦線上工具ProcessOn(本地則是visio、PPT),
思維導圖及團隊協作也可以使用ProcessOn(本地則是xmind + excel),
資料模型設計我也用的是ProcessOn(本地則可以用powerdesign)。

原諒我,成了ProcessOn腦殘粉,好用上癮(笑)。

吐槽

有時候轉到管理崗很難再有精力繼續做技術,如果還有顆做技術的心,關注開源,保持技術敏感性。

教訓
  • 原型設計

原型很重要!
原型很重要!
原型很重要!

所謂一圖勝千言,有時候客戶自己都不明白自己想要什麼,總是說“你先做一版出來看看吧”。
懵逼了嗎?

在跟客戶確認三輪需求之前,不要做,不要做,不要做!
壓力再大都不要真正地投入人力開始幹。
除非,你是政治任務。

  • 協調管理

對於客戶、上級、第三方要善於管理,及時同步相關資訊,務必不要讓專案干係人產生資訊差,導致目標與進度的偏離。

對於客戶,如有進度偏差,及時取得溝通諒解。有問題不上報,出了事就是個炸彈,為什麼不被叼?心裡沒點數嗎?
但是溝通又要有技巧,我在這方面乏善可陳,所以經常因為說話不夠藝術,而被叼。
而且每週都應該跟客戶碰面,對於進度中的業務需求演示與確認,讓客戶有參與感。特別涉及企事業多部門單位的協作專案時,客戶沒有參與感,是不會主動去幫你解決問題的。你拿錢辦事,不應該嗎?

對於上級,及時彙報進度與風險,有一些問題無法解決時,不要給上級做填空題,而是選擇題。甚至在沒問題的時候,也要從專案中找一些選擇題給領導做一下,讓領導有參與感。
但是在專案之內的事情,其實作為上級應該儘量做到不要越級插手。老蔣就是這麼丟的江山,不是嗎?
任正非都說了,砍掉高層的手腳,砍掉中層的屁股,砍掉基層的腦袋。
這說的什麼意思?高階領導不要親力親為、指手畫腳、越級幹活。
在我之前的公司中,有個總監什麼都好,就是做事太過親力親為、鉅細無遺,導致下屬的專案經理直接變成了專案助理,毫無動力。多做多錯,聽命令就好了嘛,對不對?
中層不要為了自己的小團體做打算、不顧公司利益。
在我經歷的幾個專案中,有些研發、測試、運維的leader都打著自己的一套小算盤,不以專案目標為導向,而是以自己不背鍋為導向。這樣能把事做好嗎?

對於第三方,上游公司且不說,在多數為協作外包方的公司,應及時盯緊進度,需要對方按照里程碑計劃提供專案交付物,並在中途予以真實系統演示。否則,你作為總包方,客戶叼的不是分包方,而是你。畢竟,投標、收錢的都是你啊。

2.3 團隊能力培養

每週一次的技術分享,兩週一次的程式碼檢查,每月一次的專案總結。良好的工作氛圍,友善的同事關係,愉快的工作心情。

實際上在工作的幾年中,最自豪的並非是完成了多少專案,而是可以在自己學會某些東西后,能分享給團隊裡的兄弟,在將某個專案掌握好後,能很快丟給兄弟們,並讓他們也可以獨當一面。

從來不想做什麼不可替代,如果某個人不可替代,那麼意味著公司的大風險。

也不想用公司的條條框框把人養廢,那樣哪天從公司出去了就會毫無競爭力。

得到

我自豪的是,從我們專案組出去的,不管是去公司總部還是其他地方專案組,都能很快獨當一面,成為核心骨幹。

我自豪的是,在我任專案經理期間,大家成長飛快,並且感情甚篤。在18年,大家都陸陸續續從公司離開後(我也在17下半年離任了專案經理),我們都各自成為了不同公司的團隊leader,還是會偶爾聚會,吹牛喝酒,懷念當年。

教訓

實際上技術分享 程式碼檢查 專案總結這些沒有能很好地執行下去。除了專案經理外沒有擁有足夠威望的人監督執行。有些事情一拖,便不了了之。

在成員關係上,每個同事也都有自己的稜角,能保證質量的完成任務就行了,沒必要去要求相親相愛。強行彌合,反而更不痛快。

三、抉擇:管理與技術

在一個公司/團隊/專案組中,有了一定資歷後,是繼續做技術崗還是轉為管理崗?
有時候被迫或被動地轉為管理崗怎麼辦?
到了一定年齡,還能不能繼續做技術?
還是要受專案經理的指手畫腳嗎?
技術研發、技術管理、專案管理,怎麼選?哪個適合自己?

12點多了,今天寫不完了,下篇寫吧。

四、失去:生活與生存

同上。

相關文章