十年風雨，一個普通程式設計師的成長之路（五）
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點多了，今天寫不完了，下篇寫吧。
四、失去：生活與生存
同上。